views:

380

answers:

3

I have a flex application that repeatedly polls a remote XML file to detect changes, but I've found that once the file hits a certain size, the poll blocks the UI and makes the page unresponsive for a short time.

Is there any way to ensure that the call made to the server or the event from the flash.utils.Timer class runs asynchronously to the main UI thread?

+3  A: 

It sounds like the blocking is caused by Flash parsing the XML rather than the actual loading.

If that is the case then you can keep loading the file and just check the size of the raw data you get back - if it's bigger, parse it and take the parsing hit. Otherwise toss the data and wait for the next request.

There's no explicit way to do threading with Flash at this time. Certain tasks happen async naturally (network and pixelbender comes to mind) but that's it.

Branden Hall
I've seen the same thing when dealing with very large SOAP responses in Flex applications.
cliff.meyers
+1  A: 

Branden's right -- the code we write essentially always happens on the main thread; while the network call itself does happen on a background thread, the handling of that call happens on the main one.

One thing to keep in mind is that the WebService and HTTPService classes will likely attempt to serialize your responses automatically, which could mean taking that processing hit unnecesarily. Using URLLoader, on the other hand, could give you more direct access to the response data, allowing you to work more directly with it without the unnecessary overhead of that built-in processing.

In that light, if you find you do have to process the entire XML file, you might consider breaking it up into chunks somehow, and distributing the processing of those chunks into separate functions, rather than handling everything within the scope of a single function. Just doing that might allow the player to continue updating the UI while you're processing that big bunch of text (processing a bit, exiting the function, rendering the UI, entering the next function, rendering, and so on); Oliver Goldman, an engineer on the AIR team, did a presentation on this concept at last year's MAX conference.

Hope it helps!

Christian Nunciato
+1  A: 

Like mentioned, AS3 is single threaded. But there are a couple of ways to handle your situation. Here are ur possible choices:

First,make sure you really need to parse entire XML when loaded and cant just keep the loaded xml nodes in memory as the data model (XML being a native data type now). Sometimes I create value objects by passing them an XMLNode and thats kept in memory till a node value is needed at which point I read it. This allows you to keep some of the parsing for later.

If you are using an ArrayCollection or similar structure to hold data, try using a primitive Array ( see http://www.arpitonline.com/blog/?p=114 for an issue I ran into)

See if you can creatively use callLater()(http://livedocs.adobe.com/flex/2/langref/mx/core/UIComponent.html#callLater())

Can you pass the data to the client in a native format like SWX or using Remoting

Can you use data paging? ArrayCollections and I am pretty sure XMLCollection support it

Side Note:

While AS3 is single threaded, Pixel Bender and I think Alchemy (http://labs.adobe.com/technologies/alchemy/) run on a different thread. There have been a couple of experiments on blogs using Pixel Bender to do calculations which dont slow the UI of the app (Example:http://elromdesign.com/blog/2009/02/09/using-pixel-bender-to-do-heavy-lifting-calculations-makes-flash-player-multi-thread/).

Also please vote on this feature enhancement ticket with Adobe if you feel the need for this feature enough: https://bugs.adobe.com/jira/browse/ASC-3222

Arpit
Alchemy runs on the same thread (since it is just AS). However, the LVVM supports it's own green threading model, which allows you to write background threads - but they are software threads, not OS threads.
Richard Szalay