LoaderMax: how to load images via xml into variables? Dispose?

[cerulean]

I'd like to use LoaderMax to load an xml file that will contain references to other xml files, one of which will contain nodes representing imageloaders.  I don't want to add these images to the display list immediately but instead have reference to them, perhaps in an array.  What's the best way to grab references to these loaded images from layers down?  Put a complete function on each image loaded?  Is there a simpler way

 

I imagine the pseudo-xml something like this:

 

 

 

_myLoaderMax.load(mainXML, onComplete:getTheImages);

function getTheImages():void {
 _myImageArray = getTheImagesFromLoaderSomehow(_myLoaderMax);
}

<mainxml>
  <xmlloader url='imagexml' load='true'/>
</mainxml>

<imagexml>
  <imageloader url='myimage1' load='true'/>
  <imageloader url='myimage2' load='true'/>
</imagexml>

 

 

Would it be using getContent() at the appropriate level -- i.e. pseudocode

 

_myXMLLoader= _myLoaderMax.getLoader('myXML');
_myImageContent:Array = _myXMLLoader.getContent()

 

On another related note — what's the best practice for making sure everything loaded via LoaderMax is garbage collected?  That is, I can set the main LoaderMax to have autodispose='true', but will that also dispose of all sub-loaders?  I realize that if I put listeners on any loaded assets, etc, that will affect garbage collection, but do the GS loaders hold on to loaded assets in any fashion?  Is there anything I need to do to make sure GC works well?

 

I see that there are references to unload() in LoaderCore, but how does one recursively unload everything?  

 

Thanks

[Carl]

You can use the getChildren() of any XMLLoader to get an array of loaders that it has loaded.

 

So you could first getChildren of your mainXML file which would give you the imagesXML file. Once you hit imagesXML  you can get its children.

 

Attached is a very basic example that roughly mirrors your pseudo code 

 

Here is the code that loads an xml file that loads an xml file that contains 4 ImageLoaders:

 

 

 

import com.greensock.*;
import com.greensock.loading.*;
import com.greensock.events.LoaderEvent;
import com.greensock.loading.display.*;
LoaderMax.activate([imageLoader]);


var mainXML:XMLLoader = new XMLLoader("main.xml", {autoDispose:true, onProgress:progressHandler, onInit:initHandler, onComplete:completeHandler, onChildComplete:onChildCompleteHandler, estimatedBytes:350000});


mainXML.load();




function progressHandler(e:LoaderEvent):void{
trace("mainXMLLoader.progress = " + e.target.progress);
bar.scaleX = e.target.progress;
}


//fired once xml is processed and sub-loaders are created
function initHandler(e:LoaderEvent):void{
//the xml
trace(e.target.content);
}


function onChildCompleteHandler(e:LoaderEvent):void{
trace("loaded: " + e.target);
} 


function completeHandler(e:LoaderEvent):void{
trace("mainXMLLoader *** COMPLETE ***");
trace("imagesXML  = " + e.target.getChildren()[0]);
//create reference to an array of the images.xml children (ImageLoaders)
var loadedImages = e.target.getChildren()[0].getChildren();
trace("loaded images = \n *** " + loadedImages.toString().split(",").join("\n *** "));


//add first image3 to stage
addChild(loadedImages[0].content);
} 
 

If your ImageLoader nodes in images.xml are wrapped in a LoaderMax node and you know that loader's name, that will help you save a few steps in accessing the array of images. You can just do something like 

 

var imagesArray:Array = LoaderMax.getLoader("imagesLoaderMax").getChildren();

 

The way I provided allows you to get to your images without knowing any of the names of the loaders that are being used. 

 

Yes, autoDispose will dispose the children, but once that happens you can no longer reference the loaded assets via all of LoaderMax's convenience methods like getLoader(), getContent(), getChildren() etc. http://forums.greensock.com/topic/6034-clearing-a-queue-of-dataloaders-freeing-up-memory/#entry21359

 

CS5 demo attached

 

nestedLoaders.zip

[cerulean]

Thanks — works great.  

 

I'm still somewhat new to LoaderMax —

 

In the example you provided, the main xmlLoader has autodispose:true.  So it could be GC'd at any point, above, but that wouldn't affect getting the xmlLoader's children in the complete function?  And if autodispose:true will make the children of main xmlLoader also be GC'd, then that would mean that 

var loadedImages = e.target.getChildren()[0].getChildren();

 

might also fail?  Are we relying here on the fact that it's in the complete call and thus nothing's been GC'd yet, but at some later point we couldn't rely on doing any of this?

 

If I didn't set autodispose:true, then I would get the children of the main XMLLoader, as above, and for each of them call dispose(), later?

 

Forgive my ignorance, I've been coding AS3 for years but LoaderMax seems, to the new user, complicated — it does so much 'automagically', which is great, but there is then a certain hidden logic.

[Carl]

Cool, glad the files helped.

 

Putting autoDisplose on the xmlLoader was just a test I was doing, I didn't mean for it to creep into the demos. But your assumptions are correct, in the onComplete callback we still have time to use the LoaderMax methods like getLoad(), getChildren()  etc. But once the onComplete executes and the autoDispose happens... no more.

 

In real projects I rarely (if ever) use autoDispose. The memory footprint of a loader is really inconsequential compared to the content it is loading. More often than not I will unload() a loader's content... but I usually leave the loader around. If you are building an app that loads hundreds or assets, yes you may want to have a solid clean-up routine in place. I usually prefer to have the loaders around so I can load()/unload() them at will, as well as find them with the handy methods.

 

And yes, LoaderMax takes some time to get familiar with. We prefer to call it robust as opposed to complicated though;)

 

There are a ton features and there are often many ways to accomplish the same task. It can be a bit overwhelming, but once you get the basics down, that knowledge scales quickly.

 

The best thing you can do is start real small, read through the documentation and try to implement the methods and see what they do. Check out the learning material at: http://www.greensock.com/learning/ Lots of great stuff there to get going.

 

As you learn, experiment and hit those inevitable obstacles, don't hesitate to ask questions. We're eager to help.

[cerulean]

Thanks!