Adobe AIR is a cross-platform desktop runtime created by Adobe that allows web developers to use web technologies to build and deploy Rich Internet Applications (RIAs) and web applications to the desktop.

To better understand what Adobe AIR enables, and which problems it tries to address, it is useful to first take a look at the (relatively short) history of web applications.

A Short History of Web Applications

Over the past couple of years, there has been an accelerating trend of applications moving from the desktop to the web browser. This has been driven by a number of factors, which include:

• Growth of the Internet as a communication medium
• Relative ease of deployment of web applications
• Ability to target multiple operating systems via the browser
• Maturity of higher-level client technologies, such as the browser, JavaScript frameworks and the Flash Player runtime

Early web applications were built primarily with HTML and JavaScript, which, for the most part, relied heavily on client/ server interactions and page refreshes. This page refresh model was consistent with the document-based metaphor for which the browser was originally designed, but provided a relatively poor user experience when displaying applications.

With the maturation of the Flash Player runtime, however, and more recently with Ajax-type functionality in the browser, it became possible for developers to begin to break away from page-based application flows. Developers began to offer richer application experiences via the browser. In a white-paper from March 2002, Macromedia coined the term rich Internet application to describe these new types of applications in browsers, which "blend content, application logic and communications ... to make the Internet more usable and enjoyable."

These applications provided richer, more desktop-like experiences, while still retaining the core cross-platform nature of the Web:

Internet applications are all about reach. The promise of the web is one of content and applications anywhere, regardless of the platform or device. Rich clients must embrace and support all popular desktop operating systems, as well as the broadest range of emerging device platforms such as smart phones, PDAs, set-top boxes, game consoles, and Internet appliances.

The paper goes on to list some features that define RIAs:

• Provide an efficient, high-performance runtime for executing code, content, and communications
• Integrate content, communications, and application interfaces into a common environment
• Provide powerful and extensible object models for inter-activity
• Enable rapid application development through components and reuse
• Enable the use of web and data services provided by application servers
• Embrace connected and disconnected clients
• Enable easy deployment on multiple platforms and devices

This movement toward providing richer, more desktop-like application experiences in the browser (enabled by the Flash Player runtime, and more recently by JavaScript and Ajax) has led to an explosion of web applications.

Today, the web has firmly established itself as an application deployment platform that offers benefits to both developers and end-users. Some of these benefits include the ability to:

• Target multiple platforms and operating systems
• Develop with relatively high-level programming and layout languages
• Allow end-users to access their applications and data from virtually any Internet-connected computer
• Easily push application updates to users

The growth of web applications can be seen in both the Web 2.0 trend, which consists almost entirely of web-based applications and APIs, and the adoption of web applications as a core business model by major companies and organizations.

Problems with Delivering Applications via the Browser

As web applications have become more complex, they have begun to push the boundaries of both the capabilities of the browser and the usability of the application. As their popularity grows, these issues become more apparent and important and highlight the fact that there are still a number of significant issues for both developers and end-users when deploying and using applications within the browser.

The web browser was originally designed to deliver and display HTML-based documents. Indeed, the basic design of the browser has not shifted significantly from this purpose. This fundamental conflict between document- and application-focused functionality creates a number of problems when deploying applications via the browser.

Conflicting UI

Applications deployed via the browser have their own user interface, which often conflicts with the user interface of the browser. This application-within-an-application model often results in user interfaces that conflict with and contradict each other. This can lead to user confusion in the best cases, and application failure in the worst cases. The classic example of this is the browser's Back button. The Back button makes sense when browsing documents, but it does not always make sense in the context of an application. Although a number of solutions attempt to solve this problem, they are applied to applications inconsistently, and users may not know whether a specific application supports the Back button or whether it will force their application to unload, causing it to lose its state and data.

Distance from the Desktop

Due in part to the web security model (which restricts access to the user's machine), applications that run in the browser often do not support the types of user interactions with the operating system that people expect from applications. For example, you cannot drag a file into a browser-based application and have the application act on that file. Nor can the web application interact with other applications on the user's computer.

RIAs have tried to improve on this by making richer, more desktop-like interfaces possible in the browser, but they have not been able to overcome the fundamental limitations and separation of the browser from the desktop.

While there are projects underway (such as Google Gears, Yahoo's BrowserPlus, and new browser API and functionality additions) that aim to lessen the gap between the browser and the desktop, they are still in the early stages, with no clear winner / standard emerging. Not only can the presence of such functionality not be depended on (yet), but the availability of multiple implementations and solutions threaten to further fragment the development experience for the browser.

Primarily Online Experience

Because web applications are delivered from a server and do not reside on the user's machine, web applications are primarily an online experience. Although attempts are underway to make offline web-based applications possible (through plugins and HTML 5), they do not provide a consistent development model and they fail to work across different browsers, or they require users to install additional extensions to the browser. In addition, they often require users to interact with and manage their application and browser in complex and unexpected ways. However, this is an area where the browser looks to make progress over the next couple of years.

Lowest Common Denominator

Finally, as applications become richer and more complex and begin to push the boundaries of JavaScript and DHTML, developers are increasingly faced with differences in browser functionality and API implementations. Although these issues can often be overcome with browser-specific code, they lead to code that a) is more difficult to maintain and scale; and b) takes time away from function-driven development of feature functionality.

Although JavaScript frameworks are a popular way to help address these issues, they can offer only the functionality provided by the browser, and often they resort to the lowest common denominator of features among browsers to ease the development model. The result for JavaScript- or DHTML-based applications is a lowest common denominator user experience and interaction model, as well as increased development, testing, and deployment costs for the developer.

As browser continue to mature this lowest common denominator of usable functionality will improve, but this is a process that can take a significant amount of time (often years) as new browsers are released, and old browsers are no longer used.

The fact that web applications have flourished despite these drawbacks is a testament to the attractiveness of having a platform with a good development model that has the ability to deliver applications to multiple operating systems. A platform that offered the reach and development model of the browser, while providing the functionality and richness of a desktop application, would provide the best of both worlds. This is what Adobe AIR aims to provide.

Introducing Adobe AIR

So, what is Adobe AIR, and how can it compliment web application development and deployment?

Adobe AIR is a cross-operating-system runtime developed by Adobe that allows web developers to leverage their existing web development skills (such as Flash, Flex, HTML, Java-Script, and PDF) to build and deploy RIAs and content to the desktop.

In essence, Adobe AIR provides a platform in between the desktop and the browser, which combines the reach and ease of development of the web model with the functionality and richness of the desktop model.

It is important to step back for a second and point out what Adobe AIR is not. Adobe AIR is not a general desktop runtime meant to compete with lower-level application runtimes. Adobe AIR is coming from the Web to the desktop and is targeted at web developers. Its primary use case is to enable web applications and RIAs to be deployed to the desktop. This is a very important but subtle distinction, as enabling web applications and RIAs on the desktop is the primary use case driving the Adobe AIR 1.0 feature set.

At its core, Adobe AIR is built on top of web technologies, which allow web developers to develop for and deploy to the desktop using the same technologies and development models that they use today when deploying applications on the Web.

Primary Adobe AIR Technologies

Three primary technologies are included within Adobe AIR, and they fall into two distinct categories: application technologies and document technologies.

Primary Application Technologies

Application technologies are technologies that can be used as the basis of an application within Adobe AIR. Adobe AIR contains two primary application technologies, HTML and Flash, both of which can be used on their own to build and deploy Adobe AIR applications.

Adobe Flash

The first core application technology that Adobe AIR is built on is Adobe Flash Player. Specifically, Adobe AIR is built on top of Adobe Flash Player 9, which includes the ECMA-Script-based ActionScript 3 scripting language, as well as the open source Tamarin virtual machine (which will be used to interpret JavaScript in future versions of Firefox).

Not only are all of the existing Flash Player APIs available within Adobe AIR, but some of those APIs have also been expanded and/or enhanced. Some of the functionality that the Flash Player provides to Adobe AIR includes:

• Just-in-time Interpreted ActionScript engine for speedy application performance
• Full networking stack, including HTTP and RTMP, as well as Binary and XML sockets
• Complete vector-based rendering engine and drawing APIs
• Extensive multimedia support including bitmaps, vectors, audio, and video

Of course, the Adobe Flex 3 RIA framework is built on top of ActionScript 3, which means that you can take full advantage of all of the features and functionality that Flex offers in order to build Adobe AIR applications.

HTML/JavaScript

The second core application technology within Adobe AIR is HTML and JavaScript. This includes a full HTML rendering engine, which has support for:

• HTML
• JavaScript
• CSS
• XHTML
• Document Object Model (DOM)

The same WebKit rendering engine is used in all version of Adobe AIR, regardless of which operating system it is running on. This has a number of implications. First, it means that when developing HTML and JavaScript content, you do not have to worry about compatibility issues in browser implementations. Second, you can take advantage of advanced HTML, JavaScript and CSS functionality available within WebKit, again, without having to worry about that functionality being present across different browser versions.

Yes, you read that right. You don't have to use Flash to build Adobe AIR applications. You can build full-featured applications using just HTML and JavaScript. This usually surprises some developers who expect Adobe AIR to focus only on Flash.

However, at its core, Adobe AIR is a runtime targeted at web developers using web technologies-and what is more of a web technology than HTML and JavaScript?

The HTML engine used within Adobe AIR is the open source WebKit engine. This is the engine behind a number of browsers, including KHTML on KDE and Safari on Mac OS X.

Why WebKit?

Adobe spent a considerable amount of time researching which HTML engine to use within Adobe AIR and used a number of criteria that ultimately led them to settle on WebKit.

Open project.

Adobe knew from the very beginning that it did not want to create and maintain its own HTML rendering engine. Not only would this be an immense amount of work, but it would also make it difficult for developers, who would then have to become familiar with all of the quirks of yet another HTML engine.

WebKit provides AIR with a full-featured HTML engine that is under continuous development by a robust development community that includes individual developers as well as large companies such as Nokia and Apple. This allows Adobe to focus on bug fixes and features, and also means that Adobe can actively contribute back to WebKit, while also taking advantage of the contributions made by other members of the WebKit project.

Proven technology that web developers know

As discussed earlier, one of the biggest problems with complex web development is ensuring that content works consistently across browsers. While something may work perfectly in Firefox on the Mac, it may completely fail in Internet Explorer on Windows. Because of this, testing and debugging browser-based content can be a nightmare for developers.

Adobe wanted to ensure that developers were already familiar with the HTML engine used within Adobe AIR, and that they did not have to learn new all of the quirks and bugs of a new engine. Since Safari (which is built on top of WebKit) is the default browser for Mac OS X, developers should be familiar with developing for it.

Minimum effect on runtime size.

The WebKit code base was well-written and organized and had a minimal impact on the final Adobe AIR runtime size.

Proven ability to run on mobile devices

While the first release of Adobe AIR runs only on personal computers, the long-term vision is to extend the runtime from the desktop to cell phones and other devices. WebKit has a proven ability to run on such devices and has been ported to cell phones by both Nokia and Apple.

Primary Document Technologies

Document technologies within Adobe AIR refer to technologies that can be used for the rendering of and interaction with electronic documents.

PDF and HTML are the primary document technologies available within Adobe AIR.

PDF

The Portable Document Format (PDF) is the web standard for delivering and displaying electronic documents on the Web.

PDF functionality requires that Adobe Reader Version 8.1 be installed on the user's computer. If Adobe Reader 8.1 is installed, Adobe AIR applications will be able to take full advantage of all of the features that reader also exposes when running within a web browser.

HTML

HTML was originally designed as a document technology, and today it provides rich and robust control over content and text layout and styling. HTML can be used as a document technology within Adobe AIR-both within an existing HTML application as well as within a Flash-based application.

What Does An Adobe AIR Application Contain?

Now that we know what technologies are available to applications running on top of Adobe AIR (see Figure 1-1), let's look at how those technologies can be combined to build an Adobe AIR application.

[IMAGE] Figure 1-1 Adobe AIR Application Structure

Applications can consist of the following combinations of technologies:

• Flash only (including Flex)
• Flash-based with HTML content
• HTML/JavaScript only
• HTML/JavaScript-based with Flash content
• All combinations can also leverage PDF content

Technology Integration and Script Bridging

Because WebKit and Adobe Flash Player are included within the runtime, they are integrated with each other on a very low level. For example, when HTML is included within Flash content, it's actually rendered via the Flash display pipeline, which, among other things, means that anything you can do to a bitmap within the Flash Player (blur, rotate, transform, etc.) you can also do to HTML.

This low-level integration also applies to the script engines within Adobe AIR that run ActionScript and JavaScript. Adobe AIR enables script bridging between the two languages and environments, which makes the following possible:

• JavaScript code can call Adobe AIR, Flash Player, and ActionScript APIs.
• ActionScript code can call JavaScript APIs.
• ActionScript code can directly manipulate the HTML DOM.
• Event registration can occur both ways between Java-Script and ActionScript.

Note that the script bridging is "pass by reference." So, when passing an object instance from JavaScript to ActionScript (or vice versa), changes to that instance in one environment will affect the instance in the other environment. Among other things, this makes it possible to instantiate and use Flash Player APIs directly from JavaScript, or to register and listen for events.

This low-level script bridging between the two environments makes it very easy for developers to create applications that are a combination of both HTML and Flash.

The end result of all of this is that if you are a web developer, then you already have all of the skills necessary to build an AIR application.

Adobe AIR Functionality

If Adobe AIR did not provide additional functionality and APIs and simply allowed web applications to run on the desktop, it would not be quite as compelling. Fortunately, Adobe AIR provides a rich set of programming APIs, as well as close integration with the desktop that allows developers to build applications that take advantage of the fact that they're running on the user's desktop.

Adobe AIR APIs

In addition to all of the functionality and APIs already offered by the Flash Player and WebKit engine, Adobe AIR provides additional functionality and APIs.

Some of the functionality includes, but is not limited to:

• Complete file I/O API
• Complete native windowing API
• Complete native menuing API
• Online/offline APIs to detect when service connectivity has changed
• Complete control over application chrome
• Local storage/settings APIs
• Application update APIs
• Ecrypted data storage
• SQLite embedded database

Note that functionality may be implemented directly within the runtime or on the framework layer (in Flex and JavaScript), or by using a combination of both.

Adobe AIR desktop integration

As discussed earlier, applications deployed via the browser cannot always support the same user interactions as desktop applications. This leads to applications that can be cumbersome for the user to interact with, as they do not allow the types of application interactions with which users are familiar.

Because an AIR application is a desktop application, it's able to provide the types of application interactions and experience that users expect from an application. This functionality includes, but is not limited to:

• Appropriate install/uninstall rituals
• Desktop install touch points (such as shortcuts)
• Rich drag-and-drop support:
  • Between the operating system and AIR applications
  • Between AIR applications
  • Between native applications and AIR applications
• Rich clipboard support
• System notifications
• Native icons
• Ability to capture command line arguments

Once installed, an AIR application is just another native application, which means that the operating system and users can interact with it in the same way they do with any other application. For example, things such as OS-level application prefetching and application switching work the same with Adobe AIR applications as they do with native applications.

The goal is that the end-user does not need to know they are running an AIR application to be able to use it. They should be able to interact with the application in the same way that they interact with any other application running on the desktop.

Security Model

All of this talk of APIs and desktop functionality brings up an important question: what about security? Because Adobe AIR applications have access to local resources, couldn't they theoretically do something harmful?

First, it is important to note that Adobe AIR runs on top of the operating system's security layer. It does not provide any way to get around or subvert this security. This is important, because it means Adobe AIR applications can work only within the permissions given to them by the operating system and will be subject to all current and any new security capabilities that the OS implements.

To run an Adobe AIR application, a user must download the application to the desktop, go through an install ritual, and then launch the application. This is an experience very similar to downloading and installing a desktop application. The similarity is not an accident. Adobe AIR applications run in a fundamentally different security content than applications that run within a browser. It is a security context closer to that of a native application than a web application.

Browser Security Model Overview

To enable safe browsing, the browser security model limits all I/O capabilities of web applications. This includes restricting their ability to work with local resources, limiting what network resources are accessible, and constraining their user interface. The browser only allows applications to connect with data that is associated with (usually, provided by) a server located on a single web domain. In addition, the browser provides a trusted UI for users to understand the origin of the application and control the state of the application. This model is sufficient for applications that are connected to a single service provider and rely on that service for data synchronization and storage.

Some web developers have also stretched the browser security model by integrating data from multiple sources and/or by experimenting with user interfaces that are inconsistent with the browser chrome. Some of these applications require browser plug-ins with capabilities that aren't currently provided by the browsers. Others take advantage of browser features such as user notification or customized security configurations to allow greater or lesser security to applications from specific domains. These mechanisms allow web developers to build more powerful applications, but they also are straining the browser security model.

Implications for the AIR Security Model

Rather than trying to extend the web browser so that it can act as both a browser and a flexible application runtime, Adobe AIR provides a flexible runtime for building applications using web technologies. Adobe AIR allows web developers to build applications that incorporate data from multiple sources, provide users with control over where and how their data is stored, and produce user experiences that are not possible within the browser's user interface. Because Adobe AIR applications must be installed on the desktop and require users to specifically trust them, AIR applications can safely exercise these capabilities. Browser-based applications cannot be granted these capabilities if the browser is to continue to fulfill its role as an application for safely browsing any website on the Internet.

The Adobe AIR security model has a number of implications for application developers and users. For application developers, it means that content within an installed AIR application has capabilities that should not be exposed to any untrusted content, including files from the Web. The runtime has a number of features that are designed to reinforce that distinction and to help developers build applications using security best practices.

This also means that users should not install Adobe AIR applications from sources they do not trust. This is very similar to current practices for native desktop applications and for browser plug-ins. Many applications and web content require that a browser plug-in (such as Flash Player or Apple Quick-Time) be installed in order to work. The Firefox browser has a very accessible extensibility layer that essentially allows any developer to extend the browser. These applications, plug-ins, and extensions can do potentially harmful things and therefore require that the user trust the source of the content.

Finally, one of the capabilities that included in Adobe AIR is the ability of the runtime to verify the identity of an application's publisher of an application that has bee digitally signed by a certificate issued by a trusted Certificate Authority (CA). Users should carefully consider whether they want to trust the publisher of an application, as well as whether they want to install an application whose origin cannot be verified by the runtime.

Adobe AIR Development Toolset

One of the reasons web applications have been successful is that they allow developers to easily deploy applications that users can run regardless of which operating system they are on. Whether on Mac, Windows, Linux, Solaris, or cell phones, web applications provide reach.

However, success is based not only on cross-platform deployment, but also on the cross-platform nature of the development environment. This ensures that any developer can develop for -and leverage-the technology. Neither the runtime nor the development tools are tied to a specific OS.

The same is true of Adobe AIR. Not only does Adobe AIR provide the cross-platform reach of web applications, but, just as importantly, Adobe AIR applications can be developed and packaged on virtually any operating system.

Because Adobe AIR applications are built with existing web technologies such as HTML and Flash, you can use the same tools that you use to create browser-based content to create Adobe AIR applications. The Adobe AIR SDK provides two free command-line tools that make it possible to test, debug, and package Adobe AIR applications with virtually any web development and design tool.

ADL	Allows Adobe AIR applications to be run without having to first install them
ADR	Packages Adobe AIR applications into distributable installation packages

Although Adobe has added support to its own web development and design tools for authoring Adobe AIR content (including Adobe Flex Builder, Adobe Flash CS3, and Adobe Dreamweaver), Adobe programs are not required to create applications. Using the Adobe AIR command-line tools, you can create an AIR application with any web development tool. You can use the same web development and design tools that you are already using today.

Is Adobe AIR the End of Web Applications in the Browser?

So, by this point, you may be saying to yourself, "Gee, Adobe AIR sure sounds great! Why would anyone ever want to deploy an application to the browser again? Is Adobe AIR the end of web applications within the browser?"

No.

Let's repeat that.

No.

Adobe AIR addresses many of the problems with deploying web applications via the browser. However, there are still advantages to deploying applications via the browser. The fact that there are so many web applications despite the disadvantages discussed earlier is a testament to the advantages of running within the browser. When those advantages outweigh the disadvantages, developers will still deploy their applications via the web browser.

But it's not necessarily an either/or question. Because Adobe AIR applications are built using web technologies, the application that you deploy via the web browser can be quickly turned into an Adobe AIR application. You can have a web-based version that provides the browser-based functionality, and then also have an AIR-based version that takes advantage of running on the desktop. Both versions could leverage the same technologies, languages, and code base. Indeed, some of the most popular early Adobe AIR applications, such as twhirl and eBay Desktop, complement existing web applications.

Adobe AIR applications complement web applications. They do not replace them.