An overview of RobotLegs: Actionscript 3.0 framework

Published on Tue 28 Sep 2010 by Will

I’ve been using RobotLegs to develop Flash applications for personal and commercial projects over the past year. I thought I would share this brief high level overview of the framework.

What is RobotLegs?

RobotLegs is a lightweight framework for developing applications in Flash. It is based on the MVCS meta design pattern (Model, View, Controller + Service).

As a framework, RobotLegs has the goal of providing the glue to bring the discreet parts of your application together. It provides a solid structure to build your code upon without unnecessary cruft.

Dependency injection

The single biggest benefit of RobotLegs is it’s dependency injection mechanism. Dependency injection is really just a fancy way of saying it assigns values to properties automatically when an instance is created.

Without getting too bogged down in the details, know that Robotlegs uses a form of class reflection to resolve dependencies it needs to manage.

Loose coupling

It is good practice in object oriented programming to keep the parts of your system connected in such a way that if you were to replace part of the system it would require little refactoring. This is the point of loose coupling within RobotLegs. Each of the 4 tiers of the MVCS are, for the most part, independent of one another.

Context

RobotLegs uses a centralized context which composes the framework actors. It’s role is to accept mappings for views, models and commands as well as provide a centralized event dispatcher to communicate between actors. Mappings are needed so the framework knows what dependency injections it needs to perform.

An application may have more than one context though you normally only ever have one per SWF.

MVCS?

As mentioned, RobotLegs is based on the MVCS meta design pattern. Here is a brief overview of MVCS and how it’s implemented in RobotLegs.

• Model

  A model’s role is to store state information within your application. This can be thought of as a place to store data that may need to be retrieved by another part of your program. The player’s score in a game is an example of such data.

  RobotLegs does not enforce the use of a specific Model class, any class can be treated as a Model. However, in order to gain access to the global EventDispatcher there is an Actor class which provides a single eventDispatcher property used to dispatch events to other actors in the system.

• View

  A view is another name for a user interface. Basically anything that is an interface between your application and the user can be considered a view. They can should only read data from a model, not write directly to it.

  RobotLegs makes use of the Mediator design pattern when dealing with views. The point of this is that your view should be totally oblivious to the rest of the system. A view should expose methods and properties used for manipulating itself... and that’s all.

  The mediator’s job is to quite literally ‘mediate’ the view’s connection to the rest of the system. It listens to events coming from the global event dispatcher and then invokes the change on the view. It also listens to events occurring on the view itself and then alerts the rest of the system by dispatching an event on the global dispatcher. Mediators should extend from RobotLegs’ Mediator class.

• Controller

  The controller’s job is to manipulate data on the model, processing it beforehand if necessary. The controller is usually invoked by a view in response to user input. The controller never holds onto any data, it simply processes it then hands it on (usually to a model or service).

  The controller is implemented by Command classes in RobotLegs. Commands are instantiated by the CommandMap (which is composed inside the Context) in response to an event being dispatched on the global event dispatcher.

  The Command class in RobotLegs contains a single execute method which is called immediately after instantiation. You use a Command class by overwriting the execute method with your own code. Commands are simple and shorted lived. Once a Command is instantiated and execute has been called it’s job is done. The CommandMap does not hold onto Command instances by default, they are left to the mercy of the garbage collector at this point.

• Service

  A service is used for asynchronous communication to an entity existing outside of the application’s domain. It usually only retains data long enough to service the request. An example service may be an interface to Twitter, it might expose a getLatestTweet() method which then fires an event into the system once a response is received.

  A service is very similar to a model in RobotLegs. Your services, like models, will usually extend from the RobotLegs Actor class to gain access to the global event dispatcher. They exist more in your own implementation rather than something that is explicitly defined by the framework.

Want to learn more?

If you would like to learn more about RobotLegs then head on over to http://www.robotlegs.org/ to grab yourself a copy of the framework. I highly recommend you start by reading the best practices documentation which gives a much more concise overview of how RobotLegs works it’s magic. There is also API documentation at http://api.robotlegs.org as well as a support forum at http://knowledge.robotlegs.org/. If you have any questions or comments please leave a comment below.