|
Adobe AIR is designed to enable the development of desktop applications using web technologies.
October 10, 2007
URL:http://www.drdobbs.com/web-development/adobe-air-desktopweb-convergence/202401085
Oliver is a senior computer scientist at Adobe Systems on the Adobe AIR engineering team. He can be reached at [email protected].
Over the last few years, web-based Rich Internet Applications (RIAs) have become increasingly sophisticated. They are leveraging technologies such as HTML, AJAX, Flash, and PDF to add depth and interactivity previously found only in desktop applications. At the same time, these technologies often allow for shorter development times than traditional desktop development environments such as C++.
Still, web-based RIAs are fundamentally limited by the browser security sandbox. They cannot access local filesystems and other devices (such as printers) except via a limited, user-mediated route. They cannot open new windows at will, or run without any windows open. They cannot run when offline. For all their richness, they still fall short of desktop applications in these capabilities.
These restrictions are not a bad thing. The browser security sandbox is essential to keeping the Web safe and, therefore, usable. For many web-based applications, the ease of obtaining the application—simply entering a URL in nearly any browser—more than makes up for the limitations. Desktop applications, on the other hand, do not have to operate with the same security restrictions because they require an installation ritual in which the user elects, by confirming the install, to grant greater access.
Adobe AIR, the code name for an Adobe project (labs.adobe.com/technologies/air) aimed at enabling the development of desktop applications using web technologies, aims to strike a new balance in this game by providing for the development of desktop-based RIAs. These applications can take advantage of filesystem access, windowing, offline storage, and other traditional desktop features, yet are built with the same technologies used for the Web today.
Adobe AIR consists of two pieces:
The "desktop applications" Adobe AIR is targeting are not defined merely by the presence of APIs to enable multiple window support or filesystem access. Adobe AIR targets applications that integrate tightly with the target operating system like traditional desktop applications written in C, C++, or Objective C. For example, Adobe AIR applications are launched from the start menu or dock, appear under their own name in the Activity Monitor or Task Manager, and have their own entry in the Windows Add/Remove Programs control panel (see the TimeTracker application in Figure 1 for an example of an Adobe AIR application).
Adobe AIR is not targeting all desktop applications, however. Applications with extreme size, computational, or other demands are probably not well suited for implementations in web-based technologies or Adobe AIR.
Core to Adobe AIR is its facilitation of deploying and executing Adobe AIR applications built using HTML, AJAX, Flash, and PDF. Like the C, Java, and .NET runtimes, Adobe AIR is a set of libraries and services that enable the execution of applications. The runtime mediates between the application and the underlying operating system. It handles initialization and finalization tasks as the application starts up and shuts down, and provides the application with an API to call underlying operating system services.
Adobe AIR is designed to provide a cross-platform abstraction wherever possible. For example, it provides a filesystem API that already runs on multiple platforms. Applications can be written to this API such that their code is entirely portable.
At the same time, an API that only contains cross-platform abstractions can be unreasonably limiting. Thus, Adobe AIR APIs contain platform-specific capabilities where warranted, which are simply stubbed-out on platforms that don't support them. For example, applications have an API for accessing the Mac OS Dock, but calling it won't have any effect when running on Windows. (Applications can also query to determine which platform they are running on.)
The runtime contains an embedded instance of the Flash player. This instance supports all of the capabilities of the browser plug-in version of Flash. It has been extended with new APIs for the additional functionality offered by Adobe AIR, such as filesystem access.
The runtime also contains an embedded HTML rendering engine based on the open-source WebKit project (www.webkit.org), which also serves as the HTML engine for Apple's Safari browser. Adobe AIR strives to keep the greatest possible compatibility between the embedded instance of WebKit and the version available in Safari. Adobe AIR is not attempting to introduce yet another browser to test against, but rather to leverage the existing browser behavior of WebKit.
The Flash and HTML environments are bridged so that code in either environment can call into the other. For example, ActionScript code in Flash content can traverse the DOM of an HTML document it has loaded. Similarly, HTML content can invoke Flash APIs.
HTML content can be displayed in the Flash display tree using a new HTML object, and Flash can be embedded in the HTML as well. Applications can consist solely of HTML, solely of SWF, or a mix of both types of content.
The runtime does not include embedded PDF rendering support, but instead bridges to an installed copy of Reader (or Acrobat). Thus, PDF rendering in Adobe AIR operates much the same way that PDF rendering does in a browser today. PDF can be embedded in either SWF or HTML content, but an Adobe AIR application cannot consist solely of PDF content. Script bridging to PDF is also implemented: In Adobe AIR, a single line of code can involve execution across all three (Flash, HTML, and PDF) scripting engines.
The runtime is available as a free download from Adobe and is redistributable. The target download size for the runtime is 5-9 MB.
Adobe AIR incorporates web technologies "as is." Many developers using early releases of Adobe AIR have created their first applications simply by taking existing web content—both HTML and SWF—and running it directly in Adobe AIR.
This approach, of course, is only a starting point. Adobe AIR provides new APIs for windowing, filesystem access, network detection, and more. Porting existing content to Adobe AIR is a starting point, but it's taking advantage of new features that will distinguish Adobe AIR applications from existing web applications.
Scripting. HTML, Flash, and PDF are all scriptable via ECMAScript. Of course, they don't call it by this name: HTML and PDF refer to it as "JavaScript," and Flash as "ActionScript." They are all, however, based on the same Standard.
Adobe AIR application developers do not need to pick just one of these technologies, but can combine them in a single application. Adobe AIR bridges scripting environments so that a script in HTML can use objects and APIs defined in Flash, and vice versa.
HTML and AJAX. Adobe AIR provides HTML and AJAX support via the open-source WebKit HTML engine. Although WebKit has obviously been modified to work within Adobe AIR, Adobe's goal is to make sure that HTML content rendered in Adobe AIR renders the same as it does in Safari (and other browsers) based on WebKit.
The display of HTML in Adobe AIR is integrated into the Flash display pipeline. This means that HTML content can be embedded in Flash content. Operations such as rotations, blurs, and so on can be applied to the rendered HTML content. Flash content can also be embedded in HTML inside Adobe AIR.
Flash and Flex. Adobe AIR contains a complete implementation of the Flash player—including the new open-source Tamarin scripting engine (www.mozilla.org/projects/tamarin)—extended with Adobe AIR's new APIs. Significant portions of these new APIs and new functionality are themselves implemented in ActionScript.
Flex provides a framework with additional APIs and support for creating UI in MXML markup. Originally designed for the creation of RIAs running in the browser, Flex produces applications by compiling them to Flash (SWF) content. This content can run in Adobe AIR. Flex is also being extended with new framework features that take advantage of Adobe AIR's APIs.
Adobe AIR developers can choose from a number of different development workflows:
Regardless of which option you choose, there are two available free tools. The first lets Adobe AIR applications be launched without being first installed, which enables rapid turnaround when authoring and debugging applications. The second creates deployment packages for Adobe AIR applications.
Adobe AIR applications are deployed via a single-file, cross-platform installation package that integrates with each platform's native installation technology. This lets Adobe AIR applications be delivered to any platform from a common file, avoiding the need to create separate installers for each platform. At the same time, integration with the platform installer allows for registration of file types, placement of shortcuts, and other capabilities that are not otherwise available. The installation package contains the assets that are used by the application at runtime (SWF or HTML files, for instance), some additional assets used at installation time, a manifest, and a signature.
The package file format is based on ZIP. Because the files are signed (using XML signatures), they cannot be created with just any standard ZIP utility, but Adobe provides a free utility for this purpose. Adobe AIR registers itself as the handler for these installation packages. Activating one of these files (via a double-click) triggers the application installer function in the runtime. Using data from the package manifest, the UI displays the application name, description, and so on to users and asks them to confirm the installation.
As users make a decision, the application installer converts the package contents into a form suitable for the target platform. For example, a native executable is created on the fly. It is given a name matching that of the application and, if images are provided in the installation package for this purpose, assigned the provided icon. This is one of many features that make installed Adobe AIR applications look and feel just like regular desktop applications.
Finally, Adobe AIR provides an API that applications can use to update themselves by providing an updated installation package containing a new version of the application. Combined with network detection and download capabilities, it is straightforward to implement a variety of update policies: optional, forced, payment required, and so on.
Adobe AIR provides basic HTTP support courtesy of Flash, HTML, and PDF and binary client sockets as introduced in Flash 9. Adobe AIR also extends the Flash LocalConnection API to permit communication not only between Adobe AIR applications but also between Adobe AIR applications and Flash content executing in the browser. As with LocalConnection today, applications must opt-in to receive messages from other sources.
These features are designed to allow the creation of web applications and desktop applications that work together, rather than compete. For example, a company may offer both a web-based and Adobe AIR-based version of its interface to perform banking tasks. As a customer, you might use the desktop application at home, but the web-based application from a kiosk. A single click can take users from one to the other.
Just like traditional desktop applications, an Adobe AIR application can perform operations that are dangerous. The file API permits an application to read, write, and delete files and, in combination with the network APIs, a malicious application could render substantial harm.
Adobe AIR mitigates this risk by providing a comprehensive privilege-based security model. Capabilities that are either inherently risky or that can be risky when combined with other capabilities can only be executed by an application that has been granted the necessary privilege.
This model is not simple and is not a first line of defense for typical users. Typical users should, as with all desktop applications, be careful about which applications they choose to install because installation conveys trust. (Adobe AIR uses signed deployment packages to help users make good decisions about which applications to trust.)
For enterprise administrators—and indeed, anyone who acts as an administrator, even if only for a single machine—the privilege model can be used to reduce the risks of running Adobe AIR applications. This feature is not intended to let you run applications that you don't trust in a protective "sandbox"; if you don't trust an application, you shouldn't install it. It is intended to provide an additional measure of assurance that an application you trust not to do certain things is, in fact, not doing those things.
Adobe AIR is targeted at both consumer and enterprise applications. In the enterprise, Adobe AIR will offer the same advantages of rapid development that the use of web technologies will bring to Adobe AIR applications.
Another advantage comes from Adobe AIR's security architecture that lets enterprises run Adobe AIR applications with the additional insurance that these trusted applications nonetheless cannot step outside their administrator-prescribed sandbox.
Other features are designed to be enterprise friendly, too. For example, enterprises often use native installation technologies to manage installations across a large number of machines. Adobe will provide a free tool that administrators can use to convert Adobe AIR deployment packages into native installation packages (MSI files). These MSI files can then be deployed using existing infrastructures, such as Microsoft SMS or IBM Tivoli.
Adobe AIR will provide a cross-platform runtime environment that will enable the development of desktop applications using web technologies. We believe this will enable the melding of great web experiences with the advantages of true desktop applications, both for developers and for users.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.