SomaLoader
SomaLoader is a lightweight loading manager written in AS3. You can load many types such as images, swf, xml, text, xml, css, fonts in a swf, mp3, variables and binary data. Items can be added, removed and changed in position from the queue even while loading.
SomaLoader provides a simple and unique interface for massive loading, to listen to events and access to data.
SomaLoader has some specific features such as targeting before loading, easy loading progress display, caching system and binary loading for “silent loading”.
SomaLoader is a standalone version of the library you will find in the version 2 of the Soma framework.
This work is licenced under a Mozilla Public License 1.1 (MPL 1.1)
Version 1.0.2
source code and tutorials on the SomaLoader google code project


Entries (RSS)
March 3rd, 2009 at 4:05 pm
Nice loader,
is there a way to add the context for swf files ??
Niels
March 3rd, 2009 at 5:12 pm
yes, using the loaderContext property of the SomaLoader instance:
var loader:SomaLoader = new SomaLoader();
loader.loaderContext = myLoaderContext;
March 11th, 2009 at 4:20 pm
Hi,
really awesome work you are doing. Thanks a lot.
Cool would be a option to set max parallel connections like bulkloader in the constructor:
http://www.stimuli.com.br:8080/media/projects/bulk-loader/docs/
March 11th, 2009 at 6:16 pm
Hi ffx
Thanks for the comment
I thought a lot about having a single connection or a defined number of connections. The problem is more connections you have, less responsive the Flash Player might be (depending or what you’re loading).
The thing is I’ve never really needed that, I guess having multiple connections can be useful for mass loading from multiple domains. Otherwise, loading items from a single domain, I’m not even sure multiple connections would be quicker.
So, I still think about. Just to understand and maybe convince me, why would you need to have multiple connections for?
Romu
March 11th, 2009 at 10:19 pm
That’s exactly the reason why I mentioned it. I also experienced lot of slow downs if I load a lot in a parallel way. So if there is no parallel loading at all in one instance, I am happy with it.
July 8th, 2009 at 5:57 pm
[...] SomaLoader http://www.soundstep.com/blog/downloads/somaloader/ [...]
September 30th, 2009 at 1:24 pm
[...] SomaLoader http://www.soundstep.com/blog/downloads/somaloader/ [...]
October 2nd, 2009 at 2:40 pm
Hi, if I loaded a SWF with somaloader, how can I access something inside that Moviclip?
Thanks
October 2nd, 2009 at 3:00 pm
Like this:
function completeHandler(e:SomaLoaderEvent):void {
if (e.item.type == SomaLoader.TYPE_SWF) {
var movie:MovieClip = e.item.file as MovieClip;
movie.gotoAndPlay(20);
}
}
Here I cast it to a MovieClip, but try to trace(e.item.file), and you should see the Document Class of the loaded SWF, so you can cast it to another class instead of a MovieClip.
var movie:MyDocumentClass = e.item.file as MyDocumentClass;
movie.myMethod();
This has nothing to do with SomaLoader, it would be the same with a Flash built-in loader (as they are used in SomaLoader).
Romu
October 2nd, 2009 at 3:13 pm
Thank you.
I was casting it as a Sprite, but it has its own class.
November 7th, 2009 at 12:47 pm
Hey Romu, great Loader. Was just about to play a little with it. First thing I struggled was that I couldn’t find a way to access a loaded SWF’s library / Symbol definitions. Ideally there was a additional property applicationDomain in the SomaLoaderItem, that gets copied over from the LoaderInfo Object. Via applicationDomain.getDefinition() I could then gather all linked Symbols from the loaded swf lib.
November 7th, 2009 at 1:15 pm
Also a custom id for each loader item would be cool, i.e. to check against in the complete handler. Now as far I see I can only check against the document class or the url ( type doesnt make sense if I load 10 asset swfs )
I know the url acts as an id. ( getItem( url ) ), but what if I use different urls upon a runtime check, if the movie runs local, local remote or remote.
loader.add( “mySWF.swf”, myId )
private function completeListener( event:SomaLoaderEvent ):void {
if( event.item.id == myId ) {
// do someth
}
}
November 9th, 2009 at 2:14 pm
[...] SomaLoader http://www.soundstep.com/blog/downloads/somaloader/ [...]
November 18th, 2009 at 12:16 pm
Henry, you got a “data”-parameter you can setup as any custom object, for example {id:”MY_ID”} when adding items to the SomaLoader-instance. Take a look at the parameters when adding an item.
The one thing I am missing – in which will make me try out other loaders – is that I would love to be able to add event listeners to specific items, and not only to the SomaLoader-instance. I feel that it is necessary when having different classes being able to monitor and follow the specific item needed.
For now, if I want to listen for a specific item – I must listen to the SomaLoader-events – adding an if:
private function onSomaLoaderCompleteInstanceEventHandler(event:SomaLoaderEvent):void
if(event.item.file == “matchesthisfile.jpg”){
trace(”Now MY FILE was completed”)
}
}
But this seems to be a bad option if you have many places that all the time will be needing of a specific listener.
having this would be cool:
somaLoaderInstance.getItem(”myfile.jpg”).addEventListener(SomaLoaderEvent.START, onStartHandler)
I dont think this would be hard to implement without breaking anything.
November 18th, 2009 at 1:27 pm
hi martin,
I kind of build it to be able to monitor without having to do that:
somaLoaderInstance.getItem(”myfile.jpg”).addEventListener
Now you are not the first one asking me this and I can undertand it might be useful.
I’ll have a look when I get a chance!
Romu
November 18th, 2009 at 1:50 pm
Hello Romuald,
If you are having time – and if you think my idea is a good addition – please feel free to email me if there are any questions or tests you want me to be apart of.
I managed my project without the somaLoaderItem.addEvent… so it is not a must-have feature – but it would have made the coding more practical and easier to write.