XMLLoader deferred loading

[focus]

If I have some ImageLoaders in the XML with load="false", XMLLoader creates instances for them and applies vars from XML without listeners, like onComplete.

If I apply vars with listeners later, after getting loaders via XMLLoader.getChildren(), listeners will not be set, so only way to listen complete event of the deferred loaders is adding an event listener directly, like:

 

var nextImageLoader:ImageLoader = _defferedLoaders[index];
nextImageLoader.addEventListener(LoaderEvent.COMPLETE, _onNextImageLoaded);
nextImageLoader.load();

It works for me, but it was not easy to came to this - I had to debug greensock sources to see what happens and why I can't use common vars syntax with deffered (load="false") loaders.

 

I tried both

nextImageLoader.vars.onComplete = _onNextImageLoaded;
nextImageLoader.load();

and

var imageLoaderVars:ImageLoaderVars = new ImageLoaderVars();
imageLoaderVars.onComplete(_onNextImageLoaded);
nextImageLoader.vars = imageLoaderVarsl;
nextImageLoader.load();

But it doesn't work for me - loading happens, but listeners are just ignored.

 

Also if I try to use deferred loaders and keep them for re-use, just unload()'ing content, memory consumption grows, like something still keeps internally and grow with every load() call.

[GreenSock]

That's correct - the vars object is for initial configuration upon instantiation, not for use after instantiation. To add listeners later, you'd use addEventListener() just like any other AS3 EventDispatcher. Since it would be impossible to reference functions inside your XML (after all, XML is just text/String, therefore cannot point to a function object), you cannot define onComplete there. See what I mean? It's simply impossible unless the scope is assumed (and locked into a particular object) which would be a bad architectural move.

 

Also if I try to use deferred loaders and keep them for re-use, just unload()'ing content, memory consumption grows, like something still keeps internally and grow with every load() call.

I'm not aware of any issues like that - I wonder if you forgot to clean up after yourself in a subloaded swf before unloading. For example, if your subloaded swf starts NetStreams, attaches listeners, etc., there's no way for LoaderMax/SWFLoader to know that - you must clean up after yourself (remove listeners, close NetStreams, etc.) in order to make stuff eligible for garbage collection. If you're still having trouble, please post a very simple FLA that we can publish to see the problem demonstrated clearly (no need to post your production files - just the simplest isolated example).

[focus]

Thanks for your answer!

That's correct - the vars object is for initial configuration upon instantiation, not for use after instantiation. To add listeners later, you'd use addEventListener() just like any other AS3 EventDispatcher. Since it would be impossible to reference functions inside your XML (after all, XML is just text/String, therefore cannot point to a function object), you cannot define onComplete there. See what I mean? It's simply impossible unless the scope is assumed (and locked into a particular object) which would be a bad architectural move.

I'm clearly understand impossibility of adding listeners via XML, but could be nice to mention in docs we should add them "classic way" since in this case we should add listeners not like usual while dealing with greensock classes.

 

However, we have ability to set loader's vars property - and it's really intuitive to set vars property to vars object, like ImageLoaderVars, including all necessary listeners and apply new vars on the fly (hey, we got new vars here and they contain listeners - let's add them if they already not set!), especially because we could wish to set some additional vars (like smoothing), not only listeners.

 

 

I'm not aware of any issues like that - I wonder if you forgot to clean up after yourself in a subloaded swf before unloading. For example, if your subloaded swf starts NetStreams, attaches listeners, etc., there's no way for LoaderMax/SWFLoader to know that - you must clean up after yourself (remove listeners, close NetStreams, etc.) in order to make stuff eligible for garbage collection. If you're still having trouble, please post a very simple FLA that we can publish to see the problem demonstrated clearly (no need to post your production files - just the simplest isolated example).

In my case, I loaded raw jpeg files only, using ImageLoader.

 

Before repeat file loading, I called ImageLoader.unload() on desired ImageLoader instance and called ImageLoader.load() on it afterwards. Memory increased slowly, not with BitmapData's definitely, more likely with something smaller.

I'll try to investigate further and make sure I'm not forgot anything.