One word: EventBus. The EventBus is your friend, and it will help you through this. This is how I did it:
My Eventbus class lets subscribers subscribe to events belonging to different modules in my app. There is of course different ways of doing this, if you want it more fine-grained you can always let presenters subscribe to specific events, such as "NewLineAddedEvent" or something like that, but for me I found that dealing with it on a module level was good enough. If you want you could make the call to the presenter's rescue methods asynchronous, but so far I've found little need to do so myself. I suppose it depends on what your exact needs are.
public class EventBus implements EventHandler
{
private final static EventBus INSTANCE = new EventBus();
private HashMap<Module, ArrayList<Subscriber>> subscribers;
private EventBus() { subscribers = new HashMap<Module, ArrayList<Subscriber>>(); }
public static EventBus get() { return INSTANCE; }
public void fire(ScEvent event)
{
if (subscribers.containsKey(event.getKey()))
for (Subscriber s : subscribers.get(event.getKey()))
s.rescue(event);
}
public void subscribe(Subscriber subscriber, Module[] keys)
{
for (Module m : keys)
subscribe(subscriber, m);
}
public void subscribe(Subscriber subscriber, Module key)
{
if (subscribers.containsKey(key))
subscribers.get(key).add(subscriber);
else
{
ArrayList<Subscriber> subs = new ArrayList<Subscriber>();
subs.add(subscriber);
subscribers.put(key, subs);
}
}
public void unsubscribe(Subscriber subscriber, Module key)
{
if (subscribers.containsKey(key))
subscribers.get(key).remove(subscriber);
}
}
One of my handlers (a bit of it). This handler deals with ClickEvents simply by firing them on the EventBus for the subscribers to deal with. In some cases it makes sense for the handlers to perform extra checks before firing the event, or sometimes even before deciding weather or not to send the event. The action in the handler is given when the handler is added to the graphical component.
public class AppHandler extends ScHandler
{
public AppHandler(Action action) { super(action); }
@Override
public void onClick(ClickEvent event)
{
EventBus.get().fire(new AppEvent(action));
}
The event that's get fired by the handler looks a bit like this. Notice how the event defines an interface for it's consumers, which will assure that you don't forget to implement the correct rescue methods.
public class AppEvent extends ScEvent {
public interface AppEventConsumer
{
void rescue(AppEvent e);
}
private static final Module KEY = Module.APP;
A presenter (cut a bit short). The presenter subscribes to events belonging to diffrent modules, and then rescues them when they're fired. I also let each presenter define an interface for it's view, which means that the presenter won't ever have to know anything about the actual graphcal components.
public class AppPresenter extends Subscriber implements AppEventConsumer, ConsoleEventConsumer
{
public interface Display
{
public void openDrawer(String text);
public void closeDrawer();
}
private Display display;
public AppPresenter(Display display)
{
this.display = display;
EventBus.get().subscribe(this, new Module[]{Module.APP, Module.CONSOLE});
}
@Override
public void rescue(ScEvent e)
{
if (e instanceof AppEvent)
rescue((AppEvent) e);
else if (e instanceof ConsoleEvent)
rescue((ConsoleEvent) e);
}
}
The principle behind the view is as follows: Each view is given an instance of a handler factory. The handler factry will create the correct handler based on what module the factory has been instantiated with. The view is then free to add handlers of different kind to it's components without having to know about the exact implementation details:
public class AppView implements Display
public AppView(HandlerFactory factory)
{
ToolStripButton addButton = new ToolStripButton();
addButton.addClickHandler(factory.create(Action.ADD));
/* More interfacy stuff */
}
public void openDrawer(String text) { /*Some implementation*/ }
public void closeDrawer() { /*Some implementation*/ }
And there you have it, everything is nicely decoupled, and if you throw a couple of abstract classes and interfaces on it, none of your classes will ever really know what's going on. ;)
Please let me know if there's something you need me to clarify, I'm happy to do so.
Edit (Adding some clarifications as per your request):
The subscriber is the presenter. The presenter subscribes to events sent on the eventbus, and will react to the events by modifying the state of its view.
The "subscribing to modules"-bit is just something that's valid for my app, but I've found it's worked out very well for me. The Module is just an enum where all the different views in the system makes up one module.
For example, consider a simplified Eclipse, where you have a class hierarchy to the left, a text area for code on the right, and a menu bar on top. These three would be three different views with three different presenters and therefore they'd make up three different modules. Now, it's entirely possible that the text area will need to change in accordance to changes in the class hierarchy, and therefore it makes sense for the text area presenter to subscribe not only to events being fired from within the text area, but also to events being fired from the class hierarchy. I can imagine something like this:
public enum Module
{
MENU,
TEXT_AREA,
CLASS_HIERARCHY
}
In my setup the deletion of a class file from the hierarchy would for example bring the following changes to the gui:
- The class file should be removed from the class hierarchy
- If the class file is opened, and therefore visible in the text area, it should be closed.
You would then have two presenters, the one controlling the tree view and the one controlling the text view, both subscribe to events fired from the CLASS_HIERARCHY module. If the action of the event is REMOVE, both preseneters could take the appropriate action, as described above.
The Action class is also just an enum, and even though I did have the same concerns as you express in your comment when adding it, I find that just using a limited number of thinkable operations was enough for me, as each operation has the ability to mean slightly different things in each module.
This is my Action enum:
public enum Action
{
ADD,
REMOVE,
HELP,
CLOSE,
SAVE,
DISPLAY,
OPEN,
LOAD
}
Of course, the alternative to this is using more specialised events and letting presenters subscribe to just these events, which probably is more durable if you plan on building a very big system. For the eclipse example above, this would mean that both the presenters for the hierarchy and the text area would subscribe to an event of a certain type, and in this case probably something like RemoveClassFileEvent or something similair.