Flex 4

June 7th, 2010 by Mike Oldham

Intro:

Simply put, Todd is a Flex and AIR guru. He has written three books on the topic – most recently the Flex 4 Cookbook (in stores now!). Todd has been working with Flex since its early days and he’s always ready to take on extremely complex projects. When he’s not coding, he collects and digitizes old vinyl and enjoys riding his bike to work. We finally cornered Todd earlier this month to ask him some questions about the Flex 4 release and his thoughts on the future of the technology.


Q: Why do you like working with Flex?

I was dragged into the Flex world kicking and screaming many years ago as a diehard ActionScript developer who thought there was nothing Flex could provide that ActionScript couldn’t. In some respects that is true, but it didn’t take long for me to warm up to Flex after seeing the power it provided with regards to dynamic layout, custom skinning and data binding. Those three aspects of the SDK (layout, skins and data binding) are the most compelling reasons for me to use Flex in a project. Coupled with the mark-up language (MXML) to quickly develop and easily read the visual makeup of the User Interface, the API provides the ability to architect applications with a clearer separation of responsibilities.

Q: What are some of the best new features of Flex 4?

There are quite a few, and they get lost in details because of the large change in the architecture of components. One of the biggest improvements is the separation of container and layout logic. The MX components from Flex 3 and previous versions of the SDK often hold logic for visual representation, user interaction and layout. That is a lot of responsibility for a single component, which was often seen in the rendering lifecycle in larger applications if not taken into account during architecture. Not to mention that this marriage of responsibilities often resulted in multiple flavors of roughly the same component with slight differences to change the context (ie. HBox and VBox). The separation of these concerns in the Spark architecture of Flex 4 is a huge boost not only in development time but also in getting the developer to rethink the visual architecture of what is driving the user to use the application.

With that said, I also have to mention the new Skin architecture for Flex 4 which is leaps and bounds above the previous implementation which involved programmatic skins in ActionScript married with style declarations. Style declarations are still present in the Spark Skin architecture, but now you can layout the visual representation of a component easily in the MXML markup.

The Spark architecture is clearer in the separation of responsibilities and is a huge boost to not only productivity in development but also to the lifecycle of the application.

Q: What are some of the best Flex apps you have seen?

The best Flex applications I have seen are ones that I had no idea, or rather didn’t care, if they were built using Flex. Both eBay Desktop and FineTune are two excellent applications that marry the the Flex framework with Adobe AIR capabilities and provide some nice eye-candy polish. From a platform perspective with a suite of applications, Brightcove has done a beautiful job on presenting a look and feel across administration and presentation of a product. Last but not least, SpatialKey sticks out as one of the best Flex applications I have ever seen. A beautiful marriage of information and engaging visual data.

Q: What are the most complex Flex apps you’ve worked on and why were they a challenge?

There are two main aspects of an application that always bring challenges to development and architecture: the complexity of state and the consumption and presentation of data. Couple that with real-time push of a large amount of data from a streaming server, and I would have to say that the SICK desktop console is the most complex application I have worked on. Challenging and highly rewarding to develop for, but complex none the less in managing continual updates to real-time data while maintaining a low rendering cycle to keep the application responsive to user interaction of filtering data.

Maintaining the user experience is the main goal of any application on any platform. So the complexity comes in when architecting a large application that is meant to handle and present visual information to a user while still being snappy and responsive. This also involves thinking about at what level of knowledge the application knows about itself, which should always be addressed at the beginning of a project as it plays a significant role in architecture. Some of the more complex applications I have built have been for the Entertainment industry and involved thinking about the self-awareness of the application in relation to the data it is presenting and reporting.

Q: What’s the future of Flex in your opinion?

The future of applications, I think we can all agree, is mobile. So that realm is definitely on the horizon and I am excited to see what Flex can bring to it. The dynamic layout capabilities from the Flex platform make targeting different mobile displays relatively easy and the new architecture available in Flex 4 brings along a huge improvement to the rendering cycle of components that will prove to be beneficial when running on devices with less memory.

Flex ultimately is tied to the Flash Platform, the future of which can be talked about at length with a list of hopeful features and API changes. But in addressing the future of the Flex SDK itself, we’ll just have to wait and see. Mobile is huge, and I think we will see a lot of improvements to the lifecycle of Flex components to maintain a consistent user experience on smaller devices. That might involve pushing some core Flex classes to the player level, who knows. The future is bright.

Plug: Todd co-authored the new Flex 4 Cookbook and is available in stores now.

, ,

Leave a Reply