Loadup - A PureMVC AS3 Utility

[philipSe]

@Sander

My suggestions as follows.
1. To make the code more readable, you could create an explicit LoadupHelper class and include a property, with a name such as shouldAbort, implemented as a get method e.g. function get shouldAbort() :Boolean.  This function can access and interpret the proxy's data property.  Thus the usage of the data property is kept local to LoadupHelper and can evolve over time.  There would likewise be a function set shouldAbort(...) :void.

2. In the loadingComplete function of AssetProxy, when shouldAbort is true, I would be inclined to not set loaded and assetData etc., since we want to discard anything loaded and behave as though the load failed.

3. Instead of directly modifying AssetProxy, you could extend it with your own class and override the loadingComplete method.  In addition, that class could have another method, named say loadingBehaveAsFailed
- invoked from loadingComplete when shouldAbort is true
- content same as loadingSecurityError, without the ASSET_LOAD_FAILED_SECURITY line
- thus it uses a FailureInfo object, to inform Loadup not to retry.

 Hope this helps.
----Philip

[svleeuwen]

Hi Philip,

This is clear now, thanks for explaining.

There is one more thing where I could use your advise.

Let's say Asset 1 has started loading and I want to start loading Asset 2 with the same loadupmonitor and assetgroupproxy. How would I accomplish that?

I can not wait for Asset 1 to send a 'complete' or 'finished incomplete' notification. I want to discard everything that has anything to do with Asset 1.

Is this at all possible? Or do I need unique loadupmonitors / assetgroupproxies?

Thanks again, Sander

Edit:
I realise that Loader.close() isn't implemented in Loadup. Is there a specific reason for that?

[philipSe]

@Sander
In relation to your question about asset 1 and asset 2, see the API Docs of the LoadupMonitorProxy class, specifically see the section that begins with The utility can be used to load an open-ended list of resources. In general, each instance of loadup has an associated list of resources to be loaded. When the full list is not known at the beginning, then keepResourceListOpen() can be used and addResource() can be used, as the need arises, to add a resource to the list.  Please see the API Docs for the full story. So, you could adopt that approach and use the one loadup instance for the ongoing set of resources.

Continuing with this open-ended list feature, in your case, you have an asset group proxy.  So, as each new resource to be loaded becomes known, I suppose you add it to the asset group proxy using addAssetProxy(), in addition to adding it to the loadup resource list using addResource(). I dont have experience of adding assets to the asset group in this open-ended manner, but it seems like it should be ok.

Your mention of Loader.close() is interesting. Loadup has no feature to take advantage of this; it was not anticipated as a requirement. It looks like something worth investigating. There is is the possibility of you using it directly, outside of loadup.  If you have your own sub-class of AssetProxy, as suggested in my previous post, then you have access to the loader variable.  With this, you yourself could directly invoke loader.close(), having cast loader to the appropriate type.  I dont know what event(s) this gives rise to, but the loadup instance would be depending on some expected event (e.g. IO_ERROR) in order to know the status of the resource load.  Maybe youve already tried loader.close()?

Edit: My point above about loadup depending on an event from loader.close() might be irrelevant.  After you invoke loader.close(), you could send an ASSET_LOAD_FAILED notification and that informs loadup that the resource load is to be treated as failed.

Hope this helps.
----Philip

[svleeuwen]

Hi Philip,

I did see the option to keep the resourcelist open. But this creates a problem when aborting the load. Lets say you load 3 assets. Asset 1 is loading. By starting asset 2 you flag the monitor that asset 1 is no longer required. Then you start loading asset 3. Now when asset 1 or 2 completes it sees the abort flag and aborts the load for only one of the two. You can't distinguish the requests to cancel from the ones not to. Or am I missing something?

Another thing is that an open resource list never sends loadcomplete notifications until you specifically close it. That's kind of unhandy for possible loader-views who respond to those notifications. This could be worked around by using only the progress notifications. If that's the only option.

Sander

[philipSe]

@Sander
As regards asset1 and asset2 and asset3, let's say the data property of the LoadupHelper class becomes more sophisticated: could be an array of pairs, each pair consisting of [ proxyName, shouldAbort ], or maybe it's just an array of the proxyNames that are to be discarded.  In any case, you then have a way of deciding for each case of asset loadingComplete whether it is one of the ones to discard or not.

As regards "open resource list never sends loadcomplete notifications", I'm not clear what you mean. My understanding is that the attempted load of each asset ends with invocation of one of the event handlers in the asset proxy class, such as loadingComplete. Yes, the loadup instance will not send a loading finished notification (or a loading finished incomplete notification) until all the resources it has been charged with loading have been processed.  It does send the 'waiting for more resources' notification when it has dealt with the list so far.

Hope this helps.
----Philip