Overview of custom component
changes in Adobe Flex 4 beta

by Thomas Ortega II

On June 1, 2009, Adobe Labs released betas of Flex 4 (codenamed Gumbo), Flash Builder (previously named Flex Builder), and Flash Catalyst (codenamed Thermo). With the introduction of these new tools comes a new way to work when building applications in Flex.

In this article, I explain some important changes to Flex component building. Some of the concepts may seem complex at first glance because they are so powerful, but once you understand them, you'll quickly realize how they can speed up your production process.

I start with the foundation changes, covering advancements in the core base classes and component layout mechanisms. This shows you what types of things you can build and how applications can be designed. Next, I cover the changes in the workflow between designers and developers, including skins and states as well as the metadata that lets the skins talk to the components. Last, I discuss namespaces, specifically what all the fuss is about and what it means for you.

Foundation changes: New base classes and layouts

In the past, you could create a custom component one of two ways. The typical way was to take the class that was a close approximation of what you wanted and extend it. The other way, which advanced users often used, was to extend the basic core class of the Flex framework: UIComponent. While both methods worked, neither was perfect. Each had its own set of strengths and weaknesses. Flex 4 aims to change that with two new base classes: SkinnableComponent and Group.

One of the biggest complaints about Flex is how heavy components need to be. Unless you specifically write all your components from scratch based on UIComponent, your applications can quickly get bogged down. One reason is because there is no clear delineation between skinnable and nonskinnable objects. The thinking seemed to be: Why wouldn't you want to skin an object? Flex applications are supposed to be rich and beautiful. While that's true for the most part, there are times when you have to display say 100,000 pieces of data on-screen, and you don't want pretty — you just want fast. The new Group class makes that possible (see Figure 1).

The specs of the new Group class.

Figure 1. The specs of the new Group class.

SkinnableComponent was obviously created for components that will be skinned to look pretty. Most of the new components in Flex 4 extend Skinnable Component, such as Button and TextInput. A natural extension of this class is the new SkinnableContainer.

The remaining two important base classes are MXMLComponent and SparkSkin, both of which are subclasses of the new Group Class. MXMLComponent is what most developers will use to build their custom components. It enables them to define and style their components all within the same MXML file. The SparkSkin component is the opposite. It is the companion class to the SkinnableComponent and SkinnableContainer. (I explain more about Spark later in this article.)

The other new core feature is the introduction of layout classes. In Flex 3, the layout was either built into the class (such as Lists) or inherited from the base class (such as components that extended VBox or HBox). This made for limited views of the components. Sure, you could change things up by changing colors or graphics, but there was really no way to change the layout of an object on the fly. When you chose a layout to base your component on, you were stuck with that layout (aside from using the Box class and changing the direction property, but even that was limited to vertical and horizontal).


Layout class descriptions text

Flex 4 comes with a few basic layout classes: BasicLayout, HorizontalLayout, TileLayout, and VerticalLayout. The names are pretty self-explanatory, but the copy block (above) shows the descriptions — direct from the documentation. You can use these classes to swap out the layout property on the new foundation classes listed in the sidebar. The true power lies not in the base classes provided but rather through the new custom layouts that you can create on your own. You can create layouts such as cover flow, fan, stacked, and more. You can then apply those layouts to any custom components you build with the new Flex 4 foundation classes. This helps make the user interfaces of your Flex 4 applications even more innovative.

Designer/developer workflow changes: Metadata, skins, MXML graphics, and states

Now we know we have two new skinnable classes (SkinnableComponent and SkinnableContainer) and one new skin class (SparkSkin). The two types of classes obviously work hand in hand. The skinnable classes need a skin class to tell them how to render because skinning is decoupled in Flex 4 components so that the logic of the component (such as properties and methods) can be completely abstracted from the skin (such as states, colors, and graphics).

How does the skin know which parts of the component need visual representation? And how does the component tell the skin which parts it needs to display? The answer is metadata. By designating a property of your component with the SkinPart metadata, you tell the skin that part of your component is skinnable (see Figure 2). You also have the option to tell the skin whether the particular property is required or not. Take scrollbars, for instance. Some have arrows, and others do not. Your component will dictate all the pieces that can exist.  Your component will dictate all the pieces that can exist.  You also then define which of those pieces are required.

SkinPart metadata from the new Button class.

Figure 2. SkinPart metadata from the new Button class.

While using metadata is nice for creating skin classes manually, this new paradigm offers more powerful functionality. To realize it to its fullest, you need to use a tool such as Adobe Flash Catalyst, which lets you import mockups made with Adobe Photoshop or Illustrator software. You go through the various layers of your application and tell Flash Catalyst which parts are containers, which are buttons, which are scrollbars, and so forth. Flash Catalyst then exports the new component pieces with their skins to Flash Builder where you can add functionality.

Some designers may be thinking, "But wait…my Illustrator file is just a bunch of vector drawings. Are they converted to bitmaps before they're brought into my Flex project?" The answer is no. Along with metadata, there's one more piece of magic that Flex 4 includes: MXML graphics. This is a new drawing framework made specifically for MXML that enables you to declare circles, paths, and lines all within MXML. This means you can draw your button's unique shape within your favorite graphics package and then bring it into your Flex application (see Figure 3).

An excerpt from the new ButtonSkin.mxml class.

Figure 3. An excerpt from the new ButtonSkin.mxml class.

One more workflow change is states. In Flex 3, I only did states in Design view because they were so painful to code. States in Flex 4 are dramatically simpler. The main difference is the way you designate what makes up each state. In Flex 3, you had to define a state and then tell Flex to add and remove children for the state. In Flex 4, you define your states up front. Then, in your skin or component code, you tell it to include or exclude certain parts based on the state. You can also give properties different values depending on the state they are in (see Figure 4).

An example of state-aware properties in the ButtonSkin class.

Figure 4. An example of state-aware properties in the ButtonSkin class.

Namespaces: What's all the fuss about?

Recently, there was a huge online discussion regarding namespaces in Flex 4 that you may have seen discussed in blogs or on Twitter. Let's examine what that discussion was about and what it means for you.

By definition, a namespace is merely an abstract container that holds elements to avoid conflicts and confusion. In other words, break the compound word into its two parts: name and space. Remember in school when you had to write your name on your test so there was a way to track your test back to you after the teacher graded it? Putting your name on the test ensured no one would confuse your test with your neighbor's test, even if you had matching answers (by chance, of course). The same goes for components. You may create a CheckBoxList for your project, but someone else may also create a CheckBoxList component. Without namespaces in Flex, how would you know whose CheckBoxList you wanted to add to your application? Namespaces have been in Flex since day one, but Flex only had one internal namespace it used.

Spark is the name used to define the namespace for all these great new features of Flex 4. Flex 3 and earlier used Halo. The namespaces you see in Flex 4 projects are Spark — represented by s, and the new MXML is represented by fx. The old Halo namespace is represented by the classic mx. As a quick example, in Flex 4 if you want to use the new button class, you type:

<s:Button label="New Flex 4 button"/>

If you want to use the old button class from Flex 3, you type:

<mx:Button label="Old Flex button"/>

In the root tag of your application or component, you see this defining your namespaces:

xmlns:s="library://" xmlns:mx="library://"

In the code above, you can see why we type s: and mx:. Those are the names we're giving those namespaces. Flash Builder just happens to use the arbitrary values s and mx:. If you want, you can change those values to make it look like this:

xmlns:spark="library://" xmlns:halo="library://"

Our button tags would then be rewritten as:

<spark:Button label="New Flex 4 button"/>

and as:

<halo:Button label="Old Flex button"/>

In the past, because Flex only had one namespace, writing cascading style sheets (CSS) was easy. You set all button label text color like this:

color: 0xFFFFFF;

That was it. But now, we have two types of buttons: the Spark button and the Halo button. We need to tell the CSS which is which, so now we have to introduce namespaces to our CSS documents. Don't worry. It's not as scary as it sounds. Here's the CSS to style the label color of each button type:

/* CSS file */
@namespace s "library://";
@namespace mx "library://";

s|Button {

mx|Button {

Now you know what namespaces are and how to use them in Flex 4. The discussion on the Internet was about how Flex 4 was initially going to use a prefix for the new components instead of using multiple namespaces. This means that instead of:

<s:Button label="New Flex 4 button"/>


<mx:Button label="Old Flex button"/>

we would have had one namespace with an fx prefix for the new Spark components, which would have made the code look like this:

<mx:FXButton label="New Flex 4 button"/>


<mx:Button label="Old Flex button"/>

I know it's not a big difference to the average user, but for those of us who live and breathe Flex day in and day out, it is a big deal.


There you have it. Those are the biggest changes you're going to see in creating custom components in the new Flex 4 (Gumbo) architecture. There are many other new features that I did not cover. For more information about those, check out Flex Product Manager Matt Chotin's article What's new in Flex 4 beta. From there, you'll find links to more documents that have in-depth coverage of the topics I have discussed here as well as those I have not.

This article is based on Flex 4 beta 1. While I don't expect any drastic changes, it is beta and is therefore susceptible to some alterations before final release. But that should not prevent you from downloading it. Flex 4 is a joy to play with and a great motivator to keep you excited about your choice to use Flex as your RIA platform. Download it, have fun, and create something amazing. Then blog about it so others can see what wondrous things you've done with this next-generation technology.

‹ Back

Tom Ortega II is a Principal at 360Conferences, where he coordinates low-cost, developer-friendly conferences such as 360Flex and 360|iDev. In addition, he keeps up his coding skills with projects at RapidNinja under the alias of "Ninja Debu".