Load-completion order affects swf code in Air 1.5 on PC only

Question

Very strange one.

Our air application loads multiple swfs, which together make up a lesson.

If we load them serial, rather than parallel, the code inside all swfs is broken. (There's a previous stackoverflow q on this issue). If they are loaded in parallel all timeline top level code works.

On Mac, all code works, including deeply nested code inside MCs inside MCs, all the time, regardless of the order in which loading of the swfs completes and inits.

On PC, top level (of each swf timeline) code always works, but deeply nested code is only running dependent on the order in which the loading of the swfs completes and inits.

Referring to the swfs as A,B,C and D, if the init order is A,B,C,D then code in swf A (deeply nested code only) does not function - even stop() is not working. This only happens on PC.

If the swfs init in the order B,A,C,D or even C,B,A,D then everything is as it should be. (It has been a fairly long process identifying this pattern!)

On occasion more than one loaded swf is having problems - I haven't been able to spot an obvious pattern behind this.

All 4 swfs run fine as stand-alones. All 4 swfs run fine in the Mac version. All 4 swfs should be loading into their own application domain as Air doesn't permit anything else, and the application domain is also being specified as a new domain each time. There are no detectable domain problems - no errors are being thrown.

Clearly something is borked. I don't believe the borked thing is in my code, as the application functions perfectly on Mac, and is only broken dependent on load complete order in the PC version, and only deeply nested code is borked.

The items which are borked (MCs with non functioning code) are not exported in the library as symbols.

Has anyone come across this, or anything similar to it?

Some variations I will experiment with:

1) Exporting the symbols for MCs with code in the library so that they load in frame1 (before the init event fires) even though they don't need this.

2) Not manually specifying the application domain but letting it default (to the same value)

I'll document my findings here. Can anyone think of anything else worth varying to see if there's an impact?

Answer 1

I think I've found the source of the problem.

The load order and the broken movieclip code are both symptoms of the same problem: the swf has not loaded into memory correctly.

The broken swfs are usually the largest, and when they INIT ahead of much smaller swfs it's probably a sign of incomplete loading, hence the correlation with Level-1 code not running. (Level-0 is timeline, level-1 is code inside MCs on that timeline etc).

Having run the tests hundreds of times I've found that this problem occurs approximately 50% of the time in a Parallels-XP virtual PC, and occasionally on a Windows 7 machine that has been down-versioned to windows XP (and hiccups in many other areas). So far it does not happen on a Mac book pro bootcamp XP install, or a stable Vista install.

I guess it's a genuine thread crash in the Air app, most likely some sort of memory issue?

I have not been able to find a way to prevent the problem from happening. Instead I have a work around:

Each swf contains a MC on the timeline on frame 1 with a line of code with the sole purpose of notifying the application (via the sandbox bridge) that level-1 code has been loaded correctly. If this notification is not received for a particular swf by the time the 'COMPLETE' event fires, the swf is deemed to have loaded incorrectly, and is unloaded from memory and loaded again.

This process is repeated until the load is correct. The files are local so the delay to the user is minimal.