|
|
Three primary technologies are included within Adobe AIR, and they fall into two distinct categories: application technologies and document 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.
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.
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
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.
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.
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 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.
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.
Applications can consist of the following combinations of technologies:
HTML/JavaScript only.
Flash only (including Flex).
Flash-based with HTML content.
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.
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.
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.
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.
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.
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.
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.
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.
|
|