Building modular applications

Mark Simpson's Avatar

Mark Simpson

04 May, 2012 01:11 PM


Is it possible for robotlegs to nicely handle the unloading of modular registrations? Modules/Modular is a bit of an overloaded term, so I will explicitly set out what I mean:

We're building a games platform. We provide a load of common services and handle the ticking of core/infrastructure types (e.g. exposing access to a single instance of Away3D -- all apps load textures/models etc. using a single instance that is never destroyed during the lifetime of a user visiting our website).

We dynamically load 'app' style .swf files at runtime (an app is a game / utility built on top of some common functionality that we provide). As such, we want apps to be able to access our library provided types. We currently implement this by allowing applications to register their own types via our own bespoke Module type (analogous to Autofac modules in the .NET world -- a module is simply a convenient grouping of registrations). Functionally, this works fine. However, it does mean that we have to make a corresponding unmap call for every registration which is obviously error-prone and tedious.

I'm wondering whether there's a better / standardised way of doing this?

The rationale behind doing this is that apps should be able to be loaded/unloaded in the simplest way possible. Ideally, they can register their own types without having to make corresponding unmap calls. You should just be able to say "please throw away all registrations that were made as part of this app's lifetime when the app is unloaded). I'm a touch confused about this, as things like having multiple contexts and/or using child injectors muddy the waters a little.

The ideal flow would basically go like this:
* The user loads our entry point via browsing to our website * Our platform types are registered by default, and these registrations persist for the lifetime of the user's visit to the website * User chooses an app to load (e.g. car driving game) * The app registers a load of types and is bootstrapped * The app is run for a while * A new app is selected (e.g. plane flying game) * We unload the current app and automagically unregister/dispose all of its registrations * We load the new app

Is there any guidance you could give me on how to do this in the most sensible/idiomatic way with robotlegs? Cheers. We really like robotlegs :).

  1. Support Staff 1 Posted by Shaun Smith on 04 May, 2012 02:38 PM

    Shaun Smith's Avatar

    Hi Mark,

    There are many ways to approach this. The basic idea is to make sure that everything that you "register" is done through a local (per module) wrapper that keeps track of registrations and can undo everything with one call to "destroy()".

    An example of something in the framework that uses this principle (on a small scale) is the local EventMap. A fresh instance gets injected into each mediator, and as long as all listeners are registered through the event map they can all be removed with a single call to unmapListeners().

    In Robotlegs 2 the context has a well defined lifecycle that is easy to hook into. One can add a hook to the destroy transition to perform actions when the context is destroyed (or before or after). With Robotlegs 1 you would have to dispatch a destroy type event and react to that.

    Regardless, the approach is still the same. Just ensure that all registrations are done through a local wrapper that keeps track of everything so it can undo it when required. Be sure to thoroughly profile your system to ensure that things are being GC'd as expected.

    Hope that helps.

  2. 2 Posted by Mark Simpson on 04 May, 2012 03:33 PM

    Mark Simpson's Avatar

    Thanks for the advice. We'll do that.

  3. Support Staff 3 Posted by Shaun Smith on 04 May, 2012 03:51 PM

    Shaun Smith's Avatar

    Cool, let me know if anything interesting crops up.

  4. Ondina D.F. closed this discussion on 05 May, 2012 01:23 PM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac