alt
August 26th, 2012

Written by Stoyan Rachev

I recently created Todor, a simple Web-based Todo list application based on Google Web Toolkit. This is my second entry for an ongoing internal contest at SAP, after Feeder. Again, my main goal was not to simply satisfy the contest requirements, but rather to explore and showcase the best architecture principles and programming practices of the chosen technology. In this case, these are Model-View-Presenter (MVP), shared domain model, HTML5 local storage, declarative UI, client-server communication, JDO-based persistence, and unit testing.

The contest task demanded creating a Todo list application which runs locally in the browser and uses HTML5 features such as local storage, without any backend. Participants were free to choose whatever HTML5 / JavaScript frameworks they wanted. I personally chose GWT as it allowed me to create the application entirely in Java using modern design principles (MVP). I also decided to add a JDO-based backend for GAE to end up with a real Web application which offers basic but still useful functionality.

The application is deployed on Google App Engine and available at http://todor.stoyanr.com.

You can explore the source code on github. There is also a Wiki which highlights the most intersting parts. Feedback, comments, and contributions are welcome!

Main View

Application Features

  • Add, edit, and delete Todo items that have description, priority, and status.
  • Track the dates of creation and last update for each Todo item.
  • Sort Todo items by id, priority, status, creation date or last update date.
  • Work in your browser and save your items to the backend with a button click.
  • Load your items from the backend automatically upon startup, if the last save is newer than your local changes.
  • Work offline if the backend is temporarily unavailable.
  • Restart your browser and your unsaved items are still there, ready to be saved.
  • Sign-in with your Google account to edit your personal Todo list.

Programming Highlights

  • Uses the MVP design pattern according to the principles outlined in Large scale application development and MVP.
  • A shared domain model is used both on the client and the server.
  • Takes advantage of HTML5 local storage to store Todo documents and items locally in the browser, leveraging GWT’s full HTML5 Storage support.
  • The UI is expressed declaratively as HTML pages with GWT widgets sprinkled throughout them by using UiBinder, which is a more natural and efficient way to build a Web-based UI than doing it through code.
  • Uses RPC client-server communication following the guidelines in Communicate with a Server to send local data to the backend in order to store it centrally, and retrieve centrally stored data.
  • Uses JDO-based persistence in GAE as explained in Using JDO to persist Todo documents and items on the backend.

For more highlihts, as well as known issues / TODOs, see Todor’s Wiki.

MVP Architecture

At the heart of the MVP design pattern is the separation of application logic (presenter) from the UI presentation (view). It is recommended when developing GWT apps for the following reasons:

  • Decouples development in a way that allows multiple developers to work simultaneously.
  • Allows writing lightweight and fast JRE unit tests which don’t require a browser.
  • Allows creating different views for different devices that share the same presenter logic

The main classes and interfaces of Todor and their separation into model, view, and presenter are presented in the class diagram below.

MVP Architecture

For more information, see our MVP Architecture Wiki page.

Shared Domain Model Classes

Domain model classes in Todor are Todo items and documents. Todo items have an id, text, status, priority, creation and last update dates. Documents are just collections of Todo items of particular users, and they also track the last time the collection was saved to the backend.

The model classes in Todor are shared between the client and the server. Being able to use the same domain model on the client and the server is a major advantage of GWT over other frameworks for creating rich internet applications, as it eliminates the redundant code and additional complexity from expressing and maintaining the same domain model more than once, potentially even using different programming languages.

This capability is not completely granted, however, as GWT model classes are subject to various requirements which have to be fulfilled in order to be able to:

  • compile the model to JavaScript for use on the client
  • serialize model objects for use in RPC client / server communication
  • persist model objects on the backend via JDO

Due to the above, one should follow certain guidelines in order to gain this capability. For more information, see our Domain Model Classes Wiki page.

Credits

When starting the project, I found a number of blog posts and open source projects on this topic: