Miscellaneous Garden

Building any large scale application has its hurdles, and GWT apps are no exception. Multiple developers working simultaneously on the same code base, while maintaining legacy features and functionality, can quickly turn into messy code. To help sort things out we introduce design patterns to create compartmentalized areas of responsibility within our project.

There are various design patterns to choose from; Presentation-abstraction-control, Model-view-controller, Model-view-presenter, etc… And while each pattern has its benefits, we have found that a Model-view-presenter (MVP) architecture works best when developing GWT apps for two main reasons. First the MVP model, much like other design patterns, decouples development in a way that allows multiple developers to work simultaneously. Secondly, this model allows us to minimize our use of GWTTestCase, which relies on the presence of a browser, and, for the bulk of our code, write lightweight (and fast) JRE tests (which don’t require a browser).

At the heart of this pattern is the separation of functionality into components that logically make sense, but in the case of GWT there is a clear focus on making the view as simple as possible in order to minimize our reliance on GWTTestCase and reduce the overall time spent running tests.

Building an MVP-based application can be straightforward and easy once you understand the fundamentals behind this design pattern. To help explain these concepts we will use a simple Contacts application as an example. This application will allow users to view, edit, and add contacts to a list of contacts that are stored on the server.

To begin we will break our application up into the following components:

• Model
• View
• Presenter
• AppController

We’ll then look into how each of these components interact by digging into:

• Binding presenters and views
• Events and the event bus
• History and view transitions
• Testing

Sample Project

The sample project, referenced throughout this tutorial, can be found at Tutorial-Contacts.zip.

Model

A model encompasses business objects, and in the case of our Contacts application we have:

• Contact: A representation of a contact within the contact list. For simplicity, this object contains a first name, last name, and email address. In a more complex application, this object would have more fields.
• ContactDetails: A light version of the Contact that contains only the unique identifier and display name. This “light” version of the Contact object will make the Contact list retrieval more efficient, as there will be fewer bits to serialize and transport across the wire. In the case of our example application, this optimization has less impact than it would in a more complex app where Contact objects have substantially more fields. The initial RPC will return a list of ContactDetails, and we’ve added a display name field so that there is some amount of data that can be displayed (within the ContactsView) without having to making subsequent RPCs.

View

A view contains all of the UI components that make up our application. This includes any tables, labels, buttons, textboxes, etc… Views are responsible for the layout of the UI components and have no notion of the model. That is to say a view doesn’t know that it is displaying a Contact, it simply knows that it has, for example, 3 labels, 3 textboxes, and 2 buttons that are organized in a vertical fashion. Switching between views is tied to the history management within the presentation layer.

The views in our Contacts application are:

• ContactsView
• EditContactView

The EditContactView is used to add new contacts as well as editing existing contacts.

Presenter

A presenter contains all of the logic for our Contacts application, including history management, view transition and data sync via RPCs back to the server. As a general rule, for every view you’ll want a presenter to drive the view and handle events that are sourced from the UI widgets within the view.

For our sample we have the following Presenters:

• ContactsPresenter
• EditContactPresenter

Just as with the view, the EditContactPresenter adds new contacts as well as edits existing contacts.

AppController

To handle logic that is not specific to any presenter and instead resides at the application layer, we’ll introduce the AppController component. This component contains the history management and view transition logic. View transition is directly tied to the history management and is discussed in greater length below.

At this point the overall hierarchy of our sample project should look like the following:

With our component structure in place, and before we jump into wiring it all up, we’ll want to take a look at the process that starts everything up. The general flow, as shown in the following code, is:

1. GWT’s bootstrap process calls onModuleLoad()
2. onModuleLoad() creates the RPC service, Event Bus, and the AppController
3. The AppController is passed the RootPanel instance and takes over
4. From then on the AppController is in control of creating specific presenters and supplying a view that the presenter will drive.

public class Contacts implements EntryPoint {

  public void onModuleLoad() {    ContactsServiceAsync rpcService = GWT.create(ContactsService.class);    HandlerManager eventBus = new HandlerManager(null);    AppController appViewer = new AppController(rpcService, eventBus);    appViewer.go(RootPanel.get());  }}

Binding presenters and views

In order to bind the presenter and associated view together we’ll rely on Display interfaces that are defined within the presenter. Take for example the ContactsView:

This view has 3 widgets: a table and two buttons. In order for the app to do something meaningful, the presenter is going to need to:

• Respond to button clicks
• Populate the list
• Respond to a user clicking on a contact in the list
• Query the view for selected contacts

In the case of our ContactsPresenter, we define the Display interface as such:

public class ContactsPresenter implements Presenter {  ...  public interface Display extends HasValue<List<String>> {    HasClickHandlers getAddButton();    HasClickHandlers getDeleteButton();    HasClickHandlers getList();    void setData(List<String> data);    int getClickedRow(ClickEvent event);    List<Integer> getSelectedRows();    Widget asWidget();  }}

While the ContactsView implements the above interface using Buttons and a FlexTable, the ContactsPresenter is none the wiser. In addition, if we wanted to run this application within a mobile browser we could switch out the views without having to change any of the surrounding application code. To be transparent, with methods such as getClickedRow() and getSelectedRows() the presenter is making the assumption that a view is going to display the data in the form of a list. That said, it’s at a high enough level that a view is still able to switch out the specific implementation of the list without any side effects. Method setData() is a simple way of getting model data into the view without the view having intrinsic knowledge of the model itself. The data being displayed is directly tied to the complexity of our model. A more complex model may lead to more data being displayed in a view. The beauty of using setData() is that changes to the model can be made without updating the view code.

To show you how this works, let’s look at the code that is executed upon receiving the list of Contacts from the server:

public class ContactsPresenter implements Presenter {  ...  private void fetchContactDetails() {    rpcService.getContactDetails(new AsyncCallback<ArrayList<ContactDetails>>() {      public void onSuccess(ArrayList<ContactDetails> result) {          contacts = result;          List<String> data = new ArrayList<String>();

          for (int i = 0; i < result.size(); ++i) {            data.add(contacts.get(i).getDisplayName());          }

          display.setData(data);      }

      public void onFailure(Throwable caught) {        ...      }    });  }}

To listen for UI events we have the following:

public class ContactsPresenter implements Presenter {  ...  public void bind() {    display.getAddButton().addClickHandler(new ClickHandler() {      public void onClick(ClickEvent event) {        eventBus.fireEvent(new AddContactEvent());      }    });

    display.getDeleteButton().addClickHandler(new ClickHandler() {      public void onClick(ClickEvent event) {        deleteSelectedContacts();      }    });

    display.getList().addClickHandler(new ClickHandler() {      public void onClick(ClickEvent event) {        int selectedRow = display.getClickedRow(event);

        if (selectedRow >= 0) {          String id = contacts.get(selectedRow).getId();          eventBus.fireEvent(new EditContactEvent(id));        }      }    });  }}

To respond to UI events, such as the user deleting a list of selected contacts, we have the following:

public class ContactsPresenter implements Presenter {  ...  private void deleteSelectedContacts() {    List<Integer> selectedRows = display.getSelectedRows();    ArrayList<String> ids = new ArrayList<String>();        for (int i = 0; i < selectedRows.size(); ++i) {      ids.add(contactDetails.get(selectedRows.get(i)).getId());    }        rpcService.deleteContacts(ids, new AsyncCallback<ArrayList<ContactDetails>>() {      public void onSuccess(ArrayList<ContactDetails> result) {        contactDetails = result;        List<String> data = new ArrayList<String>();

        for (int i = 0; i < result.size(); ++i) {          data.add(contactDetails.get(i).getDisplayName());        }                display.setData(data);      }            public void onFailure(Throwable caught) {        ...      }    });  }}

Again, in order to reap the benefits of the MVP model, the presenter should have no knowledge of any widget-based code. So long as we wrap a view in a display interface that can be mocked and our JRE tests never call asWidget(), all is grand. That’s how you can have your cake and eat it too: minimize the GWT ties to allow a non-GWTTestCase to be useful, but still have the ability to slap a Display instance into a panel.

Events and the Event Bus

Once you have presenters sinking events that are sourced by widgets within views, you’ll want to take some action on these events. To do so, you’ll want to rely on an Event Bus that is built on top of GWT’s HandlerManager. The Event Bus is a mechanism for a) passing events and b) registering to be notified of some subset of these events.

It’s important to keep in mind that not all events should be placed on the Event Bus. Blindly dumping all of the possible events within your app on the Event Bus can lead to chatty applications that get bogged down in event handling. Not to mention, you’ll find yourself writing a fair amount of boilerplate code to define, source, sink, and act upon these events.

App-wide events are really the only events that you want to be passing around on the Event Bus. The app is uninterested in events such as “the user clicked enter” or “an RPC is about to be made”. Instead (at least in our example app), we pass around events such as a contact being updated, the user switching to the edit view, or an RPC that deleted a user has successfully returned from the server.

Below is a list of the events that we have defined.

• AddContactEvent
• ContactDeletedEvent
• ContactUpdatedEvent
• EditContactCancelledEvent
• EditContactEvent

Each of these events will extend GwtEvent and override dispatch() and getAssociatedType(). Method dispatch() takes a single param of type EventHandler, and for our application we have defined handler interfaces for each of our events.

• AddContactEventHandler
• ContactDeletedEventHandler
• ContactUpdatedEventHandler
• EditContactCancelledEventHandler
• EditContactEventHandler

To demonstrate how these pieces fit together let’s look at what takes place when a user chooses to edit a contact. First we’ll need the AppController to register for the EditContactEvent. To do so, we call HandlerManager.addHandler() and pass in the GwtEvent.Type as well as the handler that should be called when the event is fired. The code below shows how the AppController registers to receive EditContactEvents.

public class AppController implements ValueChangeHandler {  ...  eventBus.addHandler(EditContactEvent.TYPE,      new EditContactEventHandler() {        public void onEditContact(EditContactEvent event) {          doEditContact(event.getId());        }      });  ...}

Here the AppController has an instance of the HandlerManager, called eventBus, and is registering a new EditContactEventHandler. This handler will grab the id of the contact to be edited, and pass it to the doEditContact() method whenever an event of EditContactEvent.getAssociatedType() is fired. Multiple components can be listening for a single event, so when an event is fired using the HandlerManager.fireEvent(), the HandlerManager looks for any component that has added a handler for event.getAssociatedType(). For each component that has a handler, the HandlerManager calls event.dispatch() with that component’s EventHandler interface.

To see how an event is fired, let’s take a look at the code that sources the EditContactEvent. As mentioned above, we’ve added ourselves as a click handler on the ListContactView’s list. Now when a user clicks on the contacts list, we’ll notify the rest of the app by calling the HandlerManager.fireEvent() method with a EditContactEvent() class that is initialized with the id of the contacts to be edited.

public class ContactsPresenter {  ...  display.getList().addClickHandler(new ClickHandler() {    public void onClick(ClickEvent event) {      int selectedRow = display.getClickedRow(event);              if (selectedRow >= 0) {        String id = contactDetails.get(selectedRow).getId();        eventBus.fireEvent(new EditContactEvent(id));      }    }  });  ...}

View transition is a proactive event flow, where the event source lets the rest of the app know, “Hey a view transition is about to take place, so if you have some last minute cleanup work to do, I’d suggest you do it now”. With RPC it’s a bit different. The event is fired when the RPC returns rather than before the RPC is made. The reason being is that the app is really only concerned when some state has changed (contact values changed, contact deleted, etc…), which is the case after the RPC has returned.

Below is an example of the event that is fired upon successfully updating a contact.

public class EditContactPresenter {  ...  private void doSave() {    contact.setFirstName(display.getFirstName().getValue());    contact.setLastName(display.getLastName().getValue());    contact.setEmailAddress(display.getEmailAddress().getValue());        rpcService.updateContact(contact, new AsyncCallback<Contact>() {        public void onSuccess(Contact result) {          eventBus.fireEvent(new ContactUpdatedEvent(result));        }        public void onFailure(Throwable caught) {           ...         }    });  }  ...}

History and view transitions

One of the more integral parts of any web app is the handling of history events. History events are token strings that represent some new state within your application. Think of them as “markers” for where you are in the application. Take, for example, a user navigating from the “Contact List” view to the “Add Contact” view and then clicking the “Back” button. The resulting action should land the user back on the “Contact List” view, and to do so you would push the initial state (the “Contact List” view) onto the history stack followed by a push of the “Add Contact” view. Thus when they click the back button the “Add Contact” token will be popped off of the stack and the current history token will be the “Contact List” view.

Now that we have the flow straight, we need to decide where to put the code. Given that history is not specific to a particular view, it makes sense to to add it to the AppController class.

To start with, we’ll need to have the AppController implement ValueChangeHandler and declare its own onValueChange() method. The interface and parameter are of type String because the History events are simply the tokens that are pushed onto the stack.

public class AppController implements ValueChangeHandler<String> {  ...  public void onValueChange(ValueChangeEvent<String> event) {    String token = event.getValue();    ...  }}

Next we’ll need to register to receive History events, much like we registered for events coming off of the EventBus.

public class AppController implements ValueChangeHandler<String> {  ...  private void bind() {    History.addValueChangeHandler(this);    ...  }}

In the example above, where the user navigates from the “Contact List” view to the “Add Contact” view, we mentioned setting an initial state. This is important because it not only gives us some starting point, but it’s also the piece of code that will check for an existing history token (for example, if a user bookmarked a specific state within your app) and route the user to the appropriate view. The AppController’s go() method, which is called after everything has been wired up, is where we’ll add this logic.

public class AppController implements ValueChangeHandler<String> {  ...  public void go(final HasWidgets container) {    this.container = container;

    if ("".equals(History.getToken())) {      History.newItem("list");    }    else {      History.fireCurrentHistoryState();    }  }}

With the above plumbing in place, we need to do something meaningful within the onValueChange() method that is called whenever the user clicks the “Back” or “Forward” button. Using the getValue() of the event, we’ll decide which view to show next.

public class AppController implements ValueChangeHandler<String> {  ...  public void onValueChange(ValueChangeEvent<String> event) {    String token = event.getValue();

    if (token != null) {      Presenter presenter = null;

      if (token.equals("list")) {        presenter = new ContactsPresenter(rpcService, eventBus, new ContactView());      }      else if (token.equals("add")) {        presenter = new EditContactPresenter(rpcService, eventBus, new EditContactView());      }      else if (token.equals("edit")) {        presenter = new EditContactPresenter(rpcService, eventBus, new EditContactView());      }

      if (presenter != null) {        presenter.go(container);      }    }}

Now when the user clicks the back button from the “Add Contact” view, GWT’s History mechanism will call the onValueChange() method with the previous history token. In our example the previous view was the “Contact List” view and the previous history token (which was set in the go() method) is “list”.

Handling history events in this manner isn’t limited to just “Back” and “Forward” handling, they can used for all view transitions. Going back to the AppController’s go() method, you’ll notice that we call fireCurrentHistoryState() if the current History token is not null. Thus if user specifies http://myapp.com/contacts.html#add, the initial history token will be “add” and fireCurrentHistoryState() will in turn call the onValueChange() with this token. This isn’t specific to just setting up the initial view with the app; other user interactions that result in a view transition can call History.newItem(), which will push a new history token onto the stack which will in turn trigger a call to onValueChange().

Below is an example of how you can hook up the ContactsPresenter to the “Add Contact” button, fire the associated event upon receiving the click, and transition to the “Add Contact” view as a result.

public class ContactsPresenter implements Presenter {  ...  public void bind() {    display.getAddButton().addClickHandler(new ClickHandler() {      public void onClick(ClickEvent event) {        eventBus.fireEvent(new AddContactEvent());      }    });  }}

public class AppController implements ValueChangeHandler<String> {  ...  private void bind() {    ...    eventBus.addHandler(AddContactEvent.TYPE,      new AddContactEventHandler() {        public void onAddContact(AddContactEvent event) {          doAddNewContact();        }    });  }

  private void doAddNewContact() {    History.newItem("add");  }}

Since the view transition logic is already built into the onValueChange() method, this provides a centralized, reusable way of navigating within the app.

Testing

The MVP model takes the pain out of unit testing a GWT app. That’s not to say that you can’t write unit tests without using the MVP model. In fact you can, but they will often times be slower than the average JRE-based JUnit test. Why? Well, in short, applications that don’t utilize the MVP model will require test cases that test components that rely on a DOM being present, a Javascript engine, etc… Essentially these test cases need to run in a browser.

GWT’s GWTTestCase makes this possible, as it will launch a “headless” browser to run each of the tests. The launching of the browser coupled with the actual execution of the test case is why these tests typically take longer than standard JRE tests. Within the MVP model, we strive to make a view, the component that encompasses the bulk of our code that relies on the DOM and Javascript engine, as small and as simplistic as possible. Less code equals less testing which means less time that it takes to actually run your tests. If the bulk of the code within your app is encompassed within a presenter, and that presenter relies strictly on JRE-based components, you can build the majority of your test cases as efficient, vanilla JUnit tests.

To demonstrate the benefits of using the MVP model to drive JRE-based unit tests, rather than those based on GWTTestCase, we’ve added the following tests to our Contacts app.

Each example is set up to test adding a list of ContactDetails, sorting those ContactDetails, and then verifying that the sorted list is correct. Taking a look at the ExampleJRETest, we have the following code.

public class ExampleJRETest extends TestCase {  private ContactsPresenter contactsPresenter;  private ContactsServiceAsync mockRpcService;  private HandlerManager eventBus;  private ContactsPresenter.Display mockDisplay;    protected void setUp() {    mockRpcService = createStrictMock(ContactsServiceAsync.class);    eventBus = new HandlerManager(null);    mockDisplay = createStrictMock(ContactsPresenter.Display.class);    contactsPresenter = new ContactsPresenter(mockRpcService, eventBus, mockDisplay);  }   public void testContactSort(){    List<ContactDetails> contactDetails = new ArrayList<ContactDetails>();    contactDetails.add(new ContactDetails("0", "c_contact"));    contactDetails.add(new ContactDetails("1", "b_contact"));    contactDetails.add(new ContactDetails("2", "a_contact"));    contactsPresenter.setContactDetails(contactDetails);    contactsPresenter.sortContactDetails();    assertTrue(contactsPresenter.getContactDetail(0).getDisplayName().equals("a_contact"));    assertTrue(contactsPresenter.getContactDetail(1).getDisplayName().equals("b_contact"));    assertTrue(contactsPresenter.getContactDetail(2).getDisplayName().equals("c_contact"));  }}

Because we have structured the view behind a Display interface, we’re able to mock it out (using EasyMock in this example), remove the need for access to the browser’s resources (DOM, Javascript engine, etc…), and avoid having to base our tests on GWTTestCase.

We then created the same test using GWTTestCase.

public class ExampleGWTTest extends GWTTestCase {  private ContactsPresenter contactsPresenter;  private ContactsServiceAsync rpcService;  private HandlerManager eventBus;  private ContactsPresenter.Display display;

  public String getModuleName() {    return "com.google.gwt.sample.contacts.Contacts";  }

  public void gwtSetUp() {    rpcService = GWT.create(ContactsService.class);    eventBus = new HandlerManager(null);    display = new ContactsView();    contactsPresenter = new ContactsPresenter(rpcService, eventBus, display);  }

  public void testContactSort(){    List<ContactDetails> contactDetails = new ArrayList<ContactDetails>();    contactDetails.add(new ContactDetails("0", "c_contact"));    contactDetails.add(new ContactDetails("1", "b_contact"));    contactDetails.add(new ContactDetails("2", "a_contact"));    contactsPresenter.setContactDetails(contactDetails);    contactsPresenter.sortContactDetails();    assertTrue(contactsPresenter.getContactDetail(0).getDisplayName().equals("a_contact"));    assertTrue(contactsPresenter.getContactDetail(1).getDisplayName().equals("b_contact"));    assertTrue(contactsPresenter.getContactDetail(2).getDisplayName().equals("c_contact"));  }}

Given that our app was designed using the MVP model, it realistically makes no sense to structure your tests like this. But that’s not the point. The point is that ExampleGWTTest takes 15.23 secs to run, whereas the lightweight ExampleJRETest takes 0.01 secs. If you can manage to decouple app logic from widget-based code, your unit tests will be much more efficient. Imagine these numbers applied across the board to the hundreds of automated tests that are run on each build.

For more information on testing and the MVP model, checkout the article, Testing Methodologies Using Google Web Toolkit.

Follow-up topics

The MVP architecture is expansive; in future articles we look to discuss the following concepts:

• UI Binder and MVP
• Code splitting an MVP-based app
• Using Gin to reduce code and facilitate testing

GWT 2.1 introduced a built-in framework for browser history management. The Activities and Places framework allows you to create bookmarkable URLs within your application, thus allowing the browser’s back button and bookmarks to work as users expect. It builds on GWT’s history mechanism and may be used in conjunction with MVP development, though not required.

Strictly speaking, MVP architecture is not concerned with browser history management, but Activities and Places may be used with MVP development as shown in this article. If you’re not familiar with MVP, you may want to read these articles first:

• Large scale application development and MVP, Part I
• Large scale application development and MVP, Part II

Definitions

An activity simply represents something the user is doing. An Activity contains no Widgets or UI code. Activities typically restore state (“wake up”), perform initialization (“set up”), and load a corresponding UI (“show up”). Activities are started and stopped by an ActivityManager associated with a container Widget. An Activity can automatically display a warning confirmation when the Activity is about to be stopped (such as when the user navigates to a new Place). In addition, the ActivityManager warns the user before the window is about to be closed.

A place is a Java object representing a particular state of the UI. A Place can be converted to and from a URL history token (see GWT’s History mechanism) by defining a PlaceTokenizer for each Place, and GWT’s PlaceHistoryHandler automatically updates the browser URL corresponding to each Place in your app.

You can download all of the code referenced here in this sample app. The sample app is a simple “Hello, World!” example demonstrating the use of Activities and Places with MVP.

Let’s take a look at each of the moving parts in a GWT 2.1 app using Places and Activities.

1. Views
2. ClientFactory
3. Activities
4. Places
5. PlaceHistoryMapper
6. ActivityMapper

Then we’ll take at how you wire it all together and how it works.

1. Putting it all together
2. How it all works
3. How to navigate
4. Related resources

Views

A view is simply the part of the UI associated with an Activity. In MVP development, a view is defined by an interface, which allows multiple view implementations based on client characteristics (such as mobile vs. desktop) and also facilitates lightweight unit testing by avoiding the time-consuming GWTTestCase. There is no View interface or class in GWT which views must implement or extend; however, GWT 2.1 introduces an IsWidget interface that is implemented by most Widgets as well as Composite. It is useful for views to extend IsWidget if they do in fact provide a Widget. Here is a simple view from our sample app.

public interface GoodbyeView extends IsWidget {    void setName(String goodbyeName);}

The corresponding view implementation extends Composite, which keeps dependencies on a particular Widget from leaking out.

public class GoodbyeViewImpl extends Composite implements GoodbyeView {    SimplePanel viewPanel = new SimplePanel();    Element nameSpan = DOM.createSpan();

    public GoodbyeViewImpl() {        viewPanel.getElement().appendChild(nameSpan);        initWidget(viewPanel);    }

    @Override    public void setName(String name) {        nameSpan.setInnerText("Good-bye, " + name);    }}

Here is a slightly more complicated view that additionally defines an interface for its corresponding presenter (activity).

public interface HelloView extends IsWidget {    void setName(String helloName);    void setPresenter(Presenter presenter);

    public interface Presenter {        void goTo(Place place);    }}

The Presenter interface and setPresenter method allow for bi-directional communication between view and presenter, which simplifies interactions involving repeating Widgets and also allows view implementations to use UiBinder with @UiHandler methods that delegate to the presenter interface.

The HelloView implementation uses UiBinder and a template.

public class HelloViewImpl extends Composite implements HelloView {        private static HelloViewImplUiBinder uiBinder = GWT                        .create(HelloViewImplUiBinder.class);

        interface HelloViewImplUiBinder extends UiBinder {        }

        @UiField        SpanElement nameSpan;        @UiField        Anchor goodbyeLink;        private Presenter presenter;        private String name;

        public HelloViewImpl() {                initWidget(uiBinder.createAndBindUi(this));        }

        @Override        public void setName(String name) {                this.name = name;                nameSpan.setInnerText(name);        }

        @UiHandler("goodbyeLink")        void onClickGoodbye(ClickEvent e) {                presenter.goTo(new GoodbyePlace(name));        }

        @Override        public void setPresenter(Presenter presenter) {                this.presenter = presenter;        }}</WIDGET,>

Note the use of @UiHandler that delegates to the presenter. Here is the corresponding template:

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent"><ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"                         xmlns:g="urn:import:com.google.gwt.user.client.ui">        <ui:style>                .important {                        font-weight: bold;                }        </ui:style>        <g:HTMLPanel>                Hello,                <span class="{style.important}" ui:field="nameSpan" />                <g:Anchor ui:field="goodbyeLink" text="Say good-bye"></g:Anchor>        </g:HTMLPanel></ui:UiBinder>

Because Widget creation involves DOM operations, views are relatively expensive to create. It is therefore good practice to make them reusable, and a relatively easy way to do this is via a view factory, which might be part of a larger ClientFactory.

ClientFactory

A ClientFactory is not required to use Activities and Places; however, it is helpful to use a factory or dependency injection framework like GIN to obtain references to objects needed throughout your application like the event bus. Our example uses a ClientFactory to provide an EventBus, GWT PlaceController, and view implementations.

public interface ClientFactory {    EventBus getEventBus();    PlaceController getPlaceController();    HelloView getHelloView();    GoodbyeView getGoodbyeView();}

Another advantage of using a ClientFactory is that you can use it with GWT deferred binding to use different implementation classes based on user.agent or other properties. For example, you might use a MobileClientFactory to provide different view implementations than the default DesktopClientFactory. To do this, instantiate your ClientFactory with GWT.create in onModuleLoad(), like this:

    ClientFactory clientFactory = GWT.create(ClientFactory.class);

Specify the implementation class in .gwt.xml:

    <!-- Use ClientFactoryImpl by default -->    <replace-with class="com.hellomvp.client.ClientFactoryImpl">    <when-type-is class="com.hellomvp.client.ClientFactory"/>    </replace-with>

You can use <when-property-is> to specify different implementations based on user.agent, locale, or other properties you define. The mobilewebapp sample application defines a “formfactor” property used to select a different view implementations for mobile, tablet, and desktop devices.

Here is a default implementation of ClientFactory for the sample app:

public class ClientFactoryImpl implements ClientFactory {    private final EventBus eventBus = new SimpleEventBus();    private final PlaceController placeController = new PlaceController(eventBus);    private final HelloView helloView = new HelloViewImpl();    private final GoodbyeView goodbyeView = new GoodbyeViewImpl();

    @Override    public EventBus getEventBus() {        return eventBus;    }    ...}

Activities

Activity classes implement com.google.gwt.activity.shared.Activity. For convenience, you can extend AbstractActivity, which provides default (null) implementations of all required methods. Here is a HelloActivity, which simply says hello to a named user:

public class HelloActivity extends AbstractActivity implements HelloView.Presenter {    // Used to obtain views, eventBus, placeController    // Alternatively, could be injected via GIN    private ClientFactory clientFactory;    // Name that will be appended to "Hello,"    private String name;

    public HelloActivity(HelloPlace place, ClientFactory clientFactory) {        this.name = place.getHelloName();        this.clientFactory = clientFactory;    }

    /**     * Invoked by the ActivityManager to start a new Activity     */    @Override    public void start(AcceptsOneWidget containerWidget, EventBus eventBus) {        HelloView helloView = clientFactory.getHelloView();        helloView.setName(name);        helloView.setPresenter(this);        containerWidget.setWidget(helloView.asWidget());    }

    /**     * Ask user before stopping this activity     */    @Override    public String mayStop() {        return "Please hold on. This activity is stopping.";    }

    /**     * Navigate to a new Place in the browser     */    public void goTo(Place place) {        clientFactory.getPlaceController().goTo(place);    }}

The first thing to notice is that HelloActivity makes reference to HelloView, which is a view interface, not an implementation. One style of MVP coding defines the view interface in the presenter. This is perfectly legitimate; however, there is no fundamental reason why an Activity and it’s corresponding view interface have to be tightly bound together. Note that HelloActivity also implements the view’s Presenter interface. This is used to allow the view to call methods on the Activity, which facilitates the use of UiBinder as we saw above.

The HelloActivity constructor takes two arguments: a HelloPlace and the ClientFactory. Neither is strictly required for an Activity. The HelloPlace simply makes it easy for HelloActivity to obtain properties of the state represented by HelloPlace (in this case, the name of the user we are greeting). Accepting an instance of a HelloPlace in the constructor implies that a new HelloActivity will be created for each HelloPlace. You could instead obtain an activity from a factory, but it’s typically cleaner to use a newly constructed Activity so you don’t have to clean up any prior state. Activities are designed to be disposable, whereas views, which are more expensive to create due to the DOM calls required, should be reusable. In keeping with this idea, ClientFactory is used by HelloActivity to obtain a reference to the HelloView as well as the EventBus and PlaceController.

The start method is invoked by the ActivityManager and sets things in motion. It updates the view and then swaps the view back into the Activity’s container widget by calling setWidget.

The non-null mayStop() method provides a warning that will be shown to the user when the Activity is about to be stopped due to window closing or navigation to another Place. If it returns null, no such warning will be shown.

Finally, the goTo() method invokes the PlaceController to navigate to a new Place. PlaceController in turn notifies the ActivityManager to stop the current Activity, find and start the Activity associated with the new Place, and update the URL in PlaceHistoryHandler.

Places

In order to be accessible via a URL, an Activity needs a corresponding Place. A Place extends com.google.gwt.place.shared.Place and must have an associated PlaceTokenizer which knows how to serialize the Place’s state to a URL token. By default, the URL consists of the Place’s simple class name (like “HelloPlace”) followed by a colon (:) and the token returned by the PlaceTokenizer.

public class HelloPlace extends Place {    private String helloName;

    public HelloPlace(String token) {        this.helloName = token;    }

    public String getHelloName() {        return helloName;    }

    public static class Tokenizer implements PlaceTokenizer<HelloPlace> {        @Override        public String getToken(HelloPlace place) {            return place.getHelloName();        }

        @Override        public HelloPlace getPlace(String token) {            return new HelloPlace(token);        }    }}

It is convenient (though not required) to declare the PlaceTokenizer as a static class inside the corresponding Place. However, you need not have a PlaceTokenizer for each Place. Many Places in your app might not save any state to the URL, so they could just extend a BasicPlace which declares a PlaceTokenizer that returns a null token.

PlaceHistoryMapper

PlaceHistoryMapper declares all the Places available in your app. You create an interface that extends PlaceHistoryMapper and uses the annotation @WithTokenizers to list each of your tokenizer classes. Here is the PlaceHistoryMapper in our sample:

@WithTokenizers({HelloPlace.Tokenizer.class, GoodbyePlace.Tokenizer.class})public interface AppPlaceHistoryMapper extends PlaceHistoryMapper{}

At GWT compile time, GWT generates (see PlaceHistoryMapperGenerator) a class based on your interface that extends AbstractPlaceHistoryMapper. PlaceHistoryMapper is the link between your PlaceTokenizers and GWT’s PlaceHistoryHandler that synchronizes the browser URL with each Place.

For more control of the PlaceHistoryMapper, you can use the @Prefix annotation on a PlaceTokenizer to change the first part of the URL associated with the Place. For even more control, you can instead implement PlaceHistoryMapperWithFactory and provide a TokenizerFactory that, in turn, provides individual PlaceTokenizers.

ActivityMapper

Finally, your app’s ActivityMapper maps each Place to its corresponding Activity. It must implement ActivityMapper, and will likely have lots of code like “if (place instanceof SomePlace) return new SomeActivity(place)”. Here is the ActivityMapper for our sample app:

public class AppActivityMapper implements ActivityMapper {    private ClientFactory clientFactory;

    public AppActivityMapper(ClientFactory clientFactory) {        super();        this.clientFactory = clientFactory;    }

    @Override    public Activity getActivity(Place place) {        if (place instanceof HelloPlace)            return new HelloActivity((HelloPlace) place, clientFactory);        else if (place instanceof GoodbyePlace)            return new GoodbyeActivity((GoodbyePlace) place, clientFactory);        return null;    }}

Note that our ActivityMapper must know about the ClientFactory so it can provide it to activities as needed.

Putting it all together

Here’s how all the pieces come together in onModuleLoad():

public class HelloMVP implements EntryPoint {    private Place defaultPlace = new HelloPlace("World!");    private SimplePanel appWidget = new SimplePanel();

    public void onModuleLoad() {        ClientFactory clientFactory = GWT.create(ClientFactory.class);        EventBus eventBus = clientFactory.getEventBus();        PlaceController placeController = clientFactory.getPlaceController();

        // Start ActivityManager for the main widget with our ActivityMapper        ActivityMapper activityMapper = new AppActivityMapper(clientFactory);        ActivityManager activityManager = new ActivityManager(activityMapper, eventBus);        activityManager.setDisplay(appWidget);

        // Start PlaceHistoryHandler with our PlaceHistoryMapper        AppPlaceHistoryMapper historyMapper= GWT.create(AppPlaceHistoryMapper.class);        PlaceHistoryHandler historyHandler = new PlaceHistoryHandler(historyMapper);        historyHandler.register(placeController, eventBus, defaultPlace);

        RootPanel.get().add(appWidget);        // Goes to the place represented on URL else default place        historyHandler.handleCurrentHistory();    }}

How it all works

The ActivityManager keeps track of all Activities running within the context of one container widget. It listens for PlaceChangeRequestEvents and notifies the current activity when a new Place has been requested. If the current Activity allows the Place change (Activity.onMayStop() returns null) or the user allows it (by clicking OK in the confirmation dialog), the ActivityManager discards the current Activity and starts the new one. In order to find the new one, it uses your app’s ActivityMapper to obtain the Activity associated with the requested Place.

Along with the ActivityManager, two other GWT classes work to keep track of Places in your app. PlaceController initiates navigation to a new Place and is responsible for warning the user before doing so. PlaceHistoryHandler provides bi-directional mapping between Places and the URL. Whenever your app navigates to a new Place, the URL will be updated with the new token representing the Place so it can be bookmarked and saved in browser history. Likewise, when the user clicks the back button or pulls up a bookmark, PlaceHistoryHandler ensures that your application loads the corresponding Place.

How to navigate

To navigate to a new Place in your application, call the goTo() method on your PlaceController. This is illustrated above in the goTo() method of HelloActivity. PlaceController warns the current Activity that it may be stopping (via a PlaceChangeRequest event) and once allowed, fires a PlaceChangeEvent with the new Place. The PlaceHistoryHandler listens for PlaceChangeEvents and updates the URL history token accordingly. The ActivityManager also listens for PlaceChangeEvents and uses your app’s ActivityMapper to start the Activity associated with the new Place.

Rather than using PlaceController.goTo(), you can also create a Hyperlink containing the history token for the new Place obtained by calling your PlaceHistoryMapper.getToken(). When the user navigates to a new URL (via hyperlink, back button, or bookmark), PlaceHistoryHandler catches the ValueChangeEvent from the History object and calls your app’s PlaceHistoryMapper to turn the history token into its corresponding Place. It then calls PlaceController.goTo() with the new Place.

What about apps with multiple panels in the same window whose state should all be saved together in a single URL? You can accomplish this by using an ActivityManager and ActivityMapper for each panel. Using this technique, a Place can be mapped to multiple activities. For further examples, see the resources below.

使用Google App Engine平台做了个网站www.stock-reminder.com，功能就是服务器轮询当前股价，越过警戒就会向手机邮箱发送邮件，前台还有个web界面做配置。通过这个网站学到了不少新东西。

首先是学会了java语言，我会用的编程语言现在包括了C、C++、C#、Delphi、VB、php，现在又加上java，当前的主流语言都碰了。Java让用多了C风格语言的我感觉很怪异，它没什么阻塞的操作，使用addListener添加监听，程序里面有很多new出来的Listener。

其次就是GWT，我还使用了EXT-GWT，通过强语言编写网页比用HTML写网页感觉容易一些，用HTML写的话会很快迷失在一大堆HTML标签里面，还有CSS和布局，有时候元素直接差几个像素就是去不掉，我毕竟不是专业写网页的。通过GWT直接使用Layout布局（当然最后还是会编译成HTML和javascript），还用了EXT-GWT的MVC模式，感觉很不错，准备用GWT的MVP模式重构一下。

还有就是GAE提供DataStore，任务队列，用作服务器端的保存配置和轮询股价，发邮件则是我自己写的一个API调用我的空间上的一个mail程序，GAE的发邮件配额每天只有100封。

Java程序感觉对设计模式要求很高，这个网站的结构我不大满意调整了好几次，感觉还是有可以优化的地方。

    创建一个使用AppEngine的GWT工程，出现如下错误：

Exception in thread “main” java.lang.NoSuchMethodError: org.mortbay.thread.Timeout.<init>(Ljava/lang/Object;)V
    at org.mortbay.io.nio.SelectorManager$SelectSet.<init>(SelectorManager.java:306)
    at org.mortbay.io.nio.SelectorManager.doStart(SelectorManager.java:223)
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
    at org.mortbay.jetty.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:303)
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
    at org.mortbay.jetty.Server.doStart(Server.java:233)
    at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
    at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:667)
    at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:500)
    at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1055)
    at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:804)
    at com.google.gwt.dev.DevMode.main(DevMode.java:309)

解决方法：在项目的build path里面，把GWT SDK移到App Engine SDK前面。