Chapter 1. Introducing Adobe AIR

 

 

Whether you’re using HTML, Flash, Flex, or any of the other myriad technologies, there’s one common thread among them: all these applications are built using technologies that are designed for the Web. That’s fantastic if your goal is to build a web application, but it’s a real bummer if you want to build a desktop application. Adobe integrated runtime (AIR) solves this problem for you. Using Adobe AIR, you can leverage your existing web application skills with Flash and Flex (and HTML and JavaScript) to create desktop applications. This is an exciting prospect.

Every flight starts with a preparation for takeoff. Your journey through Adobe AIR is no different. We’ll start you off with a review of AIR and then delve into how you can use Flex and Flash to build AIR applications. Specifically, we’ll look at necessary introductory concepts for creating a solid foundation with AIR, such as these:

• The different parts of Adobe AIR—including the runtime environment, installers, and AIR applications—and the relationships among all these parts.
• Application security and authenticity issues, including digital signing. You’ll learn what digital signing is, different types of digital signing, and why and when to choose which.
• Basic steps for creating AIR applications using Flex Builder, Flash CS3, or the Flex 3 SDK.

Without any further ado, let’s go ahead and jump to understanding what this whole AIR thing is about.

1.1. Anatomy of Adobe AIR

Adobe AIR allows web application developers to use their existing skill sets to build desktop applications. You can use your HTML, JavaScript, Flash, and Flex skills to create applications that can run on desktop systems with runtime environment without the need to compile them for running natively on specific operating systems.

In this section, we’ll define runtime environment and talk about why you might want to build desktop applications. On top of that, we’ll tell you why you’d want to use your existing skills to do that.

1.1.1. Developing for a runtime environment

If you use a Windows computer, you’ve undoubtedly run many .exe files. An .exe file is a compiled application that’s capable of issuing commands directly to the system on which it’s running. That means that an .exe file (or the equivalent) has the advantage of being relatively self-contained. However, there’s a setback as well, because this approach requires that you compile the application to a platform-specific format. That means that you must create a Windows-only or an OS X–only version of an application using this approach. The steps for the traditional approach to building applications are as follows:

1.  Write the code in a preferred language.

2.  Compile the code to a format that can be run natively on a specific operating system.

3.  Run the compiled application.

A more flexible way is to use a runtime environment rather than targeting a specific operating system. This runtime environment approach is used by many popular application platforms, including Java and .NET, and it’s the approach used by Adobe AIR as well. When using a runtime environment, the application creation process is as follows:

1.  Write the code in a preferred language.

2.  Compile the code to an intermediate format.

3.  Run the compiled intermediate format in a runtime environment.

Runtime environments give developers the freedom to write code once and run it from any computer regardless of the operating system, as long as the runtime environment is installed. A runtime environment is itself a library that runs natively on an operating system. The runtime environment is responsible for acting as a proxy for the programs that it runs. Because the runtime environment provides this level of abstraction between the programs that it runs and the system on which it’s running, it’s theoretically possible to create runtime environments on many different types of computer systems that can all run the exact same application files without any differences among the platforms.

What does all this have to do with Adobe AIR? As we mentioned earlier, AIR is a runtime environment. When you create an AIR application, you compile it and then package it to an intermediate format called an .air file. An .air file and its contents won’t install or run on a computer unless the user has previously installed the AIR runtime environment. If the AIR runtime is installed, the .air file enables running the application on both a Windows machine and an OS X machine. That is a huge boon to you as an application developer.

Web applications have advantages over traditional desktop applications, to be certain. So why would you even want to create desktop applications in the first place? Presumably, if you’re reading this book, you already have a few reasons, but it’s worth discussing some of the important motivations.

1.1.2. Why build desktop applications?

A web-based email client allows you to read your email from any computer connected to the internet. This illustrates one of the primary advantages of web applications, which is that they aren’t restricted to one machine. Consider that web applications

• Allow you to easily deploy updates and new versions of your software.
• Generally provide a level of security for users because they’re subject to the security limitations of the browser and player (Flash Player, for example) used.
• Allow you to distribute computing by running some behaviors on the client machine and some behaviors on the server.

However, web applications aren’t without disadvantages. The two really big ones are that they

• Don’t have access to operating system–level features and functionality like desktop applications do.
• Require that the computer be connected to the internet to work. This is disadvantageous if you want to use the application when you’re not online, such as when you’re on an airplane or in the park.

AIR applications bring together the best of both web applications and desktop applications. Because AIR applications are based on web application technologies, you (as the developer) have extraordinarily easy ways to access web resources and integrate existing web applications in part or whole. However, because AIR applications run on the desktop, they have access to system resources normally not accessible to web applications. That means you can do things such as drag-and-drop between AIR applications and the file system, access local databases, and, perhaps most importantly, create effective sometimes-connected user experiences that allow the user to work with the application both online and off. AIR applications also have features that allow you to enable seamless updates, so that users can always be assured they’re working with the latest version of the application (a topic discussed in chapter 8).

The other question we’d like to answer is why you’d want to create desktop applications using web technologies. The most obvious reason for this is that you have existing skills with web technologies that you’d like to leverage in different ways. If you can create desktop applications using skills you already have, that’s an advantage over having to learn a new language and new technologies just to create an application for the desktop. But there are more reasons why you might want to create desktop applications using web technologies. Web technologies are uniquely suited for creating applications that connect to and use web resources. In a world that increasingly demands online and networked experiences in desktop software, it’s advantageous to create those desktop applications using languages that are designed specifically for online experiences. Yet another reason to use HTML, JavaScript, Flash, and Flex to create desktop applications is that these languages tend to be vastly superior to other, more traditional desktop application languages when you want to create compelling, engaging, and interesting user interfaces.

1.1.3. Exploring AIR possibilities

AIR represents all sorts of exciting possibilities for web application developers to create desktop applications. But what exactly can you expect? Here we’ll give you the basics of what you can do with AIR. Throughout the book, you’ll learn all the details.

Everything you can do when building web applications you can do when building AIR applications. That’s because AIR includes the WebKit engine (the same engine used in the Safari browser) and Flash Player. Therefore, you can still use the same core ActionScript and JavaScript features that you would use when deploying to the Web. In addition, you have access to an AIR-specific API. This includes the features outlined in table 1.1.

Table 1.1. Understanding AIR-specific API feature categories

Feature	Description
File system integration	AIR enables reading, writing, deleting, and all basic file system operations.
Drag-and-drop	Users can drag-and-drop files and directories from the operating system to the AIR application.
Copy-and-paste	Users can use operating system–level copy-and-paste features to copy data between AIR applications and the operating system.
Local databases	AIR applications have the ability to create and connect to local databases.
Audio	HTML-based AIR applications can utilize audio easily.
Embedded HTML	Flex- and Flash-based AIR applications can render HTML and JavaScript within display objects.

You have access to all these behaviors in AIR applications. In order to use them, however, AIR applications need to run in a runtime environment that supports them. In the next section, we’ll look at how to run AIR applications.

1.2. Running AIR applications

When you create an AIR application, you use the AIR toolset, whether Flex Builder 3, the AIR SDK, or whatever other AIR tool is appropriate, and package up the files for your application in an .air file. You’ll learn more about the specifics of how to package the files in an .air file later in this chapter, in section 1.4. For now, you only need to know that an .air file is the one file you distribute when you want someone to install your application. You’ll likely hear the term installer file used interchangeably with the term .air file.

Once you have an .air file, you can distribute that file to anyone who already has the AIR environment installed on her computer, and she will be able to easily install it. If that user already has AIR installed, all she’ll have to do to install your application is double-click on the .air file you’ve sent her or that she’s downloaded.

On the other hand, if a user doesn’t already have AIR installed on her computer, she’ll have to install it before she can install your application. There are two ways that users can install AIR:

• Manual install— A manual install is achieved by downloading the platform-specific (Windows or OS X) installer from Adobe and running that.
• Seamless install— The seamless install feature requires that you publish an .swf file (called a badge) to the Web, and users must click on that .swf in order to install your application. If they already have AIR installed, they’ll immediately be able to install your application. On the other hand, if they don’t have AIR installed, they’ll be able to install it first.

 

Note

Cross-reference— You can learn more about distributing AIR applications, including the seamless install feature, in chapter 8.

 

However a user goes about installing an AIR application, whether by double-clicking an .air file you’ve emailed him or by clicking on an install badge in a web page, once he’s started the installation, he’ll be prompted through several standard install wizard steps. Figure 1.1 shows an example of what the first step looks like.

Figure 1.1. Installing an AIR application brings up the AIR install screen with information about the publisher and application.

After an AIR application is installed on a user’s system, he can run it at any time just as he can any other application: by double-clicking on a desktop icon or selecting the application from a menu.

Now that you know how to run AIR applications, we’re ready to look at how you can begin building applications.

1.3. AIR application security and authenticity

Our introduction to Adobe AIR would be remiss without a discussion of two related issues: security and authenticity. These two issues are important for you to consider as an application developer, because any breaches or violations would reflect poorly on you. Therefore it’s important that you have a good understanding of what AIR does and doesn’t enforce in the way of application security and authenticity, and what steps you need to take to protect users of your applications.

1.3.1. Understanding AIR application security

One of Adobe’s flagship products is Flash Player, a product that has been so successful, in part, because of the extraordinary measures taken by Adobe (and previously Macromedia) to ensure that Flash developers can’t intentionally or unintentionally harm a user’s computer system. Flash Player has a lot of security features to protect users. This gives them peace of mind when viewing Flash content on the Web. Users know that the Flash content won’t cause problems for their computer systems.

AIR applications are desktop applications, and as such it’s essential that they have greater access to the user’s computer system than web-based Flash applications. Even though AIR applications can run Flash content, that Flash content has more opportunities to harm the user’s system than web-based Flash content. It’s a trade-off: a vastly greater feature set, but increased risk as well.

AIR applications still run through a mediator—the runtime environment itself. Therefore, Adobe has a great deal of control over what an AIR application can and can’t do. However, while many risks are mitigated by the runtime environment, AIR still allows applications many more privileges than their web counterparts might have.

The first thing that you as an AIR developer must be aware of is that it’s incumbent on you to treat the users of your application with great respect by taking security matters seriously. For example, it’s important that you closely manage all parameters to code that might run in your application. Don’t allow users to arbitrarily enter values, and don’t use dynamic, network-originating values as parameters for code that can do things such as access the file system. You can read a more detailed security whitepaper from Adobe at download.macromedia.com/pub/labs/air/air_security.pdf.

1.3.2. Ensuring application authenticity

In order to give users of your application peace of mind, Adobe requires that all AIR applications be digitally signed. (Note that signing is only necessary to build the installer, and you can still build and test your AIR applications without a signature of any sort.) A digital signature helps to potentially verify two things to the user: authenticity and integrity. A digital signature is meant to mimic a traditional handwritten signature of ink on paper in that it verifies the publisher of the application (authenticity) and that it hasn’t been altered since it was published (integrity).

You can prove that AIR enforces integrity if you’d like with a simple test. What you can do is verify that the AIR runtime will refuse to install a modified .air file. All that you need is an .air file and zip utility. The .air format is an archive format that any zip utility can read. Do the following:

1.  Run the .air file to verify that the AIR runtime will initially prompt you to run the installation. You don’t need to actually click the Install button on the wizard once it appears. All you need to verify is that the AIR runtime will give you the option to install.

2.  Click the Cancel button to exit the install wizard.

3.  Use a zip utility to add a file to the archive. Any file will work. For the purposes of this exercise, you can create a new blank text file and add it to the archive. If you’re on a Windows computer, the simplest way to achieve this is to change the .air file extension to .zip, drag the text file into the .zip archive, and then change the file extension back to .air.

4.  Run the .air file. This time you’ll receive an error message saying that the .air file is damaged and can’t be installed.

For AIR applications, digital signatures appear together with digital certificates. There are two basic types of certificates: self-signed certificates and those issued by certification authorities. There are advantages and disadvantages to each.

Self-signed certificates are advantageous in that they’re the easiest to procure. The Flash CS3 AIR update and the Flex 3 SDK (and subsequently Flex Builder 3) provide mechanisms for creating self-signed certificates for your AIR applications. You can read the details of how to create these types of certificates later in this chapter.

Self-signed certificates provide a level of security to users, in that they verify the integrity of the application. However, they do little or nothing to assure users about the authenticity of the publisher. It’s a bit like acting as a notary for your own documents. As a result, Adobe displays the publisher identity as unknown in the installation wizard for self-signed certificates. This is clearly disadvantageous, because it doesn’t create a feeling of security for users, and they’re less likely to opt to install an application from an unknown publisher than they would be if the identity of the publisher could be verified.

A certification authority is an organization that issues certificates and acts as a third party to verify your identity. A certification authority issues certificates only after it has verified your identity, usually by requesting documents such as government-issued IDs. The advantage of a certificate issued by a certification authority is that it gives more assurance of your actual identity than a self-signed certificate. When a certificate is issued by a certification authority, Adobe displays the identity listed in the certificate as the publisher identity in the installation wizard. On the other hand, some of the disadvantages might be obvious: obtaining a certificate from a certification authority is more difficult and requires more time than a self-signed certificate. Also, be aware that most certification authorities charge a fee for certificates. (At the time of this writing, the largest issuer charges $299 USD for a code-signing certificate for an AIR application.)

Two of the best-known certificate issuers are VeriSign (www.verisign.com) and thawte (www.thawte.com), though technically thawte is now owned by VeriSign. If you want to provide the highest level of certification for your AIR application, you’ll need to purchase a certificate from one of these issuers. You’ll need what’s called a code-signing certificate. You can find more information about purchasing a certificate from the web sites of the issuers.

 

Note

There are certification authorities other than VeriSign and thawte, and there are even noncommercial certification authorities such as CAcert.org that grant code-signing certificates. You should do your research before purchasing or otherwise acquiring a certificate (CAcert.org still requires that you do a fair amount of legwork to obtain a code-signing certificate) to make sure that the certificate will be trusted on the majority of computers. If the certificate isn’t trusted, the publisher of the AIR application will still show up as unknown. Speak to someone at the organization that grants the certificates and ask questions if you’re in doubt.

 

When getting started building AIR applications, you’ll probably be hesitant to invest in purchasing a certificate just to put together a few examples and send the installers to your friends. Again, remember that the certificate is only necessary when you want to create the installer. You can always test AIR applications without a certificate.

However, when you’re ready to create an .air file for your application, you’ll need to give careful consideration to how you want to digitally sign the application. You can only associate a certificate with an application once. That means you can’t use a self-signed certificate initially and change to a certificate from a certification authority later on. If you re-sign with a different certificate, users of earlier versions of the application won’t be able to upgrade.

1.4. Building AIR applications

Now that you’ve learned about what AIR is, the various pieces of AIR, how to run AIR applications, and AIR security and authenticity issues, you’re almost ready to learn how to build an AIR application. In fact, in the next few sections of this chapter, that’s exactly what you’ll learn. You’ll even have a chance to build a few simple AIR applications to wet your feet in preparation for the rest of the book. Before rushing into uncharted territory, we’ll take a few moments to map the terrain so that you can get a sense of what’s in store.

There are many ways you can create AIR applications. Table 1.2 provides a quick guide to the toolsets.

Table 1.2. The Adobe AIR toolsets

Name	AIR application source type	Free	Description
Flex Builder 3	Flex/ActionScript	No	Commercial tool for building Flex-based web and AIR applications. The tool itself is built on Eclipse. Flex Builder 3 automates and simplifies building AIR applications.
Flex 3 SDK	Flex/ActionScript	Yes	The Flex 3 SDK is the free SDK that includes all the compilers and tools that power Flex Builder 3, but doesn’t include the automation and graphic user interface of Flex Builder.
Flash CS3 with AIR update	Flash/ActionScript	No	Flash CS3 doesn’t ship with AIR capabilities. However, with the free update for Flash CS3, you can build AIR applications directly from Flash authoring.
Dreamweaver CS3 with AIR extension	HTML/JavaScript	No	A commercial HTML editor with an AIR extension that automates much of the building of an AIR application.
AIR SDK	HTML/JavaScript	Yes	The free SDK that includes all the necessary command-line tools for building HTML/ JavaScript-based AIR applications.

We’ve included HTML/JavaScript toolsets for creating AIR applications in table 1.2 in order to provide a complete picture of AIR toolsets. However, in this book we focus exclusively on using Flex and Flash to create AIR applications. In sections 1.6, 1.7, and 1.8, you can read more about how to build AIR applications using Flex Builder, Flash, and the Flex SDK, respectively.

 

Note

All the AIR toolsets are available from the Adobe web site (www.adobe.com/go/air).

 

In section 1.5, you’ll first learn about application descriptors. An understanding of application descriptors is essential to a full picture of how to create AIR applications. Even though many of the AIR tools (Flex Builder and Flash CS3 with the AIR update) will automatically create the descriptor file for a project, it’s still a good idea to familiarize yourself with what a descriptor looks like and what data it contains. You’re encouraged to read all of section 1.5 before jumping to 1.6, 1.7, or 1.8. However, if you’re anxious to start building an application and you do jump ahead, we won’t tell on you.

We’ll next continue with application descriptors. Once you’ve read the next section, go ahead and jump to the section that discusses the toolset you’ll be using to build AIR applications.

1.5. Introducing AIR application descriptors

Regardless of which toolset you use to create an AIR application, you’ll need to create an application descriptor. Some of the toolsets will autogenerate a basic application descriptor for you, but it’s important to understand what an application descriptor is and how you can use it.

AIR application descriptors are XML files, which describe AIR applications. When you package an AIR application to distribute, you’ll need the descriptor to provide some information that the AIR toolset can use to correctly assemble the application for distribution. This information includes, but is not limited to, a unique identifier for the application, a version, and information that gets displayed during install.

To give you an idea of what a basic descriptor file looks like, here’s an example. Note that all descriptor files should begin with an XML declaration (<?xml version="1.0" encoding="utf-8" ?>).

<?xml version="1.0" encoding="utf-8" ?>
<application xmlns="http://ns.adobe.com/air/application/1.0.M4">

   <id>com.manning.books.airinaction.Example</id>

   <version>1.0</version>

   <filename>ExampleApplication</filename>

   <initialWindow>
      <content>ExampleMain.swf</content>
   </initialWindow>

</application>

If you want to jump ahead to get started building AIR applications, you can do so. The preceding example descriptor file provides what you’ll need in a descriptor file for a basic AIR application. If you do choose to jump ahead, you’ll want to revisit this section later to learn more about descriptors in greater depth.

In the following sections, you’ll learn the details of the elements of a descriptor file.

1.5.1. The application element

The application element is always required, and it’s the root element of the descriptor file. The application element requires an xmlns attribute. The xmlns attribute defines the namespace for the descriptor. The namespace value is always predefined, and, for every application you build for a version of AIR, the namespace value will always be the same. For AIR 1.0, the value should be http://ns.adobe.com/air/application/1.0.M4. The namespace indicates which version of AIR is required to run the application. Each new version of AIR will use a new namespace.

Additionally, you can specify a minimumPatchLevel attribute. Use the minimum-PatchLevel attribute if you want to require the user to have an AIR (the runtime) patch applied in order to run the application. This attribute is optional. You should only use it if you know that your application requires a particular patch to run correctly.

Because the application element is the root element of the descriptor file, all the elements that follow are nested as children within the application element. The next four elements (id, version, filename, and initialWindow) are the only required elements.

1.5.2. The id element

The id element should be a unique identifier for the application. Only one application with a given identifier can be installed on a system at a time. The application identifier is a combination of the publisher identifier (gathered from the certificate used to publish the .air file) and the value of the id element. That means that, strictly speaking, the value of the id element needs to be unique only within the scope of all applications for the publisher. Although it’s not absolutely necessary, we find it convenient to create a globally unique id by using the existing convention of reverse domain names. The example used in the earlier simple descriptor example is com.manning.books.air.Example. This uses com.manning, which is the reverse of manning.com, to ensure global uniqueness. The id value must be between 1 and 212 characters, and only alphanumeric characters plus dots and hyphens are permitted.

1.5.3. The version element

The version element is a way you can specify the version number of your application. AIR won’t interpret the version value in any way, but you can use the value to program-matically test that the user has the latest version of your application. Because AIR doesn’t try to interpret the version value in a particular way, you can use any string value. Versions are typically numeric, such as 1.0 or 2.5.1, or they might include alphabetical characters denoting revisions, such as 4.0a.

1.5.4. The filename element

The filename element is how you specify the name of the .air file. The filename value is also used for the application name (in the installer) if no name element is specified.

A filename value must include only valid filename characters, and it shouldn’t include a file extension. Furthermore, a filename value may not end with a dot.

1.5.5. The initialWindow element

The initialWindow element provides information about the actual content (either an .swf or .html file) that should be used to build the application. The initialWindow element is a container for additional elements. The only required child element is the content element, which specifies the .swf (or .html) file to use. The following illustrates a basic initialWindow element:

<initialWindow>
   <content>ExampleMain.swf</content>
</initialWindow>

Additionally, the initialWindow element allows for the following optional elements:

• systemChrome— This value indicates whether the window containing the application should use the chrome (frame and title bar) provided by the operating system. If you set this to standard, the standard operating system chrome is applied. If you set the attribute to none, the system chrome is not applied. For Flex-based AIR applications, the Flex components apply a custom chrome when the systemChrome attribute is set to none.
• transparent— This Boolean value indicates whether the application window should support alpha blending with the rest of the desktop (meaning you can see through the application). If you set this to true, you can create alpha effects, but be aware that setting transparent to true requires more system resources and can cause the application to render more slowly. Additionally, you must set systemChrome to none if you want to set transparent to true.
• visible— This Boolean value indicates whether or not the application window should be visible initially. Typically you set this attribute to false only when you want to hide the window until you can programmatically position and resize it from within the application code itself. You can then use code within the application to toggle the visibility of the application window.
• height— The height of the application window in pixels.
• width— The width of the application window in pixels.
• minimizable, maximizable, resizable— These elements allow you to specify Boolean values indicating whether or not the application is minimizable, maximizable, or resizable when running. The default values are all true.
• x, y— The x and y coordinates of the initial placement of the application.
• minSize, maxSize— The minimum and maximum sizes of the window when resized.

The following is an example of an initialWindow element with most of these values set:

<initialWindow>
   <content>ExampleMain.swf</content>
   <systemChrome>none</systemChrome>
   <transparent>true</transparent>
   <height>500</height>
   <width>500</width>
   <minimizable>false</minimizable>
   <maximizable>false</maximizable>
   <resizable>false</resizable>
   <x>0</x>
   <y>0</y>
</initialWindow>

As you saw earlier in this section, the only required value for initialWindow is the content value. If you omit the others, the default values are used.

1.5.6. The name element

The name element is a sibling of initialWindow, meaning it should be nested as a child of the application tag. The name value is used to determine the default installation directory. The name value is also displayed in the title bar when the application is running. Additionally, the name appears on the first screen of the installer, as seen in figure 1.1. If no name value is specified, the value of filename is used instead.

1.5.7. The title and description elements

The title and description elements are all siblings of initialWindow, meaning they should be nested as children of the application tag. Each of these elements is optional, and these elements control what values are displayed in the installer.

The title element determines what appears in the headers in the installer, as shown in figures 1.1 and 1.2. The description is shown on the second screen of the installer, as shown in figure 1.2.

Figure 1.2. The second screen of the installer for an AIR application, allowing the user to specify installation settings

The title and description are only used during the installation, and they never appear while the application itself is running.

1.5.8. The installFolder element

The installFolder element is an optional element that determines the name of the subdirectory used as the default install directory. The user always has the option to change the install directory during installation of the AIR application. However, using the installFolder element, you can specify a subdirectory that should appear as part of the default value as seen in figure 1.2.

 

Note

You cannot change the main directory of the default installation directory used by AIR applications.

 

On Windows, that directory is always the Program Files directory of the primary disk; on OS X, that directory is always /Applications. However, using the installFolder element, you can change the subdirectory. For example, if you use an installFolder value of ExampleInc/ExampleApplication, on a Windows machine the application will be installed in Program FilesExampleIncExampleApplication, and on an OS X machine the application will be installed to /Applications/ExampleInc/ExampleApplication.app.

The installFolder element should be a child of the application tag. It’s an optional element. If you omit the element, the application is installed in a subdirectory based on the name or filename element value.

1.5.9. The programMenuFolder element

The programMenuFolder element is used only by Windows and ignored by other operating systems. This element allows you to specify a folder name from which the shortcut should be accessible within the All Programs menu in the Start menu.

1.5.10. The icon element

By default, AIR applications use the standard AIR icons for use on the desktop, in the Start menu, on the task bar, and so forth. However, you can customize the icons by using the icon element in the application descriptor XML file. The icon element should have four child elements called image16x16, image32x32, image48x48, and image128x128. Each of these child elements should have values of paths to image files. The images specified must be in .png format, and are compiled into the AIR application. The following is an example of a value icon element:

<icon>
   <image16x16>icon16.png</image16x16>
   <image32x32>icon32.png</image32x32>
   <image48x48>icon48.png</image48x48>
   <image128x128>icon128.png</image128x128>
</icon>

Remember to save .png files with transparency if you’re using nonrectangular shapes.

1.5.11. The customUpdateUI element

If present in the descriptor file, customUpdateUI configures the application to be capable of handling updating itself programmatically. (See chapter 8 for more information on how to do this.) The value should be true if you want the application to programmatically update itself. Otherwise, if false or omitted, the standard AIR update dialogs are used.

1.5.12. The fileTypes element

The fileTypes element is an optional element that allows you to register file types with the application. When you register a file type with an application, double-clicking on a file of that type will automatically launch the AIR application if it isn’t yet running. An event is then sent to the running AIR application, providing information about the file that was just double-clicked, and the AIR application can determine how to handle the event. You can learn more about handling this event in chapter 3.

If you use a fileTypes element, it should contain one or more fileType elements nested within it. Each fileType element should contain name and extension elements. Optionally, a fileType element can also contain description and content-Type elements. The contentType value can be a MIME type. (You can read more about MIME types at en.wikipedia.org/wiki/MIME.) The following is an example of a file-Types element that registers just one file type:

<fileTypes>
   <fileType>
      <name>com.manning.ExampleApplicationSavedSettings</name>
      <extension>exp</extension>
      <description>A saved settings file for Example Application</description>
      <contentType>text/xml</contentType>
   </fileType>
</fileTypes>

You’ll notice that the name element uses reverse domain names in this example in order to ensure global uniqueness for this arbitrary name. You’ll also notice that the extension value doesn’t include the preceding dot.

1.6. Building AIR applications using Flex Builder

Flex Builder 3 has built-in AIR application development features, and it includes all necessary AIR tools. If you intend to build Flex-based AIR applications, Flex Builder 3 is an excellent choice.

In the next few sections, you’ll learn the basics of working with Flex Builder 3 to create AIR applications. Specifically, you’ll learn about configuring a new AIR project, creating the MXML and other file(s) for the project, testing/debugging the project, and creating an installer for the application.

1.6.1. Configuring a new AIR project

When you want to start a new AIR application using Flex Builder 3, the first thing you should do is create an AIR project. You can create an AIR project by selecting File > New > Flex Project from the Flex Builder 3 menus. Doing so will open the New Flex Project dialog, as shown in figure 1.3.

Figure 1.3. The first step of the New Adobe AIR Project dialog in Flex Builder 3 asks for a project name and an application type. Set the application type to desktop application for AIR applications.

The wizard is the same you’d use to create a new Flex project in Flex Builder 3, and you can consult your Flex Builder reference if you’re uncertain about any of the details of those steps. The only thing you’ll do differently is select Desktop application as the application type from the first screen of the wizard. In figure 1.3, this option is selected.

Once you’ve created the project, the Flex Builder automatically creates two files in the src directory: a main MXML file and a default application descriptor XML file. Figure 1.4 shows the Navigator pane from Flex Builder listing these files for a new project.

Figure 1.4. The Navigator pane listing the files for a new AIR project lists the source files for the AIR application as well as the descriptor XML file.

Of course, you can edit the descriptor file in the way that you learned earlier in this chapter. You can also edit the main MXML file and add additional files as described in the next section.

1.6.2. Creating AIR project files

Once you’ve created an AIR Project in Flex Builder, you’ll undoubtedly want to edit the main MXML file, and you’ll likely want to add additional MXML, ActionScript, CSS, and other types of files. For the most part, you can use the same file types, MXML and ActionScript code, CSS, and structure you’d use for a standard Flex application. The primary difference between an AIR application and a Flex application is that the root tag for an AIR application is WindowedApplication rather than Application. The following is the default code placed in the main MXML file when Flex Builder creates a new AIR project:

<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">

</mx:WindowedApplication>

The WindowedApplication component is a subclass of the Application component, meaning that all the functionality of a standard Flex application is included in an AIR application. However, WindowedApplication instances have additional functionality for AIR-specific behaviors. For example, WindowedApplication has a title property you can use to change the title shown in the title bar and taskbar for the application. You can learn more about using WindowedApplication in chapter 2.

1.6.3. Testing the AIR application

As you’re building an AIR application, you’ll undoubtedly want to test along the way. As with any other type of application, it’s important to be able to see the progress incrementally as you build an AIR application. Flex Builder 3 makes it easy to test your application along the way. You can do this by way of the run, debug, or profile options in Flex Builder. You can access these options from the Run menu or by clicking on the corresponding buttons in the Flex Builder toolbar, as shown in figure 1.5.

Figure 1.5. The Flex Builder toolbar has options to run, debug, and profile an AIR application.

The run option allows you to test the AIR application in the standard fashion without any additional information, as is provided by the debug and profile options. When you select the debug option, Flex Builder launches your AIR application in debug mode, which outputs trace() statements to the console and allows you to step through the code using breakpoints. The profile option launches the application in a profile mode that allows you to see memory usage details in real time as the application runs.

When you test an AIR application using the run, debug, or profile options, you don’t need to digitally sign the application. That’s only necessary when you publish the .air file.

1.6.4. Creating an installer

When you’re ready to distribute your AIR application, you’ll need to create an .air file to use as an installer. As you’ll recall from the discussion earlier in this chapter, an .air file packages up all the necessary files for your AIR application and allows a user to double-click on the one file in order to install the application.

Creating an .air file in Flex Builder 3 is simple. All you need to do is the following:

1.  Select the File > Export > Release Build or Project > Export Release Build option from the Flex Builder menus. This will open the Export Release Build dialog, as shown in figure 1.6. There are two steps to the wizard: selecting the project, application, and .air file to export; and digitally signing the application.

Figure 1.6. The first screen of the Export Release Build dialog prompts you to select the type of export.

2.  Fill out the form, selecting the project and application you want to export and then specifying an .air file to save, as shown in the figure. Once you’ve completed this first step, click Next.

3.  Digitally sign the application, as shown in figure 1.7. This is done by applying a certificate. (You read about certificates in the application authenticity section, earlier in this chapter.) If you have a certificate that you obtained from a certification authority or you have a preexisting self-signed certificate, you can simply browse to select that certificate. In that case, you can jump ahead to step 5. Otherwise, create a new self-signed certificate by clicking the Create button and continue to step 4.

Figure 1.7. The second screen of the Export Release Build dialog asks you to digitally sign the application.

4.  Click the Create button to see the Create Self-Signed Digital Certificate dialog, as shown in figure 1.8. Fill out the form and click OK. If you’ve filled out valid information, you’ll get a message telling you the certificate was created successfully, and then you’ll be returned to the Export Release Build dialog.

Figure 1.8. Creating a self-signed certificate

5.  Browse to the keystore for the certificate you’d like to apply. (If you just created a self-signed certificate, you should select the .pfx file that was created in the previous step.) Once you’ve selected a keystore, whether a preexisting one or a new one, specify the password for that certificate in the Password field of the Export Release Build dialog.

6.  Click the Finish button, and Flex Builder will create the .air file. That is all that’s necessary to create the distributable installer for an AIR application using Flex Builder 3.

We’ve completed our discussion of building AIR applications using Flex Builder 3. Next we’ll look at how to do the same using Flash CS3.

1.7. Building AIR applications using Flash

If you’re using Flash to build AIR applications, you’ll need Flash CS3 (earlier editions cannot output AIR files) and you’ll need the AIR update, available for free from the Adobe web site at www.adobe.com/go/air. For the rest of this section (and the rest of the book for that matter), we’ll assume that you’ve already installed the free update.

In the next few sections, we look at the details of how to start new AIR projects in Flash, test them, and then create installers.

1.7.1. Configuring a new AIR project

In order to create a new AIR project using Flash, you must use the Flash welcome screen. If you’ve disabled the display of the welcome screen, you need to select Edit > Preferences from the Flash CS3 menus, and in the General category you need to select Welcome Screen from the On launch menu option.

From the welcome screen, you’ll see an option called Flash File (Adobe AIR) under the Create New column, as shown in figure 1.9. (If you don’t see that option, chances are you either haven’t yet installed the AIR update as described in the previous section, or the update didn’t install correctly.) Click on the Flash File (Adobe AIR) option in the Create New column to start a new AIR project. It’s just that simple.

Figure 1.9. Select the Flash File (Adobe AIR) option from the welcome screen to start a new AIR project.

In order to test the application, Flash and AIR need to locate the descriptor file, so it’s important that you save the .fla file before you try to test it. Until you save the .fla file, Flash won’t be able to automatically create the accompanying descriptor file. Once you’ve saved the file, a descriptor XML file is saved in the same directory. In section 1.7.4, you’ll see how to modify that descriptor file. However, the default values in the file will be enough to allow you to test the application.

1.7.2. Creating AIR project files

Flash-based AIR projects are similar to standard Flash projects intended for the Web in terms of necessary project files. You don’t have to do anything differently in terms of the types of files you create or where you create them. You can still add assets to the library, work with timelines, use the drawing tools, and write ActionScript code in the same way you would for any Flash project. It’s worth noting that AIR requires Action-Script 3 for any ActionScript that you might write.

 

Note

AIR applications are capable of playing back Flash content that uses ActionScript 1.0 and ActionScript 2.0 if you load that content into the AIR application at runtime. However, if you want to create a new AIR application, you must use ActionScript 3 for the ActionScript contained within the main .swf file of that application.

 

1.7.3. Testing the AIR application

Testing an AIR application is also exactly the same as testing a standard Flash application. You can simply select Control > Test Movie or use the keyboard shortcut that you’re used to. The only difference is that an AIR application will run in an AIR window rather than in the standard Flash player.

If you’d like to debug an AIR application, you’ll find that too is exactly the same process you’d use to debug a standard Flash application. You can simply select Debug > Debug Movie or use the keyboard shortcut, and you can debug the AIR application just the same as a regular Flash application.

1.7.4. Creating an installer

Flash has a few commands that allow you to create the .air file for your application without having to run anything from a command line or edit anything by hand. In the Commands menu are two options for AIR: AIR—Application & Installer Settings and AIR—Create AIR File.

The AIR—Application & Installer Settings command allows you to modify the descriptor file from a form rather than having to edit the XML by hand. Figure 1.10 shows what the form looks like by default for a project called Example.fla. You can see that the file name, name, and ID are all based on the name of the .fla file. Furthermore, the default ID uses com.adobe.example to precede the name based on the .fla file name. The version defaults to 1.0. You can modify any and all of the elements of the form, and those changes will be reflected in the descriptor file.

Figure 1.10. Editing the Application & Installer Settings for an AIR application in Flash

The form requires that you specify a digital signature. As you read in section 1.3.2, all AIR applications must have a digital signature. When building an AIR application using Flash, you specify the certificate using this option in the form. Complete the following steps to apply a certificate:

1.  Click the Change button to open the Digital Signature dialog, as shown in figure 1.11.

Figure 1.11. Use the Digital Signature dialog to specify the certificate for the AIR application.

2.  Select the Sign the AIR file with a digital certificate option, then select a certificate to use. If you’re using a certificate from a certification authority or an existing self-signed certificate you already created, you can immediately browse to find that certificate file. In that case, you can skip ahead to step 6. Otherwise, if you need to create a new self-signed certificate, continue to step 3.

3.  Click the Create button to open the Create Self-Signed Digital Certificate dialog, as shown in figure 1.12.

Figure 1.12. Use the Create Self-Signed Digital Certificate dialog to create a new certificate for your AIR application.

4.  Fill in all the fields in the Digital Signature dialog, including the password, which you need to remember because you’ll use it to apply the certificate to your AIR application.

5.  Save the certificate somewhere on your system by clicking OK. This returns you to the previous dialog.

6.  Browse to find and select the keystore for the certificate that you’d like to apply.

7.  Specify the password for the certificate, once you’ve selected a certificate to use. Click OK in the Digital Signature dialog and you’ll be returned to the AIR—Application & Installer Settings dialog.

8.  Create an .air file from this dialog by clicking the Publish AIR File button. If you aren’t ready to publish the .air file yet, simply click OK.

You can return to the AIR—Application & Installer Settings dialog to publish the .air file at any time. Or, having already applied the certificate, you can now simply select the Commands > AIR—Create AIR File menu option in Flash.

We’ve now completed our discussion of building AIR applications using Flash CS3. We’ll next look at how to do the same using the Flex SDK.

1.8. Building AIR applications using the Flex SDK

If you build Flex applications using the Flex SDK, you can use the Flex 3 SDK to create AIR applications as well. The Flex 3 SDK is free, yet isn’t limited in terms of the features you can build into your AIR applications. You can build the same AIR applications using the Flex 3 SDK as you could using Flex Builder 3. The differences are that the Flex SDK doesn’t automate tasks (such as creating main application MXML files and default application descriptor XML files), and the Flex SDK doesn’t include the same graphical user interface as Flex Builder. With that said, the next few sections describe how to create AIR applications using the Flex SDK.

1.8.1. Configuring a new AIR project

Because the Flex SDK doesn’t automate anything, all of the responsibility for creating the directory structure and AIR project files falls to you. Typically you’ll want to create a directory for your new AIR project. You should then create two subdirectories, one for the source files and one for the output (the .swf files and the .air file).

1.8.2. Creating AIR project files

Again, because the Flex SDK doesn’t automatically create project files, that responsibility is yours. At a minimum, you always need to have at least one MXML file with WindowedApplication as the root tag and one application descriptor XML file. See section 1.6 for more information regarding WindowedApplication. You can also learn more about WindowedApplication in chapter 2.

1.8.3. Testing the AIR application

Testing AIR applications using the Flex SDK requires two steps. First you must compile the application. Then you can run the application using the AIR debug launcher.

You can compile an AIR application using the mxmlc compiler, much as you’d compile a standard Flex application. The difference is that you must add a compiler option when calling mxmlc in order to use the AIR-specific configuration file included in the SDK. The compiler option is +configname=air. Here’s an example of the command that compiles Main.mxml as an AIR application:

mxmlc +configname=air Main.mxml

To simplify things, the Flex SDK also includes amxmlc, which merely calls mxmlc with the +configname=air option. Therefore, you can omit that compiler option if you call amxmlc instead of mxmlc:

amxmlc Main.mxml

When you compile the application, you have an .swf file. You then need to launch that .swf using the AIR debug launcher, an executable called adl. The adl executable is in the same directory as the compilers, meaning that if the compilers are in your system path then so too is adl. When you want to launch the application, you merely specify the descriptor file that you want to test as an argument to adl:

adl Main-descriptor.xml

Running the preceding command will launch the application described by Main.descriptor.xml.

1.8.4. Creating an installer

In order to create an AIR installer (an .air file) using the Flex SDK, you need to use the AIR packaging tool, an executable called adt. You’ll find adt in the same directory as the Flex compilers and the AIR debug launcher.

Creating a Certificate

The first thing you need to do is make sure you have a certificate for your AIR application. If you have a certificate from a certification authority or if you’ve already created a self-signed certificate, you’re done with that step. However, if you need to create a self-signed certificate, you must use adt to accomplish that. Use the following syntax to create a self-signed certificate:

adt –certificate –cn name key_type pfx_file password

Substitute the name, key_type, pfx_file, and password for values you want to use in the certificate. The name is the common name of the certificate, and it can be an arbitrary string that you choose. The key_type value should be either 1024-RSA or 2048-RSA. The pfx_file value should be the path to which you want to save the certificate (which should use a .pfx file extension). The password is a value that you’ll need to remember when you apply the certificate to an AIR application. The following example creates a new certificate:

adt –certificate –cn ExampleCertificate 1024-RSA certificate.pfx 2u4fs8

Packaging the AIR Application

Once you have a certificate, you can create an AIR installer using the following syntax:

adt –package SIGNING_OPTIONS air_file descriptor FILES_TO_INCLUDE

In this syntax, the air_file and descriptor should be replaced by the actual values you want to use. The air_file value should be the path to which you want to save the .air file. The descriptor should be the path to the descriptor .xml file for the application. The SIGNING_OPTIONS and FILES_TO_INCLUDE are complex groups of arguments that we’ll discuss in more detail next.

The SIGNING_OPTIONS group of arguments varies significantly depending on how you digitally sign the application. There are a variety of signing option arguments that are all described in detail in Adobe AIR documentation. Rather than repeat that here, we’ll instead talk about the most common signing scenarios and how you would go about achieving each using adt.

• Signing with a PKCS#12 certificate (includes using a .pfx file such as you might generate when creating a self-signed certificate). If you have a PKCS#12 certificate, you need only specify two arguments: storetype and keystore. The storetype argument value should be pkcs12, and the keystore value should be the path to the keystore file that holds the certificate (for example, the .pfx file). The following is an example of a call to adt that uses a self-signed certificate stored in a .pfx file:
  adt –package –storetype pkcs12 –keystore selfsigned.pfx installer.air descriptor.xml Main.swf
• Signing with a Java keystore. A Java keystore is of type JKS. The simplest way to work with a Java keystore is if the keystore contains only one certificate and you want to use the default Java keystore. In such a case, you need only to specify the storetype argument using the value jks, as in the following example:
  adt –package –storetype jks installer.air descriptor.xml Main.swf

If the keystore has more than one certificate, you can specify the alias of the certificate to use with the alias argument, as shown in the following example:

adt –package –alias sampleCertificateAlias –storetype jks installer.air descriptor.xml Main.swf

And if you want to use a nondefault keystore, you can do that simply by specifying a value for the keystore argument, as in the following example:

adt –package –storetype jks –keystore codeSigningCertificates.keystore installer.air descriptor.xml Main.swf

When using adt, you can also use other keystore types, including PKCS#11 (hardware-based keystore), KeychainStore (OS X Keychain store), and Windows-MY and Windows-ROOT.

Certificates issued by certification authorities expire after a certain amount of time (normally one year). When you create an AIR application using a certificate, normally that application installer will expire when the certificate expires. (Note that installed instances of the application will be unaffected, but the installer itself will no longer work after the certificate expires.) However, if you can verify that the certificate is valid at the time you sign the application (when you create the .air file), the AIR application installer will not expire. In order to verify that the certificate is valid, you must point adt to a time stamp server (must be RFC3161-compliant) using the tsa argument. The following is an example that time stamps the application using http://ns.szikszi.hu:8080/tsa as the time stamp server:

adt –package –storetype pkcs12 –keystore certificates.pfx –tsa http://ns.szikszi.hu:8080/tsa installer.air descriptor.xml Main.swf

The FILES_TO_INCLUDE group allows you to specify all the files to include in the .air file. Remember that the .air format is an archive format. Any files you specify in the FILES_TO_INCLUDE group will be packaged in the archive, and when the application is installed, those files will be extracted.

You must always include the initial window content file (.swf) in your installer. The following is an example that creates an .air file including just the initial window content (which we assume in this example is Main.swf):

adt –package –storetype pkcs12 –keystore selfsigned.pfx installer.air descriptor.xml Main.swf

However, you may want to include additional files in your installer—images, audio files, video files, text files, and so on. You can simply list these files along with the initial window content:

adt –package –storetype pkcs12 –keystore selfsigned.pfx installer.air descriptor.xml Main.swf image.jpg video.flv data.txt

You can also specify entire directories. The following example simply includes all the files in the current directory:

adt –package –storetype pkcs12 –keystore selfsigned.pfx installer.air descriptor.xml

You can also use the -C flag to change directories, and everything that follows will be assumed to be relative to that directory. For example, the following includes Main.swf from the current directory and several images from the assets/images subdirectory:

adt –package –storetype pkcs12 –keystore selfsigned.pfx installer.air descriptor.xml Main.swf assets/images/image1.jpg assets/images/image2.jpg assets/images/image3.jpg assets/images/image4.jpg

When you package the application this way, the directory structure is preserved exactly as you’ve specified in the list of files. That means that, once the application is installed on a system, the image files will all exist in an assets/images directory relative to Main.swf. If that’s how your application expects the files to be organized, there’s no problem. However, if you want to add files from disparate locations, but you want them organized differently in the .air file (and subsequently when the application is installed), you’ll want to use the –C flag. Consider the following command:

adt –package –storetype pkcs12 –keystore selfsigned.pfx installer.air descriptor.xml Main.swf -C assets/images image1.jpg image2.jpg image3.jpg image4.jpg

In this example, the images are added to the archive in the same directory as Main.swf. That means that, if Main.swf looks for image files in the same directory as itself, this way of adding files to the archive is correct.

 

Note

There are additional options when running adt to create an installer. We’ve outlined the necessary steps for creating an .air file. Consult the official documentation for more information.

 

Once you run adt, you’ll have an .air file you can then distribute.

We’ve now completed the discussion of building AIR applications using the Flex SDK. Next we’ll look at a few quick-start applications. These quick-start applications will allow you to use what you’ve learned so far to build simple, working AIR applications.

1.9. Quick-start AIR application for Flex

In this section, you’ll build a quick-start application using Flex Builder. This application is simple, and not very practical. The point in this exercise is not to build a really useful application, but to walk through the steps of building an AIR application using Flex. This application simply uses a tree component to list the contents of a user’s file system, and allows the user to select image files and display them.

The first step is to create a new Flex project, selecting Desktop application as the Application type. Give this project a name of QuickStartAIRApplication. When you create this project, Flex Builder automatically creates QuickStartAIRApplication.mxml and the descriptor file.

Add the code shown in listing 1.1 to QuickStartAIRApplication.mxml.

Listing 1.1. The MXML document for the Flex quick-start

The overall structure of this code should be familiar to you if you have worked with Flex before. However, there are a few items that are probably new to you since they are AIR-specific. Don’t worry. We’ll explain many of these items in more detail throughout this book. For now, we’ll just briefly explain each of these unfamiliar pieces. The first thing you’ll note is that the root tag is WindowedApplication instead of Application. This is a requirement for Flex-based AIR applications. You’ll notice that we are using an AIR-specific component called FileSystemTree that displays the contents of the local file system. When the user clicks on an item in that component, the selectedItem of that component is a File object with an extension property that will return the file extension of the selected file.

That’s all there is to the quick-start application for Flex. Go ahead and run the application. Figure 1.13 shows the result.

Figure 1.13. The quick-start application allows you to browse your local disk for image files.

As you can see, Flex Builder makes building AIR applications simple. Although this example probably has a few things that are new to you, much of it is likely to be familiar. You already know MXML and most of the components used in this example. Those components that are new to you follow the same rules as other components you already know.

Next we’ll build a different quick-start application using Flash CS3.

1.10. Quick-start AIR application for Flash

In this section, you’ll build a quick-start application using Flash. This application is necessarily simple and fairly impractical. However, the point is not to make a really useful AIR application, but to walk through the steps and build a real, working AIR application using Flash. The application uses a List component to display a file system directory listing from the user’s desktop. Double-clicking on directories allows the user to navigate through the file system.

The first thing you want to do is create a new AIR project in Flash by selecting Flash File (Adobe AIR) from the Create New column of the welcome screen. This opens a new Flash file configured for AIR. You should save this file right away as QuickStartAIRApplication.fla.

Now that you’ve saved the file, create a new directory structure of com/manning/ books/airinaction in the same directory to which you’ve just saved the Flash file. Then create a new ActionScript file from Flash, and save the file in com/manning/books/ airinaction using the filename QuickStartAIRApplication.as.

In the Flash file, open the components panel and the library panel. Then drag the List component from the components panel into the library panel. This adds the List component to the project, and we can now create instances of it using ActionScript code. Go ahead and save the Flash file again.

Return to the ActionScript file, and add the code in listing 1.2. We’ll use this class file as the document class for the Flash application.

Listing 1.2. The code for the document class for the Flash quick-start

Some of this code may be new to you since it is AIR-specific. We’ll talk about all of the new code in more detail throughout the book. For now we’ll quickly mention what some of the unfamiliar code is and what it does. First you might notice that we import the File class . This class is used to represent files and directories on the local file system, and you’ll learn about this in chapter 2. Next you can see that we’re setting the list to display the value of the name property of each element in its data provider . The data provider we’ll use is a collection of File objects, and File objects have name properties. The File.desktopDirectory property is a reference to the user’s desktop directory, and calling getDirectoryListing() returns an array of the contents of that directory. We then place that in a DataProvider instance and assign that to the list. The isDirectory property will tell us if a File object represents a directory or not. We only want to change the directory listing if the user double-clicks on a directory. Therefore we test for the value of isDirectory . And only in that case do we update the list’s data provider, this time calling getDirectoryListing() for the selected item.

Save the ActionScript file and return to the Flash file. In the Flash file, set the document class to com.manning.books.airinaction.QuickStartAIRApplication. Save the Flash file, and test the application. You should see a listing of the desktop files and directories. If you double-click on an item in the list, it’ll refresh with the contents of the new directory if you’ve double-clicked on a directory. Figure 1.14 shows what the application looks like.

Figure 1.14. The Flash quick-start application allows the user to navigate the local file system.

You’ve just written your first (albeit simple) AIR application using Flash. This is just the starting point. Now that you’ve seen how easy it can be to create an AIR application, you’ll build more complex, sophisticated, and useful applications throughout the book.

1.11. Summary

In this chapter, we started from the premise that you didn’t know anything about AIR, and by the end of the chapter you built your first AIR application(s) using Flex and/or Flash. You learned what AIR is, what toolsets to use, and how to get started. Specifically, you learned that you can use Flex Builder 3, Flex 3 SDK, or Flash CS3 with the AIR extension to build Flash- or Flex-based AIR applications. Because AIR applications run within a runtime environment other than Flash Player, they have access to a greater scope of behavior than their web-based counterparts. AIR applications can access the local file system; create, read, and write to local databases; and participate in system-level drag-and-drop features among other behaviors that are above and beyond what is available to a web-based Flash or Flex application.

In the next chapter you’ll learn more about how to use and manage windows, menus, and AIR applications. You’ll learn how to create new windows, and the different types of windows you can create. You’ll also learn how to correctly work with windows once they’ve been opened. Then you’ll learn about the different ways to work with menus in AIR applications, from application and window menus to context menus.