Archive for March, 2009

Event Mediator

Friday, March 6th, 2009

Most people are getting pretty hyped on design patterns and frameworks these days. Most of what I have seen floating around though is the use of MVC. MVC is a really nice pattern, and I wish I had known about it when I was doing a lot of php work as it would have saved me at least 100 huge headaches. When I looked at rails I was really impressed with how easy it made it to change the application view and data as 2 very isolated entities. Now there are tons of frameworks available for flash that use this pattern. PureMVC and Cairngorm are both really nice options that encourage loose coupling. If your project is big, or has multiple developers involved than using one of these frameworks is going to be the way to go. Your app will be scalable and multiple people can pick out their own parts to work on without messing with the others. This is flash though, and a lot of times you are not building something this big.

I first started trying to figure out how to decouple objects when I first started using AS3. Immediately I was getting bugs and compiler errors because I was trying to remove objects that had a reference in some other object that needed info and not knowing to clean it up. I also found the event model started to look like the nasty parent child rats nest that I have always tried to avoid. I started by setting up a static member in my application that was an event dispatcher, passing notifications and adding listeners to it. it worked ok, but one thing that I immediately noticed was the fact that I was not getting back any info about the object that sent the event. was coming from the event dispatcher. In order to get info about the objects in question I needed to create custom events that had a variable that was required to be set in order to see any info about the original object target. I generally needed to make an extra function to handle the original event and pass it to the dispatcher which is kinda a hassle. Thirdly as my application grew, the objects started to have a lot of dependencies as they were all referencing the main app. This was fine for working within a single project, but if I wanted to shift a lot of the classes out for usage in a different environment I was essentially screwed. I also was right back where I started with dependencies.

The next thing I tried was getting in tune with event bubbling. Event bubbling is pretty cool and achieved a lot of the effect I was looking for, but I did start to notice an issue with it that became a gotcha pretty quickly. The main thing with event bubbling is that it works off the display list. This seems like a pretty necessary feature to keep it under control, but assuming that any object that is interested is in the same display tree can feel pretty limiting pretty quick. I was finding myself making helper classes sprites just so that I could get them to receive events and be tied to the stage. If they were in a different hierarchy they were useless. Frameworks like papervision3D or APE also cannot take advantage of this feature.

I then started reading about design patterns in a little more depth. Went and got the book by the gang of 4 and started going through it. The patterns that immediatly stuck out to me were observer and mediator. Observer seemed to be tuned a little more towards what flash is already doing with events, but mediator seemed like exactly what I was trying to do. The problem was that the smalltalk examples didn’t exactly translate to what I was looking for so I started going to forums for a little advice.

The only real advice from the forums that I got is that asking about design patterns is the equivalent of starting a flame war. Ask what you think is a simple question and you will immediately see 2-10 other people get into a heated discussion about “proper” implementation. Some of the insults I have not seen since looking at the World of Warcraft forums. Looking at examples of people using patterns I started to realize that the implementation seemed relevant more to the language. It also seemed to me that perhaps you could use a pattern to describe what you were trying to do.

I built out a few various event mediators, and finally came up with one that I am happy with. It takes care of a lot of the things I need in smaller projects that change a lot. It is not what a typical mediator looks like. Most of the examples I found contained a lot more knowledge of the objects associated with them. This does not assume any of that knowledge. You can just add and remove objects to/from it.

1. Any remotely loaded swf files can communicate with the host application by going through the mediator. This removes dependence on classes and and files that you do not need in a loaded module. If you redo functionality in the main app you do not need to recompile any of the loaded modules. It also removes the need to tie events to a module on load that may or may not actually be relevant.
2. Project structure can change rapidly without having too many adverse effects, and classes can be reused a lot more easily since they are not tied to each other. This really helps at an ad agency where things can change on you really quickly.

1. If your app is going to get big this will start to become a burden. It is designed for small nimble things where a lot of stuff is happening visually. Something that uses a lot of data would be better handled with something like PureMVC.
2. You have to be pretty careful about event names. Since the event types are just strings, naming something the same in a different event will cause conflicts.
3. Using with common events such as mouse events is a good way to spell trouble. This means you really need to create a specific event to send out to the mediator.

You can grab the file here: