Archive for swc

Code distribution strategies

Posted in Actionscript, AIR, Development, eclipse, Flash Extensions with tags , , , , , , , , , , , , on December 11, 2009 by andkrup

With the 4th version of Adobes Creative Suite (CS4), it is very easy for developers to manage code distribution.

The SWC code component

Using the compc compiler from any Flex SDK, you can create a swf code library file (a compiled zip file, containing your compiled classes in an swf file + an xml file describing the contents of the zip file). This shouldn’t be any news for the experienced flash developer.

Distribution

Managing and distributing swc files is easier if you use some of the tools also provided by Adobe CS4, but first lets talk about what kinds of issues we have distributing code library files.

Ease of installation

It is much simpler to click once on a mouse button than it is to follow a lengthy set of instructions. Technical people, such as developers are more or less used to follow a step-by-step guide so we might be inclined to issue step-by-step instructions that really only help to scare non-technical people away.

A similar problem is when you want to update.

Ease of everyday usage

Working with AS3-based projects, developers have it easy with Version Systems, and if everybody in the shop knows how to work with the chosen VS, code distribution and updates aren’t really an issue.
Working with designers, externals and other kinds of people might put up some restrictions in that you can’t trust people to know how to work with the VS. This means that you must find another way to distribute your code library.

MXP Flash extension files

Bold designers usually have some experience downloading and installing extensions and Adobe has put a lot of work into the extension architecture, so devising a strategy upon the mxp file seems a good idea.

Distribution Strategy

The main strategy is this:

  1. Create the Extension so it contains all the functionality required for people to use the code library and some easy ways to do it (for instance; a JSFL script that inserts the path to your swc file in the current *.fla file in the flash IDE).
  2. Deliver the Extension online.
  3. Facilitate an easy way for users to get update announcements.

1. Creating the MXP extension

MXP Extension files can be made easily with the Adobe Extension Manager2. You can google tutorials on how to create MXP flash extension files, if you don’t know how.

The important part is the <files /> tag. This is where the meat of your extension is.

My best take on what file locations are good to use atm are the Flash configuration folder which you can refer to by using the ‘$flash’ template-variable:

<file source = "as3codelibrary.swc" destination = "$flash/Libraries" shared="true"/>

This will install your swc file ‘as3codelibrary.swc’ into the end-users Flash config folder: (OSX) /Users/<user>/Library/Application Support/Adobe/Flash CS4/en/Configuration/Libraries/as3codelibrary.swc, (XP) C:\Documents and Settings\<user>\Local Settings\Application Data\Adobe\Flash CS4\en\Configuration\Libraries\as3codelibrary.swc.

The Configuration folder is really a mess and if anyone knows of any guidelines as to how to treat these sub-folders, please share.

Along with the swc file I also put a JSFL script enabling the user to add the swc into the compile-path of the current *.fla file. This is quite simple:

var myDoc = fl.getDocumentDOM();
myDoc.libraryPath = "$(UserConfig)/Libraries;" + myDoc.libraryPath;
fl.trace("library paths: "+myDoc.libraryPath);
(Notice that in JSFL, we can refer to the end-users Configuration folder by the variable $(UserConfig))

This file goes into the end-users Commands folder:

<file source = "jsfl/<jsfl filename>.jsfl" destination = "$flash/Commands/" shared="true"/>

, and will be available in the ‘Commands’ menu in the Flash IDE after it has been restarted.

2. Deliver the MXP extension online and facilitate updates

If you have ever tried to use Badger to distribute Adobe AIR applications and/or the ApplicationUpdater AIR packages, ou know how convenient it is to distribute applications online.

The basic idea is to do something similar. If you are a gamer and know Valves Steam application, you can catch my drift.

Steam is a small client that receives information about available content from the Valve servers and compares that information with already installed content.

Creating a small content distribution system that can monitor the status of installed extensions and notify the user if newer versions have been uploaded online is very similar.

This is possible because the Adobe Extension Manager saves copies of installed mxp files + a copy of the MXI file that was used to create the mxp file in a folder similar to the Configuration folder. AIR allows us to access the filesystem and parse the mxi-file for version data.

Have a look in the “Configuration/Extensions” folder: (Mac OS X) /Users/<user>/Library/Application Support/Adobe/Extension Manager2/Configuration/Extensions

Advertisements

Creating a swc library with selected packages in FDT

Posted in Actionscript, Development with tags , , , on May 9, 2009 by andkrup

Sometimes you need to expose only part of your code library in a swc code library file. Maybe you work with propriety code, but also have the need to expose your framework to external developers, so you create some pretty interfaces that externals can use without exposing company code.

One way of distributing these interfaces can be to create a swc library file that only holds your public interfaces.

The compc compiler gives you some options to specify what classes, interfaces, namespaces or packages to include, but when using the Run-configurations that comes with FDT, FDT automatically adds the whole shebang. This is ok for a swc file with no secrets hidden (no mention to decompilers)

As I remember it, the Flex-plugin/editor gives you a nice ui to select what packages to include in your swc file, but FDT is a bit more old-skool.

In this example i use the -include-sources compiler option, but the compc compiler also has the -include-classes option which gives you fine-grained control over what classes and interfaces are exposed in your public swc library file.

In FDT this is one way to do it:

    1. Create a new “FDT AS3 Library” in “Run Configurations…”
    2. Select the “Compiler Arguments” panel and uncheck the checkboxes “Auto add project classpath to arguments” and “Auto add project SWCs to Arguments”. Auto add project classpath…” will insert classpaths to all your packages, which is not the intention, and the project swcs are only needed if your code relies on the definitions found inside the swcs
    3. Insert a -source-path option. Working on a PC for a change, I found that I had to use the full path, no quotation marks and with abbreviated folder names. This means that the path variable for the -source-path option looked like this:
      -source-path=c:/docume~1/<userna~1>/mydocu~1/eclips~1/<projna~1>/src
      

Also remember to use the equals sign

    1. Insert a -include-sources option for every package you want to expose using the same fill path syntax rules. This means that if I want to include my com.andkrup.externalmodules package, I need to add this:
      -include-sources=c:/docume~1/<userna~1>/mydocu~1/eclips~1/<projna~1>/src/com/andkrup/easygame/extern~1/
      
    2. Apply and run.

The <userna~1> indicates that you should exchange it with the abbrevciated name of your user-folder. The same goes for the <projna~1> which indicates that you should exchange it with the abbrevciated name of your project-folder.

FDT will add the output option based on your Output-setting in the “Main” panel.

On the PC I found the compc compiler to act extremely picky about the syntax, using eclipse/FDT. It was very easy to get compc to compile in the commandline, but it seems that you have to be careful about whitespace and line-breaks/returns when you add custom arguments in the “Compiler Arguments” panel in eclipse/FDT.

I was banging my head on the keys for a long time, trying to get compc to accept quoted paths as this:

“C:\Documents and Settings\…”

It seems that when you specify arguments in the “Compiler Arguments” panel, you have to use dos-abbreviated folder names in the path variable which also must not be quoted.

When I get back from the weekend, I’ll have to check how it works on the Mac.

You could also create an ant build file to do the same job, but this post was primarily about how to use the FDT AS3 Library Run configuration.

edit: Instead of using the full absolute path, FDT declares a project-path variable which makes the launch settings more portable. Please read the comments for more information

Using Actionscript Library swc files in CS3

Posted in Development with tags , , , on November 22, 2008 by andkrup

Sometimes in corporate development you might want to share a generic library of classes with developers. Usually the way that is done is by giving them a zip file containing your neatly organized actionscript classes, and have them create a classpath to the unpacked contents, or by sharing a location on a network folder containing those same classes.

If the classes mostly are generic framework classes, used over and over again and you have a good framework design, wouldn’t it be cool if you could hand over a compiled library file (aka swc file)? That way you could also stop worrying about handing over company code to freelancers (it’s a bit more practical to void decompiling a swc than it is to void opening a text file).

The initial procedure would be to compile your library in FDT/Flex and share it with whomever needs to use the code, but as CS3 isn’t installed on my machine currently, this will wait until monday. Googling the subject has yet to turn up any signs of relevant problems, but that may be because I haven’t dealt into it enough to find the best search terms.

Possible show-stoppers include: alignment of flex sdk and cs3 classes (playerglobal.swc differences), how cs3 handle a pure actionscript swc.

(edit: Looking more closely on the google results revealed these among others) Links to pages on the subject:
http://www.deitte.com/archives/2008/08/using_flex_swcs.htm
http://www.deitte.com/archives/2008/09/update_on_using.htm