Adobe AIR for JavaScript Developers Pocket Guide

Chapter 1. Introduction to Adobe AIR

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.

Note

During its development cycle, Adobe AIR was referred to in public by its code name of “Apollo”.

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 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 whitepaper 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.

Note

You can find the complete whitepaper and more information on RIAs at http://download.macromedia.com/pub/flash/whitepapers/richclient.pdf.

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 interactivity

• 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 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.

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, 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.

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.

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 make web application development and deployment better?

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, JavaScript, 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.

HTML/JavaScript

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

• HTML

• JavaScript

• CSS

• XHTML

• Document Object Model (DOM)

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.

Note

You can find more information on the WebKit open source project at http://www.webkit.org.

See Chapter 3 for a more in-depth discussion of WebKit within Adobe AIR.

Adobe Flash

The second 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 ECMAScript-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).

Note

You can find more information on the open source Tamarin project on the Mozilla website, at http://www.mozilla.org/projects/tamarin/.

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

Note

Flash Player and ActionScript APIs are available to JavaScript within Adobe AIR applications.

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.

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.

Figure 1-1. Adobe AIR application structure

Applications can consist of the following combinations of technologies:

• HTML/JavaScript only.

• HTML/JavaScript-based with Flash content.

• Flash only (including Flex).

• Flash-based with HTML content.

• All combinations can 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 JavaScript 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.

Note

We cover accessing ActionScript and Adobe AIR APIs from JavaScript in more detail in Chapter 3.

The result of all of this is that if you are a web developer using HTML and JavaScript, you already have all of the skills necessary to build an Adobe 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.

Note

Adobe AIR APIs are available to both ActionScript and JavaScript.

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

• System notification APIs that tie into OS-specific notification mechanisms (not implemented in beta)

• Application update APIs

• 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

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 as 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 he is running an AIR application to be able to use it. He should be able to interact with the application in the same way that he interacts 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 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.

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.

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 QuickTime) 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 will be included in the Adobe AIR 1.0 release is the ability of the runtime to verify the identity of an application’s publisher. Users should carefully consider whether they want to trust the publisher of an application, as well as whether they want to install an application that hasn’t been signed.

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
ADT	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.

Note

We will cover the development workflow in depth in Chapter 2.

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 Finetune Desktop and eBay Desktop, complement existing web applications.

Note

You can find more information on Finetune Desktop at http://www.finetune.com/desktop/.

You can find more information on eBay Desktop at http://desktop.ebay.com.

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