Adobe AIR 1.0 brings new hope to Web developers looking to combine the global connectedness of browser-based applications with the persistence and functionality of first-class, local desktop apps.
AIR (Adobe Integrated Runtime) packages Web-enabling technologies and RIAs (rich Internet applications), and enables them to run outside of the browser on the user’s local desktop. Those underlying technologies can be based on Adobe’s own Flex, Flash, and ActionScript, for example, or just plain old HTML, CSS, JavaScript, and AJAX libraries.
The resulting application gains access to OS features such as dragging and dropping to and from the local file system, clipboard access for cutting and pasting between AIR and other applications, network connectivity, and perhaps most noteworthy, offline functionality. Thanks to AIR’s persistent, local SQLite data store, AIR apps continue to function without a network connection.
Further, AIR apps don’t require Web developers to learn anything new. They can easily create AIR apps using the tools and techniques they already know. And because AIR is cross-OS compatible, the same application code can be deployed to Windows, Mac, and eventually Linux systems. An alpha version of AIR for Linux is available atAdobe Labs.
Pieces of AIR Adobe AIR comprises several components. The SDK is a command line toolkit for packaging and deploying Web applications as AIR apps. It includes a schema template for generating the AIR manifests that accompany each application, APIs for the framework, a service monitor, and a command line debugger that lets you do some testing without first needing to package up your app. The entire lot is available for free and open sourced under the Mozilla Public License.
AIR incorporates dual engines — the Flash/ActionScript JIT and WebKit — to support applications built in either Flex/Flash/MXML or HTML/JavaScript. AJAX developers can run AIR without ever needing to learn ActionScript.
The underlying application components are packed into an AIR installer file, which is little more than a zip file containing program assets, the XML manifest, and a digital certificate to verify authenticity.
The command line tools are easy enough to work with, and you can use any text editor to create an AIR app. Adobe provides plug-ins for creating AIR applications in Flash CS3 and Dreamweaver CS3, as well as third-party tools such as Aptana Studio. However, I recommend you try Adobe’s new commercial development tool, the Flex Builder 3.0 IDE.
AIR apps can take advantage of protocols including FTP, AMF (ActionScript Messaging Format), JSON, SOAP, and RTMP (Real Time Messaging Protocol for streaming media), and they can communicate with Adobe LiveCycle and BlazeDS servers using server-side RPC and messaging calls.
I found decent support for popular JavaScript libraries, including Dojo (which now also supports AIR) and Adobe’s own Spry kit, allowing developers to make use of familiar tools. The resulting AIR application can look and feel like a native app, using the operating system’s “chrome” for menus and so on, or can be customized to your designer’s heart’s content.
For the end-user, an initial 11MB download is necessary to get started, but subsequent application installs and updates are far more seamless.
Security is thoughtfully addressed, but could go further. Local storage is protected by 128-bit encryption. AIR apps can be digitally signed and verified at runtime (via VeriSign or Thawte certificates). Administrators can control (via OS registry key) which AIR apps may be installed on a local system (trusted source only, for example), and whether they can be updated automatically. And because AIR apps are treated as native, personal firewalls can examine and block AIR applications on an individual basis (versus merely identifying the AIR runtime).
Nevertheless, I would like to see Adobe tighten the controls over system access. Although self-signed apps alert users with an “unknown signature” warning, these unverifiable apps, if installed, gain the same permissions and unfettered access to the underlying OS as verified apps. I hope Adobe will see fit in a future version to allow users to fine-tune permissions for each app during install. In Version 1.0, installs can’t be customized.
Adobe does offer best-practice guidelines for AIR. Nevertheless, I submit that many Web developers lack the technical savvy to effectively safeguard security. It’s only a matter of time before some clever ne’er-do-wells begin exploiting remote data sources through local access vulnerabilities unknowingly left open to attack.
That said, AIR does fortify against malicious code injections. The two-level sandbox framework, which restricts the access of untrusted application routines to AIR’s APIs, does help protect developers from themselves.
Grab some AIR AIR will not be suitable for every application. Personally, I’m quite content to use a browser for most things. But for enterprise dashboards and occasionally connected apps, as well as for many consumer-facing and marketing sites (watch out Webkinz!), breaking free of browser-badging and Web constraints makes a lot of sense.
On the enterprise front, companies such as Model Metrics (for Salesforce.com) and Business Objects are busy breathing AIR into their systems. There are also a number of projects under way to let AIR eventually tap native code via cross-compilation with ActionScript (for example, to migrate existing C++ or .Net applications).
Easy migration of legacy apps running on a freely available distribution of Linux (assuming Adobe follows through on the port) will be irresistible to many companies. I think we’re seeing only the first hint of turbulence in a coming wave of disruption.
The ability to reduce hurdles to desktop application deployment makes Adobe AIR 1.0 a must-see. Although we’re early in the game, Adobe’s AIR tools are ready to help you start kicking up some dust today.