UiHandlers and supervising controller

In our last post we told you how to reference your presenter (aka supervising controller) within your view in an elegant and simple way. However, we used a slightly provocative title that may lead you to think we are no longer doing MVP. Let’s get that out of the way: even though we added one arrow to the MVP diagram of Martin Fowler, this new pattern will look and feel perfectly MVP-esque to you. In fact, some people at Google added this arrow long before we did!

What does it mean to you? It means your view is still dumb (sorry, passive, we don’t want to hurt her feelings) enough that you can often afford to test only your presenters. Really, the only thing you’ll notice is an important reduction in the number of smelly anonymous classes and your love story with UiBinder will blossom!

That being said, we already told you how to use the pattern and even gave some tools to automate the process with Gwt-Platform. We decided not to use injection for connecting the presenter to the view, mostly because it would have caused an explosion in the number of class implementations. At that point we felt the user should probably make his own implementation to his liking, injecting a Provider<MyUiHandlers> if desired.

Now let’s explain why we used this pattern and take a look at what is MVP:

As you can see there’s a direct link between the view and the presenter used for forwarding events. We felt, while reading google mvp part 2, that this pattern was doing exactly what we needed to clean things up: delegating events to the presenter.

In the old approach, the view would let the presenter access either the real widgets (bad) or a simple interface such as HasClickHandlers (better). Then the presenter would bind a handler to this object and would be directly notified of any UI interaction. Since each one of these bindings require you to write a cumbersome anonymous class, a complex view would quickly generate a LOT of boiler plate in its presenter.

Instead of doing this, the new approach lets you handle events directly in the view, mapping them to methods in the presenters. If you’re using a 1-to-1 mapping, this does not add any logic to your view. But where does the savings come from? Aren’t you simply moving all these anonymous classes to the view? This is where @UiHandler comes into play! This new annotation is a real boilerplate saver: it automatically binds a widget event to a method from the view class. The only thing left to do is to invoke the corresponding method in the presenter class.

If reducing boilerplate is not a good enough reason for you, there is another important benefit of passing the presenter to the view. Hooked? Sorry, this will have to wait for a future post… Meanwhile, don’t hesitate to give us feedback or to propose subjects!