Generating Runtime Revision Control Between Dependent Applications

If there is one general weakness with the Flash Player technology as a whole, it is that it does not have very good capabilities, much less the tools, to detect runtime collisions: intentional or otherwise.

While this kind of problem is probably more rare than it is common, there is one issue that greatly increases the likelihood of encountering this problem: multi-packaged .swf files to a given project, and rises to the ranks of practically a given especially if any of those files use any of the same classes.

This problem came up a few years ago for me when I was working as a Flash Engineer supporting multi-language components and applications. Anything in Flash 8 or lower was a chore to get it to support dynamic font sets at runtime. Typically this meant building out small font files with the embedded character set plus some classes to manage the setup and tear-down of these files at runtime. Since the overall application also used these files, especially the management files, I first noticed the issue when I re-published one but not the other and both the code and trace statements did not reflect the current change I just made. Since the fonts were being loaded through the application, even if the application had a more recent version it was being overwritten by any class reference in the font file.

I had to research this for awhile but I came up with a decent detection solution, and it becomes even more automatic if the project is used in an SVN setting. I don’t have anything at this time which can do conditional exception handling, 1. because I haven’t thoroughly researched it, but 2. I’m not entirely certain if it’s possible to save a reference to the existing class (not an instance, but the class prototype itself) and inspect a namespace collision before actually overwriting that class.

Part 1: SVN File management setup.

SVN has the ability to add metadata to any text-based file at the time of commit. Currently it’s only capable of adding the revision number, the commit time, and the last author of the commit. Note: for the following screenshots, these were taken from TortiseSVN integrated file management tool.

SubVersion Properties for a controlled file SVN Add Edit Remove Property Metadata SVN Metadata Inclusion

Part 2: Adding the SVN keyword replacement indicators.
SVN uses the metadata keywords by looking for keyword enclosed in ‘$’ on each side. Use the example below to include this information for runtime use.

package {
public class MyClass {
public static var svnClassRevision:String =‘$Revision$’;
public static var svnClassDate:String =‘$Date$’;
public static var svnClassAuth:String =‘$Author$’;
}
}

Part 3. Adding in the SVNManager
Adding in the SVNManager allows the revision information to be registered to the class and have it’s raw string content parsed into something meaningful for usage in flash / flex. Following the same example from above:

package {
import flash.util.getQualifiedClassName;

import com.bfsAPI.managers.SubVersion;
import com.bfsAPI.managers.ISubVersionable;

public class MyClass implements ISubVersionable {
public function get svnClassRevision():String { return ‘$Revision$’; }
public function get svnClassDate():String { return ‘$Date$’; }
public function get svnClassAuth():String { return ‘$Author$’; }

private var svnManager:SubVersion;

public function MyClass() {
this.svnManager =new SubVersion().getInstance(); this.svnManager.addPacket(getQualifiedClassName(this), this);
}
}
}

While this solution is not a perfect fit, it does at least allow these sorts of problems to be more easily detected especially during the last development / bug-fix cycle.

 As soon as I am able to get some free time, I will post the management package I wrote if anyone is interested in developing something with it, or to inspire ideas of their own.