Ben Stucki

I’m excited to be speaking at the Nashville Flex/Flash Camp this Friday, June 19th. If you’re within driving distance and interested in learning the latest Flash and Flex technology, I’d definitely recommend checking it out - plus there’s free beer. :-) I’ll be talking about some of the more interesting and powerful features introduced to the Flash Player in the last few years including ByteArrays, BitmapData, and Sound APIs. Here’s the official description.

Cool Stuff with Flex 4 and the Flash Platform

From ByteArrays to Sound APIs the Flash Player has grown a lot in the last few years. In this talk Ben will take a look at Flash Platform features you may not even know existed and show you how to use them in the latest Flex 4 SDK.

Adobe evangelist Greg Wilson will also be on hand to talk about about some of the changes coming to the Flash and Flex Frameworks. Find more info at the official website and be sure to register if you still can.

In my last post I demonstrated how easy it is to migrate a Flex 3 application to Flex 4, but it seems that a few people weren’t satisfied - well, maybe just one person. Aral was kind enough to comment on my post, and amongst the fun and games he reminded me that I need to add spark components to my application. Thanks Aral. I guess I did promise that after the migration people would be able to use all the cool new features and components, but I didn’t go into a lot of details. However Aral’s blog does have information on what I might expect when I start to use spark components.

Simply compiling a Flex 3 app with the Flex 4 SDK is not migration. Refactoring your Flex 3 application so that you can enhance it with Spark components is not trivial and that’s the definition of migration that we need to adopt as that’s the real-world use case for migration (it doesn’t matter whether or not you can compile your Flex 3 app with the Flex 4 SDK if the first Flex 4 feature you’re going to use is going to require a far more extensive refactoring of your codebase to migrate it to a Flex 4 project utilizing both libraries.)

Ouch, looks like I got called out! To summarize, if I were to enhance the migrated Flex 3 application from my previous post with Spark components I should begin to feel the pain of Aral’s real-world migration. In fact I’m promised that the task is not trivial and that the first Flex 4 feature I use will require far more extensive refactoring than the previous demo. Sounds scary. Let’s see.

Setup

Taking the application from my previous post, I’m just going to add some mock data for the TestControl to use. Notice that nothing else changes in the application file throughout the demos.

SparkTest.mxml


<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:test="com.test.controls.*" layout="absolute">
    <mx:Script>
        <![CDATA[
            import mx.collections.ArrayCollection;
        ]]>
    </mx:Script>
    <mx:Style source="//assets/css/global.css" />
    <test:TestControl left="0" right="0" top="0" bottom="0"
        data="{new ArrayCollection(['Test 1', 'Test 2', 'Test 3', 'Test 4', 'Test 5'])}" />
</mx:Application>


Spark Components

I read in the online documentation that all the spark components are in the namespace “library://ns.adobe.com/flex/spark”. I think that’s pretty handy because I get code hinting and I’m not left to guess at what the new stuff is (especially if it’s named inconsistently), but I’ll let you try it out and see what you think.

The plan is to declare the namespace and then use a new spark component just like I would with any other library. I’m going to try out the List component first, because I’m really excited to see how the layouts work.

TestControl.mxml


<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:spark="library://ns.adobe.com/flex/spark">
    <spark:List dataProvider="{data}" horizontalCenter="0" verticalCenter="0" />
    <mx:Button label="Flex 4 Rules!" right="10" bottom="10" />
</mx:Canvas>


So, I just recompile and wait for the trail of errors and namespace hell which is promised to ensue - and… and my app runs. It doesn’t just compile, but it functions with the Spark List component running as advertised. That’s because FLEX 4 (SPARK) COMPONENTS WORK IN YOUR FLEX 3 CODE! I’m starting to think it’s not my definition of the word migration that needs help, but my understanding of the word trivial. I should keep digging though - just in case.

Flex 3 States and Spark Components

At this point I’m totally outside of the namespaces argument, but a lot of Aral’s migration headaches seem to revolve around the idea that you need to port all of your Flex 3 states to the new Flex 4 state syntax. I’ll try to recreate this requirement by adding states to my custom component and seeing what breaks. I’m even adding a Spark transition just for fun.

TestControl.mxml


<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:spark="library://ns.adobe.com/flex/spark">
    <mx:states>
        <mx:State name="vertical" />
        <mx:State name="horizontal" enterState="animation.play()" >
            <mx:SetProperty target="{list}" name="layout">
                <mx:value>
                    <spark:HorizontalLayout />
                </mx:value>
            </mx:SetProperty>
        </mx:State>
    </mx:states>
    <spark:Resize id="animation" target="{list}" widthTo="500" />
    <spark:List id="list" dataProvider="{data}" horizontalCenter="0" verticalCenter="0" />
    <mx:Button label="Flex 4 Rules!" click="this.currentState = 'horizontal';" right="10" bottom="10" />
</mx:Canvas>


You know the routine - but wait, I’m sure it only works now because the root tag is a halo component. Maybe if I tried to use the old state syntax inside of a spark component I would find hours of torturous migration pain.

Flex 3 States IN Spark Components

I’ll use the new Group component as my container instead of Canvas. I have to put my child components in the mxmlContent property since I’m still using the old mx namespace to compile language features (such as states). I also added a “data” Object since Group doesn’t normally have that property.

TestControl.mxml


<spark:Group xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:spark="library://ns.adobe.com/flex/spark">
    <spark:states>
        <mx:State name="vertical" />
        <mx:State name="horizontal" enterState="animation.play()" >
            <mx:SetProperty target="{list}" name="layout">
                <mx:value>
                    <spark:HorizontalLayout />
                </mx:value>
            </mx:SetProperty>
        </mx:State>
    </spark:states>
    <mx:Object id="data" />
    <spark:Resize id="animation" target="{list}" widthTo="500" />
    <spark:mxmlContent>
        <spark:List id="list" dataProvider="{data as IList}" horizontalCenter="0" verticalCenter="0" />
        <mx:Button label="Flex 4 Rules!" click="this.currentState = 'horizontal';" right="10" bottom="10" />
    </spark:mxmlContent>
</spark:Group>


Still working! Wow. So, I can use all the Spark components and Effects anywhere without changing the state syntax. What feature’s left that would require me to change my state syntax? Well as far as I know the only feature that requires the new state syntax is the new state syntax. So, ummm.. If you want to change your component to use the new state syntax, then you do have to change your component to use the new state syntax. You don’t have to do it throughout your application all at once though. Just like in this example you can try it out in a single component and leave the rest of your application just as it was. Your call.

Flex 4 States

To use Flex 4 states I’ll need to change the language namespace to “http://ns.adobe.com/mxml/2009″. After the language namespace change I’ll have to put non-component declarations in the “Declarations” tag, and child components are assigned to the mxmlContent property automatically. Notice that I can still use the “library://ns.adobe.com/flex/halo” namespace to use all my standard Halo components just like I would before.

TestControl.mxml


<spark:Group xmlns:fx="http://ns.adobe.com/mxml/2009"
    xmlns:spark="library://ns.adobe.com/flex/spark"
    xmlns:halo="library://ns.adobe.com/flex/halo">
    <spark:states>
        <spark:State name="vertical" />
        <spark:State name="horizontal" enterState="animation.play()" />
    </spark:states>
    <fx:Declarations>
        <fx:Object id="data" />
        <spark:Resize id="animation" target="{list}" widthTo="500" />
        <spark:HorizontalLayout id="horizontal" />
    </fx:Declarations>
    <spark:List id="list" dataProvider="{data as IList}"
        layout.horizontal="{horizontal}" horizontalCenter="0" verticalCenter="0" />
    <halo:Button label="Flex 4 Rules!"
        click="this.currentState = 'horizontal';" right="10" bottom="10" />
</spark:Group>


Conclusion

Let’s review. FLEX 4 (SPARK) COMPONENTS WORK IN YOUR FLEX 3 CODE! Flex 3 (Halo) components work in your Flex 4 code. Flex 3 states work in your Flex 4 Code. Flex 4 states actually work in your Flex 3 code. Everything kind of works everywhere. There is no need to “port” your code to start using spark components. Again, I just don’t know how else to say it - but you don’t have to take my word for it. Download the latest Flash Builder 4 Beta and try it out for yourself!

A few months ago I posted about being strongly adamantly against the use of Fx Prefixes in the Flex 4 SDK. In fact I probably went a little overboard - but holy crap, kittens lives were at stake! In the end the Flex team made what I think was the right decision and began moving away from Fx Prefixes in favor of using namespaces. Yay!

However, the impact of this change recently hit Aral Balkan, a prominent Flash community member, and suddenly the controversy was reborn. In Aral’s words:

My inner engineer understands that namespaces are the most elegant long-term solution. It doesn’t help that my inner engineer is feuding loudly with my inner agile development evangelist (who is appalled at the sacrifice of short-term simplicity in favor of long-term design) and at my inner user experience designer who cannot help but look at the issue from the perspective of the end user.

I think that’s an inner struggle that a lot of developers can identify with, and on both sides you see similar extremes trying to prove themselves correct. The point of contention for me, however, is the assumption that you must choose one over the other. Do you really have to give up standards for simplicity? I know a false choice when I see one.

The truth is that complexity exists in our line of work and it’s our job to recognize it, thoughtfully consider it, and offer a solution that values simplicity. I would argue that Fx Prefixing never solved a problem, it ignored the problem all together - which is bad in any circumstance. The use of namespaces however recognizes the issue and addresses it beautifully, adding consistency throughout the framework. Here, again, we could battle semantics forever, but let’s just migrate a Flex 3 application to Flex 4 and tangibly feel Aral’s pain instead.

I’m going to be covering all of the issues involved in migrating your Flex 3 application to Flex 4 as far as I know. I’ve been using Flex 4 for months and have written applications both with Fx prefixes and without. I’ve also migrated a handful of my own Flex 3 applications to the latest Flex 4. By my definition this means getting an existing Flex 3 app to compile with the Flex 4 SDK so that I can use all of the cool new features and components. If I’m incorrect, for the love of God somebody correct me.

Setup

To begin with I created a new project using the Flex 3.1 SDK. I wanted the app to be simple enough to blog about, but I also made sure to hit any pain points involved. I decided to make an application with one custom MXML component (so that I wasn’t avoiding custom component migration issues) and some CSS (because Aral’s really off on a tirade about the CSS). After I created my custom component I realized that I had already added the first namespace to my project - before even migrating! Here’s the code so far.

SparkTest.mxml


<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml"
    xmlns:test="com.test.controls.*" layout="absolute">
    <mx:Style source="//assets/css/global.css" />
    <test:TestControl left="0" right="0" top="0" bottom="0" />
</mx:Application>


TestControl.mxml


<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">
    <mx:Button label="Flex 4 Rules!" right="10" bottom="10" />
</mx:Canvas>


global.css


Button {
    color: red;
}


Migration

So, again, the plan is to switch the SDK to compile with Flex 4 targeting Flash 10 and see what happens - and… and my app runs. Yup, you heard it here first! FLEX 3 COMPONENTS WORK IN FLEX 4 WITHOUT MODIFICATION. In fact entire Flex 3 applications compile in Flex 4 without modification. Custom components work in Flex 4 without modification. There is no need to modify your Flex 3 code when you start to use Flex 4. I’m just not sure how else to say it - but wait! I admit there is one problem, what about that CSS warning? Ah, you caught me! There is 1 step required to get your CSS working if you used Type selectors. You must add a default namespace to the top of your CSS files.


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

Button {
    color: red;
}


I submit to you the winning entry of the 1 Step Migration Challenge.

Step 1: Add @namespace “library://ns.adobe.com/flex/halo”; to the top of your CSS files!
(do I get some kind of prize for winning?)

Conclusion

This is, in my opinion, the easiest SDK migration so far, and I think it’s unfortunate that one person’s bad experience while porting code between random Flex 4 Alpha versions could cause such mass confusion. I know that the simplicity and approachability of Flex is a huge priority to everyone (yes even the vocal minority), and it’s a great credit to the SDK team that they’re able to achieve it without sacrificing standards.