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.as.

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.