Simeon Says

Now that the Flash Builder and Flash Catalyst betas have been released on labs, we are going to see a huge influx of people taking their first look at what Flex 4 has to offer. Many of them are going to be migrating from Flex 3 and they are going to see a lot of changes about how things work. Concepts that were very familiar in Flex 2 and 3 are now overlayed with new options that make cause for a lot of study. So what really has changed about Flex 4? I believe there are 2 themes that need to be discussed to answer that question.

The first theme is the idea of what Flex is. For every release up until this point there has been this concept of a namespace. We were required to declare the mx prefix and alias it to a URI for Flex. We have always done it, it was required, but not many have dug into what that is actually doing for us. At the bare minimum it references a manifest file which has a list of components that should be included in the library associated with the prefix. But at a deeper level you are also selecting what version of the MXML language you were using. Because in every single previous release there was only one MXML language available and one component set available for the release, we only had to declare one namespace. But in that regard Flex 4 is completely different. When you consider Flex 4 its not just one MXML version and one component library. In fact when working with the Flex 4 SDK you have three (3) languages (MXML 2006, MXML 2009 and FXG 2008 )available and two (2) visual component libraries (Halo and Spark) to choose from. The fact that we have lost that one-to-one pairing necessitates the use of multiple namespaces to make use of all these features. You will choose from the primary MXML language namespace and then potentially include a second namespace which accesses the component library of your choice. However the beauty of this is that MXML 2006 and MXML 2009 languages can be intermixed when using the Flex 4 SDK. The primary note to take away with theme 1 is the version of the framework you use is no longer as important to the version of the MXML language you choose as your base.

The second theme is about leveling the playing field around implementation. In the MXML 2009 language and in the Spark component set, I think the greatest achievements have been the ones that allow us to adapt and build components without having to override core built in behaviors. A perfect and wonderfully simple example of this is skinning. The skins for the visual components in Spark assign their initial UI in exactly the same manner we use to override it. That is the full visual implementation of a component is in a Skin class which we can copy, or completely replace. The life cycle for components has been adjusted so that we can very easily replace the built in skins with our owns, and we have been given the visual tools required to build those skins. In that same manner Adobe has opened the door for alternate UI frameworks to live right along side the built in Halo and Spark component sets. By separating the language from the list of component implementations you can now choose to use MXML with Spark and Halo, or with a completely separate UI framework like OpenFlux or OpenPyro. These UI frameworks can take full advantage of the MXML language for layout, but without having to be built on top of the existing Halo components to be displayed. This is an amazing treat and something that could allow us to truly take the Flex SDK and MXML as a language beyond the boundaries we currently abide by. It is completely feasible that we could create a component framework specifically for mobile that takes advantage of FP 10 in the browser of mobile handsets and through devices on the Open Screen Project.

In the end I think its important to keep in mind that Flex 4 is not just an increment in the version number. It is truly a step forward for the framework in terms of openness, functionality and design. The upgrade may cause some changing in how you relate to it, but it is all for the best.