SWC’s & Shared Libraries in Flash Development

One of my experience sharing notes, below, to my peeps on Flashn00bz. Although SWC’s have been around since November, I’ve only recently started to understand where Flash 8, or a big updated of Flash 7 needs to take us in terms of Shared Libraries and SWC’s. Shared Libraries, even if your only using 1 SWF in the end, enable unit testing of components, and prevent redundancy in assets. If I have a Button component, Shared Libraries of many tiers all reference the same asset vs. SWC’s which compile them internally, and therefore allowing multiple SWC’s to use the same button, but keep their own copy unecessarely. However, Shared Libraries are not as portable as SWC’s, more fragile, and less control on execution order in the case of mixing SWC’s with Shared Libraries as I experienced last week. Either a decoupling of assets in SWC’s needs to happen to ensure they are not being repeated, OR you’ll just have to plan really frikin’ well ahead of time. Additionally, Shared Libraries need, as I talk about below, to get the ability to dynamically change their Shared Asset URL at runtime. It’s amazing, as much as I love both of the above technologies, I can still see tons of room for improvement, in both the IDE and the Player itself.

Anyway, read on…

4 Replies to “SWC’s & Shared Libraries in Flash Development”

  1. I am happy to see that you are interested about libraries, because this is also a major concern for me. I think that all problems should be resolved like this :

    1) Users should use a “namespace” logic when linking their assets. For example :

    2) Macromedia should add a new method to the
    movieClip class : addLibrary (). For example, if you want to update or download some new assets in you library, you would do like this :
    myMovie_mc.addLibrary (“myAssets.swf”);

    If you always update the “root movieclip”‘s library, then this mean that you can always attach any asset EVERYWHERE in you project !!! What a dream for a flash programmer !!!!!!

    I hope Macromedia will understand…


  2. The way I see the implementation is simpler, like this. A symbol in the Flash library, at runtime, can have it’s linkageURL property set by a method. This triggers the download of that shared library, and you get an onLoad event when it’s done. Example:

    var symbol = my_mc.symbol;

    This would effectively cause an onUnload event in the movie clip, because whatever asset’s he was using are not defunct. Therefore, a global approach, like JSFL does would be great, too:

    var d = fl.getDocumentDOM();
    var lib = d.library;
    var items = lib.items;
    var howMany = items.length;
    for(var i=0; i

  3. This is as alaways jesse, a good read. I’ve found the whole SWC + Shared Libraries basically hands off, as it got to the point where i sat back and went “it doesn’t make sense, and it hurts! to think about it”.

    Personally, I’d prefer short-term they introduce a method like “dupliateMovieClipInto(source,target,initObj)” or “attachMovieClipFrom(sourceSWF,sourcePath,TargetPath,initObj)”

    This would be awesome as you could simply use loadMovie() (leverage the browser cache i guess), then take your skin Symbols and dynamically attach them to your primary movie resulting in the ability to have a skinpack.swf loaded wtih all your skins?

    FUX me…

    Point is, this whole Sharing of assets through-out different SWFS has to be TOP Priority for the next Flash release, as its got to stop and its becoming a chaotic joke.

  4. I’m with ya. It’s already built in partially; __package or whatever it’s called (Peter Hall’s blog talks about it more) allows you to avoid putting a movie clip into your SWF in the first place. Additionally, an SWC is just a SWF that houses your component. If you can have an SWC with a SWF inside have it’s symbol ripped out and put into the resulting SWF your compiling, there doesn’t seem to be any reason you couldn’t do that at runtime. I don’t mean that being built in already, I mean the same concept; I’m not that arrogant.

    I agree about the sharing, too. That has GOT TO BE my favorite feature of Central is that the components are ALL Shared Libraries, so you can use 50 of them, and your end SWF is still like 22k… it’s insanely cool. I wish the next framework is like that.

Comments are closed.