In this post, Doug McCune, Flex community rock star and author of Flex for Dummies, discusses the Flex landscape and shares his insights on building custom components in Flex. In addition, he talks about what is coming in Flex 4 and how the community has changed in the last few years.
InfoQ first asked Doug about what he has been up to lately:
I've been hard at work at Universal Mind on a product called SpatialKey (spatialkey.com) that is a Flex application for geospatial analysis and business intelligence. We're trying to take all that data that people have locked away in spreadsheets and really open it up to deeper analysis. So if you've got an Excel file full of 50,000 data points, say sales transactions, you can upload that file and use SpatialKey to see your data on a map, broken down in a timeline over the past year, or even grouped by hour of day to see what's occurring during the daytime versus the night.
In addition to the work that pays the bills, I've been playing around with some fun open source projects. I'm trying to get ready for a talk I'm giving at 360|Flex in Indianapolis in May. My talk is titled "Cool Shit" and will involve me showing off experiments that have gotten me to rediscover the playful and experimental fun side of Flex and ActionScript. I've been doing a lot of work recently on facial recognition and live face tracking. I've also been paying close attention to a lot of the augmented reality work that people have been doing with Flash, and I hope to have some pretty cool augmented reality experiments cooked up.
With Doug's reputation for building cool user interface features and applications like SpatialKey, InfoQ asked Doug if he believes there are opportunities to leverage the cool sides of Flex within typical business applications:
Enterprise software is almost uniformly horrible, but there's no reason for that. We're seeing a "UX revolution" in RIA design, and for all the buzzword nonsense surrounding "user experience, " there's something real happening in terms of the overall quality of the experience delivered by RIAs. We've seen some really great and innovative work in consumer RIAs, with a trend toward simple and intuitive interfaces. And yet in enterprise software this trend has barely even begun, it's all still complex. I want to see enterprise applications treated like consumer apps, with the same attention to the user experience and with a consistent drive to simplify and make everything more intuitive. Complex systems don't have to be presented with confusing software. But it takes more work to figure out the simple, elegant solution. It's far cheaper and faster to make bad complex software than good simple software.
I also think there's a business intelligence breakthrough afoot that will bring these same concepts of intuitive software specifically to the BI arena. Business intelligence is just a fancy way of saying that you're extracting value from raw data in some way. This is typically limited to your mundane set of charts, gauges, and all the other normal dashboard UI elements that are the current standard. But I think thinking about BI problems from a fresh perspective, from the perspective of someone outside the enterprise space, will lead to the invention of new visualization methods. Maybe sales performance isn't something best shown using a silly looking speedometer gauge. Maybe there's an intuitive way to extract more value from that heap of raw data sitting on enterprise servers. But I don't think enterprise developers have been willing enough to experiment with new concepts. People need to start inventing.
Next, Doug was asked how building custom components in Flex compares with other languages / frameworks:
To be fair, I don't have a lot of experience with custom component development with other languages apart from ActionScript. I started my web development career by dabbling in Flash and HTML development, but this was a bit before the rise of the popular JavaScript frameworks, so that meant that any custom AJAX component you wanted to write had to be written from scratch. Since then, there have been a bunch of JavaScript frameworks that try to take a lot of the pain away from AJAX development, but when I was really first starting to learn about UI component development and was making the choice between AJAX and Flash, developing components in JavaScript just didn't seem like a viable choice. I'd love to catch up on the developments that have happened in the JavaScript community over the past few years, especially in terms of the IDE options and all the component libraries.
The official open-sourcing of the Flex SDK makes the Flex framework one of the most accessible ways to start doing custom UI component development, in my opinion. I think the fact that Adobe/Macromedia always released the full source code of the Flex framework (even before it was officially open source) has had a huge positive impact on the product and the development community. I think people are intimidated by the size of the Flex framework, and granted, it is a lot of code, but it's not as daunting as people think. It's incredibly well documented and well thought out.
InfoQ then asked, what parts of the Flex framework a developer should focus on learning if they want to learn how to build quality custom components?
Any of the "smaller" components in the Flex framework are great learning resources. I say small in quotes because all components are based on the UIComponent class, and that class alone is one of the largest in the Flex framework, since it's responsible for the whole invalidation and validation process. But the best part about the Flex framework is that it's all open source, so if you wonder how the Adobe engineers went about creating anything in particular you can jump straight into the code and find out (which is literally as easy as holding down the Control key in Flex Builder and clicking on any class). Taking a look at the Button class is a good way to start to understand the basics of a component, and then seeing what gets added with the ComboBox (which extends Button) or CheckBox (which also extends Button) is really valuable, so you start to get a sense of why you extend classes and what kind of functionality you can build on top of existing components.
When Flex was first released there weren't that many resources on how to do your own custom component development. You really had to read the little documentation provided and then dive straight into the Flex source code and figure it out for yourself. But now there are tons of resources on component development, and there have been some fantastic presentations. Each time I watch a presentation on custom Flex component development, I think they keep getting clearer and more succinct. Deepa Subramaniam gave a great one at MAX that covered the component lifecycle of Flex 3 and the new component architecture of Flex 4 (you can watch that video online).
Next, Doug shared common mistakes he sees in how others approach custom component development:
Not having a really thorough understanding of the component lifecycle is probably the biggest problem people have. This is something that takes a while to master, and it's pretty specific to Flex and also to the way the underlying Flash Player works. I even gave a talk at a Flex conference and got called out on the fact that I didn't know the right way to use some of the invalidation routines (which was completely true). It's one of those topics that just takes a bit of drilling into your brain and reading lots and lots of example code to really understand. In particular, the use of the invalidateProperties and commitProperties methods often trip people up (that certainly tripped me up).
The other big difficulty that I see when people are trying to learn to create their own custom components is that they haven't spent the time to read through the underlying source code to really understand how the base classes work. If you're doing something like extending the List classes, then you absolutely have to be comfortable with the stuff that's going on under the hood of all the List classes you're building on top of (and this stuff can get very complex). You don't have to know every line of the Flex framework inside out, but you have to be comfortable diving into the Adobe code to find your problem. If you're not comfortable reaching way down into the source code to debug an issue, then you'll hit brick wall after brick wall.
InfoQ asked about what has him most excited about Flex 4:
Like a lot of Flex developers who have done lots of custom component development, when the plans for the Flex 4 component architecture were first announced I breathed a big sigh and just said "yeah, now that's a better way to do it." The current Flex 3 codebase is very powerful, but when you do a lot of custom development you start seeing the same problematic areas come up over and over. The Flex 4 codebase is being created after learning what worked and what didn't in Flex 2 and 3. So, I'm most excited about the different mentality that it will bring when developing components.
I think Flex developers, and people specializing in component development in particular, are sort of holding their breath waiting to see how Flex 4 starts shaping up and when they feel ready to get their feet wet. Adobe is pretty amazing about giving the community bleeding edge access to the work they're doing. I can check out the latest build of the Flex 4 SDK from Adobe's source control repository and get the latest code, which is as up-to-date as the internal Adobe engineers have access to. That's pretty amazing, but I think it's also daunting to Flex developers while the Flex 4 release is still so far away and the code is changing so much. I certainly hope that in the next 6 months, as Flex 4 becomes more mature, Flex developers (myself included) will really start to get their hands dirty with the new component set.
Then, InfoQ asked what Doug was most concerned about that is coming in Flex 4:
I'm probably most concerned about Flash Catalyst and the kind of code that the tool will produce. Catalyst is meant to allow designers to drag and drop beautiful artwork and wire up working Flex applications without needing to write code. That always scares the hell out of me. I've never once seen good code produced by something other than a good programmer writing the code by hand. Code generators, WSYWIG editors, they all produce hideous code that has to be reworked by a programmer who knows how to deal with it. On the one hand, I work for a consulting company, and bad generated code just means more business (although not the type of business we want to be doing). I really do hope that the Catalyst to Flex Builder (and back) workflow is a harmonious nirvana of designer-developer bliss, but I must say I'm really cynical. But I should really hold my tongue until I see some more advanced builds of Catalyst to give it a fair review. I may very well be gloriously surprised.
Next, InfoQ asked how Flex development and the community have changed in the last 2 years:
It's been a wild ride for the past few years. About two or three years ago, it was like the Wild West in the Flex community. Everyone was learning at the same time, everyone was hungry to show off. I got incredibly lucky and caught a very exciting wave at precisely the right moment. I think in general (and I know for me personally) things have settled down a bit as Flex adoption has grown, and as we've all gotten busy with doing Flex development as real full-time work. And the shear size of the community has changed a lot. It used to be that everyone on the flexcoders mailing list knew each other by first name. There are now just so many more people learning Flex, that the number of new voices is impossible to keep up with. This is great, since it means that Flex is being used by a much wider audience, but it also makes me a bit nostalgic.
Finally, Doug was asked for words of wisdom for other Flex developers:
Make cool shit. Find the time to experiment. I want to see stuff that blows me away, stuff that makes me envious, stuff that makes me want to compete. Make something so damn cool that all other developers can't sleep at night because they want to make something just as awesome.
Learn more from Doug at his blog: http://dougmccune.com.