This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Here's what I've got. I've been playing around with the TrayIcon API from the JDIC project. Pretty cool stuff. It's really easy to show those annoying albeit sometimes useful baloon messages.
And here is what I'd like to do. I'd like a simple way for a large application to display messages when necessary. I'd prefer not to have to pass the TrayIcon object around to every class that *might* need it. I'd like to create some sort of observable pattern so that I can notify the object that there is a message to display and what that message is.
There are a couple options. You could have an observer pattern where some sort of tray icon "view" listens to events. However, you would still have to register your view with the "model" that is firing events. Perhaps one way to address this is to use an EventManager class. You would basically have a central manager to send events to. The tray view would then only have to listen to it. The EventManager itself could be a classic singleton accessed through EventManager.getInstance() or intialized by some flavor of IoC. A similar concept is
This project creates a bus and channels for it on the fly based on methods that exist in your classes. I would recommend defining marker interfaces for the event methods if you go the werx route however. Hope that helps.
Ok, test #1. This first way is very simple but I am not sure about it's usablility or if it might come back to bite me later. I create the following class.
Then, when I create my TrayIcon I register it with the EventManager like so:
And then from any other class anywhere I can do the following:
Comments? Good? Bad? I am stupid? [ June 09, 2005: Message edited by: Gregg Bolinger ]
Joined: Apr 05, 2005
Well the event manager should probably be a little more generic. Instead of having a tray icon specifically, I'd have a generic observer interface. You would create the tray icon and then add it as a listener to the event manager. Your events would have some sort of type so when the tray icon receives one it could say ... "ok this is a display message" I should process it. As things get more complex you also might want to add the idea of a consumable event (Swing does this). So the tray icon would consume the event so other listeners wouldn't have to deal with it.