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.