AssetLoader v3 – Ideas/Roadmap

Posted 29 August 2011 by

Hi there lovers of AssetLoader, the time as come to starting thinking about what we’d like to change with the next version. Below is a “dynamic” list of things that I have in mind. Please feel free to voice your opinion to get your idea(s) on the list.

Prospected API Changes:

Please keep in mind that these are not implemented yet, this list only consist of ideas.

ILoader – These changes will bubble to IAssetLoader

API Description
onDestroy : LoaderSignal Dispatches just before the loader is destroyed. This will give you an opportunity to null any lingering references.
onHttpStatus : HttpStatusSignal Remove – Relocate to ILoader implementations that actually dispatches http status.
prioritize (force : Boolean = false) : void If loader forms part of a loading queue, bring loader to top of queue. If force is true, stop all other loading operations.
destroy (verbose : Boolean = false) : void Loader will invoke removeAll on it’s public signals in addition to internal clean up.

IAssetLoader

API Description
onConfigAdded : LoaderSignal Dispatches when the IAssetLoader has received and parsed new config via the addConfig function. Note that onConfigLoaded will still fire, but only if config was loaded via an external file.
add (request : *, params : Object = null) : ILoader Argument – request – Can accept: URLRequest instance or url/path String or an ILoader instance.

Argument – params – Accepts an Object representation of parameters. Please note that “type” and “id” can be passed here, an automatic id will be assigned if not passed and the default type is “auto”.
addLazy Remove – No longer needed as it’s replaced by add.
addLoader Remove – No longer needed as it’s replaced by add.
breakQueueOnError : Boolean = false The loading queue will be halted if any of the child loaders failes to load. Default behaviour will cause the queue to continue and dispatch complete regardless of child error.
failOnError : Boolean Remove – No longer needed as it’s replaced by breakQueueOnError.
factory : ILoaderFactory Makes the factory swappable.

New ILoaders

Name Description
RootLoader Ability to monitor a SWF that’s being embedded/loaded by the browser. Useful for large muli-framed preloaders.
AVM1Loader Load AS2 swfs without increasing the processing usage of the standard SWFLoader.

Global Changes:

Affected Class Description
Param All values of public static constants will be rewritten to camel-case.
ConfigParser Will be completely rewritten.
StatsMonitor Move to utils package.
LoaderFactory Will be swappable for a different implementation thus needing an interface. Ability to map custom file extension association. Ability to register different ILoader implementations for type detection.
LoaderStats Revisit and extend testing.
BitmapLoader Add safety net for limited security domain. E.g. don’t access bitmap data if security domain doesn’t allow it.

Conclusion:

There will be smaller updates, other than the mentioned above, as well. It’s just a bit difficult knowing what they are at this point. :) Please voice your opinions, together we can make AssetLoader even better!

Post Details

«
»
  • http://profiles.google.com/pavel.fljot Pavel fljot

    *you’re ignoring skype, so here it is*

    breakQueueOnError sounds weird. abortOnError? skipFailed(as in LoaderMax)?Also have you though about attempting to retry loading if something fails?

    • http://doesflash.com Matan Uberstein

      Hey man, sorry about that. I missed your message when you sent it, then it got lost between the million other things I’m busy with. Also, I’d like these conversations to be public, get as much input from everyone.

      Ok, getting to the point. I chose breakQueueOnError because it will specifically do that if a child fails. So if you have more than one connection open and one of the connections fails, all loading operations in that loading queue will stop. If you only have one connection open it’s much simpler, simply don’t start the next loader and dispatch error. So in essence the queue is breaking on error.

      abortOnError, might work, but I don’t like using the word ‘abort’, something like ‘stop’ or ‘break’ feels more appropriate. I’d like to keep with the word ‘break’, because it implies failure, the end result is onError dispatching if any child failed. So we could shorten it to ‘breakOnError’, we’ll have to get more opinions though.

      AssetLoader does already retry failed loads, at default it’s 3 tries then complete failure resulting in onError to dispatch.
      :)

    • Romu

      We had long discussions about that. breakQueueOnError seems way more self explanatory than before.

  • http://twitter.com/camillereynders Camille Reynders

    Just a few small ones:

    - ILoader#prioritize (force : Boolean = false) : voidI’d choose suspendOthers or stopOthers instead of “force”, since it’s more descriptive of what will happen- onSomeAction flags handler/callback to me, it’s confusing they are signals- I’d go for suspendQueueOnError (or suspendLoadingOnError), since (assuming from what you wrote in the description) it’s possible to restart. Break sounds more final to me. (analogy: you can’t resume a loop that was stopped with the keyword break)my 2 cents.

    • http://doesflash.com Matan Uberstein

      I think ‘stopOthers’ works well and makes more sense, good one. :)

      Yeah, ‘suspendQueueOnError’ sounds good and descriptive. This lead me to think that maybe we should think about adding something new to ILoader as well, a boolean that will let the parent IAssetLoader know that if this ILoader fails, the queue should fail… *ponder – ponder* — Or maybe that’s overkill.

      Thanks for your cents, they are worth a lot. :)

  • http://twitter.com/camillereynders Camille Reynders

    Ouch formatting got messed up and I can’t edit. Logging in into disqus through twitter always gives problems…

  • Romu

    Great work, looks very good, happy you are maintaining! Drop me an email when you release so I can port!

    The breakQueueOnError looks promising btw ;)

    • http://doesflash.com Matan Uberstein

      Thanks! :) I’ll drop you a line.

  • http://twitter.com/nodinosaur George Medve

    I am unaware if this is available at the moment, but a maximum cache limit, for mobile usage.
    As we know mobile devices are relatively low powered and tend to have less RAM allocated for Flash, it would be nice to have a cache limit for images, etc… , for example we could set it to 100Kb and then as we start to over step that buffer, the first images are cleared out and newer ones stored.
    Just an idea anyway.

    • http://www.creynders.be Camille Reynders

      Great idea. But if I’m not mistaken it would have to be based on asset file disk size, not actual memory size. Which is better than nothing obviously.

      • http://doesflash.com Matan Uberstein

        Hi George and Creynders,

        Indeed great idea, but yes, one will need to look at the actual size on disk and “estimate” what the size in memory would be. Also this sounds more like an utility. I wouldn’t want to bake this kind of functionality into assetloader because it sounds expensive.

        Thanks for the comments, this is definitely something to look at. :)

  • http://www.creynders.be Camille Reynders

    Hi Matan,
    Could you take a look at my SignalResponder class?Maybe it could be of use for the new version of AssetLoader. No offense taken if you won’t consider it though :)
    I think especially in combination with my relaxed signals addition to signals it could be pretty useful. Robert Penner still needs to accept my pull request though.

    • http://doesflash.com Matan Uberstein

      Hey, interesting, we’ll need to have a more in-depth chat later. My head isn’t in the game right now. I had a mini operation done to my eye and I’m on heavy meds :P

      But first off it seems useful, but it also seems a bit unnecessary. I think if you wanted to use the SignalResponder, you can pass AssetLoader’s signal instances to a responder instance and pass/use that instance around.

      I gather the point of the Responder is to have your signals available system wide? If so, AssetLoader already provides this if you map a primary instance as a singleton.

      Sorry if I’m not making sense. :P Feel free to post your explanation here, I’d love to hear what your reasoning is.

      Thanks again!

      • http://www.creynders.be creynders

        It has a few benefits:

        a/ convenience: it’s a container for 4 possible process state signals, so there’s no need to inject 4 different signals, just one SignalResponder instance will do. On the other hand it’s just as easy to use if your listener is only interested in one specific process state.

        b/ through the SignalFactory it’s very easy to have specific custom signals for a specific (or for all) process(es) which allows for listener differentiation when using DI. At the moment the AssetLoader dispatches it’s own specific fixed signals, but with SignalResponder it would be easy to let it dispatch custom signals by process or for the whole.

        c/ it allows for separation of functionality and process state messaging into separate interfaces: AssetLoader and SignalResponder both have their own interfaces that are decoupled and don’t interfere. For instance: SignalResponder can be extended, modified and expanded upon w/o direct impact to the IAssetLoader interface. It also facilitates decoration of the SignalResponder class, again w/o affecting AssetLoader. 

        d/ SignalResponder has lazy instantiation of signals. (I still have to finish this, but I hope to come to it this week) If a signal is not listened to, it will not be instantiated, even though the AssetLoader will “think” it dispatched one.

        e/ Using RelaxedSignals listeners can listen to process state changes after-the-fact. For instance : It doesn’t matter whether the process has ended or not, a listener can subscribe to the complete signal and it will be triggered immediately with the data produced by the process the last time.  

        In other words I think it allows for more flexibility towards usage and coding style.If you want to have a more in-depth chat about it you can DM me on Twitter for my  skype coordinates.

        Oh, and good luck with your recovery. Take care of yourself.

        • http://doesflash.com Matan Uberstein

          Yes, very nice. :)

          a) I hear you, but AssetLoader uses a lot more signals, so it feels that the overall process will be broken into smaller parts that may become confusing for the “not-so-expert” user.

          b) I don’t think the intention behind AssetLoader is that people need to inject the signals, but rather the IAssetLoader instance itself, exposing the entire api. Also, I can’t think of a scenario where a custom signal would be required. AssetLoader delivers all the info you need via the signal, so if the signal is injected, the ILoader that dispatched is always there if need be.

          c) Yeah, makes sense, but my fear of complication still remains as there are more than just the 4 standard signals being dispatched. What should we do with the case of onComplete vs onChildComplete ?

          d) All signals need to up and running from the word “construct”, so lazy instantiation isn’t an option. The internal workings between IAssetLoader and ILoader depend on these signals. So adding code for lazy instantiation is just bloat, because they will always be constructed.

          e) Useful, but yet again, if the entire api is exposed, all the data/info is available when needed.

          Thanks for your comments, I would indeed love to speak to you some more on skype. Good job making SignalResponder, it seems very useful, but at this point I don’t see it fitting into AssetLoader. I think it’s just the nature of AssetLoader that won’t allow it, but I will consider it while I’m re-working AssetLoader to v3, maybe I’ll see how it fits in when diving in again.

          Ah Thanks! I feel much better today, it just looks like someone punched me :) hehehe – At least I’m able to open my eyes properly :)

          • http://www.creynders.be creynders

            Not trying to still convince you, just a quick reply to address some points:

            a/ and c/ as I wrote, SignalResponder can easily be extended, all it would take is creating a AssetLoaderSignalResponder class inheriting from the original which adds the required signals.

            b/ and e/ sure, but it couples the process listeners to IAssetLoader, which in my experience is more often than not unnecessary. I like my listeners to be unaware of the implemented originator. In fact I like my process listeners to be even unaware of process type (async or sync), but that’s another discussion.A situation in which a custom signal can be beneficial: A service uses AssetLoader but has it’s own SomeServiceDataRetrievedSignal, instead of relaying or translating the complete signal from AssetLoader, it can inject its custom signal into the responder object and be done with it.

            d/ ok, understood. It’s no substantial bloat though, just two conditionals per signal.

            And yes, having eyesight is so much better, isn’t it? :)

          • http://www.creynders.be creynders

            Here’s a gist on the benefits of using custom signals
            https://gist.github.com/b701af627d7be558e435

            and here if you’d use the responder directly for instance
            https://gist.github.com/dc189fb124b4cc1062fc

            And now I’ll stop bugging you ;)  

          • http://doesflash.com Matan Uberstein

            Hehehe :) I like you examples! Made me laugh a bit! :D

            Great, thx for creating these, they’ll be handy once I jump in.

  • Pingback: What AS3 Project to focus on next? | Does Flash? | AS3 Blog