Transitioning from Flash to Flex: An overview

Introduction

You know who you are: you got started on a bootleg copy of Flash 8 in high school, poked around with the drawing tools and were about to put it away when you discovered something called ActionScript which changed the way you looked at making content for the web. Flash-forward to today and you're a successful Flash developer. You don't write timeline code. You have a personal class library that's half-ported from AS2 and only you know how it works. Graphic design?  You have people for that. But you still use the Flash Authoring Tool for all of your production, and lately you're getting the sense that you're missing something.

Lately you've been hearing more and more about this "Flex" thing, but it makes you nervous - even though you don't really use the stage, you like the cold comfort of a library of visual assets that you can link directly to your classes. You've heard about this MXML stuff but it just makes you feel kind of dirty - who wants to use XML-based shortcuts instead of bathing in pure AS3? And yet, one-by-one your developer friends stop posting to Flash fora as they start picking up Flex - and they seem to be making a lot more money, too.

So, are you ready to see what the fuss is about? In this writeup we're going to take a look at a few key concepts in Flex development and examine what it is that Flex has that Flash doesn't. I'll explain to you why MXML is worth your time, we'll look at how easy it is to make custom components and then I'll knock your socks off with the concept of Data-Binding. We'll talk a bit about styling, and end up with a look at when Flash may still be a better bet.  This won't be a detailed step-by-step tutorial, more of an overview of the relevant concepts to get you started.

Ready?

MXML: It Doesn't Suck

MXML is a set of proprietary XML tags that act as shortcuts to writing AS3 code - when you compile your .swf, all of the MXML gets turned into AS3 and then compiled just like any other project in the Flash Platform. There are a handful of reasons why MXML is very useful - but if you're anything like me you'll be very skeptical at this point. AS3 works, dammit - why would you want to learn a whole new approach to creating content when the one you have works so well? Furthermore, if MXML is just a wrapper for AS3 anyway, why would you even bother? Why not write the AS3 directly?

Well, the short answer is that you can - there's nothing stopping you from porting over your existing AS3 packages and classes and importing them into your Flex projects. There's nothing stopping you from creating an <mx:script></mx:script> tag and writing your code in there. You don't have to use MXML at all to use Flex, and maybe that's the best way in.

As you play around with it, though, you'll find that you start to use it more and more. Sure, you can instantiate a Panel component, size it and position it with AS3 and then integrate it into your application - but why write a class to do that when it's so much easier to just type something like the following:

<mx:Panel id="loginPanel" width="400" height="150" title="{user.name}"></mx:Panel>

Once you're familiar with the ideas there - "id" is the instance name, the {}'s denote data-binding (see below), etc - you'll even start using Design View to do your layouts. Strange concept, I know - but the fact is that MXML makes it quick and easy to implement components and configure them in a way that makes sense. It's faster than writing it in pure AS3 and various layout features (the design view is handy for spacing things out, aligning to edges, etc etc etc) make it really convenient to use. And don't even get me started about connecting to remote data providers - you can replace 20 lines of AS3 with a well-executed <mx:RemoteObject />.

Still skeptical? That's ok - go download a free trial of Flex and just use AS3 for a while. MXML won't be offended - that's how cool it is.

Custom Components - Err, shh, here comes Flash, pretend we're talking about something else...

Another perk of the MXML model is that it makes creation, customization and deployment of custom components much easier. Not only does Flex Builder ship with a slick library of components to help you manage everything from layout to UI to data visualization, but they're all instantly accessible and very, very easy to customize.

Flash gives you some components, sure. But in order to modify them you've got to mess with all of the visual assets on the stage (ever tried to customize the skin for FLVPlayback? It's not impossible, but it's hardly intuitive), you've got timeline code all over the place, and ultimately each component remains something of a black box. Flex is much easier - think of each component as a self-contained Flex Application. You can open it up, edit the AS3 and MXML, change the layout or style and then plop it right into your project. And the best part? All Flex Components are also Classes - so if you want to work in straight AS3 or do something dynamic, it's no problem to type var p:Panel = new Panel() and go from there. Like any other AS3 asset they can be extended programmatically, as well.

And thanks to the meta-data customizability provided by the Flex Framework, it's easy to define custom events for each component. Create your event, add the appropriate Meta tag, and then when you add the component to your main application's MXML you'll get code hinting right in the MXML letting you specify an event handler. Couldn't be easier, eh?

Code-Hinting, Project-level Browsing and You'll Never Go Back to Flash

Writing AS3 in Flash is easy, right? I mean, it lets you have multiple AS documents open, it gives you some code hinting if you're using existing Flash classes, it catches your errors when you preview...

Listen, ten minutes programming in Flex Builder and you will never write code in Flash again. Even if you don't switch to Flex Development, you'll write your AS3 in Flex and then use it in Flash. Why?

• Custom Code-hinting - every class you write will get code-hinting when you implement it. You'll see all of your methods, along with the arguments they take. You'll see all of your public variables (or, if you're using setters, you'll see those as public variables). This works in both AS3 and in your MXML - if you want to implement any of your classes as custom components, all of their properties become attributes in the MXML tag, and as I mentioned above you'll get any possible events listed along with your properties and methods. That's slick.
• Project View - Flex knows you're not going to be creating a single file and then publishing. You've got graphical assets, you've got custom classes, you've got external libraries, you've got XML configuration files - and with Flex, because it's built on the Eclipse engine, you have a mini file-manager in the upper left to help you keep track of all of that. It's a huge time-saved to not have to go to file->open every time you need to edit a different file.
• Wizards and Shortcuts - Got your file browser open? Right click on your "src" folder and create a new folder called "classes." In that folder, create a new folder called "CustomDisplayObjects." Right click on that folder and click "Create new AS3 Class" - a wizard comes up asking you for the name of the class, what class it extends and a handful of other parameters. Then it creates a class within a package that mirrors your folder structure - "package classes.CustomDisplayObjects { public class YourClassName extends Whatever { public function YourClassName{}}}" etc. Everything lines up, and if you want to change any of your folder or class names it'll automatically update all of that for you. Neat, eh?

Data-Binding - If You Weren't Already Impressed...

And that brings us to Data-Binding. This is something that's possible to do in Flash, but it doesn't happen naturally nor does it happen easily. Data-Binding allows you to declare certain variables or classes to be "Bindable." Let's say we write the following:

[Bindable] public var sample:String = "";

You can then create, say, an MXML Panel. You can bind the String to the panel's title property -

<mx:Panel id="testPanel" title="{sample}" />

Those braces in the "title" attribute field mean that the variable "sample" is bound to that field - in other words, every time "sample" changes - be it through user input, simple program progress, some sort of custom class behavior - testPanel will be automatically notified and its title will change to reflect the new value.

Yeah, that's right - you now have access to data objects that can notify listeners when their value changes. And it's not just strings - you can define an entire custom class as Bindable, and then whenever any property within that class changes anything that's bound to that property will update automatically. It's not magic, it's just a propertyChanged event handler embedded deep within the Flex framework - but it sure saves you a few hundred lines of event handler code in a larger application. Think about it - let's say you have a custom class called "User" which contains various user information and then an ArrayCollection containing all of a user's comments. You can change out the user dynamically, and your "Selected User's Comments" component will have its contents changed to match whoever you set to "selected user." Pretty swell, eh?

Doing it with Style

Let's wrap up our look at Flex's core concepts with a look at styling your app. In Flash, the image editor is heavily foregrounded - if you want your component to look a certain way, you just draw it that way and then link it to your class. Flex doesn't have that sort of functionality - the way you control the appearance of your Flex app is with a Flexified version of everyone's old friend CSS.

That's right - you use cascading style sheets. Now I know what you're thinking - you got into AS3 development specifically so you didn't have to troubleshoot buggy CSS rendering anymore, right? Well don't sweat it, because Flex renders the style itself - no more browser compatibility issues, no more IE6 hacks, no more uneven implementation of standards. Basically, all of the visual elements you use in Flex have visual properties - width, height, background color, etc etc etc. Additionally, you can import graphical assets that your design people give you and use them as skins for your components. All of this information can be stored in a stylesheet which then applies the information to your specifications. It'll take you a few minutes to get used to the selectors etc, but other than that it's like HTML in a perfect world.

So... when would you still use Flash?

Don't get me wrong, I love Flash - other than the AS3 editor, which is kinda bad. If you're working with something where you need specific control over the graphical assets, use Flash. If you're working with timeline animation, use Flash. If you want to be able to import video from AfterEffects and map it to your Tweens, use Flash. Flash is still Flashier.

But if you are working with a lot of information and if you prefer external ActionScript files to timeline code, why not take a day or two and poke around with Flex? If you want to give it a serious shake, take five days - apparently, you can learn Flex in a week with this handy set of video tutorials from Adobe. What are you waiting for? There are a million resources for you to consult - the Flex community is made up of developers who love to spread the word, and there's probably an Adobe User Group in your city filled with folks who will talk your ear off about MVC Frameworks and Design Patterns and all sorts of topics you never knew you were interested in until you asked. It's great.

So yeah, that's that - go download the free trial and give it a spin.