Having some experience with PureMVC and even having some pleasant success with it, I was quite intrigued by some claims that robotlegs is "PureMVC done right". Hmm...At any rate, I can't help but be intrigued by a claim such as this and I always enjoy looking reading about developers' often unwavering opinions about how an MVC pattern should be implemented. So after reading the docs, development forums and checking out the examples, I feel that robotlegs is a great concept and has fulfilled its development philosophy very well. It seems to me that its primary focus has been the use of dependency injection. This allows you to keep the layers of your application nicely decoupled. In my early research, I was a bit annoyed by the fact that the injection module, SwiftSuspenders, was only compatible with the mxmlc compiler. However, the latest version includes the ability to use XML to configure the injection points so I can now use it with the Flash IDE. Yes, I, and a lot of other people, still use the Flash IDE to compile applications.

My only complaint about Robotlegs is very subjective. And let me preface this with the fact that I'm not a classically trained developer (I have a degree in design, not computer science). But Robotlegs was rather difficult to get my head partially wrapped around. More specifically, dependency injection was, and still is, rather difficult for me to understand. I understand the point of it, but how its implemented in Robotlegs still seems like magic to me. And because I don't understand the dependency injection all that well, its hard for me to feel really comfortable using the framework to develop anything. In comparison, what I really like about PureMVC was that it was pretty easy to learn and the core concepts are also easy to understand (at least to me). Regardless, this is not to say that Robotlegs is any better or worse than PureMVC.

Unlike my apprehensiveness for Robotlegs, I am really excited about Robert Penner's Signals project. I stumbled across this project while researching Robotlegs. I didn't quite understand it at first, but after checking out the source and giving a go I became instantly hooked on the idea and hope I can integrate it into my future projects. Basically what Penner has done is create an event/notification system that can pass around strongly typed objects to listeners instead of the native/traditional Event object. Signals are, to put it simply, an object that represents an event. Thus a signal object has its own API for registering and unregistering listeners. Signals also gives you the ability to define the types of signals an object should possess in your interfaces. This fulfills one of my biggest wishes for interfaces: a way to define the types of events an object should have to dispatch. As of now the project seems to still be in development with Penner experimenting how to make working with native events a bit easier. I highly recommend looking into his work, but don't expect much as he's apparently in Thailand until the beginning of January.

At first I gasped in excitement at the thought that there was something possibly, or arguably, better than using singletons. Like I said, I had no real opinion prior, so I spent today researching it. Low and behold, there's hardly any info or examples of implementations of this pattern out there. The only useful info I found was at this blog post. But, here is an example of what I gathered a monostate class to look like in ActionScript 3:

package
{
	public class ApplicationConfiguration
	{
		protected static var _language:String = "en";
 
		public function ApplicationConfiguration()
		{
 
		}
 
		public function get language():String
		{
			return _language;
		}
 
		public function set language( v:String ):void
		{
			_language = v;
		}
	}
}

So in this case I have a class with a protected static var named _language in it. This variable, because its static, will only ever exist in one place, and thats in the class definition. No matter how many times I create a new ApplicationConfiguration instance, the value of that variable will persist throughout each instance, allowing every instance to have a "mono state". Why didn't I ever think of this before? It's so simple and clever. So here's an example use of this class:

var config1:ApplicationConfiguration = new ApplicationConfiguration();
trace( config1.language ); // Output: en
config1.language = "fr";
 
var config2:ApplicationConfiguration = new ApplicationConfiguration();
trace( config2.language ); // Output: fr
config2.language = "es";
 
trace( config1.language ); // Output: es

I've commented in the output of that code, and you can see, when I make a change to the language property in config2 the value of language in config1 also changes.

So now I'm wondering what the advantages and disadvantages to this approach over a singleton might be. One of the most obvious advantages I saw right away was the fact that I can easily extend a monostate class. Extending singletons is, well, impossible as far as I know. Other than that I'm not too sure what some major advantages are. But extending seems to be big enough for me to want to start using this pattern.

At any rate, I'd like to hear some comments about anyone's experience with this pattern.

Let me outline my situation hypothetically...

1. I have an Application class. This class is the document class of an FLA. The application has a navigation component in it. Each navigation button corresponds to a section. Hypothetically these sections are Home, Gallery and News.

2. I have 5 mediators. ApplicationMediator , NavMediator, HomeMediator, GalleryMediator, and NewsMediator. ApplicationMediator and NavMediator are registered in the shell during startup. Note, I'm using the Flash IDE so the Nav component is on the stage already and a child of Application.

3. NavMediator listens for clicks on the nav component and sends out a note to load a section. The ApplicationMediator hears this note and unloads the current section (if there is one) then loads the necessary section into a new Loader object. By default the home nav button is selected to load the home section when the app starts.

4. Once a section is loaded, lets assume its the Home section, the HomeMediator must be registered in the View. This is where I got stumped. Here are my two initial ways of register the mediator:

4.A. After loading is complete, the HomeMediator is registered in the view from ithin ApplicationMediator like so:

facade.regsiterMediator( new( HomeMediator( loader.content as Home ) );

The problem with this is that it requires HomeMediator be imported into ApplicationMediator (including the mediators for the other sections as well). Additionally, within HomeMediator (and other section nediators), I have a getter for the view component that looks like this:

public function get home():Home
{
   return viewComponent as Home;
}

This ends up compiling Home (the section's FLA document class) into the main application SWF in addition to HomeMediator. I certainly don't want this to happen. I want all the code for the home section to be contained within the home SWF.

4.B. Rather than register the mediator in the ApplicationMediator, I would register the HomeMediator in the constructor of the Home component similar to the way the Application starts up. Like so:

public function Home()
{
   ApplicationFacade.getInstance().registerMediator( new HomeMediator( this ) );
}

In some cases I would also manually send a notification to initialize the section so that it would run standalone. This method requires that I import ApplicationFacade into the Home component, thus compiling any classes that are imported into that class (commands, and the Application view component) into the Home SWF. I don't want this to happen either because I don't want to bloat each section with main application code.

So therein lies my dilemma. Each section is unloaded when a new section is requested to keep the memory usage of the site/app to a minimum because, in the real project, each section is rather large (some even use Papervision). I'm just totally stumped when to register the mediator for the loaded section without having unnecessary code compiled into the shell or the section.

Also, thanks to Simon for making me rewrite my situation a bit better. It was perhaps a bit confusing before.

I resorted to the PureMVC forums and was told that the Multicore version of PureMVC would solve my problems. I haven't had time to look into Multicore yet, but I was wondering if anyone out there has used the Multicore version on a, what might be, smiliar project (one that loads and unloads sections). Also note, that I'm not using Flex here, I'm using the Flash IDE (and FlashDevelop) to publish my content. So I'd love to hear the thoughts, experiences, etc from any one thats gone this route or has some sort of solution for using the non-multicore version of PureMVC. Thanks in advance.