This article is sponsored by Adobe.
Rich-client technologies permeate not only browser-based applications, but the more traditional desktop client as well. In this interview with Artima, Rob Christensen, Adobe's product manager for AIR discusses the reasons for creating rich-client desktop applications, and how Adobe's AIR platform enables Web application developers to deploy their apps to users' desktops.
With over 200 million installations, Adobe's nascent AIR desktop runtime is already enjoying a strong following among developers. AIR uniquely combines the open-source WebKit browser toolkit and HTML rendering engine with Adobe Flash Player, SQLite, as well as other popular client-side Web technologies, and allows applications to freely mix and match HTML and Flex/Flash content.
In this interview with Artima, Rob Christensen, senior product manager for Adobe AIR, explains why one would want to develop a Web-facing application for the desktop, how an AIR application installs and updates itself on a user's desktop, how to use AIR's local relational database, and what the future holds for the AIR runtime:
Frank Sommers: What are the advantages of developing a rich-client application for the desktop as opposed to a browser environment?
Rob Christensen: An incredible amount of innovation has taken place in the past ten years inside of the browser. As a company, Adobe has helped fuel some of that innovation. For instance, Flash Player has provided developers the ability to run engaging content and applications consistently across browsers. In addition, Flash Player has helped to extend the capabilities of the browser with features like HD video and 3D capabilities.
At the same time, new trends are driving developers to build applications outside of the browser as well. First, real-time communication applications powered by cloud services are becoming increasingly common. Not only are applications like Twitter and Facebook increasing the need for real-time data for consumers, but knowledge workers within the enterprise are increasingly required to be notified of, and to respond to, events the moment they happen.
The overhead of monitoring real-time events within a web browser is often cumbersome since it requires a user to always have a specific page open. With AIR, an application can run in the background and present a notification based on a certain rule. For instance, perhaps you may receive an invitation from a friend to begin watching a television show together.
Running outside of the browser, developers can access powerful API’s that are useful for desktop applications such as the ability to manipulate the system clipboard, introduce advanced drag and drop behaviors into their application, detect when a user is online or offline, display menus and windows that look like the native operating system, create transparent windows, monitor changes to a system folder, manipulate the system tray on Windows or the application dock icon on the Mac, persist data using file APIs or the local embedded database, encrypt data and playback protected content, and so on.
AIR applications are like other desktop applications and must be installed on the local system before they can be invoked.
Frank Sommers: Java developers don't generally have found memories of deploying desktop clients: Although the Java WebStart toolkit has been around for some years, it doesn't provide the best user experience. What are some of the specific technical aspects of AIR that enable it to offer a better user experience? In general, could you describe how the AIR runtime gets installed and updated on a client?
When we were working on AIR 1.0, it was critical that we provided a very tight, clean installation experience and also to make the process of updating both the runtime and an application as simple as possible. For example, we spent a great deal of time thinking about the minimum number of steps necessary to install an application.
Many users download and install the runtime when they go to a developer’s website and click on what we call an install badge. An install badge is a Flash file that detects whether the user has the AIR runtime installed. If the user does not have AIR, the installation wizard adds an additional step asking the user to install the AIR runtime. After installing AIR, the install badge proceeds to install the application. If the runtime is installed, the user is not prompted to install the runtime, of course.
Once the AIR runtime is installed, it does not need to be installed again. Every few weeks, when an AIR application is launched, the runtime checks to see if there is a newer version available on our servers. If so, the user will be prompted to update to the latest version.
We intentionally made the size of the runtime installer small to make for a better user experience. On Windows, the runtime is about a 15 MB download. It’s about 20 MB on the Mac because we ship a universal binary for PowerPC and Intel based machined. For our next major release, we’re working on making these even smaller.
Installing AIR requires administrative privileges and many users in an enterprise environment are not admins on their machine. In these situations, a network administrator deploys software down to the machines using a technology such as SMS. AIR allows IT admins to deploy AIR silently, but they must request a distribution license for the runtime. This is free for enterprise scenarios. IT admins can find out more about this option by going to http://get.adobe.com/air/ and clicking on “Distribute Adobe AIR.”
Frank Sommers: Sun has made great strides into trying to convince computer makers to include Java and, by extension, desktop Java APIs, onto new desktops and notebooks. Does Adobe, too, work with manufacturers to bundle the AIR runtime with new computers?
Rob Christensen: Adobe technologies, such as Flash Player and Adobe Reader, have been widely distributed by OEMs for many years. Relative to other Adobe client technologies, Adobe AIR is relatively new—our first version came out last year—but we are already beginning to see increased interest from OEMs to distribute the AIR runtime. For example, Sony is shipping AIR on some of their new laptops.
Compelling applications powered by AIR are becoming the motivation for OEMs to include the AIR runtime. In some cases, applications powered by AIR are becoming a way for manufacturers to differentiate, for example, their netbooks from others' in the marketplace.
In addition, many enterprise customers in large companies are beginning to submit requests to redistribute the runtime within their own environments. That is very exciting to us. In some cases, AIR is being rolled out to enterprises that have over 100,000 employees.
Frank Sommers: What are some of the ways in which AIR achieves its remarkable cross-platform behavior? What are some of the features an AIR developer should be aware of that don't work the same way on each platform for which AIR is available?
Rob Christensen: AIR is built using web technologies that are designed from the ground up to run across operating systems. These technologies, such as the Flash Player and WebKit, are proven to work well across a wide variety of operating systems.
Nearly all of AIR’s capabilities run the same across operating system. Initially, we came out with Mac and Windows versions for our AIR 1.0 release. It was not until several months later that we released AIR for Linux. However, the minute the AIR runtime shipped on AIR for Linux, thousands of applications suddenly became available to the Linux community.
The developers of these applications originally built these applications on Mac and Windows—many probably never even realized at the time that their applications would someday just work on Linux. However, that is our goal as a runtime—to make it possible to build applications that run the same across Windows, Mac and Linux. That makes it easier for developers to target the reach of the Web instead of being limited to deploying an application to a particular OS or spending significantly more in development costs to port to another OS.
Most AIR API’s are abstracted across the various operating systems, but there are a handful of cases where we felt it made sense to add OS specific capabilities. For example, we provide a system tray icon API on Windows since it is an important UI component. We also have some API’s for manipulating the Mac dock bar icon.
Frank Sommers: AIR includes the SQLite database engine. What are some of the use-cases for persisting data in a local relational database? And what are some of the ways in AIR in which a developer can synchronize locally stored data back to a server's database?
Rob Christensen: Developers are using the local database in a number of ways. For example, local storage can be used to persist application data in games for high scores or level or character data. In other cases, it can be used to cache content locally such as the BBC iPlayer that allows users to download their favorite shows if they live in the U.K.
Another example is the sales person who may want to always have the latest customer information locally such as presentations or salesforce.com data. In fact, salesforce.com provides a toolkit to help interface with their APIs. That toolkit makes it easy to queue up changes when a user is offline for example that connect directly to the Force.com database, logic, and workflows.
Adobe provides a general purpose, powerful server called Adobe LiveCycle Data Services ES that excels at data synchronization as well.
Frank Sommers: In general, could you describe the programming model for working with client-side relational data in AIR? Does AIR include object-relational mapping for ActionScript? Is that being planned for future releases?
Rob Christensen: Though it is possible to build a basic browser in AIR, developing a web browser is really not the design center of AIR. There are already many great web browsers out there today and WebKit is really designed for rendering web content and not for providing all the additional capabilities that make a browser a browser, such as bookmark management.
That capability is quite powerful and does allow developers to have a top-level Flash application that includes HTML that also includes Flash content. It is also possible to include PDF content directly within an application as it will be rendered by Adobe Reader, similar to what is possible with the browser today.
Frank Sommers: Compared with Flex in the browser, how does AIR make working with PDF content easier?
Rob Christensen: The level of support for PDF in AIR is fairly basic at this point but powerful for many common scenarios. For example, the Polish government is using an AIR application to allow its citizens to complete their tax forms electronically. We are considering adding additional support in the future so that you could, for example, draw annotations on top of the PDF as well.
Frank Sommers: What's next for the AIR SDK and APIs? What are some of the new features you're planning in upcoming releases?
Rob Christensen: Our development team is hard at work developing the next version of Adobe AIR which will include some of the most requested features from our development community as well as a few surprises. We will also be updating our system requirements to include the latest operating systems—Snow Leopard for the Mac and Windows 7. In addition, our Linux user base would like to see us support 64-bit CPUs, and so we are also looking into this as well.
Our goal is to have a public beta for the next major version of AIR later this year. We’ll be posting announcements on our blog going forward.
Have an opinion about using Flex with Scala? Discuss this article in the Articles Forum topic, Adobe's Rob Christensen on AIR.
Adobe's AIR SDK
Frank Sommers is Editor-in-Chief of Artima.
This article is sponsored by Adobe.