Using either the arguments field when launching an AIR app from a browser or initiating a local connection between AIR apps or Flex apps and the browser is a great way to pass data and create a better integrated user experience. However, there are some serious flaws. The documented limit for passing data between flex application using LocalConnection is 40Kb. This is easily enough for a few IDs, but not a sizable XML document.

The argument field when launching or installing AIR applications from the browser when creating a custom AIR badge is even more restrictive. It is not clear what the limit is for this although in various tests it seems closer to 10Kb. The workaround is to split data into chunks and then send multiple messages. Here is how I did it….

Firstly gather the XML either by generating dynamically or in my case fetching it from the page using the ExternalInterface call to a JS function embedded on the page in the browser…

var orderXML:String = ExternalInterface.call(”getXML”);
var arguments:XML = XML(orderXML);
xmlChunkProcessor(arguments);

Next the xmlChunkProcessor loops through the repeated nodes in the XML passes blocks of 10 items back out. 10 worked fine given the limited amount of data in each “delivery” node. However this figure may need to be change depending on the complexity of each node…

private function xmlChunkProcessor(arguments:XML):void {
var item:XML;
var counter:int = 0;
for each (item in arguments..delivery) {
counter++;
chunk += item.toString();
if (counter == 10) {
xmlChunkDispatcher(chunk);
chunk = “”;
counter = 0;
}
}
if (counter < 10) {
xmlChunkDispatcher(chunk);
chunk = "";
}
}

Lastly the xmlChunkDispatcher adds xml headers and footers to the collected nodes and sends it off to the application the needs it using the localCollection method in the function sendMessage…

private function xmlChunkDispatcher(chunk:String):void {
var queueString:String = xmlHeader;
queueString += chunk;
queueString += xmlFooter;
sendMessage(XML(queueString));
}

I have tested this with upwards of 300 items, so the receiving application would receive 30+ messages in quick succession. This seems to work OK, but performance in the application degrades depending on what processing needs to be done to the XML the other end. In my case i am using the XML to build UI objects and so once you get beyond 300…it runs very slowly.

Sometimes it may be useful to cache images locally or provide default alternatives in situations where an AIR application is used offline. When linking to images at a URL always add an IOErrorEvent listener to the image, so that it is caught….

myImage.addEventListener(IOErrorEvent.IO_ERROR, Application.application.img_error);

Then rather than showing a broken image, a better and local alternative can be shown in its place….

public function img_error(evt:IOErrorEvent):void {
var defaultImage:String = File.applicationDirectory.resolvePath(”images/default.jpg”).nativePath;
}

If the AIR application is launched by the browser, then its fair to assume that the application is likely to be online when first launched, this gives you the opportunity to cache images for use later when the application has more patchy connectivity.

Take a look at this CacheImage class, which can be used when the application is online to cache images and then use them later….

var imageCacheFile:File = File.applicationStorageDirectory.resolvePath(”imageCache/” + imageName);
if (imageCacheFile.exists) {
myImage.source = imageCacheFile.nativePath;
} else {
var imageCache:CacheImage = new CacheImage(imageSource, imageName, imageCacheFile, defaultImage);
myImage.source = imageSource;
}

Over on the Adobe live docs page on embedding fonts and anti-aliasing there is plenty of help on how to go about getting elements looking good.

Firstly, is it really necessary to embed standard web fonts to do anti-aliasing? Seems a bit overkill, since 99.9% of users must have these fonts…thats why they are standard web fonts. It increases the size of each application and creates more work/processing. Lets just have an option to make text anti-aliased and be done with it.

Secondly, is it just me or do the examples on the Adobe page clearly show buttons with dreadfully pixelated text. Sure, the labels looks good. But try making the text of a button, or a tab or a progress bar label anti-aliased. It just doesn’t work. This is fine for applications that do not use any of these items. But for everything else, it seems like a bit of an irritating gap.

I ended up using images or simple labels to get round this.

Sending messages from the browser and AIR using the Flex localConnection class is fairly well documented. I recently needed to extend this to support multiple instances of the same browser flex application talking to a single AIR app. (Cheers to Dave for this trick!)

To do this I assigned each browser instance a random ID, which is sent across in the arguments of a standard AIR launch call…

_air.launchApplication(appID, pubID, currentlyConnectedSwf);

or on install of the application

_air.installApplication(appURL, runtimeVersion, currentlyConnectedSwf);

Over in the AIR application I then return the message from the AIR app targeting the specific browser instance using the ID collected by the browserInvoke method….

outGoingConn.send(”www.imbimp.com” + “:” + currentlyConnectedSwf, “localConnectionHandler”, ‘AIR to SWF’);

Flex does not appear to have a library that deals very well running out of disk space, and this was a key part of the recent work I did on a download manager. When downloading files using the URLStream method and saving to disk with a fileStream, if you run out of space, either on your main hard disk or perhaps a USB flash drive you will get a runtime IO error, #3003.

This is handled easily enough with an event listener…

stream.addEventListener(IOErrorEvent.IO_ERROR, ioErrorHandler);

But also ensure this is followed up with a check for the error code, since the same ioError will be fired if network connection goes down unexpectedly.

In my recent efforts to create an MP3 downloader application I have been extensively investigating the Adobe Flex browser API to pass through download URLs and other meta data through to my app.

Any sensible person would ensure a web service or suitable server-based XML file was available to AIR requiring only an ID or two to get going but in this instance I had no such luxury.

Typically a flash/flex badge sits on a website and can detect, install and launch an AIR app while passing through simple arguments. It is not widely documented that these arguments may only be alpha-numeric and may not include special characters like dots, slashes, percents and ampersands. This counts simple encoding out.

The way the flash badge fetches content from the page is using the External Interface method whereby the flash badge can call JavaScript functions embedded on the page, which in turn allows XML, also embedded in the page, to be collected and encoded.

I came up with my own encoding mechanism so that XML could be passed through the flash badge and into my AIR app as a string and then decoded there. This meant replacing . with DOT and % with PCNT and / with SLSH etc etc

So everything is working a lot better now, although it would be helpful if Adobe included details about this restriction in their Flex documentation to save wasting time debugging why the flash badge fails to launch the AIR app for no apparent reason. It’s probably a fair restriction for various security reasons due to people running dubious scripts on even more dubious websites that would somehow take hold of your computer via AIR. I had never thought a percent sign could be so dangerous, exclamation marks are much more scary.