Preloader logic placement

[tobydeh]

I have a separate swf that contains all graphic assets for my app.

I cannot decide where the logic for preloading should go...

Somewhere it has to interact with a view to display the load progress.

Should the loading logic be placed into a proxy and dispatch a progress notification  ?

If so how would you use the "data" property of the proxy? to hold the "LoaderContentInfo" of the loaded swf and then provide a getAsset() method?

any thoughts?

Thanks.

[puremvc]

Hi Toby,

Since the pattern for loading data really is the same as for loading these assets, I see no reason to do it any other way than you have described.

-=Cliff>

[tobydeh]

OK great,

The only thing i cant decide is startup flow... does the following sound correct?

StartupCommand - sends LoadAssets notification
LoadAssetsCommand - tells AssetsDataProxy to loadAssets()
LoadAssetsCommand - creates ProgressBarMediator and views etc
ProgressBarMediator - listens for AssetsLoading Notifications from the AssetsDataProxy
AssetsDataProxy  - sends AssetsLoaded Notification
AssetsLoadedCommand - removes ProgressBarMediator & views etc then continues with app

Is this a bad approach?

Thanks.

[puremvc]

Toby,

You've worked through the problem and come to the logical conclusion.

Startup in an application that loads resources asynchronously tends to be a relay-race right now. One thing kicks off another until you arrive at a collective state of readiness in the Model and View and are prepared for user interaction.

Soon (I promise) with the release of 2.0, you'll find a StartupManager utility that handles multiple async resource loading, with load-order dependancy, timout and retry, progress reporting, etc.

-=Cliff>

[tobydeh]

Sounds great!

[londonskater]

Toby - I've been playing about with the same thing - I'm tinkering with a LoaderProxy right now so I can tie it directly to a mediator and stage progressBar clip, but I don't like the structure. Also, I don't want all the assets pre-loaded because that makes startup to slow.

I like the asset load command idea, but really I want to tie in sections to assets with lazy loading so that all assets are added to the BulkLoader with a section id or type, but only loaded when that section type becomes active.

Not sure. Still playing with it.

[headwinds]

OK great,

The only thing i cant decide is startup flow... does the following sound correct?

StartupCommand - sends LoadAssets notification
LoadAssetsCommand - tells AssetsDataProxy to loadAssets()
LoadAssetsCommand - creates ProgressBarMediator and views etc
ProgressBarMediator - listens for AssetsLoading Notifications from the AssetsDataProxy
AssetsDataProxy  - sends AssetsLoaded Notification
AssetsLoadedCommand - removes ProgressBarMediator & views etc then continues with app

Is this a bad approach?

Thanks.

nice recipe - I've been following this logic in my own attempts to get my head around this framework and I've found it very helpful

[puremvc]

Given this scenario, you probably want to have LoadAssetsCommand create the ProgressBarMediator, et al, before you start your assets loading. Because the AssetsDataProxy could get a result and send a notification before the ProgressBarMediator was in place to hear it.

Also, there's a similar discussion going on over in the StartupManager utility thread:
http://forums.puremvc.org/index.php?topic=259.msg1685#msg1685

StartupManager gives you lots of control over loading of data, and there's really (IMHO) not much difference in the requirements for an asset loader. The discussion there is going along the lines of whether to include that functionality in SM or do a separate utility, and what the req's might be for it.

Maybe everyone should put their heads together on this one and flesh out the reqs. It'll be nice for people to have a solution but it'll be nicer if its well though out...

-=Cliff>