Blog

In my final MX days, I finally found the Utopia of application design using components. I’d create a component, export it as a shared library, and drag it into a FLA that needed it. I’d do this for a few tiers, and end up with a bunch of tiny SWF files, all utilized in one main one. This for the most part worked out pretty well. Fast to compile and test, and faster for the user to download and run because of the lack of redundancy in code and component initialization.

However, there were still problems. For instance, something as simple as folder structure. Although Flash still detected the component being used twice in a library if you attempted to drag it in from another FLA, the assets and such were usually yuked amongst your library contnets. So, if Component A used some assets, who were also exported as shared assets, they still came with the component if they were on the assets layer like they should be. Still, you didn’t “need” them in the other FLA’s library, and sometimes, you could have conflicts with similiary named assets, asset folders, or linkageID’s. It made them really easy to break. Although multi-tier Shared Libraries are great and powerful, components usually have assets they need, and even though their distribution does not negatively affect your runtime playback or authortime compiling time, it hoses your organization and poses a risk that you may accidently break a component by removing or overwriting an asset.

Enter SWC’s. As a component developer, exposing certain assets is a necessity to allow the designers and developers that I distribute to customize their look and feel, and sometimes the code itself. However, it also makes them fragile, and easy to break. Although empowering users to make the most of my components, great power comes with great responsibility… sometimes adding more work than is really necessary for a designer/developer. Therefore, utlizing an SWC, I can have the designer/developer simply use one file that is protected from modication, and they can’t really lose except from my lack of ability to code it right. Assuming you have some sort of style and skin support, your golden.

…what I HAVEN’T figured out is if works exactly like a Shared Library does in terms of compiling, etc. This is probably a PowerSDK question, really, but in my tests using SWC’s as SharedAssets, the filesizes are different, meaning the SWF that actually uses the shared asset has like no filesize at all, telling me it’s pulling it correctly. I just can’t tell from the actual time it takes to compile if it’s really making a difference (having an SWC as a shared asset), but regardless, I now have a great way to ensure it’s nigh impossible to break one of my components, ecspecially when implmented into a mutli-tired Shared Library application.

In a bare bones simple creation of a SWC file, I could not get it to work. Testing the component as well as testing a compiled clip both worked, but not an SWC. I read the tutorial by <a href=”http://www.macromedia.com/devnet/mx/flash/articles/buildtest_comp.html”>Allen & Nigel on Macromedia’s site</a>, dug into the chattyfig archives, and re-read the Flash help a few times. Still no dice.

Turns out, you have to ALSO define your AS2 class in the Component’s defintion panel. Right click on the symbol in the Library, select “Component Definition…”, and then type in your AS2 class name in the AS2 class field provided.

I didn’t see this documentated anywhere, so until someone body checks me on a RTFM part that I somehow missed, I’ll make a tutorial soon so no one has to go through the 2 day pain that I did.

Thanks again Johan Nel from Flashcoders with helping me out!