{{ !articles[0].partner.isSponsoringArticle ? "Platinum" : "Portal" }} Partner
ria,flex & air

A Comparison of Flex 3 and Flex 4 beta

The Flex 4 (codename: Gumbo) beta release is a major change from Flex 3. The Flex 4 beta introduces a new component and skinning architecture. As a Flex 3 developer, however, you will likely not encounter too many challenges when compiling Flex 3 applications with the Flex 4 beta, since a goal of the new release is to maintain backwards compatibility with Flex 3.

In this article, I will provide a general overview of the main objectives in the Flex 4 beta, architecture differences, and an introduction to changes in components, layouts, use of states, and effects. I'll also answer some questions regarding what to expect when you compile your Flex 3 application in Flex 4 beta. This article will not cover all of the new features and functionality in Flex 4. For that information, see Matt Chotin's What's new in Flex 4 SDK beta article.

Throughout this document, the term Halo components refers to components originally included in Flex 3. The term Spark components refers to the new set of components in the Flex 4 beta.


In order to make the most of this article, you need the

Flex 4 SDK beta

Prerequisite knowledge

This article assumes knowledge of the Flex 3 Framework.


Migrating applications to Flex 4 beta

When migrating Flex 3 applications to the Flex 4 beta, you should not expect to do very much work. Other than bug fixes and a change in the default theme, you can look forward to your application generally working the same (or better) than it did in Flex 3. However, there are a few things to watch out for.

Player dependency

Be sure that you compile against Flash Player 10. The Flex 4 beta requires Flash Player 10 support.

Type selectors require a namespace

A CSS type selector names the Flex class to style. For example, the following are type selectors for Button and DateField:

Button {
cornerRadius: 10;
DateField {
color: #780800;

As of the Flex 4 beta, when an application uses type selectors, a namespace is required. If you are using only the MXML 2006 namespace in your Flex Application, add the following default namespace declaration to your CSS:


@namespace "http://www.adobe.com/2006/mxml";


If you are using multiple namespaces in your application, then you will need to provide each of the namespaces in your CSS. For an example, see Namespaces and packages in Flex 4 beta later in this article.

Further, if an application used a method like StyleManager.getStyleDeclaration("Button"), the type selector will need to include its package. For example, the call to getStyleDeclaration() would change to StyleManager.getStyleDeclaration("mx.controls.Button").

Theme change

The default theme for Flex 3 (Halo) components is now the Spark theme. Therefore, your application may look and size itself differently when you compile it using the Flex 4 beta. If, however, you want to use the Flex 3 look you still can because Flex 4 beta includes the Halo theme from Flex 3. To compile using the Halo theme, you can use the -compatibility-version=3.0 flag or compile your application using the -theme as an additional compiler argument. In Flash Builder 4 beta, you can do this by changing the Additional Compiler Arguments setting in the Flex Compiler section of the Properties panel (see Figure 1). If you are using the additional compiler arguments, make sure that the framework/themes/Halo directory is in your source path.


Figure 1. Setting additional compiler arguments

If you do choose to use the new Spark theme, note that many of the styles that worked with the Halo theme do not work in the Spark theme. The Spark theme only supports a limited number of styles including baseColor, color, contentBackgroundColor, focusColor, symbolColor, selectionColor, and rollOverColor. To change visuals like borders or rounded corners on a component using a Spark theme, you will need to create a custom skin. Flex 4 beta has also added a Wireframe skin that was designed to be used for quick mock-ups.

In addition to the theme change, the default preloader has changed to the mx.preloaders.SparkDownloadProgressBar for Flex 4 beta applications. This lighter weight preloader should shorten start-up time a little. If you want to use the Flex 3 preloader, you only need to change one line of code. In your Application tag add the following: preloader="mx.preloaders.DownloadProgressBar".

If you are migrating an application from Flex 3 to Flex 4 beta, I do not recommend that you replace each of your Flex 3 Halo components with their corresponding Flex 4 beta components. This is probably not a good investment of your time. Instead, move to the Flex 4 beta component architecture for new applications.

An overview of Flex 4 beta architecture changes

One of the major themes in the Flex 4 beta is "Design in Mind". This goal involves creating a smoother workflow between designers and developers. To help achieve this, the framework provides a clear separation of the visuals for a component and the rest of its behavior. In Flex 3, an individual component's code included logic around its behavior, layout, and visual changes. In Flex 4 beta, the components are factored out into different classes, each handling specific pieces of behavior.

As specified in the Gumbo Architecture Document:

"The main component class, the one whose class name matches the component's MXML tag name, encapsulates the core behavior of the component. This includes defining what events the component dispatches, the data that component represents, wiring up any sub-components that act as parts of the main component, and managing and tracking internal component state (we discuss states in more detail below).

Coupled with that component class is a skin class which manages everything related to the visual appearance of the component, including graphics, layout, representing data, changing appearance in different states, and transitioning from state to state. In the Halo model, Flex component skins were assets responsible for only one part of the graphics of a component. Changing any other aspect of a component's appearance, like layout or visualization of states, required sub-classing the component and editing the ActionScript code directly. In the Gumbo model, all of this is defined declaratively in the skin class, primarily through new graphics tags called FXG tags."

To learn more about the new graphics tags in Flex 4 beta, you can read the FXG 1.0 Specification.

As an example of the architecture discussed above, you can look at the code for the spark.components.Button class. This class only contains logic around the component's behavior. All of the visuals for this component are defined in the skin class spark.skins.default.ButtonSkin.

For performance reasons, the Flex 4 beta has provided building blocks for developers to pick and choose the functionality that you need. Heavyweight functionality such as scrolling and virtualization that is not needed by all applications is not turned on by default.

Namespaces and packages in Flex 4 beta

While keeping Flex 3 classes intact in the same mx.* packages, the Flex 4 beta introduces the spark.* packages for components, core classes, effects, filters, layouts, primitives, skins, and utils.

The Flex 4 beta provides a new set of components and effects that share many of the same class names as Flex 3 components. To avoid name collisions in MXML, the Flex 4 beta comes with four distinct namespaces: MXML 2006, MXML 2009, Spark, and Halo.

MXML 2006: The legacy MXML language namespace used in previous versions of Flex. Flex 3 applications compiled using Flex 4 beta can continue using this namespace.

URI: http://www.adobe.com/2006/mxml

Default Prefix: mx

MXML 2009: The new MXML language namespace. This is purely a language namespace, and does not contain component tags.

URI: http://ns.adobe.com/mxml/2009
Default Prefix: fx

Spark: This namespace includes all of the new Spark components. It should be used in conjunction with the MXML 2009 language namespace.

URI: library://ns.adobe.com/flex/spark
Default Prefix: s

Halo: This namespace includes all of the Halo components. It should be used in conjunction with the MXML 2009 language namespace.

URI: library://ns.adobe.com/flex/halo
Default Prefix: mx

Here is a small example that uses the MXML 2009, Spark, and Halo namespaces to create a simple Flex 4 beta application. This sample uses a Halo DateChooser and a Spark Button.


<mx:DateChooser id="main_calendar" x="20" y="20"/>
<s:Button label="submit" x="220" y="20"/>


Flex 4 beta has also added multiple namespace support in CSS. If you are using the MXML 2009, Spark, and Halo namespaces along with Type selectors, you will need to define a set of namespaces in your CSS definitions to avoid name collisions.

Here is an example of CSS that uses type selectors for both Halo and Spark components:


@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/halo";

s|Button {
color: #FF0000;

mx|DateChooser {
color: #FF0000;


Default Property and the Declarations tag

Prior to the release of the Flex 4 beta, the Flex language allowed the Application root tag to include visual children and non-visual children. The visual children were added to the Application with addChild() and non-visual children were treated as property declarations. Going forward, non-visual children that represent new property declarations are not allowed as immediate children of an Application. You can add these non-visual children under a <fx:Declarations> tag. This includes non-visual children such as effects, validators, formatters, data declarations, and RPC classes. Here is a short example:

<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"   
<s:Fade id="fadeEffect" target="{targetButton}" alphaFrom="1" alphaTo="0" />
<s:Button id="targetButton" />
<s:Button label="play effect" click="fadeEffect.play()" x="80" />


New components and containers

As I mentioned earlier, Flex 4 beta introduces a number of new component classes that use the new architecture, which should make skinning and other customizations much more straightforward. Here is a table showing Flex 3 Halo components and their Flex 4 beta Spark counterparts:

Flex 3 Halo Component Flex 4 beta Spark Component
mx.controls.Button spark.components.Button
mx.controls.ButtonBar spark.components.ButtonBar
mx.controls.CheckBox spark.components.CheckBox
mx.controls.ComboBox spark.components.DropDownList (w/o editability)
mx.controls.HorizontalList spark.components.List (with a HorizontalLayout)
mx.controls.HRule spark.primitives.Line
mx.controls.HScrollBar spark.components.HScrollBar
mx.controls.HSlider spark.components.HSlider
mx.controls.Image spark.primitives.BitmapImage
mx.controls.LinkBar spark.components.ButtonBar (with a custom skin)
mx.controls.LinkButton spark.components.Button (with a custom skin)
mx.controls.List spark.components.List
mx.controls.NumericStepper spark.components.NumericStepper
mx.controls.RadioButton spark.components.RadioButton
mx.controls.RadioButtonGroup spark.components.RadioButtonGroup
mx.controls.TextArea spark.components.TextArea
mx.controls.TextInput spark.components.TextInput
mx.controls.TileList spark.components.List (with a TileLayout)
mx.controls.ToggleButtonBar spark.components.ButtonBar
mx.controls.VideoDisplay spark.components.VideoPlayer
mx.controls.VRule spark.primitives.Line
mx.controls.VScrollBar spark.components.VScrollBar


mx.core.Application spark.components.Application
mx.core.Window spark.components.Window
mx.core.WindowedApplication spark.components.WindowedApplication
mx.containers.Canvas spark.components.Group
mx.containers.HBox spark.components.HGroup
mx.containers.Panel spark.components.Panel
mx.containers.Tile spark.components.Group (with a TileLayout)
mx.containers.VBox spark.components.VGroup

Adobe encourages you to use Halo components and containers along with Spark components. Because Adobe continues to build components atop the same base class (UIComponent), there should be full interoperability between Spark and Halo. Here is a table of the components and containers that do not currently have direct Spark equivalent classes.

Flex 3 classes with no direct Flex 4 beta counterpart

Changes in states syntax

Flex 4 beta has promoted the states functionality to a full MXML language feature. As a result, you will likely find states to be much more flexible and direct. The new states syntax is more inline, allowing state-specific changes to be specified in context. Here are the key differences in the Flex 4 beta syntax:

  • Only states are defined within the states array.
  • In the new states syntax, you cannot use AddChild and RemoveChild. Instead, you define a component's role in a particular state on the component itself using the includeIn and excludeFrom attributes.

In the following Flex 3 example, states are used to include a Button and remove a TextInput only when the currentState of the document is submitState. This approach can get very verbose with more complex states.

<mx:State name="submitState" basedOn="">
<mx:AddChild relativeTo="{loginForm}" >
<mx:Button label="submit" bottom="10" right="10"/>
<mx:RemoveChild target="{firstTextInput}"/>

<mx:TextInput id="firstTextInput" />
<mx:Canvas id="loginForm" />

Here is the simpler Flex 4 beta code using includeIn and excludeFrom.

<s:State name="submitState" />
<s:TextInput id="firstTextInput" excludeFrom="submitState" />
<s:Group id="loginForm" >
<s:Button label="submit" bottom="10" right="10" includeIn="submitState"/>
  • SetProperty, SetStyle, and SetEventHandler have been replaced by a new dot syntax, which allows you to qualify MXML attribute values with a specific state identifier.

In the following Flex 3 example, the code defines a property, style, and event for a Button in submitState.

<mx:State name="submitState" basedOn="">
<mx:SetProperty target="{submitButton}" name="label" value="submit" />
<mx:SetStyle target="{submitButton}" name="textDecoration" value="underline"/>
<mx:SetEventHandler target="{submitButton}" name="click" handler="trace('done');"/>
<mx:State name="clearState" basedOn="">
<mx:SetProperty target="{submitButton}" name="label" value="clear" />
<mx:SetEventHandler target="{submitButton}" name="click" handler="emptyDocument()" />

<mx:Button id="submitButton" />

In Flex 4 beta, the code looks like this:

<s:State name="submitState" />
<s:State name="clearState" />

<s:Button label.submitState="submit" textDecoration.submitState="underline"
click.submitState="trace('done')" click.clearState="emptyDocument()"
label.clearState="clear" textDecoration.clearState="none"/>
  • A component can no longer be in an undefined or null state. By default, the first declared state is the initial state of a component.
    The new syntax is available when a document uses the MXML 2009 language namespace. You cannot mix the legacy syntax and the new states syntax. The old syntax is available only in the MXML 2006 namespace.

Additionally, each component now supports a set of states defined in its skin class, which makes it simpler to apply visual changes depending on the state of a component. For example, if you look at the skin for the Spark Button, you will find the following states defined:

<s:State name="up" />
<s:State name="over" />
<s:State name="down" />
<s:State name="disabled" />

The ButtonSkin class defines what happens visually to a Spark Button in each one of these states.

This is only a brief introduction to the new Flex 4 beta states syntax. Visit the Enhanced States Syntax Spec to find more details.

Changes in effects

Many improvements have been made in the Flex 4 beta effects infrastructure. While Halo effects will only work on controls based off of UIComponent, the Spark effects can operate on any target including the new graphic primitives in the framework. All of these effect classes live in the spark.effects.* package. Because Spark effects work on Halo components, Spark components, and graphic primitives, Adobe recommends that you use Spark effect classes for future applications.

I've kept this description brief because you can get much more information about the new functionality in the effects classes from Chet Haase's Effects in Adobe Flex 4 SDK beta article.

Changes in layout

In previous versions of Flex, the layout of components and containers were defined inside individual controls. Therefore, you had components such as List, TileList, and HorizontalList, which all share the same functionality except their layout. Still, their layout logic was defined within these component classes. In the Flex 4 beta, layout has been decoupled from components. Now, Spark components such as Application, List, ButtonBar, and Panel can define their layouts declaratively. In all of the components, containment is managed by the Group class and the layout of the Group's children is delegated to an associated layout object. The layouts support both Spark and Halo components in addition to the FXG graphic primitives. Layouts can even be changed at runtime.

As a developer, you can easily write custom layouts and swap them in and out of various individual components. Here is an example of defining a vertical List, horizontal List and a tiled List.

Vertical List (the default layout of a Spark List is VerticalLayout):

<s:List />

Horizontal List:

<s:HorizontalLayout />

Tiled List:

<s:TileLayout />

As I noted earlier, the Flex 4 beta architecture is set up to provide developers with building blocks to pick and choose what functionality they need. By default, virtualization and scrolling is not turned on. To add the option for scrollbars on a Group and turn on virtualization, you will need to:

1) Set useVirtualLayout to true on your layout object 2) Add a Scroller component to your Group.

Here is an example of using virtualization and scrolling on a Spark Panel:

<s:Panel title="Horizontal Panel" width="300" height="220" left="20" top="20">
<s:Scroller width="100%" height="100%">
<s:HorizontalLayout useVirtualLayout="true" />
<s:TextInput />
<s:Button label="clear" />
<mx:DateChooser />
<s:Button label="submit" />

For more information regarding all of the enhancements in the Flex 4 beta layouts including better support for transformations, check out the Spark Layout Specification.


Working with text

All of the Spark components use the new text engine in Flash Player 10. These new classes offer low-level support for controlling text metrics, vertical text, typographic elements such as ligatures, and bidirectional text. Additionally, device fonts now have most of the functionality of embedded fonts that can be anti-aliased, rotated, and styled. The Flex 4 beta has leveraged this functionality in all of the Spark components that use text. For more information on the text primitives and text components provided in the Flex 4 beta, see thethe “Text primitives” section of the Flex 4 Features and Migration Guide.

The Spark components also now use the DefineFont4 embedded font format in Flash Player 10 and AIR 1.5. As of the current beta, Halo components do not have the capability to use the DefineFont4 format. This causes some overhead when mixing Spark and Halo components in an Application and embedding fonts. For now, if you want to use the same embedded font for all of your components, you will need to embed the font twice using DefineFont4 for Spark components and DefineFont3 for Halo components.

Here is an example of embedding the font Arial for a Flex 4 beta application that uses a Spark TextInput and a Halo DataGrid.


@namespace s "library://ns.adobe.com/flex/spark";
@namespace mx "library://ns.adobe.com/flex/halo";

@font-face {
src: url("arial.ttf");
fontFamily: "ArialDF3";

@font-face {
src: url("arial.ttf");
fontFamily: "ArialDF4";
cff: true;

s|TextInput {
fontFamily: "ArialDF4";
fontAntiAliasType: "normal";
mx|DataGrid {
fontFamily: "ArialDF3";
fontAntiAliasType: "normal";

Notice that when embedding fonts for Spark components, you need to specify cff: true in the font definition.

Solutions for embedding fonts for Spark and Halo components are under development, so this process should be easier in the future.

Backwards compatibility with Flex 3

As in Flex 3, you can compile your application with an additional compile argument:


This compiler argument will allow your applications to use some of the Flex 3 behavior instead of the new Flex 4 beta behavior. To get a full list of backwards compatibility changes in Flex 4 beta that support the use of the -compatibility-version argument, see the backwards compatibility document.

Note: You cannot selectively keep a subset of the Flex 4 beta behavioral changes when invoking Flex 3 compatibility. If you compile with the argument -compatibility-version=3.0.0, you will get all of the Flex 3 behavior described in the documentation.

Where to go from here

Hopefully, the migration from Flex 3 to the Flex 4 beta is relatively painless. The framework is designed to be mostly backwards compatible. Plus, once you get acquainted with the new architecture, you'll find that it is more ‘flex'ible! For more info on Flex 4 beta features, visit the web Help.


Published at DZone with permission of {{ articles[0].authors[0].realName }}, DZone MVB. (source)

Opinions expressed by DZone contributors are their own.

{{ tag }}, {{tag}},

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}
{{ parent.authors[0].realName || parent.author}}

{{ parent.authors[0].tagline || parent.tagline }}

{{ parent.views }} ViewsClicks