Jump to content
GreenSock

ccollomb

Simplifying and clarifying caching behavior

Recommended Posts

It seems to me that a better caching code interface would benefit both use and resources.

 

For example what happens if I load twice the same URL through BinaryDataLoader? I saw some code to pseudo-cache the bitmap with ImageLoader, but could not find the equivalent with BinaryDataLoader. And even the BinaryDataLoader creates a new bitmap reusing the bitmapdata.

 

So basically from a caching mechanism I would expect two identical successive calls to automatically return the same loader.

 

imageLoader1 = new ImageLoader( "assets/pic.png", { name: "test", onComplete: onCompleteImage1 } );

imageLoader2 = new ImageLoader( "assets/pic.png", { name: "test", onComplete: onCompleteImage2 } );

 

Would only download the image once but would also only create ONE bitmap. I know this behavior might need variations (some people might want 2 different bitmaps), but the idea is all the work is the internals of ImageLoader would handle the work. And same for other resources.

 

For example for Binary data here is an example of what I am doing if I want to get access to the callback of the loaded resource.

 

mBinaryDataLoader = LoaderMax.getLoader( urlAmf );

if ( mBinaryDataLoader == null )

{

mBinaryDataLoader = new BinaryDataLoader( urlAmf, { name: urlAmf, onComplete: onCompleteAmf } );

queue.append( mBinaryDataLoader );

}

else if ( mBinaryDataLoader.status == LoaderStatus.COMPLETED )

{

onCompleteAmf( null );

}

else

{

mBinaryDataLoader.addEventListener( LoaderEvent.COMPLETE, onCompleteAmf );

}

 

Am I doing something wrong, or is there a recommended way to handle those cases?

 

Thanks for your help,

 

Cedrick

Link to comment
Share on other sites

It looks to me like you're handing it fine for the type of result you want. Good job.

 

I don't think it would be appropriate to have LoaderMax assume that when a developer creates 2 loaders for the same URL that he wants them to share the same instance of the actual loaded data. That could cause frustrating complications in some scenarios. Bitmaps are a unique exception and even in those cases, a unique Bitmap instance is created but the BitmapData is shared. Imagine a scenario where you want to load the same swf multiple times to play some animation at various places around the screen, but each one would be running independently and at different sizes/alphas/rotations/etc. If the same instance is returned for all those SWFLoaders, it would be a disaster - only one instance would show up on the screen. See what I mean?

 

I think the safer approach is to assume the developer has a reason for creating multiple loader instances with the same URL and that they should receive unique instances of the raw data. If they don't want unique instances, they can implement code to avoid that pretty easily (as you're doing).

 

Sound reasonable?

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.
×