MOD: CacheManager // Gaia.api.cacheBranches( $braches:Array );

[Gaia.api.cacheBranches( $braches:Array );]

MOD: CacheManager // Gaia.api.cacheBranches( $braches:Array );

Demo and full source zip:
http://www.elevation-inc.com/dev/jeff/gaiacache

The AS3 source code attached to this post - it's just code, full zip is too big for upload, see link above.


com.gaiaframework.core.CacheManager

The CacheManager modification to the open-source Gaia Flash Framework provides two basic features:

• Automated asset storage & retrieval within a Dictionary structure; which can reduce secondary load times to zero.
• A mechanism for preloading multiple branches and their related assets during idle bandwidth.

To make the most of the demo, use a proxy tool like Charles or Safari's Actvity viewer to see how the caching utilizes bandwidth.



API

Gaia.api.cacheBranches( $braches:Array );

• Pass an array of branches in that will preload and cache their assets when the framework has idle bandwidth.
• If a Gaia.api.goto( branch ) is called while caching is in progress, the caching load will be canceled and the new branch will be given priority.
• After the new branch is loaded, caching will be resumed.

Gaia.api.interruptCaching( );

• Interrupt caching to clear the bandwidth pipeline.
• resumeCaching will need to be called before caching will be enabled again.

Gaia.api.resumeCaching( );

• Enable caching after an interruptCaching( ) call.

Gaia.api.clearCache( );

• Creates a new cache dictionary and sets the old one to null.
• Destroy all non-active assets.

site.xml and Dynamic Externalized Assets :: cache='true'

• Individual assets/pages can also be cached via the site.xml or asset xml by adding cache='true' to the asset node.

Notes

50+ edits were made to the com.gaiaframework packages to enable the CacheManager. A project wide search on 'cacheEdit' within the project files will show all the edits.

Core idea is based on adding a new flow, Gaia.CACHE. When caching pages/swfs, it is very important to garbage collect within those assets. Pages will never be destroyed, but will rather rely on calling transitionIn and transitionOut - potentially several times in a browsing session.

Many thanks to Steven Sacks, Gaia's author, for creating and innovating such a great framework. Ideally this modification will be integrated with the trunk in some form or fashion for the community. Integration would also alleviate the need for others (including myself!) to merge this feature edit every time a new and awesome update to Gaia is released.

Cheers for the source 

Great contribution! its gonna be so handy.

Could've used it on... well every Gaia site I've built thus far :-)

Great work!  I look forward to getting the latest and checking it out.

Hey Steven, do you think this might be a good candidate for merging into the main build? Would love to share & leverage this functionality without the manual merge.

Or do you have concerns?

Thanks.

I think this is a cumbersome and expensive way to cache pages. Since the pages are not really unloaded (you only call transitionOut) this could be a memory and performence leak. And 50+ edits make updating to the newest Gaia a pain in the ass.

I created a more lighter and easier way to cache pages. With ony 2 Gaia changes:

http://www.gaiaflashframework.com/index.php/topic,2933.0.html

Agreed, it is cumbersome & expensive to make 50+ edits. The details of the above implementation are certainly up for debate & optimization. What I'm hoping survives is an extension of the API to support each of the above features.

Agreed, it could cause memory & performance leaks. 'With great power, comes great responsibility.' The impetus for this mod was to solve the recurring requirement to background load content during idle bandwidth. This sort of functionality should certainly not be used by default or for all assets. However, for experience/story/quiz/sequence based projects where there are dead pockets of bandwidth & lots of heavy content just waiting to be loaded, this can help preserve the valuable commodity of a user's time & attention. Does it introduce coding complexity & additional test cases? No doubt. Does that make the project requirement go away? Not always.

The solution you've shared is excellent & insightful. The ByteArray approach makes great sense. How would you suggest adding XML and Sound support? My tests didn't work for those but maybe I missed something. Your preloading solution, however, comes at the cost of loading all the content upfront, no? How could this solution be applied to background loading during idle bandwidth? If it helps, I've taken xml/sound elements from my project and dropped them into your solution in case anyone has time to tinker.
http://jfroom.com/dev/gaia/cache2/
http://jfroom.com/dev/gaia/cache2/gaiacacheV2.zip

Alas, I'm not sure how far we should go with. Word on the street is that Steven is reworking Gaia from the ground up, and noodling over these type of things.

Thanks.

My solution does only what is says: cache and preload pages. So you can't use it for XML or Sound (however you could embed them inside a SWF file and still use my cache trick).

Preloading pages upfront was exactly what we needed, so indeed that is how it works. But preloading content during idle time is a good idea. I am still working on my page caching to improve it. So maybe I could implement something like that.

I like TyZ solution, It's easier to apply.

Leaving complex logic aside, I would set the assets meant to preload pages with preload="false", and simply call the load() method in the transitionIn. This way they would preload in the background. I haven't tried it, but I believe even in the case that a user goes to a page still being preloaded, that page will load normally, unload normally, and then use the preloaded one if the user goes again.