Best practices global static objects

brunofenzl's Avatar


22 Dec, 2011 10:52 AM

Hello All !

I´m developing my first AIR App with Robotlegs and have the following scenario:
My app have many data input types (data import, own native file, drag and drop from system) that needs to refresh 3 or more different interconnected views and models/services. My first solution was to create a static global file on the root package that just holds the values (most collections of VO´s) and is accessible from everywhere. That's a really bad Idea, i know. So here comes my question:
I´m sure there is a better workflow for Robotlegs. How would be the best practices here?

Any help is more than appreciated!!

  1. Support Staff 1 Posted by Ondina D.F. on 22 Dec, 2011 04:35 PM

    Ondina D.F.'s Avatar

    Hi Bruno,

    Because your description is pretty vague I’m not sure that my answer will address your real issue. Some more details, maybe? :)

    Short answer: use Commands to access Models or Services, which will dispatch an event with the data as a payload and all interested Mediators would listen to it and pass the data to their Views. Your “static global file“ would become a Model - in my example below I will call it VisualDescriptor.

    Long answer:
    Let’s say you have 2 mediated Views in a ViewStack: SomeViewOne and SomeViewTwo in a parent View, called NavigatorView. In the NavigatorView you also have a List of colors. If the user selects a color you want SomeViewOne and SomeViewTwo to change their background color accordingly.

    So, onSelectedListItem the NavigatorView dispaches an event ColorEvent.SET_BG_COLOR with the chosen color as a payload. NavigatorMediator listens for that event and redispatches it, triggering the SetColorCommand.

    SetColorCommand calls VisualDescriptor.setBGColor=event.payload (the color) which then dispatches ColorEvent.BG_COLOR_CHANGED.
    VisualDescriptor extends Actor, so it dispatches events on the shared eventDispatcher

    SomeMediatorOne and SomeMediatorTwo register a listener for this event on their onRegister() method, and when they are able to hear it, they call a method on their views, view.onBGColorChanged(event.payload) which then sets the BG color to the one selected in NavigatorView.

    Now, while SomeMediatorOne is probably able to react to the event, SomeMediatorTwo is not, because SomeViewTwo hasn’t been added to the display list yet, and that means SomeMediatorTwo hasn’t been created yet.

    But by the time the user navigates to SomeViewTwo you want it to have the BG color chosen in NavigatorView, right? So, what do you do? You want to have access to the settings in VisualDescriptor from everywhere, at any time. You can achieve this by using commands:

    SomeMediatorTwo onRegister() registers an event listener for ColorEvent.BG_COLOR_CHANGED and then dispatches ColorEvent.GET_BG_COLOR, which triggers GetColorCommand.
    GetColorCommand reads the value of VisualDescriptor.BGColor and dispatches ColorEvent.BG_COLOR_CHANGED with the BGColor as a payload and SomeMediatorTwo reacts to it and calls view.onBGColorChanged(event.payload).
    Of course you can let the Model dispatch the event instead.

    So, if you want some of your Views to share the same configuration data you let their Mediators listen for the same event (ColorEvent.BG_COLOR_CHANGED) dispatched somewhere in your application and then pass the payload to their Views.

    In the case of deferred instantiation or whenever a View needs data, you let the Mediator ask for data by dispatching an event (ColorEvent.GET_BG_COLOR) and let a Command access it (from a Model or Service), and then again, the Mediator will react to the event dispatched after the data has been received in a way or another and access its View’s API..

    (Note: in case of deferred instantiation you can use Stray’s RelaxedEventMap)

    I hope it wasn’t too confusing.


  2. Ondina D.F. closed this discussion on 02 Feb, 2012 10:40 AM.

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