There seems to be a general obsession with getting flash onto mobile devices of all kinds, but little documentation around running it from a set-top box. Given this is what I want to do, I thought I would write about some of the considerations, given there appears to be little else written about this other than some high-level points and brief tutorials on the Adobe site. Apologies in advance to anyone else stumbling across this article…it provides no answers, but perhaps some helpful sole will comment.

Availability:

Availability lists seem to show mobile devices, when in fact there is no reason a fridge couldn’t be flash enabled or even a tap. So firstly I would like to know what set-top boxes, available now have Flash Lite 3.1 on them, and where can they be purchased from?

Software Stack

Now if these mysterious devices do indeed exist, what comes with them? Do you get a video player, with all the c++ extensions and ActionScript methods all sitting there waiting to be used, or is this a prerequisite of the development?

Hopefully this is enough for this post to surface in Google and maybe the lack of any helpful information will encourage others to improve the level of support in this area. Updates once I learn more…

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.