The Adobe Integrated Runtime, or AIR, allows you to take the skills that you have already developed in building rich Internet applications and apply them to desktop applications. Your applications need not be bound to a Web browser; with AIR, you can create true desktop applications that work across multiple platforms.
The foundation of these cross-platform applications is the Adobe Integrated Runtime. Similar conceptually to the Java Runtime, Adobe's runtime allows you to develop an application once and be assured that it will run in Windows, Macintosh, or Linux environments. The runtime takes your code and translates it into platform-specific code so that you do not need to worry about any differences that may exist.
Your users must have AIR installed on their machines in order to run your application. However, the installation is seamless: When a user attempts to install your application, the installer will check to see if AIR exists on the user's computer and will automatically download and install it if needed. AIR is free to both you and your users.
As of this writing, Adobe offers three primary tools for developing AIR applications: Dreamweaver CS4, the Flex platform, and Flash CS4 Professional. If you are familiar with developing applications using XHTML, CSS, and possibly Ajax, then you can apply those skills directly to AIR development using Dreamweaver CS4. Flex developers can create AIR applications through the open-source Flex SDK, or they can use Flex Builder, Adobe's commercial tool for Flex development.
Flash CS4 Professional introduced AIR development to the Flash community. The remainder of this chapter covers the basics of creating a simple AIR application using Flash.
The runtime for AIR includes an integrated Web browser based on the open-source WebKit rendering engine, the same engine used by Apple for its Safari browser and by Adobe for Dreamweaver CS4's Live View feature. Thus, any XHTML, CSS, and Ajax that are supported by WebKit can be used with AIR. AIR also includes the Adobe Reader software, enabling it to view PDF files. The runtime includes a copy of the SQLLite database for data storage, and most importantly for this discussion, it includes a full copy of Flash Player 10.
AIR applications can do anything that your Web application could do. Your application can display images, PDF files, and Flash movies. It can play sound and video. It can access server-based resources.
For security reasons, Web-based applications, whether written in Flash or HTML or any other technology, do not have local file system access. Web applications can write cookies to the user's hard drive and then later read those cookies, but that is the extent of the browser's access to your user's hard drive. A browser-based system cannot, for example, open a Microsoft Word document on the user's hard drive.
AIR applications do not suffer from this limitation. Because an AIR application is installed on your user's computer, it can fully access the user's hard drive, allowing for not only reading and writing existing files, but even for creating and deleting files. AIR applications also have access to other hardware on the user's machine, such as the printer, and they can access and consume network resources. It is these additional capabilities that will set your AIR application apart from traditional Web applications.
Because AIR includes Flash Player 10, any ActionScript that you would write in a traditional, Web-based Flash movie can be written for an AIR application. Adobe has also created a set of classes for ActionScript that are specific to AIR to enable the additional functionality available in those applications. For example, ActionScript includes a set of SQL classes to allow you to interact with AIR's built-in SQLLite database. The complete ActionScript Language and Components Reference, available at http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/, designates these AIR-only classes by placing a small AIR logo next to each.
You can have an AIR application and a Web application that perform the same tasks. In certain situations, it may be helpful to have some users access the application via a traditional Web- and browser-based interface and have others download and install an AIR application. Although the AIR application and the Web-based application will need to be two separate files, they can be created from the same source: You could create your Web application, save a copy, and then convert that copy to AIR. Unfortunately, it will then be necessary to maintain both independently; changes to one would not be reflected automatically in the other. You may also end up adding additional, AIR-specific functionality to that application that would not apply to the Web version.
Obviously, Web applications are built with the assumption that the user will be online when he or she interacts with the application. Desktop applications, however, are not always built with this assumption. You can use Microsoft Word or Adobe Photoshop in the same way whether you are connected to the Internet or not.
AIR applications can be built so that they require an Internet connection. For example, you might be populating the application with information that must be requested at runtime from a server. However, because the applications are desktop applications, they can also be built to run without a connection. AIR includes the SQLLite database for exactly this reason: Your application can keep its own set of data internally, without the need to connect back to a server.
Your application can also be written so that it can run in either scenario. You might, for example, have the application make a call back to a server if available to get data, but if the server is unavailable, it could simply use data stored internally.
Once installed, your AIR application will work exactly like any other application on your users' computers. If they use Windows, they can access it from the Start menu; on Macintosh, it will be available in the Dock. Either way, your application will be represented in the operating system by an icon. You can use the default icon for AIR applications, which looks like a rocket blasting off; this is a reference to "Apollo," AIR's development codename. You can also create your own custom icon, using any modern graphics application such as Adobe Fireworks, Photoshop, Illustrator, or even Flash itself. The icon must be in PNG format, and you can create up to four icons, at sizes of 128 pixels x 128 pixels, 48 × 48, 32 × 32, and 16 × 16.
While working in Flash CS4 Professional, you can test AIR applications just as you would a regular Flash application, by pressing Ctrl + Enter on Windows or
You need to designate to Flash that you are creating an AIR application so that when it is published, Flash creates an AIR file, rather than the traditional SWF. You can do this in the Publish Settings dialog box on the Flash tab by selecting AIR 1.1 under the player version. You can also have Flash do this for you by simply selecting Flash File (Adobe AIR) from the Start screen, as shown here, or from the New Document dialog box.
Regardless of the method used to set the application to AIR, you need to configure some settings for the application through the Publish Settings dialog box. In the AIR settings, you can designate a name and version for your application, provide a description that will be visible when your user installs the application, insert copyright data, and configure the installer.
After you have configured these settings, you can proceed with the development of your project. When you begin planning an AIR application, you should keep in mind that everything you would normally do in a Flash application can be done in AIR. Therefore, most of the design and development process will be identical in both cases. You can therefore add text fields to capture user input, insert images, add symbols, and include animation. The ActionScript needed to handle all of these is identical to that needed for a regular Flash movie.
Remember that your AIR application will be running independent of the browser. Although many Flash developers tend to keep their Flash movies small to allow for room for the browser's menus and toolbars and for any HTML that might be on the page, you can make your AIR application any size that you want.
Note
If you do not see the Start screen, click File
The file is created.
The Publish Settings dialog box appears.
The Settings dialog box appears.
You are returned to the Publish Settings dialog box.
The new file is created and configured to run on AIR.
Most of the settings for AIR are beyond the scope of this chapter, the purpose of which is merely to provide an introduction to AIR development, not a comprehensive look at it. Much more information on developing AIR applications can be found online at www.adobe.com/products/air/ or in Adobe AIR Bible, by Benjamin Gorton, Ryan Taylor, and Jeff Yamada, published by Wiley.
You may also want to download and install the Tour de Flex application, available from www.flex.org/tour. Itself an AIR application, Tour de Flex was created by the Adobe Flex team as a resource for its developers. Although obviously focused on Flex, the application does include a comprehensive ActionScript resource, valuable to anyone using either Flex or Flash, and it includes all the AIR-specific classes, along with examples.
As you are no doubt aware, many malicious programs exist on the Internet. When you download a program such as the latest version of Flash Player, you can be confident that you are getting the actual application created by Adobe, and not a piece of malware that happens to have the same filename as the Flash Player installer, because the software will identify itself as having been created by Adobe. This identification is done via a digital signature.
You should digitally sign your AIR applications so that your users know that the program is coming from you, a presumably trusted source. In fact, AIR applications require a digital signature; you can create an intermediate, unsigned file for testing but cannot distribute an unsigned file.
You can create your own digital signature, which simply identifies you as the program's developer, in the AIR Settings dialog box. You can create a new signature file if you do not already have one, in which you will identify yourself, create a password, and determine the level of encryption to be used by the signature file.
Once created, you can specify the location on your computer of the signature file and a password to prevent others from signing their programs as you whenever you create another AIR application.
This signature information will be displayed on the first screen of the installation process for the application. Your users can review this and, if they recognize that you are a developer who they trust, they can install the application.
The Settings dialog box appears.
The Digital Signature dialog box appears.
The Create Self-Signed Digital Certificate dialog box appears.
You are returned to the Digital Signature dialog box.
You are returned to the Settings dialog box.
The digital signature is created and saved with the file.
When your users install an AIR application that uses a self-signed certificate, they will receive a security warning stating that the publisher is unknown. This is because self-signed certificates cannot be trusted. There is nothing to prevent you from claiming to be anyone when you set up the certificate. In other words, in the steps shown here, you could easily enter a publisher name of "Adobe Systems, Inc."
The solution to this issue is to use a certificate issued by a trusted third party. When you install an AIR application that is actually created by Adobe, AIR will not generate the security warning because the certificate is not one created by Adobe, but instead Verisign. Verisign is the industry leader in certificates; almost all the certificates used to identify Web sites in e-commerce transactions, where the same issues exist, come from Verisign. If you want to distribute your application and have it be trusted, you need to go to Verisign's Website at www.verisign.com and purchase a certificate.
AIR applications have the capability to detect whether users are interacting with their computers and can respond based on this interaction. This is similar to the concept used by your computer's screensaver: After you have failed to interact with your computer for a number of minutes, it turns the screensaver on. An AIR application can be set up to simply display a status message informing the users that they have been inactive, or it can perform other actions such as logging inactive users out of an application or automatically saving data.
Your AIR application is represented in ActionScript as the nativeApplication instance of the NativeApplication class. This class provides a set of methods and properties that allows you to interact with the application as a whole. One of these properties is idleThreshold, which can be set to an integer representing a number of seconds. Any time your users stop interacting with the application by not using either their keyboard or their mouse, AIR will begin an internal countdown; when this countdown reaches the value of idleThreshold, a userIdle event will be dispatched. Note that unlike many other timer functions in ActionScript, idleThreshold is set to a number of seconds, not milliseconds.
You can create an event handler to listen for this event and deal with it accordingly. In the example shown here, a message will be displayed, informing the users that they have timed out, using the trace method. For the purposes of the example, a very low threshold is being set; obviously, for real applications, you would want this number set much higher.
When you use idleThreshold, you are not just detecting that the user is inactive. AIR applications can also be used to detect the opposite: When the next keyboard or mouse action occurs, a userPresent event is triggered. This could be used to display a "Welcome Back" message or something similar to the user.
Should you need to determine precisely how many seconds have elapsed since the last user input, you can read the lastUserInput property of nativeApplication. For example, you may have an application that users must log in to and plan to use idleThreshold to automatically log them out after a period of time. You can then use the lastUserInput property to display a warning to users shortly before they are logged out to tell them that they need to do something to prevent being logged out.
One of the nicest features of AIR is its local file system access. Because it is an application that has been installed locally on a machine, it has full access to the user's hard drive, meaning that AIR applications can not only read, but also write data to the local file system.
One practical application of this is a simple word processor. You can use a text field for input, setting it to allow multiple lines and wrap text. Unfortunately, Flash does not include a rich text editor that would allow for formatting, although third-party components for this do exist. Keep in mind, however, that Flash text fields do support a subset of HTML, so basic formatting is possible.
After the users have entered their text, they could click a Save button. In a word processor, they would expect a dialog box to open to prompt them to name the file and provide a location for it. In your AIR application, you can have this same functionality, thanks to the File and FileStream classes. The File class includes a browseForSave method that generates a Save As dialog box. It can take as an argument a string, representing the title of the dialog box.
The browseForSave method generates a SELECT event when the user clicks the Save button in the Save As dialog box. Using this event, you can invoke an instance of the FileStream class. You can use the open method of this class to open the new file, the writeUTFBytes method to write the data to it, and the close method to close it, all of which have the effect of creating a new file on the user's computer.
You can control the directory that initially appears in the Save As dialog box by setting the File instance to either File.desktopDirectory or File.documentsDirectory. The former will open the dialog box at the desktop; the latter will open it in the user's documents folder:
var fileInstance:File = File.desktopDirectory(); var fileInstance:File = File.documentsDirectory();.
The File class contains many more properties and a host of useful methods; you can explore these at http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/filesystem/File.html.
The example shown in this section writes the data using the FileStream's writeUTFBytes method, which takes a string of text encoded as UTF-8 and writes it to the file. Other write methods of the class include writeBoolean, writeByte, writeBytes, writeDouble, writeFloat, writeInt, writeMultiByte, writeObject, writeShort, writeUnsignedInt, and writeUTF. You can explore the rest of the methods and properties of the class at http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/filesystem/FileStream.html.