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

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

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.clear();
    graphics.moveTo(50, 50);
    graphics.lineTo(150, 100);

Flex

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.

FlexBuilder

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).

AIR

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....