Cairngorm 2.2 – Front Controller Weak References

In a continuation on my series of posts covering the recent Cairngorm 2.2 release, today I’ll give the motivation behind another one of the changes that we made in the MVC micro-architecture for Flex: weak references in the front controller.

In Cairngorm 2.1, the base FrontController class added itself as a listener onto the CairngormEventDispatcher as follows:

CairngormEventDispatcher.getInstance().addEventListener( commandName, executeCommand );

meaning that, when Cairngorm events are dispatched at various places throughout the Flex application, the controller would be notified, and the executeCommand() method called. However, the line of code above added the controller to the CairngormEventDispatcher as a hard reference, meaning that the controller would never be eligible for garbage collection while the CairngormEventDispatcher was still in memory.

Fast forward to the release of Flex 2.0.1 and the addition of Module support to the Flex framework. This feature gives us the ability to load and unload parts of our application, dynamically, at runtime. With Cairngorm 2.1, if someone wanted to create a Cairngorm application as a module, even if that module is unloaded, the controller would never be eligible for garbage collection because the CairngormEventDispatcher (which is a singleton, and therefore global) still has a hard reference onto it.

So, in Cairngorm 2.2, we have made, by default, the addition of the controller to the CairngormEventDispatcher as a weak reference. Holding objects as weak references means that the object will be eligible for garbage collection if the only references to it are weak.

Now, when the FrontController is unloaded, and assuming that all other hard references to it have also been removed, the controller will be eligible for garbage collection, because the CairngormEventDispatcher only has a weak reference onto it.

You can still decided to add the controller as a hard reference to the CairngormEventDispatcher, via a parameter of the addCommand() method of FrontController, but I see little need for that.

There is one final point to add here. The ASDoc for the addCommand() method of FrontController states that the command is added as a weak reference to the controller. That is just plain wrong and I hold my hand up to that – the comments were added in a rush just before I did the final build, instead of when I did the code change. The docs will be fixed in the next release.

6 Responses to Cairngorm 2.2 – Front Controller Weak References

  1. Mark says:

    Hi Alistair,
    I am a little confused by this post…
    In my Cairngorm FrontControllers, all my event handlers are added using the addCommand method.
    Does the addCommand method in Cairngorm 2.2 add weak references? Or should I be using the method stated above?
    My main concern is the Command objects created to handle my events are not garbage collected over time. I want my Flex app to run for hours and in that time many Command objects would be created.
    Am I getting my wires crossed?
    Is this only the ability for the FrontController Object to be Garbage Collected?
    Is the motivation for this to do with the ability to load up multiple FrontControllers when using Modules (assuming that each Module would have its own FrontController?)
    Any clarifications would be appreciated.

  2. Hi Mark,
    The line of code I gave is what FrontController does internally. You still use addCommand to register commands with your controller.
    Your command instances will already be garbage collected (in as much as the rest of your application allows) – that hasn’t changed from any previous version of Cairngorm 2.x. You pass the command type to addCommand() and, when an event is received, the controller creates a command of that type. However, the controller never keeps a reference to that instance of the command that was created.
    Once the command’s execute() method has been called (and the result/fault handler called, if the command is also a responder), assuming you don’t have a reference to that command instance anywhere else in your codebase, it will be eligible for garbage collection.
    So, you’re right in saying that the motivation for the change is so that a module with its own own FrontController will be eligible for garbage collection when the controller is unloaded from the application.
    Note, that I’m not saying that, in every modularised application, I’d recommend each Module being its own Cairngorm application, but there may be use-cases where that is one possible solution.

  3. Stefan Schmalhaus says:

    Thank you very much for explaining why specific changes were made and what they mean in terms of application architecture, etc. I’m wondering what strategy you recommend for developing Flex applications regarding the short cycle of new Cairngorm releases. Right now I’m working on a mid-size app that is based on Cairngorm 2.0. I see the advantages of the 2.1 and 2.2 releases but I’m not very keen to update my app every time a new version of Cairngorm is released. Can we expect more Cairngorm releases before Flex 3.0?

  4. Hi Stefan,
    We’re very cognisant of keeping Cairngorm backward compatable, so you should just be able to drop in the latest swc into your application and carry on as normal.
    Of course, we’d also recommend that you thoroughly test your code after doing that 🙂
    Cairngorm is the application of our best practices, as we see them emerging from our day-to-day work with clients, and, it is that that drives new feature.
    However, releases are roughly aligned to Flex releases, so we don’t regard Cairngorm as having a short release cycle – the 2.2 release was to reflect some things that appeared in Flex 2.0.1.
    We do expect to have to make another release when LiveCycle Data Services (nee FDS), which is currently on Labs, is released, due to some changes there, but I wouldn’t expect a huge number of releases between now and Flex 3.0.
    But, if you’re happy with Cairngorm 2.0, and there’s nothing in list of changes in the release notes that you feel you require, I don’t see any problems in sticking with 2.0.

  5. Josh says:

    I just started using Cairngorm a month or two ago, and I just wanted to say thanks for sharing such a great tool. It has helped me significantly with project organization and I feel it has improved my development practices quite a bit. Thanks again!

  6. Roman says:

    Sorry, just a short question. Maybe it is already answered, but I can’t find an answer to the following question:
    If I have events which only occur e.g. during initialization, shoudl I remove the correpsonding commands from the controller after the event was fired and executed?