I have had more problems than worth mentioning with the LocalConnection API, but felt compelled to write about it after finally getting everything up and running.

The setup I have involves an AIR app communicating with a Flex 3 application running on an SSL enabled web page and back again. There seems to be rarely any problems going from browser to AIR, since the AIR app is easily addressable using the applicationID and publisherID strings or by passing strings though outside of the localconnection method in arguments along with the browserInvoke event.

When communicating from the AIR app back to the browser it seems to be rather fragile and fails regularly. Addressing the browser I use the last part of the domain and random ID of the browser flex instance (see previous post) eg “imbimp.com:dhdvgks35357″.

Now unbeknown to me, the domain string should not be the top level domain shown in the browsers address bar but should in fact match the TLD of where the Flex SWF file is hosted if of course it is different from your original site.

There are a few confusing bits and pieces to include around allowDomain and allowInsecureDomain, all of which are fairly well documented on Adobe’s livedocs pages, but seemed to have little effect when faced with inadvertantly addressing the wrong place.

No error event is thown in this case, just a statusEvent classing the connection attempt as an error of no particular type. Annoying.

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.

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’);

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.