GWT ramblings of a Flex developer - View / Presenter communication (events vs. UiHandlers)

  Hello again!

 

This will be part 6 of the series, you can check out the previous ones here.

 

Today, we'll discuss View-Presenter communication (events and other alternatives).

I'll be comparing Flex implementation for PureMVC vs. GWTP View-Presenter paradigms.

 

When using Flex PureMVC, the actors are the Model (Proxies), the Control (Commands) and the View (Mediators and their corresponding view components). Proxies, Commands and Mediators communicate amongst themselves using a notification mechanism (which is essentially business logic events). An actor registers to listen for a specific notification, and when that notification is fired – it has an opportunity to react.

 

Mediators and their corresponding views communicate in a special way. Mediators know their views intimately, and so they can invoke public functionalities implemented in the view directly. The views, however, are oblivious of the Mediator and as such dispatch events (either Flex/Flash events or custom events), which the Mediator listens to and reacts accordingly.

 

With GWTP, the MVC pattern is replaced with MVP pattern (Model, View, Presenter) – where the Presenter acts as the Mediator but also has some of the responsibilities of the Control. Unlike Flex above, where the view does not know the Medaitor, here the view and the Presenter have means to communicate without events but rather with a "two way communication contract" of sorts.

 

Let's review this contract. I said it's two way – that means that the Presenter has the means to communicate with the view and cause functionalities to run on the view, but also the view has the means to communicate with the presenter and cause functionalities to run on the Presenter. I use the term communicate loosely here, and you will soon see why.

 

Presenter -> View direction:

The Presenter defines an internal public interface, usually named MyView, which includes the API the Presenter expects its view to implement (ignore the HasUiHandlers<MyUiHandlers> code for now, we'll talk about it in a sec):

 

	public interface MyView extends View, HasUiHandlers<MyUiHandlers> {
		void doSomethingOnView(String arg1);
	}

 

The view should implement this interface and presto! You have the first direction of the communication.

All you have to do in the Presenter code is:

getView().doSomethingOnView(arg);

 

 

View -> Presenter direction:

 

This direction is a little trickier, but still not complicated.

First, we create an interface that extends UiHandlers:

public interface MyUiHandlers extends UiHandlers {
        void DoSomethingOnPresenter();
}

 

This interface will include the API the view expects its Presenter to implement.

The Presenter implements it:

public class MyPresenter extends PresenterWidget<MyPresenter.MyView> implements MyUiHandlers {

 

But that in itself, is not enough.
The Presenter should also, in its constructor, call:

                getView().setUiHandlers(this);

 

 

And this will 'seal the deal', letting the view know that the Presenter is its UiHandler. Remember that in the first code snippet we saw that the MyView interface also extends HasUiHandlers<MyUiHandlers>? This is where it comes in.

Now, the view code can invoke Presenter functionality using:

getUiHandlers().DoSomethingOnPresenter();

 

 

So, the Presenter communicates with its View through the MyView interface and the View communicates with its presenter using the UiHandlers interface – no events required!

 

 

Thank you for your interest!

We will contact you as soon as possible.

Send us a message

Oops, something went wrong
Please try again or contact us by email at info@tikalk.com