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.