by James Polanco
Back in 2007, Adobe announced its plans to make Adobe Flex open source under the Mozilla Public License. This includes not only the source code for the ActionScript components from the Flex SDK, but also the Java source code for the ActionScript and MXML compilers, the ActionScript debugger, and the core ActionScript libraries from the SDK. Fast-forward to 2009: the Flex Gumbo SDK and compiler is fully open source, and the team has begun the process of publishing technical specifications and white papers on the future of Flex components. Because of this transparency of development, we now have the visibility to explore the next version of Flex (codenamed "Gumbo") well before the beta versions are available.
In this article, I examine how the Flex team is changing the fundamental architecture of components, how this new structure is going to change the process of stylizing the components, and how it will affect the way we work.
With today's Flex 3 component architecture, applying highly stylized designs and/or functionality requires both an intimate knowledge of how the components are structured and proficiency with ActionScript.
For example, let's say I want to create a button that performs a cross-fade from the Up state to the Over state as I roll my mouse over it. In Flex 3, this is not a built-in behavior of the Button component. To implement the design requirement, I would have to first create a new programmatic skin that handles the different state changes; the skin is also responsible for managing the tween to create the fade. This is by no means a simple feat to accomplish, and for a developer, this could take anywhere from a few hours to a few days depending on your understanding of the component structure and how complex the design requirements are.
Because Flex 3 requires a lot of code to solve a rather simple design requirement, we have seen the process of skinning components become one of the most time-consuming processes of Flex development. The further the design pushes away from the default UI behavior, the more time and development investment is required. This also means that as design requirements change, a project involves much more than simply updating the UI. Often you have to spend more time in the code to meet the design change.
The Flex component team has heard the community talk about these issues and is in the process of designing a new skinning and component architecture, codenamed "Spark." The focus of Spark is to separate the layout from the logic as much as possible. With Flex 3, much of the layout is intertwined within the ActionScript class, which is why Flex developers have to spend so much time in the code.
With Gumbo, the component team has introduced the concept of a skin class. This skin class is an MXML file that defines the look and feel of a component. Not only does it define layout but it also allows for the creation of transitions and effects within the skin file, which enables rich and complex interactions without requiring additional ActionScript code to meet the design needs.
Note: At press time, new Spark components are using an Fx prefix. This means that the newly architected Button component would be FxButton. The Flex 3 Halo components are still available and can be used in Gumbo. The Halo components do not use the prefix, so the button component would be Button.
To create a clear separation between layout and function, a component needs to establish touch points that enable the design to hook into the functionality. There are four main touch points that all Spark components need:
Let's take a more in-depth look at these touch points and examine how the Spark architecture implements them.
Skin states define the different looks of a component. An FxButton component has four states: Up, Down, Over, and Disabled (see Figure 1). This means that the ActionScript code will inform the component skin class when the components state changes. With an FxButton, the ActionScript code would listen for the mouse over, mouse out, and mouse down events. When these events occur, the code would change the component state to the matching look. For example, a mouse over event would set the component state to Over.
Figure 1. Skin states of a component.
A skin class can then leverage the new MXML state syntax to enable designers and developers to create different looks and layouts within the component. When the component state changes, from Up to Over, this tells the Skin class to change from the Up state to the Over state.
By exposing state changes to the skin class, Flex now enables you to tie into MXML state transitions, so that when you want to fade from the Up state to the Over state in an FxButton, it's as simple as defining an MXML transition. This also means that you can fundamentally change the look and layout for any state that is exposed in the component without relying on ActionScript.
Skin parts are elements that make up the component. The button example has one skin part: the text label. In my presentations at the Adobe MAX conference, I used a video player as a component example. Coincidently, this is the same component example that Deepa Subramaniam used during her session on the future of Flex components.
We all understand the basics of how a video player UI works (thanks to YouTube), so it's a good example. A video player's skin parts include the video window, play/pause button, volume control, scrub bar, and full screen (see Figure 2).
Figure 2. Video player user interface controls.
There are two types of skin parts in a component: required and optional. Required skin parts tell the skin that they must have this element in the MXML layout. In the video player example, the required skin part is the video window. For optional parts, it's at the skin's discretion how to use the part. With an FxButton, the label field is optional. With our video player, all the other parts are likely optional.
The data element of a component defines what information is available to the skin and how it is exposed. In an FxButton, the data element is the text property that is displayed in the label (or however you want to show it in your skin).
The video player could also have a total time field, a time remaining field, a title, and so forth. ActionScript exposes this data to the skin as bindable. This way, the skin can tie directly into the component and when the ActionScript code changes, the value (such as time remaining) is updated in the UI.
The last element of a Spark component is the metadata. The metadata is the glue that binds the skin to the logic and helps tools, such as Adobe Flex Builder and recently announced Flash Catalyst, display information about the component to the user. Without metadata, we would not know what elements are skin parts or whether the skin part is required or optional.
Metadata is a set of special tags for ActionScript and MXML that tell the tools and the compiler specific details about the code that may not be apparent by simply reading it. Metadata is not a new concept in Flex. In fact, it has been around since Flex 1.0. When you mark a property or a method as [Bindable], you are using metadata.
Gumbo introduces a few new metadata types, but two are very important to Spark components: SkinState and SkinPart. By using this metadata, you can define exactly what properties make up your parts and whether they are required or optional:
[SkinPart(required="false")] /** * A skin part that defines the label of the button. */ public var labelField:TextGraphicElement;
You can also define which states our component can go into:
[SkinStates("up", "over", "down", "disabled")]
As I mentioned earlier, tools can read metadata and give hints or change their UI depending on the provided metadata. A great example of this is how Flash Catalyst shows you the different states in the UI. If you select a button in Catalyst, you will see the four different states (Up, Down, Over, Disabled) in the UI. This is all driven by metadata in the Flex Gumbo SDK. Without it, Flash Catalyst would not know what the states are or how to generate the proper MXML to meet the skin's needs.
This is just a brief look at where Spark is taking components. I am personally excited about this new structure because I can see how it will streamline the development and design process for creating Flex applications. The best thing about Gumbo is that it's open source, and you can read up on the new architecture and the component set the development team is building for the final release. I encourage you to read more about Gumbo, download the Flex Gumbo SDK, and try building some components to learn how the new architecture will help you and your team in the future.
James Polanco is the co-founder of DevelopmentArc, a boutique consulting firm that specializes in web application and user interaction front-end development. James specializes in application development and has provided system architecture and code development on projects such as Scion.com, Toyota.com, and Adobe® kuler Desktop. James was also a Senior QE Team Lead on the Adobe® Flex® Builder™ team focusing on ActionScript® 3.0 development harnesses and automated testing systems.