Flash-db

RobotLegs is one of the more recents frameworks based on Dependency Injection like Parsley or Swiz, but with a strong emphasis in a Model-View-Controller arquitecture, that is suggested as the pattern of choice (but is not mandatory) RobotLegs use the SwiftSuspenders library to perform injector in the three allowable ways: constructor injection, parameter (method/setter) injection and property (field) injection.

Injection mappings are supplied to Robotlegs in three places. The MediatorMap, the CommandMap, and through the Injector directly. Both the MediatorMap and the CommandMap are making use of the Injector as well, but they are doing additional work required by these tiers. As the names imply, MediatorMap is used for mapping Mediators, CommandMap is used for mapping Commands, and anything else that needs to be injected (including but not limited to Models) is mapped directly with the Injector.

You can download the demo application from here

Context
At the heart of any Robotlegs implementation lies the Context. The Context, or Contexts as the case may be, provides the mechanism by which any given implementation’s tiers will communicate. An application is by no means limited to a single Context, but for many use cases one Context is sufficient. The Context has three functions within an application: provide initialization, provide de-initialization, and provide the central event bus for communication. In this sense is similar to the ParsleyConfig mxml file or the Swiz Beans mxml, where the main configuration is provided.
Here’s the startup method of the Context in our example:

override public function startup():void
{
	// Controller
	commandMap.mapEvent(LoginEvent.LOGIN_REQUESTED, AuthenticateCommand);
	// Model
	injector.mapSingleton(UserProxy);
	injector.mapSingleton(QuizProxy);
	// Services
	injector.mapSingletonOf(IAuthService, DummyAuthService);
	// View
	mediatorMap.mapView(QuizRobotLegs, ApplicationMediator);
	mediatorMap.mapView(LoginForm, LoginFormMediator);
	mediatorMap.mapView(QuizView, QuizViewMediator);
	mediatorMap.mapView(ResultsView, ResultsViewMediator);
	// Startup complete
	super.startup();
}

Controller and Commands

The Controller tier is represented by the Command class. Commands are stateless, short-lived objects used to perform a single unit of work within an application. Commands are appropriate for communication between application tiers and are able to send system events that will either launch other Commands or be received by a Mediator to perform work on a View Component in response to the event. Commands are an excellent place to encapsulate the business logic of your application.

View and Mediators

The View tier is represented by the Mediator class. Classes that extend Mediator are used to handle framework interaction with View Components. A Mediator will listen for framework events, add event listeners to the View Components, and send framework events in response to events received from the View Components they are responsible for. This allows the developer to put application specific logic on the Mediator, and avoid coupling View components to specific applications.
Probably the most important view in our example is the QuizView, that iterates over the questions listening to user selections (onRegister fires automatically when the framework instantiates and bind the Mediator):

override public function onRegister():void
{
	quizView.addEventListener(QuizEvent.USER_SELECTION, onAnswer);
	quizView.qModel = quizModel;
}
protected function onAnswer(evt:QuizEvent):void
{
	userModel.addResult(evt);
	if (quizView.qModel.hasNext())
	{
		quizView.qModel.moveNext(evt);
	}
	else
	{
		dispatch(new QuizEvent(QuizEvent.FINISH));
	}
}

Model, Service and the Actor

Conceptually there are many similarities between the service and model tiers in the MVCS architecture. Because of this similarity, models and services are extended from the same base Actor class. A class that extends the Actor base can serve many functions within your application architecture. We are going to utilize extensions of Actor for defining both the models and the services an application will need .

Model
Model classes for use in the model tier encapsulate and provide an API for data. Models send event notifications when work has been performed on the data model. Models are generally highly portable entities. We follow the same lines as in PureMVC (probably just because do this example after the other) and use Proxies and ValueObjects for our model. In the heart of our Quiz, there’s a simple QuestionVO holding the basic neccesary needs as a collection of public properties:

Service

A Service for use in the service tier communicates with “the outside world” from within an application. Web services, file access, or any action that takes place outside of the scope of your application is appropriate for a service class. Service classes dispatch system events in response to external events. A service should be highly portable, encapsulating interaction with an external service. We use a dummy AuthService to simulate the user login

Framework Events

Robotlegs uses native flash events for communication between framework actors. Custom events are typically utilized for this purpose, it is however possible to use existing Flash events for this same purpose. Robotlegs does not support Event bubbling, as it does not depend on the Flash display list as an event bus. Utilizing custom events allows developers to add properties to the Event that can be used as strongly typed payloads for system events between framework actors. In our example we use the typed LoginEvent and QuizEvent for communication

Highlights

- We have used a very similar structure as in PureMVC, but with injection avaibility, code becomes more compact, bur naming convention is very similar (Mediators i.e)

- As in Parsley and Swiss, to allow Dependency Injection variables need to be public, I have expend some time when my injection fails until find that my injected variables are private (probably you as me, use always private variables by default)

- The best practices document is a very concise guide to build the basics in good shape and short time.

- You can use normal addEventListener and dispatchEvent to normal event handling but if you want to use RobotLegs event bus, you should use eventMap.mapListener and dispatch.

- Pay attention to different methods to instantiate classes: mapValue, mapSingleton, mapSingletonOf are different ways to provide a class or an instance of a class as a singleton value

- Remember that the framework use lazy instantiation, that means instances are not created until they’re needed, so will not exist magically if you don’t inject somewhere.

- There’s an interesting example where RobotLegs use Signals isntead of normal Flash Events. Signals are light-weight, strongly-typed AS3 messaging tools writed by Robert Penner. We’re not using in our example right now, but will use in a future example so take a look at Joel Hooks bloog

Foru further reading you can check http://www.robotlegs.org/

PureMVC is probably one of the oldest ActionScript and Flex frameworks. It was born using ActionScript, but quickly was ported to other languages like Ruby, Python, C++, PHP or Java. His name expose clearly his matrix: it follows Model-View-Controller pattern, one of the most naturally when working with Flash and Flex.

You can download the demo application from here

PureMVC have 3 core singleton clases or actors: Model, View and Controller, plus another singleton, the Façade, that simplifies development by providing a single interface for communication with the Core actors.

Is important to note that PureMVC has his own Notification system that don’t rely on Flash Events system, and is based on a model/subscriber mechanism without the need of strong typing, since it carries and object ready to be used and aditionally a string identifier, anyway nothing prevents you to use Event mechanism and in fact we use in our example.

Model and proxies

The Model simply caches named references to Proxies. Proxy code manipulates the data model, communicating with remote services if need be to persist or retrieve it. This results in portable Model tier code. Generally speaking, the Proxy pattern is used to provide a placeholder for an object in order to control access to it. In a PureMVC-based application, the Proxy class is used specifically to manage a portion of the application’s data model. Data manipulation is done using Value Object, basically a class with a collection of public properties. Proxies can also retrieve data from Webservices of databases in asynchronous patterns. Here’s an excerpt of our QuizProxy that gets data from an XML file:

public class QuizProxy extends Proxy implements IProxy {
    public static const NAME:String = "QuizProxy"; (...)
    public function QuizProxy() {
    super(NAME);
    var ldr:URLLoader = new URLLoader();
    ldr.dataFormat = URLLoaderDataFormat.TEXT;
    ldr.addEventListener(Event.COMPLETE, onLoadXML);
    ldr.load(new URLRequest("com/flashdb/quiz/model/questions.xml"));
}

In the constructor, we load all the quiz question that will be used trough the application an will be accessed by the view.
The proxy, as any other piece in PureMVC, is registered to the Facade (in the StartupCommand in our application):

The proxy never manipulates Mediators, it just send notifications. The Model maintains its integrity through the use of Proxies, which house Domain Logic, and expose an API for manipulation of Data Objects

Controller and Commands

Commands are executed by the Controller as a result of Notifications being sent. Commands should never be instantiated and executed by any other actor than the Controller. To interact with the system, commands send notifications to be responded by others commands or mediators and manipulate directly proxies and mediators. Commands house the Business Logic of our application. Commands interact with Mediators and Proxies, but should be insulated from boundary implementations.
Commands could be chained, so you can use a MacroCommand (a chain of commands) in your application. A typical example is the StartupCommand:

public class StartupCommand extends MacroCommand {
    // Initialize the MacroCommand by adding its subcommands.
    override protected function initializeMacroCommand() : void {
        addSubCommand( ModelPrepCommand );
        addSubCommand( ViewPrepCommand );
    }
} 

The StartupCommand calls two other commands when Model and View should be setup before entering the application. In our example the StartupCommand just register the proxies and the Application and Login mediators (since the others view are created by deferred instantiation)

View and Mediators

A Mediator class is used to mediate the user’s interaction with one or more of the application’s View Components (such as Flex DataGrids or Flash MovieClips) and the rest of the PureMVC application.
To the PureMVC-based application, a View Component is any UI component, regardless of what framework it is provided by or how many sub-components it may contain. A View Component should encapsulate as much of its own state and operation as possible, exposing a simple API of events, methods and properties. The responsibilities for the Mediator are primarily handling Events dispatched from the View Component and relevant Notifications sent from the rest of the system.

The base mediator accepts an argument in the constructor that represents the concrete view component. You need to explicitly cast this object based on your concrete implementation, and for this implicit getter/setter comes in handy. Another important concern of Mediators is to register a list of interests, that’s the notifications the mediator is interest in handling, and of course the handler for it. Here’s is an example of the ApplicationMediator from our example:

public function ApplicationMediator( viewComponent:Object ) {
    super( NAME, viewComponent );
}  
//implicit getter to avoid casting
private function get application():QuizPureMVC {
    return viewComponent as QuizPureMVC;
}
 (...)
override public function listNotificationInterests():Array{
    return [ ApplicationFacade.AUTHENTICATED_SUCCESS, ApplicationFacade.SEND_ANSWER, ApplicationFacade.SHOW_RESULTS ];
}
override public function handleNotification( note:INotification ):void{
    switch ( note.getName() ){
        case ApplicationFacade.AUTHENTICATED_SUCCESS:
            application.currentState = "quizz";
            break;
        case ApplicationFacade.SEND_ANSWER:
            userModel.addResult(note.getBody() as QuizEvent);
            break;  
        case ApplicationFacade.SHOW_RESULTS:
            application.currentState = "results";
     }
}

Facade

The Facade brokers your requests to the Model, View and Controller, so that your code does not need import those classes and you do not need to work with them individually. The Façade class automatically instantiates the Core MVC Singletons in its constructor.

The Façade provides an implementation that should be considered abstract, in that you never instantiate it directly. Instead, you subclass the framework Façade and add or override some of its methods to make it useful in your application. Once the application’s View hierarchy has been built, the PureMVC apparatus is started and the Model and View regions are prepared for use.

Highligths

- Since PureMVC was writed as language agnostic, his first implementation was ActionScript, so still the main documents (like best practices) features ActionScript examples, so is easy to read for Flex developers

- Since examples on StartupCommands usually calls a couple of composite commands (ModelPrepComand and ViewPrepComand), we don’t need such a preparation, but probably medium to big applications do.

- It’s very important to give views an implicit getter for the reference to the view, this way you access to the advantages of strong typing instead of work with a generic object. Also you avoid to possible receive compile errors or warnings.

- Proxies are usually paired with Value Objects to store pieces of data.

- Asynchronous access to external services is routed trough proxies, since in our case is just an XML file

- Is very important to take into account instantiation process: you can’t register a Mediator on a view not on DisplayList (say hide inside a ViewStack or TabNavigator) For this you should use Deferred Instantiation, a common problem that arise when trying to use Mediators. Take a look at ApplicationMediator in our example, it receives notifications for creationComplete callbacks upon components and register the proper Mediator as needed.

- Since proxies are useful, the lack of an exposed Model singleton that stores itself reference to data (as in others frameworks) makes confuse at beginning the use of proxies

- The ApplicationFacade, ApplicationMediator and StartupCommand are central pieces to chain the whole framework

- Using Events and Notifications is sometimes confuse, since both could be used for similar purposes. In our example application we use both.

For further reading you can check http://www.puremvc.org

Mate is a is a tag-based, event-driven lightweight Flex framework that could be used mixed with others like Cairgorm. It uses injection to pass reference to the views declared in a central EventMap, where you also declare event handling. You have a lot of helper classes, like Mocks or different tags for invoke methods, but mate doesn’t impose a rigid structure.

Let’s take a very quick tour trough Mate fundamentals.

You can download the demo application as fxp file (Flash Builder Project) from here

You can see the running application here (select framework you’re working on for multiple choice)

Event map
Central to Mate is the Event Map. In the Event Map (or multiple event maps), you define what needs to happen when certain events are dispatched. Each event type you want to listen to will have its own Event Handlers block in the event map. Usually you declare it in the main application and use for handling events and inject dependencies. Here’s an example from our test application

Event Handlers
An Event Handlers block defined in the Event Map will run whenever an event of the type specified in the EventHandlers’ “type” argument is dispatched. In order to handle events, the bubbling phase should be set to true and should be dispatched from an object that has Application as his root. You can see an example of event handler in the previous code

MethodInvoker, WebServiceInvoker, HTTPServiceInvoker, RemoteObjectInvoker
Easy to understand by its names, all this tags are used to invoke methods or services usually inside an EventHandler.
methodInvoker is one of the most used, it will create an object of the class specified in the “generator” attribute. It will then call the function specified in the “method” attribute on the newly created object.
The others invokers depends on external services, so declare an resultEvent and a faultEvent to manage results. Here’s an example of a MethodInvoker

There are others handy tags like DataCopier (to copy data into some storage), StopHandlers (to prevent handlers to run at certain point) or MessageHandlers (for Flex Messaging system) between others.

Multiple choice using Mate

Being the second example of this story, I begin coping the files from the Swiz project directly to my new one, keeping some of the classes that probably will survive without much change among all the others frameworks, like Events classes or Models for quiz and User (in the case of the user basically a Data Transfer Object)

Steps were as follows

• Add the compiled framework code to your project (Mate.swc).
• Create a file that will be the EventMap, to declare injectors and event handlers
• Include the event map in your main Application file.
• Create one or more custom event.
• Create one or more views
• Dispatch that event from the different views as needed.
• Add EventHandlers in your event map that listen for the event type you dispatched.
• Execute some actions inside the EventHandlers block (ie: call the server, store data, etc).

Add as many event handlers as you need

Highligths

- The event map centralize the functionality and probably you will go back and forth to it as far as you add views
- A bunch of events is needed for different actions, create as much as you need
- If you use states for the main application be careful: move the EventMap tag to the first view, if not each time you move to another view it will be redeclared.
- Avoid any relationship between view and models (in the business folder), use injection instead trough the EventMap
- Use a Services.mxml to declare your external services.
- You can use Mocks for your service at development stage, just use a MockRemoteObject tag inside services and create your Mock class (inside mock.quiz.services package)
- For the clock we have used just a custom class that dispatch events and is injected into the view
- For the final result we collect all the info from the User, where we store progress.

Summarizing: Mate is an extremely easy framework with a centralized management, just avoid it if you don’t like mxml tags but prefer pure AS classes

For further reading on the topic: http://mate.asfusion.com/

Sometimes we face the case where we should skin multiple components in a similar way, but with a small difference. Yesterday I should skin 6 spark Panels with different header color. Spark panels doesn’t support headerColors style as his Halo counterpart, so instead of writing different styles or set just a property, I should write 6 different skins with just a small difference: the header color. So I was wondering if it’s possible to pass some parameter like

<s:Panel skinClass=”{skins.mySkin(someparameter)}” …

And find some clue in s StackOverflow post, http://stackoverflow.com/questions/2574425/possible-to-pass-parameters-to-a-skin

Since the correct way seems to subclass the component to have your custom parameter, there’s another simple way just using some existing parameter as a selector for a color. So I just added a name on each of my Panels (I use the id as the identifier, so an unused property like the name looks fine to me) So my panels are

   <s:Panel skinClass="skin.mySkinClass" name="panel1"> ....
   <s:Panel skinClass="skin.mySkinClass" name="panel2"> ....
   <s:Panel skinClass="skin.mySkinClass" name="panel3"> ....

So in my Skin class I add a small switch in the <fx:Script block (don’t check Remove ActionScript Styling Code when creating the MXML skin)

First I declare 2 bindable variables

                [Bindable]
		private var headerColor1:Number;
		[Bindable]
		private var headerColor2:Number;

Then I use a switch in the updateDisplayList method

override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
{
       (...)
      switch(hostComponent.name){
          case "myPanel1":
                headerColor1 = 0x006633;
                headerColor2 = 0x006633;
                break;
          case "myPanel2":
                headerColor1 = 0x0033cc;
                headerColor2 = 0x000099;
                break;
         case "myPanel3":
                headerColor1 = 0x990000;
                headerColor2 = 0x990000;
                break;
   }
}

Finally I use in the fill for the header bar

<!-- layer 0: title bar fill -->
                <!--- @private -->
                <s:Rect id="tbFill" left="0" right="0" top="0" bottom="0" alpha="0.4">
                    <s:fill>
                        <s:LinearGradient rotation="90">
                            <s:GradientEntry color="{headerColor1}" />
                            <s:GradientEntry color="{headerColor2}" />
                        </s:LinearGradient>
                    </s:fill>
                </s:Rect>

With a similar approach, you can reuse a skin when they’re very similar.