The Anatomy of a GWT Project

What is GWT?

I guess a little background first for the uninitiated.  Formally known as Google Web Toolkit, is a project that allows you to write your webcode in Java and then it transpiles (source-to-source compile) the java code into JavaScript.    This allows you to develop an application that run using JavaScript (which is everywhere) without the nightmare of actually writing (or reading) JavaScript.

The largest bonus is that you get to use all of the great and wonderful tooling that comes with Java.  Say what you will about the language itself, but the Java language has some of the best tooling around (code coverage, unit testing, dependency injection, mockito, eclipse, etc…) and access to these tools and the really nice patterns that have been developed in Java make development very productive.

From the GWT manual

Java technologies offer a productive development platform, and with GWT, they can instantly become the basis of your AJAX development platform as well. Here are some of the benefits of developing with GWT:

• You can use all of your favorite Java development tools for AJAX development.
• Static type checking in the Java language boosts productivity while reducing errors.
• Common JavaScript errors (typos, type mismatches) are easily caught at compile time rather than by users at runtime.
• Code prompting/completion is widely available.
• Automated Java refactoring is pretty snazzy these days.
• Java-based OO designs are easier to communicate and understand, thus making your AJAX code base more comprehensible with less documentation.

What about browser differences?

We all know that IE has a tendency to be a bit of a pain in the backside when it comes to making you site look and behave like other browsers, it is really no difference when it comes to the JavaScript in the browser.  Fortunately GWT compiles multiple permutations of your application, once for each browser dialect and then at runtime it serves the right version.  So everything works the same  between browsers.

The Anatomy of an Application

As with any toolkit or framework once you have it you are free to shoot yourself in the foot with it, so Google generally gives many talks on GWT Best Practices at their annual IO conference.  Back in 2009 Ray Ryan gave a talk about the architecture of an application. It is a great video and I still suggest that people watch it.  It is interesting because during his talk he referenced a number of technologies and concepts that weren’t incorporated into the toolkit yet.  Then they were released as libraries that you could pull in, then some of them were promoted to be stock members of the toolkit.

So now in 2013 I thought I would take a look back at the best practices and talk about the current state of thing.

UIBinder (Declarative UI, MVP)

This is a big one, and one of my favorite upgrades to GWT from its initial versions.  When you are writing a webapp, it is unnatural to use anything other than HTML and CSS.  The UIBinder allows you to do just that you can layout all of the panels and widgets using quasi-normal markup.  This really helps when you are working with designers that aren’t going to be the ones that actually code the application, because you can reuse their designs and styles directly in the application.

More can be read about the UIBinder here: http://www.gwtproject.org/doc/latest/DevGuideUiBinder.html

Gin (IoC)

Once I had experienced a dependency injector I no longer can remember living without it, it was a very trans-formative event in my professional career.  On the server side I like to use Guice as my IoC container, and the good thing is that for the client side they have GIN.  GIN is great because it supports most all of the same semantics of Guice, but is stripped down for the client side.  The primary difference is that GIN does all of its injection at compile time, so you can’t do runtime substitutions of classes, but that isn’t something that I have ever really wanted to do on the client.

This way you can write all of you classes the way you normally would so they are accessible and easy to unit test and then allow the injector to wire it all up for you.

GWT Dispatch (Command Pattern)

This is one of the patterns/libraries that  I really like.  I know several developers that prefer the stock GWT RPC, but I always hate defining all of the servlets require.  The GWT Dispatch library implements the command pattern where you define a series of Actions that are serialized (automatically) and corresponding ActionHandlers on the server.   For me this is a much cleaner pattern and much easier to extend, and because it all shares the same servlet endpoint it is much easier to refactor.   Also if you use this pattern, you get the ability to do call batching for free (its built in) and you are 80% of the way to have an undo stack.  Each Action handler allows you to define rollbacks for actions, its just up to you on how you want to track the stack.
Read More about the command pattern here.

History, Activities, and Places

This is where it all comes together.  The key to writing a successful client side application, is how you structure it so that the back button works.  I hate it when I see developers tell clients that they can’t use the browsers back button, or have to build their own back button into the application.   As of version 2.1 (which was a while ago) GWT started to build tools that would help with history tracking, and that was nice but for a long time it was still largely up to the developers to figure out.  Then they added support for Places and Activities.

I believe this is the most important page in their manual, and the concept that people should spend the most time understanding.  Mastering the Activity and Place controllers will allow you to easily use the tools outlined above while achieving auto-magic support for history tokens and the back button (as well as bookmarks etc..)

I have built many different applications that use the methods outlined about and am excited to see how the toolkit will continue to evolve to make programming large scale ajax applications more pervasive and less painful in the future.