ich Internet Applications (RIAs) represent not only an established, but a rapidly expanding, segment of software development. Although descriptions of RIA abound, most people agree that they blur the line between server-based and desktop applications. Typically, RIAs are more robust and feature-rich than conventional web applications. In most cases they handle much of the interface and user-experience heavy lifting on the client side, but stay current by maintaining the data and shared networking elements on the server side.

Perhaps most important, however, they handle more activity on the client side to dramatically reduce the number of server calls, page refreshes, and often-significant delays found in traditional client-server relationships. This client-side approach decreases bandwidth strains, increases productivity, and reduces processor loads on the server, allowing more clients to interact with the application.

As RIAs become more common, and their benefits more obvious, questions loom. How can this scenario be improved even further? Which remaining limitations can be bested, and which new features can tomorrow’s RIA exploit? The logical extension of moving more server processing to the web client is continuing that progression from the web client to the desktop.

From R-I-A to A-I-R
Adobe Integrated Runtime (AIR)?formerly known as Apollo and recently renamed?is Adobe’s answer to these needs. Adobe already enjoys a large portion of the RIA development market, with industry-leading applications like Flex, Flash, and Dreamweaver. AIR, currently in beta, is likely to continue that trend.

AIR is a cross-platform, run-time engine that helps developers use existing software-development skills to create and distribute Internet-enabled desktop applications.

Using a distribution metaphor similar to the Flash Player delivering SWF content to the web browser, AIR delivers RIA content to the desktop. After users have performed a one-time install of the AIR run-time engine, sites can distribute minimized application files without the runtime-code overhead. These files can then be played back through the centralized AIR engine. Over time, this characteristic means the end-user performs fewer downloads and enjoys work or play easier and faster.

Much has been made in the development community as well as the media of AIR’s cross-platform focus on Flash and Flex playback, including leading ActionScript 3.0 features. However, AIR can also deliver HTML, JavaScript, and PDF, all within the same file, if desired. For this diversity and currency alone, AIR is the current frontrunner (warts and growing pains included) among other desktop RIA efforts such as Flash projector enhancers, connected database runtimes, and HTML renderers.

Take a look at some of AIR’s significant features:

• Cross-platform delivery: AIR currently runs on Mac (OS 10.4.8 and later, both Intel and PPC) and Windows (XP and Vista), with support for Linux and additional Windows OSs expected sometime after AIR is officially in release.
• Database capabilities: In addition to existing capabilities of working with databases through middleware (such as PHP), and more directly through XML Sockets and reading and writing binary data, the AIR runtime ships with an embedded version of SQLite.
• Tight OS integration: AIR can currently manipulate directories and files (including reading and writing all kinds of data and binary data among them); create and manipulate windows; drag and drop assets between applications; display resolution-savvy custom application icons; support rich, formatted clipboard data; and support native menus (Mac only). It is expected to support multiple mouse buttons, contextual menus, system notifications, and Windows menus after it’s in official release.
• Flash Player 9/ActionScript 3.0: AIR is current in its support of the Flash Player, meaning all the capabilities of ActionScript 3.0 are included.
• Multiple internal file formats: AIR can render Flash Platform content, both from Flash and through the Flex framework; HTML through the open source WebKit initiative; and JavaScript, including the attendant DHTML, AJAX, and so on, and PDF.
• ActionScript/JavaScript bridging: AIR serves as the bridge between ActionScript and JavaScript content within its files. It can currently host HTML within Flash applications and is expected to be able to host Flash within HTML applications once in final release. (That is, it can render HTML in a Flash environment, but can’t yet behave as the Flash Player does, by embedding SWFs within HTML content.)
• AIR application bridging: AIR applications can communicate with one another through the LocalConnection ActionScript API, which makes it possible for enhanced inter-application data exchange.
• Transparent windows/custom chrome: This feature brings RIA development into the next level of design. By supporting transparent windows (a transparent Flash/Flex stage, HTML document, or PDF document) AIR allows even entry-level developers to create custom interfaces and window shapes.

Setting AIR Apart from Other Desktop Runtimes
As is to be expected these days, any major initiative from Adobe?particularly where Flash is concerned?will draw a fairly significant amount of attention, ranging from praise to vitriol, from naysayers to pundits of all flavors. Most of the commentary appears to be in the form of comparisons with tools that are similar in one or more ways to the functionality of AIR.

The truth is, like any product, particularly one at the start of its life cycle (AIR isn’t even 1.0 yet), AIR has pros and cons; choosing a desktop runtime is very much a decision about using the best tool for the job.

Initial discussions compared AIR to third-party Flash projector enhancers, such as ScreenTime’s mProjector. Comparisons to Flash projectors are fairly obvious because of AIR’s tight ActionScript integration, and because the projectors Flash creates are nearly worthless. To be more precise, native Flash projectors are little more than an extension of the Flash Player. They offer a scant handful of new features, the most often-used one being the ability to present a file in full-screen mode, but lack everything essential to desktop delivery, including OS integration.

However, while AIR is salivation-worthy compared to existing options, it may not always be the best tool for the job. Without delving into a deep, point-by-point comparison, here are a few general reasons AIR may not fill all your desktop application needs at this time. (By comparison, ScreenTime’s mProjector addresses these limitation examples either in whole, or in part.):

• Extensibility. AIR cannot be extended with native code, leaving its feature set pretty much where it stands upon release.
• Launching external applications: AIR cannot currently launch other applications. This functionality exists in a very limited way in Flash projectors, but security played a large part in restricting this feature in AIR.
• Installation: AIR applications must be installed to work. In addition to being seen by some as a potentially risky or invasive process (an opinion I don’t share), the big issue here is that AIR applications cannot be run from a CD- or DVD-ROM, or even a kiosk, if not previously installed. In some circumstances, such as some of the education work I do, this can be a nonstarter.
• ActionScript version support: For the purposes of this particular analysis, AIR supports only AS3. Based on what I understood when AIR was first being discussed with developers, I was later surprised to discover that legacy SWFs are in fact supported, which is great. However, as the AIR-specific APIs are ActionScript 3.0 only, older SWF files will not have access to the desktop-application-specific functionality cited previously.

Another factor is installation size, which is somewhat of a half-full/half-empty debate. The AIR installer is between 5 and 9 megabytes, which is a hefty download. By contrast, ScreenTime’s mProjector averages 300?800 KB, which isn’t as disparate as it may seem, however, because the AIR runtime, like the Flash Player, must be installed only once (though it will require updating from time to time).

The final AIR applications, like Flash SWFs, are very small. (One of the demo files included in the accompanying download, including two PNGs, is only 54 KB.) If you are likely to download a lot of AIR files, the large initial file size will eventually be met by the per-installer file size of other projector enhancers.

The AIR file/player approach has other benefits, too, such as tighter technology integration (Flash, HTML, PDF), more standardized delivery, and tighter security. AIR will also support an integrated application update feature that other projector enhancers don’t have.

To be fair, Adobe isn’t aiming its application at the desktop-enhancer market. From its product materials: “Adobe AIR is not a general desktop runtime that competes with lower-level application runtimes. Adobe AIR comes from the web to the desktop and is aimed at web developers. Its primary use is to enable web applications and RIAs to be deployed to the desktop.”

Strangely, AIR has drawn blunt comparisons from the other side of the fence, as well. Critics have compared AIR’s HTML/JavaScript/SQLite features with Mozilla’s in-development WebRunner and Google’s in-development Google Gears. It’s unclear, however, what significant benefits these and similar applications may have over AIR, and you will have to draw your own conclusions. Again, it’s all about choosing the best tool for the job.

Development Environments
Initially, AIR (formerly Apollo) applications could only be authored easily in a Flex environment, such as FlexBuilder. This characteristic has changed dramatically, however, and you can take a look at several options for creating AIR applications. Discussing how to install and use each environment is outside the scope of this article, but links to each relevant site where additional information can be sought will be provided.

To begin, there is a free SDK with command-line tools that build an AIR application from your Flash/Flex/HTML/PDF project. For those looking for additional GUI support, there are two options for the Flash Platform and two for HTML/JavaScript.

HTML/JavaScript applications can be authored with just about any text editor, but some good enhanced editors to consider are Aptana and Dreamweaver CS3. The former is a well-designed, free, and open source IDE for AJAX, AIR, Ruby on Rails, (and even iPhone widgets) that is winning a lot of praise. It is available in stand-alone versions for Mac, Windows, and Linux, and also as an Eclipse plugin.

Dreamweaver CS3 is the familiar web asset development powerhouse from Adobe, with AIR support coming in the form of an extension. The extension is easy to use, and Adobe really gave some thought to making the experience as pleasant as is practical under the circumstances. For example, Adobe created a JavaScript “alias” page that remaps paths to packages so you can simply type “air” instead of longer, qualified class names. The alias file functions much like an import statement in Flash, allowing you to import the package and call the class directly.

Authoring AIR applications with Dreamweaver is very easy to do. All you have to do is set up a new site for each AIR project, and the AIR preview player is available just like any other browser. When it comes time to package your application for delivery, another menu command from the Site menu is all you need. A dialog will appear, allowing you to fill out the minimal application parameters, and you’re all set. (This procedure is necessarily brief, and the basic steps will be covered when the Flash sample is discussed later, but is very similar. Current Dreamweaver users will be very comfortable with the process.)

Flash Platform applications will likely be edited in FlexBuilder (Beta 3 here) or Adobe Flash C3 Professional. The Flex Builder workflow is the most mature, and consists of straightforward use of existing Flex assets. Adobe maintains that Flex users should be able to make AIR applications of existing projects without changing a thing, but will have to add simple programming to take advantage of any native AIR APIs.

The Flash CS3 workflow is a bit different. This workflow is quite recent and requires a software update (not just an extension) to make it work. For design-time testing, the most recent public beta of AIR is also required, which at present is the M4 version.

The update will add an AIR New File type to the Welcome screen, an AIR option in the publishing settings, a new playerglobal.swc file to add all the new AS introduced by AIR, and two commands for compiling the files. One command sets up the packaging preferences, and the second compiles without having to revisit the original dialog. The new workflow introduced by Adobe is more integrated and complete than previous options, but cheerful props should go out to early innovators like Guy Watson and Grant Skinner for pushing the AIR-Flash CS3 tie in along. To see how the process works, you’ll build a simple “Hello World” application.

Build a Simple Application
The traditional Hello World computer-programming exercise, or something similar, is usually a good place to start when learning a new language or environment. It’s simple enough that you can concentrate on a specific topic without a lot of tangential code getting in the way. In this case, however, although that simplicity would certainly show how easy it is to make an AIR application, even with a custom window shape, it wouldn’t demonstrate any of the AIR-specific APIs. Therefore, a few simple tasks will be added to the application that will demonstrate the new Flash CS3 workflow.

Figure 1. Hello World: You’ll build this sample application with a few twists to get a feel for the AIR-specific APIs.

The very first thing you need to do is create an AIR-compatible Flash file. If you have your Welcome screen enabled, you should see the option available (see Figure 1). (If you’re sure you installed the required update and this option doesn’t show up on the Welcome screen, see the Flash CS3 Update document in the related resources. It will describe a way to delete a system folder to force a rebuild of the dialog.)

The first functional departure from the traditional Hello World application is that the text is a visual, in the form of a word balloon. It is initially hidden, as seen in line two of the script, and shown when you click on the baby. For simplicity, the word balloon remains visible after it’s displayed.

Clicking and dragging on the translucent maroon bar at the bottom of the image allows you to drag the application around your screen. Just for fun, when you click and “pick up” the application, a drop shadow will appear. When you let go of the mouse and “put down” the application, the shadow disappears.

Creating the shadow occurs in lines 3?8, using standard ActionScript:

1  import flash.filesystem.*;2  wordBalloon.visible = false;3  var ds:DropShadowFilter = new DropShadowFilter();4  ds.color = 0x000000; 5  ds.alpha = 0.5; 6  ds.blurX = 10; 7  ds.blurY = 10; 8  ds.distance = 10; 

The next five lines create the event listeners needed to trap the events that control the application (all with weak references for safer memory management). For example, a click event on the baby (instance name sally) calls the onShowMsg() function. Note that the drag bar (drag_btn) uses MOUSE_DOWN and MOUSE_UP, rather than CLICK for its events.

 9  sally.addEventListener(MouseEvent.CLICK, onShowMsg,false,0, true);10  drag_btn.addEventListener(MouseEvent.MOUSE_DOWN,onDragWindow,false,0,true);11  drag_btn.addEventListener(MouseEvent.MOUSE_UP,onDropWindow,false,0,true);12  close_btn.addEventListener(MouseEvent.CLICK,onCloseWindow,false,0,true);13  min_btn.addEventListener(MouseEvent.CLICK,onMinimizeWindow,false,0,true);

The onShowMsg() function is the nitty gritty of this application. First, it sets the visible setting of the word balloon to true. Note another AS3 migration issue: no built-in properties start with an underscore. Next it populates a variable with a text string to write to the text file. The last block is writing the text file. Line 17 resolves a local path, relative to the location of the application, to the desktop and creates a file called hello_world_as.txt. Line 18 checks to see if the file doesn’t exist. If it doesn’t, line 19 creates a FileStream?a class instance that will handle the opening, writing, and closing of the file. Line 20 opens the file created earlier, in write mode. Finally, line 21 writes the string using UTF encoding, and line 22 closes the file.

14  function onShowMsg(evt:MouseEvent):void {15    wordBalloon.visible = true;16    var stringToWrite:String = "Sally says, 'Hello World!'";17    var f:File = File.desktopDirectory.resolve("hello_world_as.txt");18    if (!f.exists) {19      var fs:FileStream = new FileStream();20      fs.open(f, FileMode.WRITE);21      fs.writeUTFBytes(stringToWrite);22      fs.close();23    }24  }

The last four functions handle the utility tasks. The onDragWindow() function assigns the DropShadow filter to the baby and drag bar and starts a system move to drag the application around the screen. The onDropWindow() function empties the filters from the baby and drag bar, and the last two functions minimize and close the window, respectively.

25  function onDragWindow(evt:MouseEvent):void {26    sally.filters = [ds];27    drag_btn.filters = [ds];28    stage.window.startMove();29  }30  function onDropWindow(evt:MouseEvent):void {31    sally.filters = [];32    drag_btn.filters = [];33  }34  function onMinimizeWindow(evt:MouseEvent):void {35    stage.window.minimize();36  }37  function onCloseWindow(evt:MouseEvent):void {38    stage.window.close();39  }

Packaging Your AIR Application
When you’re ready to package your application, choose the AIR ? Application & Package Settings command, which will open the dialog shown in Figure 2. For simple testing, you can usually accept all the default values in this dialog, but you must be sure to test your movie after any changes, before compiling. The Test Movie command generates a current SWF that will be used to create the AIR application.

Figure 2. Putting the Baby to Bed: Usually you can accept all the default values in the AIR ? Application & Package Settings dialog, but be sure to test your movie after any changes and before compiling.

In this case, you’ll want to make sure one additional change is made, which is switching the Window Style menu to Custom Chrome (transparent). This change will cause the Flash stage to disappear, and only nontransparent pixels will show in the application. Optionally, you can also choose which icons are used for your application by choosing pre-created PNGs in 16-, 32-, 48-, and 128-pixel square sizes.

You may notice in Figure 2 that these options appear disabled, and the “Use custom application descriptor file” checkbox is checked. If desired, you can configure the autogenerated XML document yourself. You may find this approach easier to repurpose from project to project, for example. (An example is included here.) If so, check the aforementioned checkbox, and browse for this file:

  HelloWorld-AS      A simple Hello World application with the following features:     draggable, minimizeable, closeable, shows/hides assets,     writes text file to desktop.       Creative Commons Attribution-ShareAlike 3.0      HelloWorld-AS.swf  Adobe/AIR/FMA      icons/AirApp_16.png    icons/AirApp_32.png    icons/AirApp_48.png    icons/AirApp_128.png

Also, once you’ve set up the dialog or XML file the first time, you can then skip immediately to the AIR?Package AIR File command.

Again, this entry level “first AIR application” tutorial was pushed a bit to demonstrate the AIR-specific commands. If you are just interested in creating a custom shaped window for your linear Flash animation, you can do that without any extra work at all. If this tutorial seemed like a breeze, dig in deeper. There are several impressive sample applications in the related resources list.

Also included is a reference to Adobe Integrated Runtime (AIR) for JavaScript Developers Pocket Guide (see related resources). It’s a fine book that provides a handy pocket reference for you to have right on your desk. If you’re comfortable with digital text, and you have the screen real estate to move back and forth between a PDF and your application, the authors and O’Reilly generously teamed up to make the book freely downloadable through the folks at Ajaxian.

Finally, a bonus source package that isn’t included in the source code download is included in the related resources. It is the same exercise but recreated in HTML/JavaScript for use with the Dreamweaver CS3 AIR extension.

Related Resources

• 35+ AIR Examples for JavaScript Developers at Kevin Hoyt’s web site
• Adobe Developer Center Article: Six Must-See Adobe AIR Sample Applications Rob Christensen (2007)
• Adobe Integrated Runtime (AIR) for JavaScript Developers Pocket Guide Mike Chambers, Daniel Dura, and Kevin Hoyt (Adobe Development Library/O’Reilly 2007) A free PDF version of this guide is available for download at ajaxian: Adobe AIR Free Book Download.
• Adobe Labs: Adobe Integrated Runtime (AIR) official site
• Adobe Labs: AIR Sample Applications
• Adobe Labs: AIR Wiki
• Adobe Labs: Air Documentation
• Adobe Labs Downloads: Adobe Integrated Runtime (AIR)
• .airchive (nee CodeApollo) code archive
• Bonus Exercise: DevX Supplemental Downloads: HTML/JavaScript through Dreamweaver CS3
• on Air National Bus Tour!