Jump to content
Search Community

LoaderEvent instances - do LoaderEvent listeners get removed

slint test
Moderator Tag

Recommended Posts

I notice that there are a lot of LoaderEvent instances which remain in memory when using LoaderMax. 1.) do internal LoaderEvent instances get cleaned up properly everywhere (removing their listeners)? 2.) is there a global removeAll type of method that can be called which recursively cleans up all listeners?

Link to comment
Share on other sites

I notice that there are a lot of LoaderEvent instances which remain in memory when using LoaderMax.

1.) do internal LoaderEvent instances get cleaned up properly everywhere (removing their listeners)?

Yep. Keep in mind that garbage collection in Flash doesn't happen at entirely predictable intervals. Flash decided when it wants to run its sweeps. So it is perfectly normal to see some event objects hang around for a while. That doesn't indicate some memory leak in LoaderMax.

 

That being said, LoaderMax doesn't keep track of the event listeners that YOU manually add with addEventListener(), so if you add listeners yourself then you need to removeEventListener() just like any other EventDispatcher in AS3. It does, however, automatically remove the event listeners that you added via the vars object like onComplete, onProgress, etc. It does that when you dispose() the loader.

 

Either way, LoaderMax doesn't retain references to any of the LoaderEvent instances themselves, so there is no [internal] reason why you'd see LoaderEvent instances being forced to stick around.

 

2.) is there a global removeAll type of method that can be called which recursively cleans up all listeners?

Not a global one, no, but all you need to do is dispose() your loader(s). If you tucked them into a LoaderMax instance, you can call dispose(true) and it will also dispose of all its child loaders.

Link to comment
Share on other sites

  • 1 month later...

Do you think it could be a good idea to be able to remove all listeners defined in the vars object without the need to dispose of the loader?

 

I have a situation where I have a root LoaderMax instance (which i never want to dispose of) with several child listeners (childComplete, childProgress), during an initial load, nested loaders will have their events dealt with thanks to those child listeners. Later in the project, I want to be able to unload and load those nested loaders (in this case, when the user toggles HD assets on and off), but I don't want the onChild listeners of the root LoaderMax to fire. Yes, I can remove each listener from the root LoaderMax manually in its complete handler, but it'd be nice to have public access to the following code (from LoaderCore._dump):

 

for (var p:String in _listenerTypes) {
if (p in this.vars && this.vars[p] is Function) {
	this.removeEventListener(_listenerTypes[p], this.vars[p]);
}
}

 

That way, if LoaderCore is ever updated with new listeners, I don't need to potentially add a new manual removeEventListener. What are your thoughts?

Link to comment
Share on other sites

Hmmm...this is such an uncommon edge case that I'm reluctant to bloat the API and file size with that kind of addition, you know? Not that it would cause massive bloat or anything, but it's little things like this that can accumulate over time and cause the API to get cluttered and confusing (plus the file size would creep up). It's always a balancing act and I try to consider the cost/benefit ratio for any feature I add. If it seems useful enough and I get enough requests or I can imagine that quite a few people would put it to good use, I'll add it (unless the file size cost is too high). Since you can pretty easily handle this kind of functionality separately without adding to the core LoaderMax API/files, and since it is pretty uncommon (you're the first to ask for this), I think I'd just recommend that you handle the adding/removing of the listeners manually. No offense, though - I don't mean to imply it's a bad feature request. In your edge case I can see why it would be convenient.

Link to comment
Share on other sites

  • 3 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...