Messages Instead of Events

I recently started experimenting with a different concept in Flash development, and I want to get some community feedback. As I was starting to define relationships between components in an application I built recently, I realized that part of my architecture was being affected by my use of events. In other words, components seemed to need to be related, which usually meant physically close to each other, in order for it to be convenient for them to be able to listen for events broadcast from each other. I found I needed some common point of contact (a controller) between components that wanted to be aware of other components.

I thought about what the ideal way would be for communication to take place, and I decided that rather than events, a concept of “messages” might make more sense. I decided that what I’d really like to do is publish a message (as opposed to broadcasting an event), and have anything that was subscribed to that event — regardless of the relationship between the publisher and the subscriber — get that message. It seemed like a good idea, so I wrote

Messenger is a singleton, which means that it’s API enforces that there can only be a single instance of it in the entire Flash player. In other words, you cannot instantiate a new Messenger, but instead must use its static getInstance() function to obtain an instance. That ensures that everyone is using the same reference, which makes this type of communication possible.

The API looks something like this:

Messenger.getInstance().subscribe("new-row-selected", this, "onRowSelected");public function onRowSelected(rowId:Number):Void{trace("You picked: " + rowId);}

… then anywhere else in your code …

Messenger.getInstance().publish("new-row-selected", myGrid.getSelectedItem().id);

I found that this worked exceptionally well, and allowed me to:

  1. Write less code. Publishing and subscribing to messages seemed to require less code than broadcasting and listening for events. Additionally, my application does not have a controller at all! Just a bunch of objects publishing and reacting to various messages.
  2. Allow more flexibility in my architecture. I didn’t have to worry about the logistics of adding listeners in certain places. Anyone can listen for any message anywhere in the entire application.
  3. Create a more dynamic and interactive application. Since any part of my application could have access to any message, I found myself coupling parts of my app that wouldn’t normally have been coupled. For instance, I already had a progress bar in my application for web service loading which was listening for “show-progress” and “hide-progress” messages. Suddenly, any operation that might take more than a few seconds could make use of the progress bar simply by stating:
Messenger.getInstance().publish("show-progress", null);

The other thing I was thinking about doing is adding a configurable logging option to the Messenger object so that I could watch every message the entire application sends, allowing me to easily pick and choose the types of messages I want various pieces of my application to subscribe and react to. I haven’t implemented that part yet, but it’s next on my list. Then I’ll look into an LCMessenger. You can guess what kind of cool functionality that should allow.

6 Responses to Messages Instead of Events

  1. Will Dent says:

    Seems like this allows you to develop smaller apps that don’t require maybe quite the extensive structure some RIAs require.

  2. Brian says:

    Exactlly in functionality of ASBroadcaster. I live the new events architecture; Instead of passing copied data you pass a reference to the broadcasting object and expose whatever data you feel is appropriate via public properties. Grant Skinners GDispatcher makes this process even more elegant.

  3. Brian says:

    I meant to say, “I like the new events architecture”. 😛

  4. Scott Barnes says:

    Exactly what Brian said, basically get Grants extended version of the EventDispatcher, he’s added some “All” concepts to it, same functionality as you normally would with dispatchEvent only you can nominate an object to subscribe to all.I’d probably be against a concept such as the one above, as from an overhead point of view, there will be allot of back-channel feedback happening needlessly between objects, great part about specific event listening is that its locked into a narrow output/input filtering system.Dunno, have to see how a lager RIA would handle such an event manager and whether or not the overall memory would be impacted (doubt it).

  5. This concept is obviously based on the ASBroadcaster (which is what I was using initially), but it doesn’t require you to set listeners. That’s the point. Anything that has subscribed using the code in the post is automatically a listener, which means there doesn’t have to be a relationship between the publisher and the subscriber as there has to be when using ASBroadcaster. Is there a way to use the ASBroadcaster that I’m not aware of? Messages seem much more convenient.