What a line-up. Yugo Nakamura, Kevin Lynch, Mario Klingemann, Ralph Hauwert, Grant Skinner... The list is huge, and filled with top notch presenters. I'm a bit sad, as I am presenting at the same time as Keith Peters. His "Programming Art" talk sounds awesome. It is going to be three full days jam-packed with awesome.

I'm going to be giving a talk on Robotlegs at the event.

There is still time to get the early bird tickets, and FiTC is offering a 10% discount if you use the code "joelhooks" - really hope to see you there.

SwiftSuspenders beautifully supports constructor injection. This means that you don't need to annotate any methods or the class with metadata for it to honor injection into the constructor. With the [Inject] tag, you are marking required dependencies. They aren't optional. If there is no rule to supply the injection you will get a runtime error saying as such. So, given these non-optional dependencies, injecting them into the constructor makes a lot of sense. One drawback to this approach is that if you are injecting a lot of dependencies your constructor might get really big. In fact, the limit is 10 parameters. Guess what? If your class requires that many dependencies, it already smells bad. Clean it up and think single responsibility. For the love of Uncle Bob, keep it clean.

To illustrate this point I have refactored the Image Gallery example. It was my first example for Robotlegs almost a year ago. The original version resides in the Robotlegs Demo Bundle. In this refactoring I removed all occurrences of the [Inject] metadata tag. In addition, I removed all of the extensions of Robotlegs mvcs implementation sub-classes with the exception of Mediator. There are no Actor or Command subclasses. So what you end up with is a Command, Model, and Service tier that is completely meta and framework free. That rocks. It is just AS3 code doing its job. I love that.

Here's a link to the source for this project on Github.

Tooling is very lacking for metadata in all of the IDEs currently available. The SourceMate plugin from ElementRiver is a nice addition to Flash Builder if you make use of metadata. It actually gives you code completion, which in and of itself is a huge improvement over... nothing. I hope to see more IDE support for metadata soon. It would really make it a lot easier to manage.

In my professional life, I use all of the Actionscript DI frameworks (Robotlegs, Swiz, and Parsley). They are all great, when used appropriately within a defined set of patterns and practices. I worry about the trend for increased use of metadata. I think the complexity overhead is large. Sure, you get it, but there is a responsibility to build systems that can be understood by a wide range of developers without weeks of remedial training on a complex metadata based DSL. The less complex we make our complex systems the better. They are easier to train for, document, and build.

Modular programming is a versatile technique for separating an application into smaller parts. Each module is effectively an application and can be developed independently from one another. In a typical modular application you will have a Shell that is loaded initially. The Shell will manage the loading of modules and displaying their contents. Flex modules can be visual components that extend the Module class, but this is certainly not the extent of what can be considered a module.

Robotlegs is well suited for modular application development. Each Context is encapsulated and provides its own internal method for communication. A barrier to writing modular applications thus far with Robotlegs is that while these Context objects can exist in abundance in an application, they aren't very useful from a modular standpoint unless they can communicate with one another. As with many things within the Robotlegs eco-system, this is best accomplished through the development of a utility that can be used in conjunction with the core framework to provide the specific functionality that we are looking for. There has been some good work done in this area, but with Robotlegs 1.1 and more specifically the 1.5 release of the default Dependency Injection provider SwiftSuspenders, we have been equipped with better tools to accomplish modular contexts in a Robotlegs application in a clean effective manner.

A Little Backstory

Prior to Robotlegs I used PureMVC exclusively. There is a utility for PureMVC called Pipes, which I have written about previously. Pipes is pretty cool. It uses a plumbing metaphor to describe the connections between modules. It is... verbose... and requires a shit-ton of wiring code to be functional. This can be a challenge to get your head around, and can create code that you have to stare at for a good while to fully understand HTF everything is actually being wired.

My original path for a Robotlegs modular utility was to port Pipes. In fact, I didn't really have to port Pipes, but just wrote an adapter that allowed Pipes to fit into a Robotlegs application. The problem was that it didn't feel like Robotlegs. Verbose and confusing goes against the core moral fiber of what Robotlegs is all about. So I started whittling it down. At that point it looked like Stray's excellent work with the Robotlegs Modular utility. Heh. Full Circle! So instead of using Pipes, I've taken her work and expanded on it for Robotlegs 1.1 and at the same time clarifying some of the concepts within the utility and making it more useful across a broader range of use cases.

Where we are now

So with Pipes set aside for now, we have a dead simple modular implementation that can be used for Flex, AS3, and maybe even Flash applications. It doesn't provide all of the functionality that Pipes brings to the table. Specifically it is missing concepts like message filtering and queuing. While these are likely useful tools, I didn't feel that they needed to be implemented just yet. I have some ideas about how they might be implemented, but feel that the Robotlegs Modular Utility is clean and simple covering a big majority of typical use cases. Start simple and expand from there. This is where I am relying on you, gentle reader, to help guide the utility into something more useful while still keeping the clean and simple Robotlegs aesthetic.

With that behind us, lets look at an example of a modular application written with the Robotlegs Modular Utility. It is fairly useless, but covers the core concepts of what a modular application should be able to do.

Modular Doodads: A Lame but Functional Example

The full source for this example can be found HERE...

In this example you have three separate modules: the Shell, or the main application, a logging module that provides "console" output, and Doodads. Doodads are simple modules with not a whole lot of functionality. When you add a Doodad the shell creates a new Doodad and adds it to a container. The Doodads have a "request" button that will ask any other Doodads to change color. In addition to that, they have a close button to remove the Doodad. Above the Doodad container is a "trigger" button. This sends out an event that triggers a command on all of the Doodad modules (causing them to flash violently).

ModularDoodadsContext.as

1
2
3
4
5
6
7
8
9
10
11

public class ModularDoodadsContext extends ModuleContext
{
    override public function startup():void
    {
        //map the modules so that instances will be properly supplied (injected) with an injector.
        viewMap.mapType(LoggerModule);
        viewMap.mapType(DoodadModule);
 
        mediatorMap.mapView(ModularDoodads, ModuleDoodadsMediator);
    }
}

The main shell application context context is doing a couple of things. As with the other modules within the application, this Context extends ModuleContext. ModuleContext will create the ModuleEventDispatcher (IModuleEventDispatcher) as well as a ModuleCommandMap that can be used to map commands that respond to events on the ModuleEventDispatcher. ModuleContext is a convenience mechanism.

Since the modules in this application are view components we can use the ViewMap to map their types. This facilitates injection into the modules when they are added to the stage. The reason for this will become clear as we look at one of these modules.

LoggerModule.mxml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

<?xml version="1.0" encoding="utf-8"?>
<mx:Module xmlns:fx="http://ns.adobe.com/mxml/2009"
           xmlns:s="library://ns.adobe.com/flex/spark"
           xmlns:mx="library://ns.adobe.com/flex/mx"
           implements="org.robotlegs.utilities.modular.core.IModule"
           layout="absolute" width="100%" height="75">
    <fx:Script>
        <![CDATA[
            import org.robotlegs.core.IContext;
            import org.robotlegs.core.IInjector;
            import org.robotlegs.utilities.modular.core.IModule;
            import org.robotlegs.utilities.modular.core.IModuleContext;
 
            import robotlegs.examples.modulardoodads.modules.logger.skins.LoggingTextArea;
 
            protected var context:IModuleContext;
 
            [Embed(mimeType='application/x-font', source="assets/AnonPro.ttf", fontName="Anon")]
            private var anon:Class;
 
            [Bindable]
            public var messages:String = "";
 
            public function addLoggingMessage(message:String):void
            {
                message += "\r";
                messages += message;
                scrollToMax();
            }
 
            private function scrollToMax():void
            {
                messageDisplay.validateNow();
                messageDisplay.scroller.verticalScrollBar.value = messageDisplay.scroller.verticalScrollBar.maximum;
            }
 
            /**
             * We need to initialize our context by setting the parent
             * injector for the module. This is actually injected by the
             * shell, so no need to worry about it!
            */
            [Inject]
            public function set parentInjector(value:IInjector):void
            {
                context = new LoggerModuleContext(this, value);
            }
 
            public function dispose():void
            {
                context.dispose();
                context = null;
            }
 
        ]]>
    </fx:Script>
    <fx:Declarations>
        <!-- Place non-visual elements (e.g., services, value objects) here -->
    </fx:Declarations>
    <s:TextArea
        id="messageDisplay"
        fontFamily="Anon"
        fontSize="12"
        width="100%" height="100%"
        text="{messages}"
        skinClass="robotlegs.examples.modulardoodads.modules.logger.skins.LoggingTextArea"/>
</mx:Module>

Looking at the LoggerModule.mxml it is important to note that it implements the org.robotlegs.utilities.modular.core.IModule interface. This provides a contract to ensure that we supply the appropriate API to initialize the module. The IModule interface provides a setter for the parentInjector as well as a dispose() method that we can use to cleanup the module when it is removed. The key here is the setter for the parentInjector that supplies an injector to the module. This setter actually creates the context or the module and passes the injector into the context. As you will recall in the ModularDoodadContext above, the LoggerModule was mapped with the ViewMap. This means that when it is added to the stage its dependencies are injected. parentInjector is marked with the [Inject] metadata so the injector is automatically provided to the module. The context will then use that injector and create a child injector.

Child Injectors

A child injector is a new concept in Robotlegs 1.1. It is a powerful tool. When the parentInjector is set, the module context uses it to create a child injector. This child injector has a reference to its parent and the parent's injection mappings. This means that if you don't create a mapping in the child injector it will supply the injection a mapped within the parent (or grandparent). The parent has no reference at all to the child, and doesn't even know that it exists so if you create mappings in a child injector they are not reflected up the injector chain to ancestors. If you create a mapping that is identical to a mapping within an injector's family tree, the first mapping is honored and the injector will not check with its ancestors to see if the mapping exists.

Through this mechanism of child injectors we are able to map an event dispatcher within the top level application context that can then be shared amongst any number of other contexts providing that they are able to create and use a child injector. This is the core of how these modules are able to communicate with one another. We create the IModuleEventDispatcher in the shell and all sub-modules now have access to it through their injector. As long as you don't map a IModuleEventDispatcher with the child, any injections that call for it will be supplied with the original dispatcher from the parent injector.

Now what? For the most part, you develop modules as you would any other Robotlegs application. The Modular Utility does provide one other convenient mechanism to help save you on some typing. That is the ModuleMediator.

DoodadModuleMediator.as

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

public class DoodadModuleMediator extends ModuleMediator
{
    [Inject]
    public var view:DoodadModule;
 
    private var madeRequest:Boolean;
 
    override public function onRegister():void
    {
        addViewListener(DoodadModuleEvent.DO_STUFF_REQUESTED, handleDoStuffRequested, DoodadModuleEvent);
        addViewListener(DoodadModuleEvent.REMOVE, handleRemove);
        addModuleListener(DoodadModuleEvent.DO_STUFF_REQUESTED, handleDoStuffRequest, DoodadModuleEvent);
        addContextListener(DoodadModuleEvent.FLASH_YOUR_DOODAD, handleDoodadFlashRequest);
    }
 
    private function handleRemove(event:DoodadModuleEvent):void
    {
        dispatchToModules(new LoggingEvent(LoggingEvent.MESSAGE, "Removing DoodadModule"));
        dispatchToModules(event);
        view.dispose();
    }
 
    private function handleDoStuffRequested(event:DoodadModuleEvent):void
    {
        madeRequest = true;
        dispatchToModules(new LoggingEvent(LoggingEvent.MESSAGE, "DoodadModule made request..."));
        moduleDispatcher.dispatchEvent(event);
    }
 
    private function handleDoStuffRequest(event:DoodadModuleEvent):void
    {
        if(!madeRequest)
        {
            view.color = Math.random()*0xFFFFFF;
            dispatchToModules(new LoggingEvent(LoggingEvent.MESSAGE, "DoodadModule changed color: " + view.color));
        }
        madeRequest = false;
    }
 
    private function handleDoodadFlashRequest(event:DoodadModuleEvent):void
    {
        view.flashIt();
    }
}

The DoodadModuleMediator extends ModuleMediator. The ModuleMediator provides basic injections for the ModuleCommandMap and the ModuleEventDispatcher. ModuleMediator also provides some convenience with a bit of syntactic sugar to make it easy to dispatch events to the ModuleEventDispatcher. The dispatchToModules() method sends events over the ModuleEventDispatcher in contrast to the dispatch() method which sends events over the EventDispatcher that is local to the context. Additionally you are provided with addModuleListener() that makes it easy to add a listener for an event type that is expected to be dispatched from another module (including the shell). These methods simply abstract the eventMap.mapListener() method, which in turn is abstracting eventDispatcher.addEventListener(). You have nothing if not options when it comes to adding a listener within a mediator!

Modular Application Development in Flex... Some Caveats

Possibly the biggest gotcha with modular application development is managing memory. With a typical application you are dealing with a single "module" - the application itself. You do not typically attempt to unload your entire application from memory. Simply refreshing the page or navigating away more effectively does this. We do try to prevent memory leaks diligently (right?) to provide our users with the smoothest possible experience, but this is different from trying to release all of the memory the application uses at runtime. Modules, on the other hand, can come into existence at runtime at any point during the lifecycle of your application. On the flip side of that is that the modules should be able to completely unload and release all of the memory that they have used.

There are a host of "tricks" to getting modules out of memory. This article is a good overview of the major ones. In addition to these sneaky memory peggers, you will also want to carefully ensure that your modules release references and dispose of objects properly.

The Modular Utility makes every effort to provide mechanisms for disposing of your modules, but when it gets down to it most of that responsibility will be left up to you. If you notice that Robotlegs or the Modular Utility is preventing a module from unloading please let me know so that I can address it as soon as possible. The end goal is to provide a robust tool for developing Robotlegs applications with modules. The Modular Utility is currently very modest, but what it isn't is a solution looking for a problem. As it grows it will be in response to real problems, and your feedback and use is critical to meeting that goal.

The bits you'll need...

Robotlegs Modular Utility (my fork)
The full source for this example
Robotlegs AS3

On a related note...

I recently had the pleasure of writing a full 22 pages on Robotlegs in the upcoming Flex 4 in Action from Manning. It is a great book overall and if you'd like to learn more about Robotlegs (or Flex 4 in general) then I highly recommend it.

direct link to the video (42mb QT)

Resources

IntelliJ IDEA EAP Download Page
Jesse Freeman's IDEA Workflow series on InsideRIA

With the standard Robotlegs MVCS implementation you leverage the events provided by Actionscript 3 to communicate amongst the various actors of an application. From models and services dispatching notifications of their actions to triggering commands, events are a core piece of the implementation. To facilitate the use of Signals within MVCS it was necessary to create an extension to allow for Signals to be registered as Command triggers. This need spawned the SignalCommandMap utility.

The SignalCommandMap extends the normal MVCS context and creates a SignalContext. The SignalContext instantiates and provides access to the SignalCommandMap alongside the other maps that are standard to Robotlegs. The SignalCommandMap allows you to map Signal classes and instances to commands that will be executed when the Signal dispatch() method is called. The value objects that are passed in the dispatch are then injected into the command alongside any other mapped injections you have created.

Let's take a look at a simple example that makes use of the SignalCommandMap and discuss some of the underlying code to see how it works:

Source available on Github (zip)

The example is a menu that allows you to add food which is displayed in a list. The total cost of your selected items is displayed and you can remove items from your order. First let's get started by taking a look at the context of the Application, which extends SignalContext:

SignalCafeContext.as Bootstraps the Application

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class SignalCafeContext extends SignalContext
{
    override public function startup():void
    {
      injector.mapSingleton(FoodOrderModel);
      injector.mapSingleton(FoodOrderUpdated);
      injector.mapSingleton(FoodItemAddedToOrder);
 
      signalCommandMap.mapSignalClass(AddFoodItemToOrder, AddFoodItemToOrderCommand);
      signalCommandMap.mapSignalClass(FoodItemSelected, FoodItemSelectedCommand);
      signalCommandMap.mapSignalClass(RemoveAllOfSelectedItem, RemoveAllSelectedItemCommand);
      signalCommandMap.mapSignalClass(NoFoodItemSelected, NoFoodItemSelectedCommand);
 
      mediatorMap.mapView(FoodSelectionView, FoodSelectionViewMediator);
      mediatorMap.mapView(CurrentOrderView, CurrentOrderViewMediator);
      mediatorMap.mapView(FoodOrderSummaryView, FoodOrderSummaryViewMediator);
      mediatorMap.mapView(FoodItemRemovalView, FoodItemRemovalViewMediator);
    }
}

A SignalContext is structured exactly the same as a standard Robotlegs MVCS Context class. You override the startup() method and bootstrap your application. The major difference here is that you are mapping signals to commands instead of mapping events to commands. With the SignalCommandMap you are not restricted to just using Signals for triggering commands. You could mix events and Signals liberally as your needs or requirements dictated. As a warning, this could quickly became confusing and choosing one or the other might be a saner choice.

SignalCafeContext is mapping 4 Signals to 4 commands. The Signals are typed extensions of the base Signal class. This is necessary to provide Robotlegs (and more specifically in this case SwiftSuspenders) object types to differentiate for the purposes of injection. You could use named injections, but this would rapidly riddle your application with strings that would need to be laboriously checked for accuracy. Avoiding strings in favor of compiler-checked object types is always a good choice.

The strongly typed Signals are relatively simple. They contain a constructor and no additional methods or properties are added to the Signal. You can of course add properties and methods to the extended Signals,, but it wasn't necessary for this example. The SignalCommandMap will accept any class that implements the ISignal interface. Let's take a look at one of the commands triggered by a Signal mapped in the SignalCafeContext:

AddFoodItemToOrder.as triggers the AddFoodItemToOrderCommand

1
2
3
4
5
6
7

public class AddFoodItemToOrder extends Signal
{
	public function AddFoodItemToOrder()
	{
		super(FoodType);
	}
}

That is the whole of the extended Signal. As mentioned, it is not very complex at all. You will notice that super(FoodType) is being called. Signals take constructor arguments consisting of classes or interfaces that will be used as the value objects transmitted via the dispatch() method. In this case we are using FoodType as this value to ensure that our Signal will carry the payload that the mapped command is expecting.

Command signals are named a bit differently than standard reaction Signals. A Signal that is triggering a command is "requesting action" or specifying an action that needs to occur. Standard signals are typically past tense, or informative, describing an action that has occurred. By using this standard it is much easier to differentiate quickly what each Signal's purpose is. This can help with overall clarity within your application.

The AddFoodItemToOrder signal is dispatched by the FoodSelectionViewMediator which is mediating the DropDownList of FoodTypes and the "Add Some Food" button:

FoodSelectionViewMediator.as mediates a view and dispatches a Signal when the user has clicked the "Add Some Food" button

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

	public class FoodSelectionViewMediator extends Mediator
	{
		[Inject]
		public var view:FoodSelectionView;
 
		[Inject]
		public var addItem:AddFoodItemToOrder;
 
		override public function onRegister():void
		{
			view.itemTypeAdded.add(handleItemTypeAdded);
		}
 
		protected function handleItemTypeAdded(itemType:FoodType):void
		{
			addItem.dispatch(itemType);
		}
	}

When the AddFoodItemToOrder Signal's dispatch(aFoodTypeInstance) is called the AddFoodItemToOrderCommand is triggered:

AddFoodItemToOrderCommand.as is executed in response to AddFoodItemToOrder Signal dispatch

1
2
3
4
5
6
7
8
9
10
11
12
13

public class AddFoodItemToOrderCommand extends SignalCommand
{
	[Inject]
	public var itemType:FoodType;
 
	[Inject]
	public var model:FoodOrderModel;
 
	override public function execute():void
	{
		model.addItemToOrder(itemType);
	}
}

AddFoodItemToOrderCommand has two public properties that are marked for injection. The itemType property is a FoodType object. As you will recall, FoodType is the parameter that was passed to the AddFoodItemToOrder Signal super constructor. The AddFoodItemToOrder Signal dispatch() included an instance of a FoodType object which will be injected into the AddFoodItemToOrderCommand alongside any other injections that have been mapped and specified. In this case we are also injecting the FoodOrderModel instance that was mapped as a singleton in the SignalCafeContext.

The AddFoodItemToOrderCommand has a simple job. It accesses the FoodOrderModel instance and calls its addItemToOrder method adding the FoodType parameter that was dispatched with the Signal to trigger the command.

That covers the basics of using the SignalCommandMap within a Robotlegs application. There are options that this example doesn't cover. I would recommend looking through the SignalCommandMap unit test suite for a thorough review of its capabilities. There are several more commands and Signals in the example for you to look over as well. Additionally the example uses Signals within views and the model to dispatch notifications. Outside of binding and UI events, no events are being passed within the application.

Hopefully this will give you the basic understanding of using the SignalCommandMap in a Robotlegs application. Let me know if you have any criticisms, comments, suggestions, or ideas regarding the utility's implementation at http://knowledge.robotlegs.org

These conversations are always good natured. While we work on (or use) "competing" frameworks there is always a sense of mutual respect. We like our tools but have obvious inclinations towards the projects that we've invested our hearts and souls into.

Ben Clinkinbeard has pointed out (several times!) that Robotlegs is all about extending the MVCS classes. My stock answer is that there is a clear separation between the framework and the concrete MVCS implementation. To paraphrase Ben, "Well show it to me then!"

All of the "official" Robotlegs examples are making use of the MVCS implementation. Why? Because it is solid, recognizable, and fairly easy to get one's head around. It provides a common ground for developers and a set architectural structure which is a huge advantage in any team environment. It is important to make the distinction between the framework and the MVCS implementation. What does that even mean? At the core, Robotlegs is a modular set of tools to provide a convenient mechanism for wiring applications. Robotlegs is not doing class reflection. Robotlegs is not an automated dependency injection solution. Robotlegs is an adapter to a dependency injection solution,by default the lightweight SwiftSuspenders library. Through a set of tools, namely the MediatorMap, CommandMap, ViewMap, and the injection adapter Robotlegs provides a robust starting place to begin coding your application.

The MVCS implementation is a set of base classes loosely modeled on PureMVC. At the heart of the implementation is the Context. The Context creates instances of the various mapping classes, the injection adapter, and gives the developer a centralized IEventDispatcher that can be used for messaging between application tiers.. The other three classes, Actor, Mediator, and Command, reduce boiler plate and provide convenient access to injected dependencies typically used in the the MVCS tiers.

What if you hate PureMVC, don't want to extend any framework classes, or generally just want to work in a different way outside of a prescribed MVCS architecture?

No problem.

Here's the deal. Robotlegs, the framework, is a set of interfaces. You can effectively do whatever you want with these interfaces. You can make use of the base concrete implementations of the core interfaces, use a class from the MVCS implementation, implement your own concrete classes based on the framework core, bring in other libraries or any combination you can think of. In terms of a framework, Robotlegs can be whatever you want/need it to be.

Man Joel, that was a long intro. Where's the freaking code??!?

So, to that end, I sat down to rework my first (and still favorite) Robotlegs example application and demonstrate this concept a bit.

I've stripped the example down slightly, using just the XMLImageService and not connecting to Flickr (in an effort to keep it simple).

Get the source on GitHub
Download the full source as a Zip

This example requires:
Robotlegs
AS3-Signals
SignalsCommandMap library
Flex 4 SDK (a fairly recent version)

The example should be familiar if you've looked at the Image Gallery previously. It loads images from a service and displays them. This version is much different on the code level however. Instead of mediators and data models, the gallery is using presentation models and AS3-Signals. It still uses the Context from the MVCS implementation. it's so f'n handy and I don't want to manually instantiate the maps.

ImageGalleryContext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public class ImageGalleryContext extends Context
{
	private const VIEW_PACKAGE:String = "org.robotlegs.examples.imagegallery.view.components";
	private const LOAD_GALLERY:String = "loadGallery";
 
	override public function startup():void
	{
		//map the views
		viewMap.mapPackage(VIEW_PACKAGE);
 
		//map the presentation models
		injector.mapSingletonOf( IGalleryViewPresentationModel, GalleryViewPresentationModel );
		injector.mapSingletonOf( IGalleryThumbnailsPresentationModel, GalleryThumbnailsPresentationModel );
 
		//map the services and their factories
		injector.mapSingletonOf( IGalleryImageService, XMLImageService );
		injector.mapSingletonOf( IGalleryFactory, XMLGalleryFactory );
 
		//map the signals
		injector.mapSingleton(GalleryUpdatedSignal);
		injector.mapSingleton(GalleryImageSelectedSignal);
 
		//map the command
		commandMap.mapEvent( LOAD_GALLERY, LoadGalleryCommand );
 
		//go!!
		eventDispatcher.dispatchEvent(new Event(LOAD_GALLERY));
	}
}

As you can see here the context is performing the duty of mapping the injections the application will use.

Automated Dependency Injected View

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

<s:Group xmlns:fx="http://ns.adobe.com/mxml/2009"
		 xmlns:s="library://ns.adobe.com/flex/spark"
		 xmlns:mx="library://ns.adobe.com/flex/halo" width="100%" height="100">
	<fx:Script>
		<![CDATA[
			import org.robotlegs.examples.imagegallery.view.models.IGalleryThumbnailsPresentationModel;
 
			private var _model:IGalleryThumbnailsPresentationModel;
 
			public function get model():IGalleryThumbnailsPresentationModel
			{
				return _model;
			}
 
			[Inject]
			[Bindable]
			public function set model(value:IGalleryThumbnailsPresentationModel):void
			{
				_model = value;
			}
		]]>
	</fx:Script>
	<s:Rect width="100%"
			height="100%">
		<s:fill>
			<s:SolidColor color="#111111"/>
		</s:fill>
	</s:Rect>
	<s:Group width="100%" height="100%">
		<s:layout>
			<s:VerticalLayout gap="0"/>
		</s:layout>
		<s:DataGroup id="dgThumbnails"
					 clipAndEnableScrolling="true"
					 dataProvider="{model.dataProvider}"
					 width="100%"
					 height="85"
					 itemRenderer="org.robotlegs.examples.imagegallery.view.components.renderers.GalleryImageThumbnailItemRenderer">
			<s:layout>
				<s:HorizontalLayout gap="0"/>
			</s:layout>
		</s:DataGroup>
		<s:HScrollBar id="thumbScrollBar"
					  viewport="{dgThumbnails}"
					  width="100%"
					  smoothScrolling="true"/>
	</s:Group>
</s:Group>

The viewMap is set to map the entire components folder. This is a convenient way to provide automated dependency injection to a large number of views. It also maps views in any sub-package of the mapped package.

GalleryViewThumbnailsPresentationModel

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

[Bindable]
public class GalleryThumbnailsPresentationModel implements IGalleryThumbnailsPresentationModel
{
	[Inject]
	public var updated:GalleryUpdatedSignal;
 
	[Inject]
	public var imageSelected:GalleryImageSelectedSignal;
 
	[PostConstruct]
	public function mapSignalListeners():void
	{
		updated.add(galleryUpdated);
		imageSelected.add(updateImageSelectionState);
	}
 
	private var _dataprovider:ArrayCollection;
 
	public function get dataProvider():ArrayCollection
	{
		return _dataprovider;
	}
 
	public function set dataProvider(v:ArrayCollection):void
	{
		_dataprovider = v;
	}
 
	private function galleryUpdated(gallery:Gallery):void
	{
		dataProvider = gallery.photos;
		if(gallery.photos[0])
		{
			imageSelected.dispatch(gallery.photos[0]);
		}
	}
 
	private function updateImageSelectionState(image:GalleryImage):void
	{
		for each(var galleryImage:GalleryImage in dataProvider)
		{
			galleryImage.selected = galleryImage == image;
		}
	}
}

IGalleryViewThumbnailsPresentationModel

1
2
3
4
5
6
7
8

/**
 * This interface is simple because the application is simple. Obviously in
 * a large application you'd get more complex interfaces.
 */
public interface IGalleryThumbnailsPresentationModel
{
	function get dataProvider():ArrayCollection;
}

The presentation models are provided as singletons. The application will only display one of each view that requires the model. They are also mapped as interfaces with the interfaces being injected into the views. With the presentation model, the view does not update the model directly. By using interfaces we can supply read-only contracts between the presentation models and the views they control:

XMLImageService

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

public class XMLImageService implements IGalleryImageService
{
	protected static const BASE_URL:String = "assets/gallery/";
 
	[Inject]
	public var galleryFactory:IGalleryFactory;
 
	[Inject]
	public var galleryUpdated:GalleryUpdatedSignal;
 
	public function XMLImageService()
	{
		super();
	}
 
	public function loadGallery():void
	{
		var service:HTTPService = new HTTPService();
		var responder:Responder = new Responder(handleServiceResult, handleServiceFault);
		var token:AsyncToken;
		service.resultFormat = "e4x";
		service.url = BASE_URL+"gallery.xml";
		token = service.send();
		token.addResponder(responder);
	}
 
	protected function handleServiceResult(event:Object):void
	{
		var gallery:Gallery = galleryFactory.createGallery(event.result.image, BASE_URL);
		galleryUpdated.dispatch( gallery );
	}
 
	protected function handleServiceFault(event:Object):void
	{
		trace(event);
 
	}
}

IGalleryImageService

1
2
3
4

public interface IGalleryImageService
{
	function loadGallery():void;
}

The service and its factory class are also mapped as singleton interfaces. This makes it really easy to swap out services (to add a Flickr service for example).

GalleryUpdatedSignal

1
2
3
4
5
6
7

public class GalleryUpdatedSignal extends Signal
{
	public function GalleryUpdatedSignal()
	{
		super(Gallery);
	}
}

The signals are simple classes that merely extend the Signal class and declare their payload type in the super() of the constructor. Signals are a really marvelous concept and provide a lot of very nice functionality. They make a great companion to Robotlegs and I think you will see some really cool stuff being done with Signals and Robotlegs in the very near future.

LoadGalleryCommand

1
2
3
4
5
6
7
8
9
10

public class LoadGalleryCommand
{
	[Inject]
	public var service:IGalleryImageService;
 
	public function execute():void
	{
		service.loadGallery();
	}
}

The application has a single command, LoadGalleryCommand, that is used to actually load the initial images from service and is only called once. In fact, the event that is fired to launch this command in the context startup method is the only event that this application uses (outside of the Flex events on the UI items). That is awesome!

Something you will notice right away looking at the source is that the ImageGalleryContext is the only class that extends a Robotlegs class. You could do without that too, frankly, and create your own context that created the maps and injector instances. I'm not a masochist however, and I will use the provided context for this example. There is a huge amount of potential there for implementing your own custom contexts. I think an interesting implementation might pitch Flash Events altogether and use only Signals for communication between application actors. This example is essentially doing that, but I'd like to get rid of that single event in startup too!

Download the full source as a Zip

Let me know if you make something cool with Robotlegs and post details about it, I've got a stack of these to give away:

I've finally found the opportunity to rewrite the continuous scrolling thumbnail view portion of the slideshow and I am much happier with the results. Now, instead of resembling an application it is structured like a standard Flex 3 List based component. You supply it with a dataProvider and an itemRenderer (IListItemRenderer) and it acts as you would expect it to.

This approach is much nicer, as the data is cleanly decoupled from the component implementation and it opens up the doors for reuse.

The code is available on Github. If you have any suggestions or would like to add to the component, fork it and let me know!

Here is the "completed" project on Github.

This is a roughly 25 minute walkthrough of wiring together a Twitter client using the Robotlegs AS3 Micro-Architecture MVCS implementation. It covers setting up the context, using commands, mediating composite view component, granular view component mediation, and retrieving data from a service.

Apologies in advance for the ambient noise. 4 kids, 2 dogs, and a busy wife does not make the perfect sound booth

I am considering expanding on this example and creating a start to finish video series creating a full Twitter client with Robotlegs. This would cover the actual component building, wiring everything together, working with data models (local storage, etc), and refining the application to use the advanced features available with the Twitter API using TDD the whole time for development. Is this something that you'd be interested in?