Flex Article

Building Rich Internet Applications with Macromedia Flex: A Flash Perspective

Flash user, meet Flex. Flex, meet Flash user. You may not know each other yet but you have a lot of mutual friends. This could be the beginning of a beautiful relationship.

It's exciting for me personally to watch momentum grow behind the idea of building Rich Internet Applications using Flash Player as a development platform. Although we're still only in the early stages, when I look at applications like the EMI Film & TV Music song licensing extranet (http://www.emifilmtv.com) or the Intro conference networking application (http://www.intronetworks.com) from Mixed Grill, I definitely get the sense that we're getting somewhere. With the release of Macromedia Flex, I'm starting to feel like a whole new team of players may be ready to join us.

"We Call This 'The Timeline.' No, Wait, Come Back!"

A bit of history: I've been a Flash user since Version 3 (circa 1998) and my heart has been with the product ever since. I'd had a fair amount of multimedia experience when I first picked it up, so I found concepts like the Timeline and Library easy to learn and use. Once I'd finished my computer science training, I found myself taking those concepts and running with them to places they probably weren't originally designed for. Gradually, I was finding ways to use the Timeline and Library for application development. The states of a form could be spread out as frames on a Timeline; individual classes fit nicely in symbols of the Library, which I was starting to use as a class browser of sorts. I felt as though I was onto something really big that any application developer would want to use. I was making some pretty cool, rich interactive stuff—at least I thought so—so I started showing these authoring concepts to some Java and C++ developers I knew to try to draw them into this amazing new way of building richer applications.

Almost all of them thought I was completely crazy.

Not necessarily crazy in a bad way. More of an "OK, so you're a mad scientist" kind of crazy. But the results couldn't really be ignored. The apps you could make looked much better and they could be deployed much more universally—you know the story. Although the finished product appealed to them, once I fired up Flash to show them the way I'd used the beloved authoring tool to make the product, their reaction was usually somewhere between "stunned silence" and "fear."

Therein lay the problem. I, among the growing ranks of power Flash users, could see how bringing a multimedia designer's sensibilities to application development led to much more engaging, charismatic user interactions. Flash Player included new language concepts and syntax structures that gave code-oriented users the ability to do nearly anything they wanted. But to many of the hardcore, developer-oriented minds outside the Flash community, what we accomplished was nearly completely inaccessible. The learning curve in using the Library and Timeline was just too great. The Flash environment has so much more in it than a normal software engineer is used to dealing with, and every bit of unfamiliarity lends itself to distraction and frustration. Let's face it: Flash is intimidating, especially to the power developer who is used to feeling at home just writing code.

Just Writing Code

Macromedia Flex was developed to address this very problem. With Flex, you can build an entire Flash application in EMACS or BBEdit. No new development environment to learn, no Timeline to fumble with, and no Library to get lost in. From a developer's point of view, all you really have to do to get started is learn the basics of MXML, ActionScript, and components—none of which are all that unfamiliar.

Let's take a brief look at a painfully simple MXML application (see Figure 1). Here is the code for it:

<?xml version="1.0" encoding="iso-8859-1"?>
<mx:Application width='200' height='170' 
        xmlns:mx="http://www.macromedia.com/2003/mxml">
    <mx:Script>
    <![CDATA[
        function bPressed()
        {
             alert("Hello World");
        }
    ]]>
    </mx:Script>
    <mx:Button height="40" label="Here's a Button!" 
             click="bPressed()"/>
</mx:Application>

Figure 1. A screen shot of the Best Flex App. Ever.

It doesn't do much but this example shows how little you need to do to get basic things working in Flex.

A quick thought experiment: If you are a developer used to working in Java, having never seen the Flash IDE, what would the steps look like to get this application working in Flash?

1. Adjust the Stage's width and height by clicking on the Stage and opening the appropriate dialog box from the Property inspector.
2. Find the Component panel and drag a button to the Stage. Use the Property inspector to give it a name.
3. Use the Property inspector to adjust the width and height of the button, and set the label of the button. Experiment with the button's width until it fits the text provided.
4. Drag an Alert component to the Stage.
5. Delete the Alert from the Stage and make sure it is in the Library.
6. Select the frame on the Timeline in which the button sits and open the Actions panel.
7. Write code to addEventListener in the Actions panel to make the Alert appear.
8. Press Control-Enter to test the movie.

Looking at this list, you can see that there are at least three UI gestures or metaphors that a Java developer would not instinctively guess. Forget the fact that the developer would have to ignore all the other irrelevant panels. This is, of course, the easiest possible scenario. Consider some of the intricate preloading and Timeline-management problems that come with more complex apps and the Java developer would be stuck doing animation tutorials before being able to figure most of it out.

Obviously, Flex is meant to solve these problems by giving traditional developers an environment they want and already know. Every MXML tag maps to a component being placed on the Stage, and the tag's attributes set the properties of that component. The server compiles the MXML file into a SWF and serves it to the browser. It's powerful, yet extremely simple.

Confessions of a Mad Scientist

I'll admit it: When I first started working with Flex, I had a hard time understanding why you'd want to use it. It seemed almost too simple. I was so used to the expressiveness and power of the metaphors I'd become comfortable with in Flash that I just couldn't see the point in authoring with anything else. I could do almost anything in Flash and I doubted that Flex could offer the same amount of control. In some strange sense, I even felt threatened. Would this New Big Thing overwhelm Flash and reduce its relevance?

The more I worked with Flex, the more I started to see that it offers developers a choice that will help increase the relevance of Flash as we use it today.

What I think has always drawn me to Flash is its ability to join worlds. Its ubiquity isn't just a matter of Flash Player penetration; it's about how many people can participate within it. It's an environment that allows traditional graphic designers to combine their talents with interactive designers, animators, sound producers, and coders, to name but a few. Flash has an amazingly broad reach but it is not quite what experienced developers need—and we want those developers! Most of these talented people have had little ability to participate until now. Flex helps make Flash more ubiquitous by making the platform, and its tremendous pool of talented users, accessible as collaborators with these developers.

You might ask yourself where someone like you or me fits into this scenario. It's great to be able to work with traditional developers but what role does a seasoned Flash expert play in creating Flex apps?

Bridging Flash and Flex: Components

If you've coded in Flash for long, you've probably created a component. You know that you can export a component from Flash as an SWC file. What you may not know is that almost every MXML tag in Flex maps directly to an SWC file. It's certainly possible to build your own components in Flex but for managing skins and low-level MovieClip events, and for UI components especially, Flash is still the most powerful tool around for creating rich component designs and interactions.

Let's take a quick look at an extremely basic component in Flash and how it relates to Flex:

class MyButton extends UIComponent
{
    [Event("click")]

    function MyButton(Void) : Void
    {
        //setup the button – details not important
    }

    [Inspectable(category="General",verbose=1)]
    function get label() : String
    {
        // return the button's label
    }

    function set label(s : String)
    {
        // set the label of the button
    }

    function onRelease(Void) : Void
    {
        dispatchEvent({type:"click"});
    }
}

So, it's a button. Let's say you bind this class to a component in the Library and export it as an SWC. I left out the code for what the button really does; mostly I want to highlight the two tags shown in blue and show how they relate to Flex. These tags tell the Flex compiler what the allowed events and properties of the component's MXML tag will be. You can take this SWC file, place it in the directory containing your Flex app, and use this tag:

<MyButton label="My First Flex Component!" click="doSomething()" /> 

Using this tag, your button is placed on the Stage, has its label property set, and has an event handler added for its click event. This is obviously a very simplified example but if you are a skilled component coder in Flash, Flex gives you a whole new audience for your work—traditional developers who can collaborate with you to add business logic around the components you build.

Bridging Flash and Flex: Design

If you are already an amazing interactive or graphic designer in Flash, Flex needs you! The strength of this tool for developers is not in designing multimedia or subtle interactions. There will always be a place for skilled Flash users who made this platform as compelling as it is. Flash users will still design entire rich components with it. They will still add design treatments to the existing set of components. Maybe most importantly, they will still build animations, video, rich media, interactive design, and all the other Flash content we already know and love. Flex is just waiting for this kind of content, courtesy of the Image tag and @Embed.

The Image tag and @Embed are two of my favorite features in Flex. They form a bridge that allows almost anything that Flash does to cross into the developer's world. Here's a really basic example. Say I have an animation that looks like this:

It's beautiful, I know. It's a MovieClip symbol with a color tween in it. First day of Flash kinda stuff. The SWF here is called MyAnimation.swf and the symbol inside it is called GlowingCircle. It is set to export on the first frame. Check out what I can do in Flex, using @Embed:

<?xml version="1.0" encoding="iso-8859-1"?>
<mx:Application width='300' height='200' 
       xmlns:mx="http://www.macromedia.com/2003/mxml" xmlns="*">

   <mx:Image source="@Embed('MyAnimation.swf')" />
   <mx:List dataProvider="{['one','two', 'three', 'four']}" 
       width="100" height="100" 
       defaultIcon="@Embed('MyAnimation.swf#GlowingCircle')" />

</mx:Application>

Here's what you get:

To view this content, you need the latest version of the Macromedia Flash Player.
Download the free Macromedia Flash Player now.

@Embed is an incredibly useful tool that lets you compile other SWFs or symbols into the SWF that Flex creates from the MXML file. This all happens at compile time, which means your app does not perform any loading. You can see in the code that I used @Embed in two different ways. The first is as the source for an Image tag. The Image tag in Flex does more or less what you would expect: It displays the image (in this case, the SWF). But the second usage is more interesting.

Note that for the List component above, defaultIcon is set (shown in blue). In Flash, this parameter takes the name of a symbol in your Library that you want to use as the icon. Flex doesn't have a Library but it does know how to look into the Library of any SWF you give it. By specifying my symbol using @Embed('MyAnimation.swf#GlowingCircle'), I am able to add that symbol from MyAnimation.swf to the application that Flex generates. It's pretty much limitless in what it can do. This way you can embed anything that Flash makes into your Flex application. In some senses, this makes Flex a superset of the Flash environment, encompassing both developers and designers and giving them a platform upon which they can really begin to collaborate.

Some Parting Considerations

Although it's exciting to think about the possibilities, it's important to remember that Flex is not for everyone. Flash will not be supplanted in any way. As a server technology, Flex is more costly and somewhat harder to deploy. The runtime framework is more involved and has a greater bandwidth cost than the lighter-weight apps that you make with Flash. All developers who know and feel comfortable with Flash should continue to use it. Flash is great and Macromedia is deeply committed to it. There is no reason for Flash users to feel they must leave Flash authoring behind.

Flex is aimed at large-scale intranet or high-speed Internet applications with considerable layers of business logic—the sort of apps that require larger, broader teams of engineers and designers working together to deploy successfully. This is an area that some talented Flash developers have been exploring, which will open up even more as Flex attracts more traditional developers. It is a great opportunity for Flash to become more important in more established organizations. As a result, there should be new opportunities opening up for Flash developers.

Because Flash is all about ubiquity, it's great to see the Flash platform reach a broader audience of developers. It makes everyone work more collaboratively, learn from one another, and start experiments together—which is where rich and interesting experiences come from.

About the author