Although a number of HTML IDEs (such as Adobe Dreamweaver) have support for launching and testing AIR applications directly from within the IDE, we will focus on launching and testing AIR applications using the ADL command-line tool included within the SDK. This will provide a solid basis for an understanding of what is going on. It also provides the most flexibility in integrating the development process with other IDEs, editors, and workflows.
The first step in testing the application is to run it as an AIR application to make sure that:
The application launches
The HTML renders correctly
The JavaScript code functions as expected
Although we could package up the entire application and then install it, this would be tedious, and it would make it difficult to quickly iterate on and test new versions. Luckily, the Adobe AIR SDK provides a command-line tool called ADL, which allows you to launch an AIR application without having to install it first.
To test the application:
Change to the directory that contains the AIRHelloWorld.html and AIRHelloWorld.xml files.
This should launch your application within the standard system chrome of your operating system (see Figure 2-2).

If the application does not launch correctly, or if you get an error, do the following:
Make sure you have configured the SDK correctly so that the ADL tool can be found.
Make sure you are running the ADL command from the same directory that contains the AIRHelloWorld.xml file.
Make sure your application descriptor file contains well-formed XML.
Make sure the information in the application descriptor file is correct. Pay particular attention to the application attributes and the initialWindow value.
Make sure the AIRHelloWorld.html and AIRHelloWorld.xml files are in the same directory.
Now that we have fixed any issues and our application is running correctly, we can explore how to get information from the application at runtime.
When running applications from the command line via ADL, you can get runtime information and debugging information from the application in a number of ways.
Any runtime errors that arise from JavaScript execution while an AIR application is launched via ADL is running will be output to ADL's standard out.
Let's modify our application to cause it to generate a JavaScript runtime error. Change the contents of AIRHelloWorld.html to the following
<html>
<head>
<title>AIRHelloWorld</title>
<script>
function init()
{
runtime2.trace("init function called");
}
</script>
</head>
<body onload="init()">
<div align="center">Hello World</div>
</body>
</html>
All we did was change the init function to try to access a property named runtime2 that does not exist:
runtime2.trace("init function called");
Save the file, and run the application from ADL:
adl AIRHelloWorld.xml
The application should launch, and you should see the following error output from the command line from which you launched the application:
ReferenceError: Can't find variable: runtime2 init at app:/AIRHelloWorld.html : 8 init at app:/AIRHelloWorld.html : 8 onload at app:/AIRHelloWorld.html : 13
This output provides the error, which in this case is that the variable named runtime2 cannot be found, as well as the line number on which the error occurred (8) and a stack trace of the call. You can use this information to track down any errors within your application.
There are also times when the application may not be functioning correctly, but is not throwing any errors. In such cases, it is useful to be able to capture information about the state of the application at runtime to track down any issues.
Adobe AIR provides a function to make it possible to send information from the application to standard out at runtime.
As we touched on earlier in the chapter, Adobe AIR provides a mechanism for sending strings from JavaScript to the command line.
The trace function on the runtime property takes a string, which will then be output to ADL's standard out. Here is an example of its usage:
runtime.trace("This will be sent to standard out");
This can be useful for tracking information about the state of the application without having to interrupt the execution of the program.
Any non-string objects passed to trace() will have their toString() function called. The JavaScript Object object provides a default toString() implementation, although some classes (such as Array) implement more context-sensitive toString() functions.
Here is an example of tracing an array that contains various data types:
var a = ["a", 1, {foo:"bar"}];
runtime.trace(a);
This will result in the following output on the command line from ADL:
a,1,[object Object]
Of course, you can implement your own toString() method on your custom JavaScript classes, or override toString() functions on existing classes to provide more class-specific output.