Apr
6

Problems with unloadAndStop? A Guide to Some Undocumented Caveats Mike Baker

Actionscript, Flash

Here’s the scenario; you’re writing a Flash application which loads in SWFs at runtime, uses them for some functionality, and then moves on. You want to do your due diligence and make sure the SWFs don’t stick around in memory because your application is so awesome users will be compelled to spend hours using it. So, you ask the developers publishing the loaded SWFs to make sure they clean up their stage references, stop their audio, etc. But you’re a developer (potentially with a mild case of OCD) who wants to be sure that all references are cleared up and you do some research.

This is where unloadAndStop() on the Loader class comes in handy. According to the Adobe Documentation:

“Attempts to unload child SWF file contents and stops the execution of commands from loaded SWF files. This method attempts to unload SWF files that were loaded using Loader.load() or Loader.loadBytes() by removing references to EventDispatcher, NetConnection, Timer, Sound, or Video objects of the child SWF file.”

What the documentation fails to mention are a few caveats to keep in mind when trying to unload assets.

  1. Event.UNLOAD will not get dispatched to your loaded code if it is instantiated from the library:
    I ran into this while trying to debug the use of unloadAndStop(). I had added a listener to the unload event to see if maybe unload was getting fired but it wasn’t. I soon realized that the unload event only seemed to fire if my clip was a child of the document class. Given that discovery, I make sure not rely on the Unload event reaching my code in loaded applications. Even if I know my code is going to be part of the document class instance it’s best to code defensively; the context the code is run in may change. Another developer could going to import your code into their project and use it differently or it could be used in a different context by the parent application.
  2. The instance of Loader you’re calling unloadAndStop on must be a part of the display list:
    This was a detail that had me stumped for quite a while but makes sense in retrospect. Since I normally load SWFs and instantiate assets from the library I rarely add the contents of a Loader instance to the display list. My solution has been to temporarily add the Loader instance to the display list, call unloadAndStop(), then immediately remove it.

    To prove this I’ve created a quick sample application which loads another SWF and instantiates a linked MovieClip from its library. The linked MovieClip has a stage event listener listening to the ENTER_FRAME event. This event will only stop firing if you have the loader added to the display list when unloadAndStop is called.

  3. As you can see in the demo the unloadAndStop() call only seems to work the first time it is called. Currently I don’t know how to get around this. Of course you can refresh the page and unloadAndStop() will work again. Basically don’t rely on unloadAndStop() to work!
  4. Assets can still be instantiated after unloadAndStop() is called. This caveat I only noticed while making the example application for #2. I’m beginning to think this call is really only designed to work with the document class of a SWF.

Note that this is in no way a comprehensive list of caveats with unloadAndStop but just the ones I’ve run into so far. If you know of any other caveats I would love to know! I’ll add them to the list and provide some examples.

Caveats 3 and 4 really bug me. I’m not sure why they happen or even how to work around it. Feel free to take a look at the source to my example, I may just be doing something wrong.

https://breaktrycatchrepo.googlecode.com/svn/trunk/developers/mikebaker/flash/unloadAndStopExample

If you are just diving into the use of unloadAndStop() Grant Skinner wrote a great article when Flash 10 first launched describing in detail what exactly the method does.

This entry was posted on Wednesday, April 6th, 2011 at 8:11 pm and is filed under Actionscript, Flash. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.