Debugging Adobe AIR Applications Using The Dojo Toolkit

By on January 27, 2009 12:01 am

In a previous post I provided the steps to get you up and running with Adobe AIR. I’ll continue with the debugging features available in AIR and the Dojo Extensions for Adobe AIR (dAIR). The Adobe AIR Introspector is a Firebug-like console that logs messages and has code inspectors. Its logging capability is good, but it’s made even better with code in the dair namespace.

Setup

We’ll use basically the same files we used in the AIR Basics post, renamed to Main.html and Main.xml. In Main.html, include dojo.js as usual, and add the djConfig as an object in a script tag above it. Add require("dair.AIR"), and insert a log statement in an addOnLoad. You should have this:




The dair.AIR file uses a little bit of magic to load in the necessary AIR files, including AIR’s Aliases file and the AIRIntrospector.

From the command-line, navigate to the directory of Main.xml and type: “adl Main.xml”. That should open a window and the Introspector:

Console01

Note that if you don’t send any messages to the Introspector, it won’t open.

dAIR Console

The Introspector comes with a few logging statements: log, info, warn, error, and dump. dair.Console extends the Introspector to bring it close to the same functionality as Firebug, adding the methods debug, time, assert, count, dir, dirxml, and even trace. We can add these logs to our test case:

console.time("load dom");
dojo.addOnLoad(function(){
	console.debug("DEBUG");
	console.dir({
		"console.dir":"test",
		myVar:"myValue",
		myNum:999,
		myArray:[1,2,"a",{o:"object"}]
	});
	console.timeEnd("load dom")
	console.assert(true==1, "true == 1")
	console.assert(true===1, "true === 1")
	console.count("alpha");
	console.count("alpha");
	console.count("beta");
	console.count("beta");
});

I personally don’t find the information given to the left of the log statement (seen in the graphic above), [app:/Main.html][08:33:41], to be very useful. The “file” is always the HTML file, not the JavaScript file from where the call (or error) originated. The time stamp is of dubious usage, especially since we have console.time() if we need to measure performance. However, the dair.Console is very configurable, and these extra comments can be removed. Add an airConfig object to the djConfig and use the following parameters:

djConfig={
	isDebug:true,
	airConfig:{
		showTimestamp:false,
		showSender:false
	}
}

This will turn off the comments on the left and clean up the log list.

Console02

Trace

The console.trace logger that I wrote works very well and comes in handy, as AIR is not perfect at catching errors. The following is an example of the trace logger:

var whole = function(a, b){
	console.log("Whole name:", a, b);
	console.trace(5)
}
var last = function(a, b){
	whole(a, b);
}
var first = function(a){
	last(a, "Wilcox")
}
var testTrace = function(){
	first("Mike")
}

console.time("load dom");
dojo.addOnLoad(function(){
	testTrace();
});

Console03

If I found that the whole() function wasn’t working properly, or was throwing errors, I could add the trace statement to it and get a list of the last few functions that had been called. trace() accepts one argument, which is the depth of the call stack you wish to log. It also logs the arguments of the function, if applicable.

Command-Line Output

There are other ways to output data as well. Add terminal:true in djConfig.airConfig:

djConfig={
	isDebug:true,
	airConfig:{
		terminal:true,
		showTimestamp:false,
		showSender:false
	}
}

And change our test logs to look like this:

console.log("LOG");
console.debug("DEBUG");
console.info("INFO");
console.warn("WARN");
console.error("ERROR");
console.dir(dojo.config);

The output is now logged to the command-line, showing the types of log statements used, with text-based formatting:

Terminal_Air

File Logging

Yet another way to output data is to a log file, using AIR’s capability of writing to the file system.

djConfig={
	isDebug:true,
	airConfig:{
		terminal:false,
		showTimestamp:false,
		showSender:false,
		file:true,
		options:{
			path:"documents",
			folder:"DairLogs/Console",	
			name:"Log",					
			append:false,
			timeStamp:true				
		}
	}
}

Here we’ve changed the terminal parameter to false and added file:true and file options. The target path of our log file is set to the user’s documents directory, and in there we’re creating a folder within a folder: DairLogs/Console. Within that folder we are placing a file named “Log”. We have append set to false, which creates a new file every time the app is launched, whereas setting append to true would continue to append new log messages to the same file. timeStamp is true, so a new file will be added with a time stamp added to the file name, so we will accumulate a list of log files. The path parameter will accept a value for any of a user’s system directories, like desktop, application, etc. If it is not in one of these directories, it is assumed the path is an absolute file path that will put the file anywhere you like. See the dair.Log file for a full list of options.

Note that setting terminal and file to false (or if both equal undefined) will open and log to the Introspector. Setting isDebug to false will not have any output, regardless or the other airConfig parameters.

ReCSS

Finally, I’ve added one more nugget. Because of the compilation step for previewing, and the lack of Firebug’s excellent CSS inspector, doing style work on an AIR app is a little more difficult that it should be. I added David Schontzler’s ReCSS code to dair.Console, so using control/command-r will refresh all style sheets on the page that were included in link tags.

Conclusion

Hopefully these enhancements to the Introspector will make debugging your Dojo-powered AIR desktop applications as easy as possible. To get started using Dojo Extensions for Adobe AIR, download the package and browse through the tests to see all the possibilities.

Comments