Thoughts on RobotLegs

Recently, you may have read and heard a lot of people talking about Robotlegs. Well maybe you haven’t, but if you’re a dork like me, you probably have. And even dorkier of me, I find it actually really exciting and has changed how I approach programming.

For those of you who don’t know what Robotlegs is, it’s a micro-framework for Actionscript 3 whose structure is derived from PureMVC and based on the MVCS design pattern. MVCS is basically your standard MVC pattern with the S providing for a Service branch, which is the place to communicate with any external services or processes. It was created by Shaun Smith with Joel Hooks contributing and pushing it into the public. They both have some great information on their websites and have been really open to the community in answering questions and helping other developers out. Like many open source projects nowadays, this project is on GitHub making it free to download and fork and contribute to if you want.

A few months ago, I had a post about my experience with PureMVC, which really actually changed the way I program for the better. Then I heard about RobotLegs from a my fellow Flash developer Justin Emter who started experimenting with it. From there, I heard them talking about it on the InsideRIA and The Flex Show podcasts, at FlashCodersNY meetings, and all over twitter. So there were many opportunities to pick it up. Since I heard that it was based on PureMVC, I figured that I had a good basis to get started and run with it.

Similarities to PureMVC

  • The idea of a main gateway to set everything up and get it started. In Robotlegs, it’s called the Context. In PureMVC, the Facade.
  • The role of the Mediator as the class that handles all incoming framework events that its view components need to be aware of  and outgoing view component events that the framework needs to be aware of.
  • The idea of mapping events to commands, sort of. In PureMVC, the unique “notification” is really what is mapped to a command from other framework pieces, while Robotlegs use flash’s build-in events and custom events that can be mapped to commands. Robotlegs is also expandable enough that you can also use AS3 Signals.
  • The model branch has classes to store your applications data and states.
  • The controller branch is a repository of your applications commands.


  • Robotlegs is smaller (file size wise) and requires fewer files for the most basic project making it ideal for projects of any size.
  • Because of dependency injection and the use of the native event system, Robotlegs makes it much quicker and easier to set up your projects.
  • Robotlegs uses dependency injection so that there is less typing when creating and initializing your main framework classes and automates the process a lot more.
  • Robotlegs doesn’t advise you to create value objects for your models, not that it can’t be done. But for smaller projects, it’s perfectly fine to keep your variables in the model. I prefer to do this when possible, just so that there is one less step between the framework object that needs the data and where the data itself is being stored.

Dependency Injection

Dependency injection is partly what makes Robotlegs so quick and easy to build out projects, but was a new concept to me. Dependency injection, as Wikipedia explains it, “is a technique for supplying an external dependency (i.e. a reference) to a software component – that is, indicating to a part of a program which other parts it can use.” This means that class reference that you inject into a class must exist to reference it, otherwise you’ll get an error. To inject a dependency, the [Inject] metatag is used. The unfortunate thing about this, is that the Flash IDE compiler doesn’t support that, so you have to use the workaround found in Helmut Granda’s blog post. It’s not hard, it just involves a bit more typing up front.

To get started, here are some additional resources: