Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Author Topic: loading various assets on application startup  (Read 8313 times)
Posts: 4

View Profile Email
« on: September 03, 2008, 07:52:31 »


I'm creating my first application in PureMVC (ActionScript 3 and Flash) and I can't quite figure out what the best way would be to handle asset loading.

I have a main.swf which holds all of the code and the MainApplication. When the SWF runs, the following files should be loaded:

- assets.swf (movieclip assets, no code, just used for view components)
- fonts.swf (a SWF holding fonts that are later registered so they are available throughout the entire app)
- styles.css (a CSS file containing styles)
- application.xml and possibly more XMLs (data like labels, navigation info etc for the app)

Now, I realize that some of these things will later be handled by mediators (view assets), others by proxies (xmls). How and WHERE should I load all these files?
Just in one huge loading process in the beginning after the facade is started? Or should I load the view SWFs OUTSIDE of PureMVC in my MainApplication and the rest later after I started up the facade? Maybe there are even other, better, ways... I don't know.

Please help.
Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #1 on: September 07, 2008, 06:37:12 »

There are two schools of thought about this:
1) Loading assets is 'like' loading data, so handle both with the same pattern, (i.e. use proxies to communicate with the server and expose assets just as they expose data).

2) Assets are ultimately for composing and decorating the View tier, and should be managed independently of the Model tier (i.e. use a custom asset loader class managed by a Mediator)

Both of these approaches could arguably be 'the right' way.

The strength of the former is that all server comunication is concentrated in one tier. Its weakness is that the Model tier is less portable since it must not only represent the domain, but also the unique needs of this View implementation.   
The latter idea has a mirrored set of strengths and weaknesses. The View's unique requirements are handled entirely within its own tier. Thus two apps that use the same model but with different use cases and correspondingly different UIs are able to reuse the Model tier classes  without hacking out the stuff that serves the View. The downside is that you have asynchronous loading activity happening in both the View and the Model tiers (assets in the View and data in the Model).

I myself vote for the latter and in particular have had great success with handling module loading in a MultiCore app that way.

Pages: [1]