10 replies

1. 

   Nice class, I felt the same way when loading XML, its such a repetitive process, I made an XMLLoader class too. I haven’t posted the latest version of it yet ( ugly style of coding too ), but I really like the retry feature. Good post. I’ve yet to use the new signals system yet, but I see its all the rage.

   Clemente Gomez  Jan 19  9:59 am
2. 

   I (apparently like everyone else) have an XMLLoader class in my internal framework. It uses the dreaded singleton, but you can’t beat its simplicity of use:

   XMLLoader.instance.load(”file.xml”, onLoaded);

   Which matches all my other loaders:

   MediaLoader.instance.load(”file.gif”, onLoaded);
   BinaryLoader.instance.load(”file.dat”, onLoaded);
   etc.

   Yours has some more flexibility and more events/signals though. Different strokes for different folks, I guess.

   Thanks for sharing!

   Jackson Dunstan  Jan 19  3:13 pm
3. 

   @Jackson — I’ve been straying from Singletons more and more lately—I’ve been burned too many times. XMLLoader provides more flexibility because I often need to cancel load operations, handle errors or access more detailed return info.

   ps — it’s been a while! I thought you got off the grid :p

   Jonnie  Jan 19  3:52 pm
4. 

   @Jonnie – Singletons don’t necessarily get in the way of any of that. Those are actually features that my loaders have. Here’s how I handle canceling:

   BinaryLoader.instance.cancel(”file.dat”);

   And error handling:

   1 2 3 4 5 6 7

   function onBinaryLoaded(bytes:ByteArray): void { if (bytes == null) { // handle error } }

   And detailed return info:

   1 2 3 4 5 6 7

   function onMediaLoaded(result:MediaLoaderResult): void { result.content; // DisplayObject result.appDomain; // ApplicationDomain result.bytes; // ByteArray // ... other fields (eg. total time to load) can be added as necessary }

   Singletons seem to have their pros and cons. your version is still more flexible than mine (pro), but it takes more typing to use (con). Clearly there are more pros and cons and it’s probably a choice best made with the prospective users in mind.

   PS: I’m still on the grid. I’ve just been taking a bit of a vacation for the holidays. I’ll be back to writing articles soon!

   Jackson Dunstan  Jan 19  4:05 pm
5. 

   @Jackson — Since the URL is the identifier in your case, do you have a secondary identifier in case you have multiple load operations of the same URL, but need to cancel a specific one?

   Jonnie  Jan 19  4:12 pm
6. 

   @Jonnie – I’ve never run into that situation, but no. As a workaround/hack, you could fake it a bit with a query string:

   “file.xml?id=1″
   “file.xml?id=2″

   My system actually groups the loads. So if you do this:

   XMLLoader.instance.load("file.xml", onLoaded);
   XMLLoader.instance.load("file.xml", onLoaded2);

   The second call would not start a load. When the first load finishes, both callbacks will be called. This has been very handy for removing duplicate loads. For example:

   class Enemy extends Sprite
   {
     function Enemy()
     {
       MediaLoader.instance.load("enemy.png", onLoaded);
     }
     function onLoaded(result:MediaLoaderResult): void
     {
       addChild(result.content);
     }
   }
   for (var i:int = 0; i < 100; ++i)
   {
     enemies.push(new Enemy());
   }

   That will not start 100 loads. Only one will be started, but the code can remain very simple and the Enemy class does not need to worry about it. There are lots of other ways around this that could have been employed, but they all add some complication. I could have “injected” the “dependency” on the loader and such, made some class to do pooling of loads, or something like that but I didn’t. I went the simple way and it seems to work out for me and the users of my loaders. Still, it has its drawbacks. Perhaps differentiating between loads by keys other than the URL is one of them.

   Jackson Dunstan  Jan 19  4:22 pm
7. 

   Interesting class…
   But something surprises me: you say you use XML because it’s native (so it’s faster than JSON, for example) but you use the Signal logic instead of the EventDispatcher one, which is native.

   Are Events that bad?
   Using Signals doesn’t slow things down too much?

   I’m always interested in new ways of thinking (used to love Grant Skinner’s AS2 GDispatcher, for example) but the first step to using them is to understand why other folks do so!

   By the way, thanks for changing you programming style! I guess your previous one didn’t match Adobe’s recommendations, right?

   Quentin  Jan 20  5:11 am
8. 

   I don’t know the exact terminology for the explanation, so I’ll be as broad as I can. When I say ‘native’, I mean it takes advantage of non-AS3 code underneath the hood. Because of this, the XML class couldn’t stand alone as a single AS3 file. EventDispatcher, on the other hand, is not native in the sense that XML is. It is a single AS3 file. It could be rewritten and improved with just pure AS3.

   Signals is faster—from my tests, I saw a ~25% performance boost with dispatching. It lacks the event instantiation overhead that EventDispatcher has—there are no event instances to create each time dispatch is called. Signals use classes as event types instead of strings and provide a serious amount of flexibility with listeners. If I were you, I’d give it a shot. You feel ‘cleaner’ after using Signals

   In the past few months, I’ve been following Adobe’s coding conventions pretty closely. I find my code much cleaner and easy to read now.

   Jonnie  Jan 20  8:32 am
9. 

   Thanks, I’ll give Signals a try for sure.
   About Adobe’s conventions: I totally agree (and also try to follow them, too)!

   Quentin  Jan 20  8:38 am
10. 

    First time I’ve seen the signal pattern, it does look like less code.

    It breaks the event model that display objects use, not sure I’d like my projects dispatchers use different standards, but I’ll keep an eye on the project.

    Kris  Feb 25  11:37 pm

Reply