Stoyan Rachev edited this page Aug 26, 2012 · 12 revisions
Clone this wiki locally


Todor is a simple Web-based Todo list application, based on Google Web Toolkit. One of its most prominent features is using HTML5 local storage to enable offline editing of Todo items. It showcases GWT architecture principles and programming practices such as Model-View-Presenter (MVP), shared domain model, HTML5 local storage, declarative UI, client-server communication, JDO-based persistence, and unit testing.

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

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.


Similarly to Feeder, Todor was originally created in July / August 2012 for an internal "geeks" contest at SAP. 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.


When starting this project, I found a number of blog posts and open source projects on this topic. I learned a lot from examining their code and the chosen approaches. However, Todor was written from scratch and is only vaguely similar to any of them:

Programming Highlights

  • Uses the MVP design pattern according to the principles outlined in Large scale application development and MVP. MVP both decouples development in a way that allows multiple developers to work simultaneously, and also allows to write lightweight and fast JRE unit tests which don't require a browser. See MVP Architecture for more information.
  • A shared domain model is used both on the client and the server. With GWT, it is possible to create domain model classes that comply to requirements from both sides - compilable to JavaScript for use on the client, serializable to serve as data transfer objects in RPC calls, and appropriately annotated with JDO annotations for JDO-based persistence. See Domain Model Classes for more information.
  • Takes advantage of HTML5 local storage to store Todo documents and items locally in the browser, leveraging GWT's full HTML5 Storage support. Since the local storage allows storing only string key / value pairs, and Todo items are somewhat more complex than simple strings, each Todo item is serialized to JSON before storing it.
  • 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.
  • There are unit tests for all utility and presenter client-side classes based on best practices for JUnit testing in GWT.
  • The code is extremely clean, well-structured, and easy to read. Formatting, naming, and comments are uniform and consistent, as well as exception handling and logging. There are no commented-out lines of code. A lot of attention has been put in the proper partitioning of the application into classes and packages and appropriate use of object-oriented and declarative techniques such as inheritance and annotations.

Read more:

Known Issues / TODOs

  • Layout and styles could be improved a lot.
  • Additional views for smaller screens (mobile devices) could be added.
  • More unit tests could be added, especially the views and the backend services are currently not covered by unit tests.
  • No Maven build.