Tuesday, January 20, 2009

XML and Flash Lite..... stuff of nightmares

XML has long plagued Flash Lite developers. It really is the stuff of nightmares, if you use XML you enter a world where nothing is what it seems. Your application lives or dies on the whim of Flash Lite and the XML document itself. If you are not careful you will find that the XML object is not cleared by Garbage Collection, scripts will reach the script timeout limit and stop processing silently, your application will fail.

After years of suffering here a few short notes on successful use of XML.

1. IdMap locks an XML object in memory. This is a bug. Here's the issue, with some XML files it is impossible to delete the XML object from memory because somehow the idMap holds a reference to the XML object itself. So before deleting an XML object you must first delete the XML.idMap property.

2. If you want to avoid the potential pitfalls of creating and then deleting XML objects, try just reusing the same XML object to process all your files.

3. Never do too much in a loop, this can cause the FL player to freak out and stop processing the loop, leaving you with an unfinished set of data. The timeout for loops on desktop is 15 seconds, on mobile this seems to be a lot less. This could be because OEMs have set it lower or it could just be because of poor implementations - who knows!

4. Don't forget the UI. Flash is single threaded so when you are executing code Flash must finish before it can render. This means your UI won't respond if actionscript is busy parsing an XML file.

5. onData() and onLoad() happen in the same frame. This means when an XML file is loaded it first creates the XML object via parseXML() then it calls onLoad() where you can walk through the DOM and access the nodes. The implication of this is that Flash has 2 heavy bits of processing to do in one frame, increasing the likelihood of a timeout. If timeouts are an issue you can overwrite the onData() event, call parseXML() and then call onLoad() in the next frame.

6. If you control the data you use then process it into something other than XML on the server or locally. XML objects occupy a lot of memory, name value pairs are much more efficient and you wont need to process them at all.

7. Test your XML loading needs at super speed in device central. So take your basic requirements for XML processing, create a new fla and set the FPS to 120. Do your loading operation 1000s of times and look at the memory. You'll get a good idea how good your memory handling is.


Blogger [BlocketPC] Marcos said...

Hi Nick.

This is absolutely true. I have worked with Flash Lite and XML intensively connecting flash Lite to a SOAP webservice that served the same data for flash lite than the web version in XML format (uauh I like BIG XML's!!! XDD) and I have the same thoughts than the ones you explain in this post.

I used the same XML for all my app, I handle the data in onData event and have to split the extracting method into different ones (with a gap of time between them) because I lost some information without an error, I tried to extract data from the XML with a recursive String parsing approach,... but the memory goes crazy, never the same behaviour.

I have a draft for posting about this at blocketpc a year ago, but all my testing to find a pattern about behaviour got me crazy, so still it's a draft XD.

Really good post, very useful. when I found the point number 3, I freaked out!

9:41 AM  
Blogger MarkDoherty said...

Hi Nick,

Thanks for bringing this feedback to our attention, we are aware of the problems but its great to have something to point to.

I believe that desktop Flash has dictated our XML implementation for mobile devices, and so we have suffered a little as the use of XML has grown.

I have asked our engineering team to look into this issue, let's see what can be done.

Mark - Adobe Platform Evangelist

12:31 PM  
Blogger biskero said...

Ciao Nick,

great points!
These are some of the reasons I do not use XML at all!

10:20 PM  
Blogger Nick Gerig said...

Marcos, it is painful, you know! No.3 is a difficult one because as I understand it the way Flash Lite deals with the timeout or slicing is different to the desktop and is different on different OEM implementations. My most difficult experiences were with Flash Lite 2 on S60. Now that could have been a poor implmentation but what happened was that the onLoad was called with success true, but the loops that tried to walk the DOM were just skipped over.

Mark, thanks for the support and proactive response :) Its a near impossible one to solve, optimising an XML implementation by creating a special XML api for constrained devices would definately help. Making parseXML() truly asychronous would help too. A clean XML implementation would making walking the DOM better.

11:28 PM  
Blogger [BlocketPC] Marcos said...

Hi Nick, I have the same problems with S60 and Flash Lite 2, with the same results than you had. I get onLoad successful but when I tried to walk along the XML tree, I lost some data inside for loops. Terrifying!!!

8:38 PM  
Blogger Nick Gerig said...

Hi Marcos, It is scary!

So there must be some logic to this. Maybe this something Nokia had implemented. Its not the script timeout because you should get the actionscript stuck message. Also in my experience it wasn't a particularly big loop. So its almost like there is another trigger for the actionscript to jump outside a loop apart from time.

Marcos do you have a simple test case?



9:44 PM  
Blogger [BlocketPC] Marcos said...

Hi again Nick,

I have a test case, but I can not to post it, and I don't know if I could reproduce it if I isolate the xml from the whole app.

In my case, the xml was big in amount of data (talking in terms of flash lite of course, and I have to load it many times, basically the same XML with different values inside it and maybe some extra nodes), but it hadn't too much nodes, so as you said, I think the problem is not in the number of iterations of the loop.

I solve the problem walking the DOM in 2 steps, with a gap of time between the method calls. I noticed that I didn't get the error always (in the same device, or in different devices), and it dinn't appear always in the same loop. I think it could depend of the device overload... (but it's only an intuition.

I remember that when I found this behaviour, I found some information about it on the web. I'll try to find the original post that openned my eyes :)

10:43 PM  

Post a Comment

<< Home