Static Flash Classes and Loader Dangling Pointers
I did not know what to call this post. I have tried to get enough key words into it so if anybody else came across this issue they would find the post. This post is basically about Flash but the issue became apparent while messing with loading Flash animation SWF’s into a Flex 1.5 application.
The idea was to create a centralized place to attach and remove all our animation movie clips. The approach we took was to create a static class that would keep track of all the dynamicaly attached movie clips and provide methods to delete all the current movie clips to make room for new ones. As the animation SWF jumps around depending on user’s interaction they need to be able to wipe out all attached movie clips and add new ones in a centralized place.
To describe it in different terms we created a Factory that you give a symbol identifier which in turn attachs the movie clip. The Factory keeps a reference for it self and is capable of retrieving these references for removing of the movie clips.
The fun began when we started loading these animation SWF’s into the Flex 1.5 application. I’ll call the dynamic animation SWF’s the child SWF, and the Flex 1.5 application the parent SWF. The parent loads the child just fine the first time, but when you click the reload button the child has issues. The child SWF is reloaded through the same mx.controls.Loader class, but this time the child is missing references to the added movie clips and other functionality. We had side effects of ranging from loading the first time, then not working to just acting really random.
We tried creating new Loader classes for each load and still had issues with the references of the child SWFs. Now looking in hind sight I should have looked closer at the static class but it did not present it self until we noticed some debug code in the Factory static class. The Factory’s debug traces showed that the number of references grew each time we loaded and played the child SWF. Although the child SWF is referencing the static class through an import it does not keep its own static scope. Since the child is being loaded by a parent SWF the static class’s one instance resides for the length of the parent’s life cycle and not the child’s life cycle.
Our issue was that the static class on unloading a child had the possibility, depending on when the child SWF added movie clips, to have dangling references to the destroyed movie clips. This is where the randomness came in, because depending on how the child SWF played out the factory was not necessarily in a state with references to movie clips.
We create a mechanism in the static Factory class to make sure the static class’s internal state is what we wanted each time the child SWF loaded. A side note is that Flash does not treat dangling pointers (references) as undefined as you might hope, they are just pointing to nothingness.
In summary static classes no matter where you load or use them keep their state as long as the instance of the first SWF loaded stays open. So be very careful how you treat your static classes when loading many dynamic elements that us the static class into a single parent SWF, even when you are just reloading the same dynamic element.
Recent Comments