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:


Sometimes, you need to use a dynamic textfield in flash where it’s necessary or more convenient to create the textfield completely dynamically (not placed on the stage in a movieclip in the library). You style your text nicely and set up everything so that it looks just right and then when you go to animate it, the animation looks very rigid and jaggy. This issue is most likely the result of the gridFitType property.

GridFitType is a textfield property that controls how a textfield’s anti-aliased pixels appear within the the stage’s pixel grid. When the textfield is resizing, it’s pixels might be forced out of the flash stage’s pixel grid, which in turn may force a word to move over to the next pixel, which in turn can force it down to the next line if it’s close to the edge. It also makes it so that when animating, each pixel rounds out its position to the next full pixel instead of letting it smoothly animate between pixels, creating the jagged looking motion

The solution to this jagged pixel animation issue is to change the gridFitType property to either NONE or SUBPIXEL. When the textfield is created dynamically, the default gridPixelType is set to PIXEL, while when created through the IDE it’s set to NONE. Below is an explanation of the three options below according to the Adobe AS3 livedocs here.

The 3 available options are:

  • NONE– This specifies no grid fitting and provides for the smoothest animation. This is the default when a new textfield is placed on the stage through the IDE.
  • PIXEL– This specifies that strong horizontal and vertical lines are fit to the pixel grid. This setting works only for left-aligned text fields. This setting generally provides the best legibility for left-aligned text. This is the default for dynamically created text fields.
  • SUBPIXEL – This specifies that strong horizontal and vertical lines are fit to the subpixel grid on an LCD monitor. The subpixel setting is generally good for right-aligned and center-aligned dynamic text, and it is sometimes a useful trade-off for animation versus text quality.

In order to take advantage of the GridFitType property, the textfield’s anti-alias property is set to ADVANCED. Otherwise, it will use the default gridFitType property.

The examples below show how the default textfield plus the 3 types affect the text when it’s being resized. As you can see, setting it to NONE is the smoothest, while PIXEL is the most readable. Setting it to SUBPIXEL is best when you need something more readable than none and smoother than PIXEL.

[swfobj src=”” alt=”This shows how the default and the 3 types of gridFitTypes when applied to a textField that is created dynamically and has animation applied to it.” width=”400″ height=”340″ align=”center” allowfullscreen=”false” required_player_version=”10″]

Thoughts on Pure MVC

Recently, I used the Pure MVC framework for the first time on a project and it opened my mind to the right ways, wrong ways, and new ways to structure a project in Flash. Before I get into the pros and cons, I want want to first warn any of you that are new to using frameworks in general that there is some studying involved in order to fully wrap your mind around how this thing works. But it’s totally worth it.

Before you jump in, it’ll help if you are familiar with OOP programming basics and have an understanding of what the MVC design pattern is. When I started, I was already quite familiar with MVC pattern and decided that having a framework that laid out some rules for my programming may help in keeping the project consistent. In order for me to completely grasp this new way of thinking, I first took a look at the conceptual diagram and quickly decided that it made absolutely no sense to me. Then I read through the Framework Overview and the Best Practices PDFs multiple times and it started to finally click. The guys who put together this framework did a really good job of providing lots of examples and documentation to help you though this difficult time, so search through and give it a good honest go around before throwing you hands in the air.

After using it for a few months, here’s a summary of the advantages and disadvantages.


  • Provides structure and “rules” for programming your project
  • Used among multiples languages, so your one leg up if you want to use it in C#, Java, or PHP
  • Gives you a better understanding of OOP concepts in general and why they’re so useful
  • Makes it easy to separate your project into multiples pieces which may help if there are multiple people working on a project
  • Makes it easy to remove or turn off features


  • Forces you make a lot of classes
  • Adds to the compile time, so it’s probably not a good idea to use with small projects
  • When adding new functionality, it may take a little more time to implement if it’s going through the entire framework, though it’s more likely that it will be less buggy


Pure MVC was great to learn and helped me more concretely understand some OOP concepts that I was a little spotty on. I’m sure that I will use it again, but only for larger projects where I need a  shell that ties everything together and has a lot of different “modes”. For a smaller project, I’m going to try out Robotlegs, which seems to have some of the same core concepts in a tighter package. Either way, I know that all of my future projects will have some solid structure and some of my own rules for developing it.

Check back soon to see how this Pure MVC-based project turned out.

Oscars 09 Ballot project

I have a new flash project up that I’ve been working on for a few months on and off.

This is an Oscars ballot site that was set up for my family and friends. I used a bit of practical Papervision3D for the ballot selection and Aftereffects for the transitions. It was a fun project, but now it’s time to move on to the next project, the personal portfolio site redesign.

Getting stop() to stop

In as3, the introduction to of the display list has made the stop() method a little less straightforward. Traditionally, when you used stop() on the timeline of a movieclip, it would do just that, stop the playhead from playing past where that script is. To be fare, this does still work, but only if you place the movieclip on the timeline manually (not via code).

Now to get a movieclip to stop on the first frame when added to the display list via the addChild() method, you must be sure to add stop() once it’s added. Also, note that you cannot call any other timeline based methods such as gotoAndPlay() and gotoAndStop() to a dynamically added movieclip unless it’s on the display list either.

This is specifically useful when you are using a movieclip that has a timeline based rollover and rollout animation as a button.

Adding Dynamically Named Library Items to the Display List

To add a library item to a display object using as3, here is the basic method:

var dynamicClass:Class = getDefinitionByName("libraryName") as Class;
var mcFromLibrary:MovieClip = new dynamicClass();

dynamicClass is a variable typed as a Class returns a reference to the class object of the class specified by the name parameter.

“libraryName” is the the name given to the MovieClip’s Class in the Symbol Properties options in the flash library.

Don’t forget to import get the definitionByName class using

import flash.utils.getDefinitionByName;

This is especially useful when looping through an array to attach multiple instances of the same movieclip. Most recently I used it to pass the reference of a loader in the library since I wanted to use the same class to potentially attach different loaders depending on what was being loaded where and when in the program.