Adobe Integrated Runtime: More Than Just Hot AIR

Reprinted from the Tech Times #187.

I’d like to use this opportunity to take you on a journey into the Twilight Zone.

Of course, when I say Twilight Zone, I’m actually talking about that strange, unexplored space that exists between web applications and desktop applications. Only a couple of years ago this seemed like a wide, uncrossable chasm; an eerie, transitory void between two separate worlds.

While the Mozilla Prism package that I posted about recently takes the relatively low-tech approach of packaging an existing site into a box that looks like a desktop application, the Adobe AIR platform is entirely more sophisticated.

With its 1.0 release appearing just last month, Adobe AIR still falls into the “shiny and new” category, but feels remarkably mature. AIR is much, much more than a single-site browser—it’s a cross-platform runtime environment, and the differences between the two are significant. In fact, AIR’s extensive API means it has more in common with Java than it does with Mozilla Prism.

What makes AIR particularly interesting, however, is the fact that you can build a desktop application to run on the AIR platform using any of the following technologies:

• HTML, CSS and JavaScript
• Adobe Flash, or
• Adobe Flex.

Because of this flexibility, the biggest potential stumbling block for AIR’s adoption—the learning curve faced by developers—is almost non-existent. This point alone makes Adobe AIR a very appealing platform for web developers, no matter where their expertise lies.

But What’s The Big Deal?

While SSBs like Prism, Bubbles, Fluid and Pyro are nifty for packaging up an existing web site and presenting it as a standalone desktop application, what separates Adobe AIR from the pack is its comprehensive set of APIs.

Tapping into the Adobe AIR API, your desktop app has the ability to detect whether it is currently connected to a network, tap into native menu options, write to the file system or another data resource, take control of windowing, or interact with the operating system—pretty much anything that a regular desktop application can do. And it can do so regardless of whether the user is on a Windows PC or a Mac (a Linux version of the runtime is on its way).

Applications “running on AIR” therefore look and feel like native desktop apps (much more so than Prism apps), and they can be bundled up into a package that makes installation easy for the end user, from storage media such as a CD-ROM, or as a single click from a web page.

It’s worth noting that AIR apps built with HTML, CSS and JavaScript are displayed using the WebKit rendering engine—the same engine that powers Apple’s Safari browser and the Linux-based browser, Konqueror. So any rendering issues that you experience with these browsers are also likely to show up in your AIR app.

Development tools

There are several tools that you can use to develop an AIR app. If you use Dreamweaver CS3, then the Dreamweaver AIR extension is a natural fit given that both products come from the Adobe family.

A similar extension exists for Aptana Studio, an IDE of which I’m a big fan. Kev reviewed Aptana in Issue 148 of the Tech Times.

If your code editing tool of choice is something else, fear not! You can still create AIR apps using the AIR SDK—a set of command line tools for compiling, packaging and deploying your AIR apps. You just won’t get any of the nice extra benefits that these extensions provide, such as code completion, package management and debugging functionality.

Building A Simple AIR Application

Let’s look at some sample code for building the simplest of Adobe AIR applications—a Single-Site Browser. For this demo, we’ll create a desktop version of the popular online service Google Calendar.

Much like JEE applications, Adobe AIR applications consist of a specific file structure—for example, there’s an application.xml file that defines a bunch of configuration information. If you like, you’re welcome to explore the excellent AIR documentation to understand all this stuff. Personally, I’d rather let my toolset handle it for me …

As I mentioned, Aptana Studio is an excellent, free, cross-platform development environment. With the AIR extension, creating an AIR project is as simple as selecting File > New Project > AIR Project and filling in a couple of fields.

Aptana Studio makes creating a new AIR project a breeze.

With that out the way, we can jump in to writing our application, which, in this case, consists of just about the simplest HTML that you’ll ever see:

<html>
  <head>
    <title>Google Calendar</title>
    <script type="text/javascript" src="AIRAliases.js">
   </script>
  </head>
  <body>
    <iframe frameborder="0"
         src="http://calendar.google.com"
         sandboxRoot="http://calendar.google.com/"
         documentRoot="/"
         width="100%"
         height="100%">
    </iframe>
 </body>
</html>

In any Twilight Zone episode, there’s always a twist at the end—and this episode is no exception. The twist is that this is all the code that you need to write! Simply deploy your AIR application (in Aptana Studio, that’s achieved by clicking the Export Adobe AIR Package button) and the result will be a nice little installer with a .air extension.

Packaging your shiny new AIR application from Aptana Studio.

Our masterpiece is now neatly packaged up in this .air file, ready to be installed, distributed, or sold for a small fortune.

Of course, most AIR applications are going to consist of more than a simple iframe that acts as a wrapper for an external service. But hopefully seeing this example in action will encourage you to begin experimenting with more complex applications—either offline or online—using your existing HTML, CSS and JavaScript skills.

You’ll certainly be seeing plenty more about Adobe AIR on SitePoint in the coming months.