Timing

To extend any framework you need to be able to hook into that framework’s initialization process.

That Damned Context

The Robotlegs 1 context class was, to be frank, rubbish – it set defaults, configured dependencies and controlled initialization. Worse, to hook into the initialization process or change the defaults, users had to extend the class itself resulting in the proliferation of funny looking words like SignalDrivenCovariantlyMediatedModularShellContext.

How Could You Let That Happen?

Extending the context was a silly idea – and I knew it at the time. It made me sad, deep down inside, but I knew that if I waited for a better solution to emerge the framework might never ship.

Also, my goals for Robotlegs 1 were:

1. Make it small
2. Make it fast
3. Release it

A ton of compromises were made to keep the number of classes down to an absolute minimum. That’s not how I usually write code. Besides…

Small Only Goes So Far

I always start by doing the simplest thing possible – it’s a good way to feel out a problem space. “What am I trying to do?”. The “how” doesn’t matter yet, but becomes important much later when I ask “How would I like to do this?”.

When writing actual code, however, I’m constantly faced with this annoying question: “Should I break this out?”. When doing the simplest thing possible I often decide against extraction: I’ve got a specific task to complete (like getting a test to pass) and I can refactor later if the idea proves itself to be worthwhile. Also, I know that extraction inevitably leads to a new set of design decisions. And I’ll have to start with a test – for something whose purpose I am only just discovering. And it ups the class count.

Keeping class count down for it’s own sake is almost always a bad idea. However, I don’t think Robotlegs 1 would have experienced the same adoption if it had had hundreds of classes instead of the quite digestible 15 presently in its belly. OK, 24 total if you add the interfaces.

When browsing open source libraries I get happy feelings from projects with a limited number of source files – it gives me a sense that if I really wanted to I could read through the entire codebase and understand it.

But there’s a point where that simplicity inverts. Profit becomes debt. Without good abstractions in place every participant in the system ends up doing too much. At that point the question becomes: “Do I need to introduce a new layer of abstraction?”.

Now You Have Two Problems

The introduction of a system wide abstraction layer fueled by a mid feature code extraction will do one of two things: it will strengthen the system or it will weaken it. A bad abstraction might solve the immediate design issues (like duplication) just fine but end up adding complexity and reducing quality overall.

Extensions? Timing?

So anyway, I want Robotlegs to be extensible in a sensible way. Users should be able to install custom extensions easily. Those extensions need a way to hook into the context initialization process:

Some extensions may need to be configured before others. Some may need to pause the initialization process and wait for a resource to become available. Some might directly depend on others and may need to wait for those extensions to be fully configured before self initializing. Some may only come to life after the entire context has been initialized.

It’s clear that the initialization process needs to be asynchronous. But without a good abstraction in place for dealing with asynchronous processing the context will be burdened with co-ordinating a complex series of events. Event soup is not delicious.

Events, Signals, Tokens, Tasks, Promises, Futures, Callbacks

There are a number of patterns for dealing with asynchronous processes. They have wildly different properties.

Some are low level, like the callback pattern. Some are high level, like the promise pattern. Some are guaranteed to be asynchronous, while others have the potential to be synchronous. Some are only good for observing. Some can be terminated, while others can be suspended and resumed. Some can be composed and chained. Some necessitate the instantiation of throw-away objects and put stress on the garbage collector. Some put stress on the stack.

Take Your Pick

I wanted something fairly low level that enabled asynchronous processing without adding unnecessary overhead in the cases where things could be synchronous (or skipped entirely).

I tried a number of things. For the most part: floppy, verbose and annoying implementations that moved the core problems around in less-than-useful ways.

Dispatch

Slowly it dawned on me. In this case all I wanted was an asynchronous message dispatcher. With a well defined set of callback conventions I could write something resembling an Event Dispatcher but without the overhead of creating throw-away objects (events) and with the ability to suspend and resume the dispatch when desired:

Some Async Conventions

The Message Dispatcher

Initialization, Extension, Please Continue

Very well. Suppose that context initialization comprises 3 steps: preInitialize, selfInitialize and postInitialize. When told to initialize the context moves through those steps in sequence. Anyone can listen in and halt the process as required at any point. What we end up with is in essence just a simple state machine where the observers have the potential to be guards.

The End

Well, that’s where the re-write started anyway.

Robotlegs 2

p.s. I dropped a bunch of stuff from the version2 branch. I’ll be going back to pull out any functionality that might have been lost shortly. If you come across anything that’s missing feel free to adapt it to the new codebase and send a pull request. Or drop an issue on the tracker. For quick reference, here’s the old version2 branch: version2-old

[Test]
public function null_criteria_should_not_match():void
{
  assertFalse("passing null should return false", instance.match(null));
}

When reading the test above I have to do a lot of scanning.

First I see the string message in the middle because it jumps out. The message is redundant as it’s included in the test name. If I change the test I’ll need to change both the method name and the string description. I can see that the string message would be useful for a test with multiple asserts, but that’s generally not a good idea.

After reading the string I look to the right to see what is being tested and mentally try to evaluate it.

Then I look to the left to see what the expectation is, possibly flipping the evaluation I just did to match the expectation.

It’s disconnected, and it’s hard work.

Consider this instead:

[Test]
public function null_criteria_should_not_match():void
{
  assertThat(matcher.match(null), isFalse());
}

Now I just read normally: top-to-bottom, left-to-right. I read the test name, look at what is being evaluated and see what is expected.

While doing some work on multi-context view auto-wiring I wrote a little utility that iterates through the containers in a given display object container and builds some useful stats.

If you have a moment I would love it if you could run it against your Flex or Flash app and post the results in the comments. Please also indicate whether you ran it against a single complex component or an entire app, and whether it was Flash, Flex or Mobile.

GitHub: https://github.com/darscan/boyblack-toolkit

ZIP download: boyblack-toolkit

Usage:

trace(new DocStats(doc));

Sample output:

Display Object Container Stats

All Container Stats
Containers:             521 total
Children per container: 8 max, 1.16 avg
Depths (distance):      29 max, 18.45 avg
Unique container types: 86 total

Unfiltered Container Stats
Containers:             153 total
Children per container: 8 max, 1.69 avg
Depths (distance):      26 max, 16.98 avg
Unique container types: 65 total

Filtered (mx., spark., flash.) Container Stats
Containers:             368 total
Children per container: 8 max, 0.94 avg
Depths (distance):      29 max, 19.07 avg
Unique container types: 21 total

http://oreilly.com/catalog/0636920021216

Written by the amazing @stray_and_ruby and @jhooks

We decided to keep the initial meetup small and focused, but development of the framework itself is completely open and anyone is free to contribute once we’ve nailed down some core priorities.

More info over on the Robotlegs forums:

http://knowledge.robotlegs.org/discussions/feedback/20-robotlegs-20-how-to-get-involved

Automatic Mediation

In order to determine the scope of a view component, Robotlegs listens to the contextView for bubbling capture-phase ADDED_TO_STAGE events:

MediatorMap.as#L233
MediatorMap.as#L260

Every display object that lands on the stage inside the contextView is checked against a mapping dictionary. This can be quite expensive for complex display object hierarchies where there is a lot of re-parenting. It’s also the only option available if you want to keep your view components completely framework-unaware. If, however, you’re prepared to modify your components slightly (it’s a one-liner) then you can try out this utility:

http://github.com/eidiot/robotlegs-utilities-LazyMediator

Instead of listening for ADDED_TO_STAGE events emitted by every component, we listen only for custom events dispatched by view components that explicitly require mediation.

Note: This utility currently only supports the MediatorMap and needs to be expanded to support the ViewMap. Fork and improve!

Default Injection Points

The actors in the MVCS package have a number of pre-configured injection points (dependencies). When you extend mvcs.Command all you are really doing is inheriting some dependencies:

mvcs/Command.as#L23

Whilst handy, it is quite seldom that we actually use all of those in a given Command.

A much cleaner, and ever-so-slightly cheaper approach is to declare only the dependencies that you actually need. Instead of extending Actor or Command (this doesn’t work so well for the Mediator class), just create a vanilla class and declare your dependencies manually:

public class MyCommand
{
	[Inject]
	public var injector:IInjector;

	public function execute():void
	{
		injector.mapClass( Vehicle, Car );
	}
}

Remember, the Robotlegs apparatus is already mapped for you if you need anything:

mvcs/Context.as#L190

Notice that the IEventMap is not mapped as a value or singleton – you’ll get a new IEventMap instance whenever you ask for one.

That’s it for now!

A huge big “Thank You” to everyone involved. Let the “utility building” begin!

Robotlegs is an automated dependency injection framework for Flash, Flex and AIR.

RobotLegs is nearly at v1.0! Many awesome changes since v0.8, with the most community involvement to date:

http://github.com/robotlegs/robotlegs-framework/commits/v0.9.2

The “Official RobotLegs Framework Repository” has also been moved:

http://github.com/robotlegs/robotlegs-framework

A LOT of exciting stuff is going on, and I encourage you to check out the Wiki:

http://wiki.github.com/robotlegs/robotlegs-framework

An upgrade guide from v0.8 isn’t really necessary is it? Here’s a list of some of the changes introduced in this last sprint:

• SwiftSuspenders DI solution fully integrated (bundled) into RobotLegs
• Constructor Injection (via SwiftSuspenders)
• Bonus DI Adapters removed
• CommandMap now features strong Event mapping
• As3commons logger removed
• Utils inlined and removed: createDelegate() and DelayedFunctionQueue
• dispatch() helper method renamed to dispatchEvent()

And various miscellaneous optimisations, cleanups and API changes.

RobotLegs AS3 is a Dependency Injection Driven MVCS Framework for Flash, Flex and AIR.

Help make RobotLegs the cleanest, smallest, most testable, and most kick-ass framework for Flash and Flex ever built – join the discussion group:

http://groups.google.com/group/robotlegs/topics

Or help fill up the Robotlegs Knowledgebase:

http://knowledge.robotlegs.org/