The History

Almost exactly two months ago, I announced the first public version of SwiftSuspenders, my DI/ IoC solution for AS3.

In that announcement I proposed that SwiftSuspenders might be finished and probably wouldn’t receive many changes anymore. Well, as it turns out, that was ridiculously wrong. Starting with version 0.8.1, the Robotlegs framework bundled SwiftSuspenders and as of Robotlegs version 0.9.1, it’s the only bundled DI solution, with adapters for other solutions available in their own github projects.

The Contributions

Combined with a huge increase of popularity of Robotlegs, this caused a constant influx of not only demands for features and bugfixes in SwiftSuspenders, but also design feedback and substantial contributions from Shaun Smith, Joel Hooks and Robert Penner.

The Release

Based on this feedback and in large parts thanks to these contributions, I’m happy to announce the release of a much improved SwiftSuspenders 1.0!

Contained in this release are many improvements over my initial beta release:

• setter injection
• method and constructor injection with optional arguments
• [PostConstruct] metadata annotations, allowing method invocation after the injection process completed
• XML configuration of injection points, enabling developers to use SwiftSuspenders in Flash Pro, which doesn’t support custom metadata
• Injector#mapRule, enabling mapping multiple requests to the same response configuration
• much improved unit tests
• countless bugfixes
• an even cleaner codebase

The Future

As outlined in this thread in the Robotlegs discussion group, I’m planning to tackle the “robot legs” problem next (for which I can’t seem to find a good explanation anywhere – links are much appreciated!)

I hope to get that done pretty quickly, so a 1.1 release might not be too far off.

describeTypeJSON

So it looks like Flash Player 10.1 might support a somewhat improved reflections API containing support for:

• retrieving reflected information as JSON (or rather, as an AS3 object tree)
• filtering the request to only retrieve certain types of information
• Some more functions that are used internally to construct the result of describeType

In other words, it containes improved access to the information available through describeType and nothing more.

All of this functionality resides in the avmplus package in the playerglobal.swc that can be downloaded from labs.adobe.com.

This package contains a few methods and an assortment of constants:

The most (or only, really) interesting of these is DescribeType.describeTypeJSON. Using this method, it’s possible to retrieve reflection data as an object and to filter certain types of information using the constants seen in the image above as bit flags. For example, to get only information about the reflected classes constructor, you use the following code:

DescribeType.describeTypeJSON(TargetClass,
	avmplus.INCLUDE_CONSTRUCTOR |
	avmplus.INCLUDE_TRAITS | avmplus.USE_ITRAITS);

Using the different flags, it’s possible to request an object containing exactly the information needed for a certain use-case. For example, in SwiftSuspenders, I’d use the following code to get information about a types’ methods, getters/setters, variables and constructor, all with associated metadata:

DescribeType.describeTypeJSON(TargetClass,
	avmplus.INCLUDE_CONSTRUCTOR |
	avmplus.INCLUDE_METHODS |
	avmplus.INCLUDE_VARIABLES |
	avmplus.INCLUDE_ACCESSORS |
	avmplus.INCLUDE_METADATA |
	avmplus.HIDE_OBJECT |
	avmplus.INCLUDE_TRAITS | avmplus.USE_ITRAITS);

The last two flags have to be present to get any meaningful information at all. I honestly have no idea why it’d be necessary to explicitly state that, yes, I want to include traits – you know, the mechanism with which the virtual machine links everything to classes and without which a class is completely uninteresting. And don’t get me started on what avmplus.USE_ITRAITS stands for.

All of this can also be used with the new avmplus.describeType, which is essentially identical to flash.utils.describeType except that it adds an additional parameter for the configuration flags:

describeType(target : Object, flags : uint) : XML

Detours

If you think that that’s all you need to know about how to use this new API, think again. All of these methods and the DescribeType class are implemented as internal types of the avmplus package and thus not accessible from outside this package. Fortunately, this can be worked around by creating a public wrapper in the same package:

Is it all just a mistake?

There are some things that are a bit fishy about this whole affair: Why is all this functionality internal to the avmplus namespace? And what’s with the name “avmplus” in the first place? Seems like a weird choice to expose the project name of the VM in such a way. Also, the API feels quite rough and exposes functionality that’s seemingly useless to AS3 developers.

Investigating some more, I discovered how this entire API came to be: It’s the new implementation of the old describeType functionality in the new version of the ActionScript Virtual Machine, code named Tamarin Tracing. The log message of the commit which added it sheds some light on this. Since this initial commit, a few changes have been made, resulting in the current version of the API as exposed in 10.1 beta.

Now here’s my guess about what’s happened: When creating the Flash Player beta, some configuration option was set the wrong way, causing the avmplus package to be visible within playerglobal.swc, when it really should be an invisible implementation detail. At the very least, the API in this state probably isn’t meant for public consumption and might well be removed in the final 10.1 version.

Now what?

I’d really like for this API to stay – be it in the current state or as a polished version located in the flash.utils package or wherever. Unfortunately, I’m not sure what to do to that end; Adding a bug to the Flash Player issue tracker to ask that something that’s available in the beta should stay that way in the final release seems odd.

Working with RobotLegs

Recently, I started working with the awesome MVCS framework RobotLegs by Shaun Smith.

As I’m not a big fan of the configuration overhead that the Spring framework for Dependency Injection brings with it, I immediately fell in love with the metadata based SmartyPants IOC framework. While I really like the approach and everything worked great, I quickly realized that SmartyPants has two problems: It’s somewhat slow and, due to some dependencies on the Flex framework, rather big.

SwiftSuspenders: A fast, lightweight DI solution

That’s why I started implementing an ultra lightweight DI framework (which hardly even deserves being called a framework) which then became SwiftSuspenders.

SwiftSuspenders implements exactly the functionality needed by RobotLegs, nothing more, but, crucially, nothing less – and it does so as fast and as lean as possible. By focusing on these needs, I was able to implement a solution that’s about an order of magnitude faster and weighs only 10% of SmartyPants file size-wise. And yes: Both of these values are SWAGs and shouldn’t be relied on for, well, anything.

Right after I published SwiftSuspenders on GitHub – as you should do with everything you build that might be of help to your esteemed colleagues – awesome stuff happened: Shaun Smith immediately forked to project, started fixing bugs and embarrasing mistakes in the documentation and switched most of the examples for RobotLegs to using SwiftSuspenders and hinted at creating unit tests – which I shamefully neglected. Yesterday, he followed up on that and pushed a range of unit tests to a new GitHub project!

What now?

Apart from you reading the introductory documentation, starting to use SwiftSuspenders and forking it on GitHub? I’m not sure.

I think that maybe, SwiftSuspenders is pretty much done as it is. SmartyPants still has some features that SwiftSuspenders doesn’t, but for now, I don’t think that those are really essential. Then again, I might implement Provider Binding and Rule Binding sometimes later – whereas I can almost guarantee that I won’t implement live bindings.

Most people don’t think in code points – which seems like a pretty good state of the world to me.

The only downside is that dealing with fonts for Flash applications and sooner or later the whole web is far more complicated than it would otherwise be. Let me explain.

Each time your client requests you use their corporate typface or your designer decides that he absolutely, positively can’t use a web-safe font for some other reason, you have to somehow get font glyphs to the user that he doesn’t already have installed on his machine. In html, this is mostly done using png’s, increasing the download time and the complexity of changing the content. But at least for Flash you can instead embed the glyphs and keep your content as text. How do you do that? You embed the font in your swf and let the Flash player use it to render the content.

Now what you don’t want to do is embed the whole font, because that’ll add between several dozen kb and several mb (no kidding!) to your swf. Instead, you’ll want to embed only the glyphs you need to display your content. And this is where Unicode code points come into the picture: You need to use those to tell the compiler which glyphs to embed.

To make a long story short, you’ll have to find out which Unicode ranges to use to make the compiler embed the glyphs you need. And for that, I’ve written a small JavaScript tool, which allows you to enter ranges of characters or just a bunch of text, which it then converts into an optimally reduced set of Unicode ranges.

You can find this tool here, I hope you find it useful and not too ugly.

To the world at large and you who is reading this in particular: Hello!

As seems pertinent for an introductory blog post, let me tell you a little bit about myself and what you can expect to read here in the future.

I am a web developer mostly concentrated on solving highly technical, rather abstract problems using ActionScript and other front end web development technologies. That is to say: I’m a Flash developer, but in contrast to many of my peers, I’m not too interested in fancy animations and gratuitous effects. Thus, I’m drawn not the quickly built, glossy high end projects that dominate the Flash world but to the invisible technical challenges that lie behind each well-built site or application.

I constantly re-evaluate my views on what is a good balance between pragmatism and theoretical soundness in my daily work, trying to stay on the right side of the boundary between writing maintainable code and becoming an architecture astronaut.

For the last two and a half years, I’ve lead the Flash development team at Fork unstable media. Before that, I worked as a freelancer for about seven years and studied philosophy and an ever-changing assortment of minor fields.

As of July 2009, I will be a co-founder of a yet-to-be-named startup located in Hamburg, Germany. What are we going to do? Mostly two things:
1. Work as a technical sub-contractor for for internet agencies, concentrating on websites, applications and presentations mostly done in Adobe Flash.
2. Try to cross the chasm that lies between the proprietary world of Flash and the standards-based rest of the web-universe.

Should you decide to return, I’ll tell you a lot more about this second aspect of what we’re going to do and about why I think that we’re going to fill an important niche.