Jump to content


LoaderMax FAQ

Recommended Posts

Will there be a LoaderLite or LoaderNano system?

No, there are no plans for a "Lite" or "Nano" system. It just doesn't make a whole lot of sense as far as I can tell at this point. LoaderMax is relatively lightweight and robust as it is.


What if I need to send variables to the server along with my request in a loader?

The first parameter of the various loaders (ImageLoader, XMLLoader, SWFLoader, MP3Loader, etc.) accepts either a simple String URL or a URLRequest. So if you want to pass data to the server, simply construct a URLRequest accordingly, like:


var request:URLRequest = new URLRequest("http://www.yourDomain.com/whatever");
var variables:URLVariables = new URLVariables();
variables.exampleSessionId = new Date().getTime();
variables.exampleUserLabel = "label1";
request.data = variables;
var loader:ImageLoader = new ImageLoader(request, {name:"image1"});


How can I listen for individual loader events when they're nested inside a LoaderMax instance?

It's actually quite easy. You can either use the onComplete, onProgress, onError, etc. special vars properties on each loader directly or use the onChildComplete, onChildProgress, onChildFail, etc. on the parent LoaderMax instance. For example:


var queue:LoaderMax = new LoaderMax({name:"mainQueue"});
queue.append( new ImageLoader("img/photo1.jpg", {name:"photo1", onComplete:completeHandler, onProgress:progressHandler, onError:errorHandler}) );


var queue:LoaderMax = new LoaderMax({name:"mainQueue", onChildComplete:completeHandler, onChildProgress:progressHandler, onError:errorHandler});
queue.append(new ImageLoader("img/photo1.jpg", {name:"photo1"}) );


function completeHandler(event:LoaderEvent):void {
   trace(event.target + " completed");
function progressHandler(event:LoaderEvent):void {
   trace(event.target + " progress: " + event.target.progress);
function errorHandler(event:LoaderEvent):void {
   trace("error with "+event.target+" details: "+event.text);


Or you can use they typical addEventListener() on any loader instance. One benefit of using the onComplete, onProgress, and onError special properties is that when dispose() is called on the loader, it will automatically removeEventListener() those listeners.


Also note that error events (including IO_ERROR, SECURITY_ERROR, SCRIPT_ACCESS_DENIED, and ERROR) bubble up through the hierarchy, so there's no need for an onChildError.


Do I need to define estimatedBytes for all my loaders?

No, not at all. If you don't define one, the default value of 20000 will be used. The only benefit of defining an estimatedBytes is to make the loader's progress more accurate before it has downloaded enough information to determine the bytesTotal. Once it can accurately determine the bytesTotal, it will do so and stop using the estimatedBytes. By default, when a LoaderMax loads, it will loop through its children first and find any that don't explicitly define an "estimatedBytes" and quickly open a URLStream to determine the bytesTotal if possible. There's a slight speed penalty when the LoaderMax first starts loading, but it makes it very accurate.


If a child loader inside a LoaderMax has already completed and I call load() again on the LoaderMax, will it waste time reloading that already-completed loader?

No. If a loader has completed, LoaderMax will skip it in the queue for maximum efficiency and performance. If you want to force a full reload, though, set the "flush" parameter to true in your load() call, like myLoader.load(true)


Why do I have to use different loader types (ImageLoader, XMLLoader, SWFLoader) instead of LoaderMax automatically figuring out the type of loader needed based on the file name extension?

Actually, LoaderMax has a parse() method that can do exactly that (automatically figure out the type of loader necessary based on the file extension) - you just need to make sure you use LoaderMax.activate() first to activate the loader types that you want LoaderMax to be able to recognize (like ImageLoader, SWFLoader, etc.). This extra step may seem annoying, but there are a few reasons I opted to avoid building the system in a way that activates all of the loader types by default:


1) It forces ALL types of loaders to be compiled in your swf so that they're available just in case you need them. So your project may never need an SWF loader or MP3 loader, etc. but they still must be compiled in your SWF for the logic in the "lazy" loader. In my opinion, this bloats the whole system which isn't good because a loading system should be relatively lightweight in order to get things moving quickly.


2) It's virtually impossible to accurately determine the file type if the extension is something like ".php" because you could have a server-side script that spits back any type - an image, an XML file, etc. In those cases, the "lazy" system would break down. You'd have to explicitly define the type anyway.


Ultimately I believe it is much cleaner to have the developer choose the appropriate loader for the asset whenever possible (ImageLoader, SWFLoader, XMLLoader, etc.) and it definitely allows the system to be more lightweight and efficient. It could literally reduce the file size requirement by more than 60% in many cases.


Also see the Tips & Tricks page at http://www.greensock.com/loadermax-tips/

Link to comment
Share on other sites

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.