The AIR Application Structure
for this application contains these three files:
- AirQuery.xml: application manifest
- AirQuery.html: initial application window
To test the application, copy the above three files (together with AIRAliases.js) to a directory and type adl AirQuery.xml at a command prompt in the directory where you saved the files. ADL is the AIR Debug Launcher, which allows you to run AIR applications without packaging and installing them first. If everything went OK and the application runs, you will see the window in Figure 1.
|Figure 1. The Main Window at Run Time (AirQuery.html)|
The application manifest file, which Adobe calls the application descriptor, tells the runtime a couple of things about the application:
- The HTML container where the application should run
- How it should be sized
For example, here's the application manifest for this project (AirQuery.xml):
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/air/application/1.0.M4" appId="AirQuery" version="0.1">
At runtime, AIR will load the HTML document pointed at by the rootContent element. In this case, the HTML file (AirQuery.html) is very simple. All it does is call the appLoad function in the AirQuery.js file when the onLoad event fires:
<body onLoad="appLoad();" id="pBody" bgcolor="#ffffcc">
Type query here:
This HTML file is also the main visual container in which the application runs. However, the runtime can create any windows it needs.
The appLoad function is the entry point into the application, and besides painting the screen by inserting into AirQuery.html's DOM, it registers an INVOKE event with the runtime. This is an event of the air.Shell class, which is triggered when the application launches. This class can be used to parse the command line parameters, which is what AirQuery.js does in the event handler (the starting function). If there is a parameter, the application will attempt to open a database by that name; otherwise it will use a default name.
Shell is one of the four system classes of the runtime. Other categories of classes (as defined in the official documentation) are file, events, window, geometry, networking, desktop, service monitoring, media, SQL, and utilities. These classes map to a more complex structure that includes the Flash classes. For example, the full path for the Shell class is window.runtime.flash.systems.Shell. Aliasing defined in AIRAliases.js allows the class to be referenced as air.Shell.
The heterogeneous hierarchy, which includes native AIR classes, Flash classes, and possibly Flex classes, will no doubt be one of the more confusing aspects of working with AIR. This will become apparent later when I discuss creating windows in AIR.