Last month’s Flash platform group meeting was presented by Michael Plank and Frank Piotraschke from Powerflasher, authors of FDT the Actionscript IDE plugin for Eclipse. One of many features of FDT Frank demonstrated was SWC and SWF(-ish) browsing support.
He opened debate as to whether adopting a SWC or SWF nominated workflow for handling compiled components and libraries is more desirable, presenting methodology for both. Although then a decent excuse for him to show off FDT, each approach has its benefits and it’s good to know how to code both – previously I’d never used SWFs in this way, always choosing SWC files.
To use a SWC as a linked library and access a clip as a dynamic class, establish a linkage in the library to a class definition that does not exist – for example:
com.hibbins.Clip
When you click the ‘Validate class definition’ tick, you’ll get an alert that the definition cannot be found and it will be automatically generated upon export. Export the SWC and add it to your project classpath and it’s ready to use. Just instantiate it as you would any other class, note the import if your packaging requires it:
package
{
import flash.display.Sprite;
import com.hibbins.Clip;public class SwcTest extends Sprite
{
public function SwcTest()
{
var clip:Clip = new Clip();
addChild(clip);
}
}
}
To do the same with a library from a compiled SWF, you need to load the SWF file containing your assets into the same Application Domain as your loading SWF file. The following diagram represents the classes available to each SWF file considering their respective domains:
The SwfTest class exists within the loading SWF file, the Clip class in the library file (published as assets.swf). Loading the file in to the current Application Domain shared the loaded SWF domain classes within the main class pool:
The following code demonstrates how to do that, then instantiate the class with the getDefinitionByName method:
package com.hibbins
{
import flash.display.Loader;
import flash.display.MovieClip;
import flash.display.Sprite;
import flash.events.Event;
import flash.net.URLRequest;
import flash.system.ApplicationDomain;
import flash.system.LoaderContext;
import flash.utils.getDefinitionByName;public class SwfTest extends Sprite
{
public function SwfTest()
{
var loader:Loader = new Loader();
var context:LoaderContext = new LoaderContext(false,
ApplicationDomain.currentDomain);loader.contentLoaderInfo.addEventListener(Event.COMPLETE,
onLoadComplete);loader.load(new URLRequest(“assets.swf”), context);
}private function onLoadComplete(event:Event):void
{
var ClipClass:Class = getDefinitionByName(“com.hibbins.Clip”)
as Class;var clip:MovieClip = new ClipClass();
addChild(clip);
}
}
}
Both are pretty quick ways to handle custom MovieClips from your library dynamically. If you want to add any functionality to the clips you can write their classes using matching definition paths. Be aware though, any timeline actions will be dropped if you do this.
If you really want to keep frame actions, I’ve found two ways – firstly by using frame labels which are maintained elsewhere and coding around those, the other only works with SWC files, creating a class which extends from the dynamic clip class. With the SWC in your class path you won’t have any compilation errors.
As Frank pointed out, SWC files can be a lot heavier when loaded on application startup which can make your main SWF quite large. Using SWF files over SWCs, you can create an sequential load manager or only load them asynchronously when necessary. Also, with SWCs being relatively new in comparison to SWF use, you might have no choice. On the other hand, the SWC workflow is simpler and many IDEs have some form of SWC explorer – FDT and Flex Builder, for example.
There’s also an a shortcut to display the contents of a SWF in the same way in FDT, though it’s undocumented. Hit Alt+Shift+W and you can get an outline view (I don’t think this works on all versions of FDT though). It would be good if when this is better integrated into FDT, the classes are recognised in a similar way to the SWC support for auto-completion – as Tink says in the video, to avoid the ‘flakey’ long line of code that’s easily prone to mistyping.
Presentation slides, source code and videos are now online [via].
