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

Know Free Launch

Adobe released a bunch of good stuff yesterday. It's pretty huge. Not mentioning it would be like forgetting to tell your wife you like her new haircut; tactless and just plain dumb.

• Adobe AIR 1.0: Bringing Flex, web programming, and Rich Internet Applications in general to the desktop.
• Flex 3: The latest release of the Flex platform, a powerful GUI toolkit sitting on top of the rich Flash rendering engine.
• The open-sourcing of both the Flex SDK and BlazeDS (back end services for Flex and AIR applications)

Meanwhile, I'm still putting together technical pieces on a Flex app I've written; expect that to start dribbling out here soon. Like the crumbs that multiply on my shirt as I eat my breakfast; at first it's just a couple of crumbs, but pretty soon you've got a whole scone there in its component parts.

Eventually, I want to be able to write pieces that help describe the work we’ve done on Flex, the features we’re working on, the future plans, and the inner details that help people understand how to use it most effectively.

But hey, I just got here; I don’t know any of that stuff. I’ve been developing graphics software for my entire career and hacking the internals of desktop Java for the last several years, and I am very familiar with desktop client technology in general, but the whole stack offered by Flex is completely new to me. I will, I’m sure, eventually learn all of the fun internals, and when I do I’ll execute on the plan above.

But until then, I’ll be coming up to speed on Flex, Flash, AIR, ActionScript3, and everything else I need to be able to help out on the Flex team. And as I do, I thought it would be useful to post interesting things that I discover, applications that I’m working on, and random thoughts on Flex development to hopefully help others on a similar learning curve.

Maybe you’re a Java developer, trying to learn about Flex. Or maybe you’re a Flash developer, interested in Flex’s GUI toolkit. Or maybe you’re new to desktop development and are checking out the various technologies available. Or maybe you did a Google search on “acid reflux”, ended up here and haven’t a clue what I’m talking about.

In any case, stay tuned for future postings here where I’ll talk about some of the things I’m working on and interesting things I find out about the platform as I cruise along.

What the Hello World

I know what the world needs - another weblog! There's surely not enough of them out there already...

Welcome to my new weblog, Codedependent (a term which comes from this joke on my humor blog). I intend to use this blog for random discussions of graphics software; demos, tutorials, how-tos, snippets, announcements, algorithms, whatever. I'm also not above the odd humor piece or two (which can be even funnier when people take it seriously, despite my best efforts to be completely ridiculous).

I've recently joined Adobe Systems to work on the Flex SDK. Much of the material I write will be about Flex, Flash, AIR, ActionScript, and related technologies, although I also intend to have non-technology-specific pieces as interesting graphics software topics arise.

I feel the need to offer some kind of explanation to justify my writing this blog. Given some of the stuff out there in the blogosphere, all that bloggers really seem to need is an internet connection and a vague sense of where the keyboard is. But I’m after a higher goal here – I actually want people to read the articles, enjoy them, interact with me, and maybe even learn a thing or two as I, too, will be learning from working on the material.

Anyway, here’s me in brief (not "me in briefs"; this is not that kind of blog): I’ve been developing graphics software for my entire career, after a short-lived stint doing Network Communications, where I realized just how dull that work was. I work on anything that puts the pixels on the screen. I’ve worked on graphics technology at the application level, at the API level, in library development, and even down to the drivers for graphics chips. I was recently at Sun Microsystems, where I was an architect in the desktop client group for the last several years. I worked with all of the technologies in desktop Java, such as the Swing GUI toolkit and the Java 2D rendering layer. Some of my efforts there included hardware-acceleration for Java 2D rendering and, more recently, animation and whizzy graphical effects for Swing. On the topic of nifty graphical effects, I published a book last year with Romain Guy, entitled Filthy Rich Clients.

One of the things that attracted me to Flex, and to Adobe, was a client platform that enables very rich user experiences; transitions, animations, filters, and just darned good-looking UIs are all pretty exciting to this graphics geek. I hope to be able to help make Flex an even richer platform going forward.

As part of my recent stint at Sun, I kept a weblog on java.net; you can check out that blog if you want an idea of the kinds of things that interest me. That blog's postings are pretty Java-specific, since that was the intent, so I probably won't be adding to it in my newfangled life here at Adobe. Instead, I’ve started this new blog to be able to talk about Flex and, well, anything else that seems appropriate.

This should be fun - I hope you can join me. I promise to get more technical in future pieces. I just needed to get this "Who the heck are you?" piece out of the way so that I could get to more interesting material. For example, I've just finished writing a simple vector-drawing application as a way to teach myself about various elements of Flex and Flash. I'll be posting that application and going over the code in upcoming articles for anyone that's interested in learning along with me.

By the way, I also have a humor weblog that I post to when I want to write stuff that has nothing whatsoever to do with software (although I have been known to post jokes of a geeky nature there). If it’s technical, look here. If it’s not, look there. And if it's complete junk, look somewhere else.