Wednesday, February 27, 2008

Moment of Reflexion

A comment on my previous posting asked for some explanation of what Flex is and how it relates to Flash.

I'm still intending on posting some technical content here and going over some sample code, but hey - I'm Flexible.

I was sort of assuming that everyone had heard of Flex and knew something about it. But since I'm new to the platform myself, and since I intend this blog to be for relative newcomers to the platform (at least for now, since that's where I'm at), it seems reasonable to define some terms. Here is my understanding of how these various Adobe products and platforms relate to each other. If I get whacked from someone in marketing, I'll replace them with something more correct, but I think this will do for now.


ActionScript is the programming language used to program Flash applications. The current version of the language is ActionScript3, which is based on ECMAScript (read: JavaScript), and should be quite familiar to most web programmers because of its similarity to JavaScript. ActionScript is more type-safe that JavaScript in general (or at least that's my impression from using it in the Flex environment); you need to declare most variables as having specific types at compile time. The base syntax is actually not too unlike Java. I've found the transition easy overall, although I still write my variable declarations backwards out of habit and then go back and fix them when the compiler pukes on my code. For example, the following declaration in Java:

    Object blah;
would be writtin in ActionScript as:
    var blah:Object;

I should write a macro in the IDE to do the switch for me, since I seem to have a hard time twisting my brain around after all this time to do it correctly.


Flash is a graphical library and runtime that enables animated graphics applications. There is an authoring tool for creating Flash content, a language for programming Flash applications (ActionScript3), a class library of graphics and other useful objects, and a VM that enables Flash applications to perform well. From the start, Flash was about creating animations, and the tools and libraries for Flash all reflect that time-based model; the Stage, MovieClip objects, and frame rates are all part of a normal Flash application.

The rendering in Flash takes place via a "display list" (also known as a scene graph, or retained-mode graphics). Instead of issuing direct rendering calls in your code which get executed immediately (like they do in immediate-mode APIs such as Java 2D), you place rendering requests on a display list which gets processed and displayed which the next frame is rendered. These requests then stay on that display list until removed.

The use of a scene graph is a subtle point, and perhaps one that most application designers couldn't frankly give a toss about. But it ends up being important to Flash and Flex developers, as it's important to understand what is being put on the display list and when that display list needs to be cleared and repopulated with other rendering requests instead.

For example, if you put the following rendering calls into the display list of a Flash object (where graphics is the graphics context of a Flash display object):

    graphics.moveTo(0, 0);
    graphics.lineTo(100, 100);
then you will get a line on the screen from (wait for it...) (0, 0) to (100, 100). Suppose you later want to move the line to be from (50, 50) to (150, 100). If you made these calls to the graphics object:
    graphics.moveTo(50, 50);
    graphics.lineTo(150, 100);
and ran your application, you would see two lines on the screen. You didn't actually change the line's position; instead, you simply added another line to the display list. The typical way to get what you want is to recreate the display list from scratch by clearing it first, and then add in the rendering calls you want:
    graphics.moveTo(50, 50);
    graphics.lineTo(150, 100);


Flex is a GUI toolkit library that sits on top of the Flash library and runtime, much like Swing sits on top of Java 2D (for the Java folks in the audience). The addition of Flex did a few things to improve (at least for folks like me) the programming experience of Flash applications:

  • GUI components: Prior to Flex, most Flash applications brewed their own components (buttons, etc.), which meant more work for the developer, less consistency between applications, and potentially buggy or unpredictable behavior. Who here has run across bizarre implementations of scrollbars in Flash applications that didn't look or behave at all like the scroll bars we know and love? Flex brings uniformity and functionality to this previously, er, more chaotic space.
  • Programming model: As I alluded to before, the programming model of Flash is, well, different than most GUI developers might expect. Thinking about an enterprise UI in terms of MovieClips, frames, and display lists is, well, different. Flex abstracts all of that away and allows developers to write GUI applications for Flash in a much more traditional way. A button control is a button control, with events, skins, states, and so on; it's not a MovieClip added to a Stage or anything so unusual (at least to me, but maybe I just have Stage fright).
  • Declarative programming: Flex also introduced the MXML language for declarative programming of applications. This XML-based language allows programmers (and design tools) to create static code that tells Flex how the UI should be layed out, and saves the actual dynamic programming logic via ActionScript for things that cannot be declared statically. There are various advantages to this model (from what I've seen so far): clear XML code that sets up the GUI briefly (as opposed to lots of code to do the same task), a logical hierarchy of XML tags that reflect the parentage of GUI containers and components, and interaction with design tools for ongoing creation and editing of the GUI in a WYSIWYG builder (such as the one in FlexBuilder). It's pretty cool to be able to go in and out of design mode, hand-coding stuff where appropriate, and dragging and dropping other things when possible. The fact that the GUI layout is persisted in XML means that the builder tool can handle edits much better than approaches that use actual code behind the scenes (typically, the code is not allowed to be edited or if you do edit it you probably cannot get the tool to read it in again).

Given all of these advantages and advances of Flex, GUI programmers should now find it much easier to write real, full, robust GUI applications that run on the Flash platform.

The output of a Flex build is simply a SWF file (the type of file that the Flash player will run); it ends up just being another Flash application. But inside of that application is the set of Flex components and capabilities used in your application, which then translate into Flash rendering.

The Flex SDK is free and open sourced; you can write Flex applications, compile them, and ship them all for free.


This IDE (a plugin for the Eclipse platform) is optional - you can use the Flex SDK for free as a command-line compiler, using whatever IDEs and code editors you want. The FlexBuilder tool does cost money, but gives you some advantages over hand-coded Flex applications, such as the GUI builder I mentioned above as well as all of the code editing features you would expect for both ActionScript and MXML (code hinting, and so on).


Think of Adobe AIR as the packaging of both web applications (HTML/JavaScript) and Flex/Flash applications for the desktop. Flash was written originally for the browser, and Flash content is predominantly browser-based today. Although you can run SWF files in a standalone SWF player, traditional Flash applications are really intended for use in web browsers. The same goes for Flex applications, since they are essentially Flash applications with more built-in capabilities.

But what if your users want to run your application offline? Or what if they want access to their local filesystem, a feature that browser applications typically don't allow because of security restrictions?

AIR enables all of this; it allows applications to be installed on the local operating system and accessed from the desktop just like the other applications that the desktop user runs. AIR applications can still access online information, in fact that is still an important model for these rich applications, but they can also run offline when appropriate or necessary.

AIR also bundles in more capabilities that are not currently a part of the Flash or Flex platform, such as a full HTML/JavaScript rendering engine. So even if you're a web developer, just writing AJAX applications with HTML and JavaScript, you can use AIR to deploy these applications to your user's local desktop.

BlazeDS, LiveCycle, etc.

I think I'll leave these product terms for another day. There's a host of Flex-related products and capabilities for the back-end. But frankly, I'm still figuring out the stuff on the client, and I'd really rather stick to what I know on this blog....


Unknown said...

Great run down of the adobe products. Looking forward to trying out the flex sdk and hearing about blazeds

Maurizio Vacca said...

Great work! Now, waiting for something to see :). Anyway, do you think that Flex/Flash are the only directions for the web application development in the future?

Anonymous said...

Nice writeup! I found it very helpful how you relate the Adobe tech to Java Swing. Please keep it up =)

Anonymous said...

Thanks for the roundup. I'm looking forward to reading your future posts. I'm interested in using Flex/Air to access the service layer of our spring based web app.
My only concern with learning this is that practically all of the tutorials seem to assume that you're using Flex Builder, which I'm not prepared to buy yet (and the trial period restriction isn't very tempting). As a Java guy, the IDE situation seems like a bit of a step backwards and a hindrance to Flex's adoption - it just doesn't seem as easy to jump straight into and test the water as Java. Do you know of any other options?
Anyway, keep it up (oh, and the Filthy Rich Clients book was great, thanks).

Chet Haase said...

I don't know about other IDE options in particular, but then I'm new to the space and haven't surveyed the territory.

I would think that there are plenty of editor options that would do a decent job of handling ActionScript3 editing as well as helping out with the XML editing of mxml files.

The GUI builder is definitely a nice thing to have for the main UI construction, but it's also not critical; the layout managers in Flex do a lot of the work for you.

The point of the trial period is, I assume, to get you to try it and see whether the productivity of the tool outweighs the cost. You might try it out and see what you think. In the meantime, check out your other options and see where you want to invest your time or money.

Aziz said...

Excellent write-up. I have been a “Java Swinger” for almost 8 years, and just as I was thinking about learning Flex, which is used--alongside Swing--by my employer, you show up at Adobe; impeccable timing.

Chat, I seriously think that you can make Flex much more attractive by helping us make the “transition”. I intend to purchase a Flex book (Adobe Flex 3: Training from the Source). As you already know, this is a crucial time for RIA, I know that a lot of developers are thinking (at least those that haven’t decided yet) about which RIA technology to learn; trying to decide where to invest their precious time and energy. Blogs like these, books that are targeted to a Java audience or just plain good books “like Filthy Rich Client”, and even promotions like a FlexBuilder community edition or personal license (a la IntelliJ) would probably add a large number of Java developers to the Flex roster.

I hope Adobe understands how valuable you are in attracting those who use one the most popular programming languages on earth.

Thank you.
Aziz K.

Anonymous said...

Aptana Studio( supports editing of ActionScript 3 and Flex files, and works with Adobe Air as well.

It is also based on Eclipse.

There is a pay version, but the basic version has everything you need for Flex/Air development(with a plugin they provide).

It doesn't have the drag and drop editor, but it seemed competent in other respects when I buzzed through it.

Anonymous said...

Very well than! Great work! The definitions are well structured and sophisticated as well. I think they are adressed to beginners and to everyone who has or wants to look some basic defnitions up. BD