<meta name="viewport" content="width=device-width, initial-scale=1.0,
  minimum-scale=1.0, maximum-scale=1.0, user-scalable=no,
  target-densitydpi=device-dpi"/>

To be fair, it’s not a Flash/Flex issue at all, but rather a mobile browser detail worth knowing about:

http://www.html-5.com/metatags/index.html#viewport-meta-tag

Essentially, mobile browsers assume a default viewport width of 980px at 72dpi for any given web page and scale the content according to the actual device DPI.

Good for HTML; probably not want you want for your fullscreen Flash/Flex app. Use the tag above to prevent scaling.

What surprised me most about the first Try { Harder } was just how intense the whole thing was. At other conferences you can often just sit back and learn at your own pace (provided the material is actually technical enough to keep you interested). T{H}2011 was different.

I remember feeling completely exhausted at the end of each day – but it was accompanied by that lovely feeling you get when you know you’ve worked and grown as much as you can in a single day. Sleep is pretty epic after days like that!

However, it wasn’t just the talks and workshops that did this, it was meeting and talking to those folks whose blogs you read. Those people who you chat to on twitter but haven’t met in real life. That was, perhaps, the best part for me.

Now, I’m not the most social person in the world at the best of times, so this aspect was also quite overwhelming. Fortunately the week started off with an amazing talk that helped put everyone at ease. I can’t share the details but everyone agreed: it was the perfect way to reduce the inevitable resultant anxiety of a bunch of smart nerds meeting each other for the first time. This is just one example of the thought that went into the conference as a whole.

Try { Harder } Level Up: 19th – 23rd March 2012

I believe there are a couple of spots left for T{H}LU. If you can, you should come join us next week. It’ll be fun!

http://www.tryharder.org.uk/level-up-2012/

Update: Pricing for freelancers has dropped to £699 (including accommodation).

Update2: JetBrains are supporting the event by offering personal licences of IntelliJ IDEA to all attendees!

When you put a readme file into a folder that file is formatted and presented nicely through GitHub’s file browser. For example:

https://github.com/visionmedia/uikit

Scrolling down a little we can see a nicely formatted readme file.

GitHub strongly recommends adding a readme file to the root of your repository, but what I didn’t realise until recently was that it works for any folder in your repo. GitHub already has the best online file browser out there, but this specific feature can turn your source tree into your documentation.

For Robotlegs 2 I decided to try it out:

Async
MessageDispatcher
Extensions

Almost every package in the entire repo has a readme file. The best way to learn about Robotlegs 2 is to browse the source and readme files on GitHub.

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

Bad “I did this” form:

I had a cup of coffee, went for a walk, and changed some code.

Better “This commit does this” form:

Adds unmap() to the command map API.

A commit message should describe the commit, not the process you went through to create it – it is not a diary.

[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

Some things that these framework experiments will probably have in common:

Support for the Mediator pattern
Support for the Command pattern
Display-list processing (auto-wire)
Dependency Injection through Swiftsuspenders

The first of these is Boiler by Rasheed Abdul-Aziz (@squeedee): http://devblog.vworkapp.com/post/8538689880/r

Please have a look and give Squeedee some feedback. Some things that I like: convention over configuration, avoiding inheritance, the name!