How I made my GWT/AppEngine application appear to load quicker

It’s a well known “feature” of AppEngine for Java that if your application does not retrieve much traffic, it’ll be unloaded to free resources for other applications. When your application does receive a visitor, your java application must be started. This is referred to as a “cold start”.

Jakob Nielsen’s Usability Engineering guidelines state that for any delay of greater than 1 second feedback is required. A GWT application running on Google AppEngine takes much longer than 1 second to get started. My GWT 2.0 application takes about 7 seconds from cold, or about 4 seconds on a warm AppEngine.

The following describes how I made my AppEngine application appear to load faster, without losing the XSRF protection provided by the gwt-platform framework.

Previously, when I loaded my app, my browser would show a blank page for about 7 seconds while the main html page loaded. To improve the user experience, I wanted to show the user a “fake” progress indicator that makes it seem like something was happening while the application is loading. (Something like every second, % complete += (15% of percentage incomplete). If % complete > 95, then % complete = 50. Gmail used this same pattern when loading. For more discussion on progress indicators, see

In my main html file, I moved the script tag that included my .nocache.js from the head, to the bottom of the body.

Above this script tag I added some javascript that renders my progress bar, and use setTimeout to update it every second. The progress bar will continue to update as the javascript is loaded in background, and once my application is ready to be loaded I hide the progress bar in revealInParent() of my top-level presenter. By ordering things this way, my progress bar was displayed first and then the browser made the request to AppEngine to load the .nocache.js file.

Main HTML page

<!doctype html>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
    <div id="loading" style="display: none">
      <div id="progressbar" style="margin: 15px; width: 300px; height: 10px; border: 2px solid black; overflow: hidden;">
      <div id="progress" style="background: silver; height: 100%; width: 0;"></div>
        <script type="text/javascript">
          var loading = document.getElementById('loading');
          var progress = document.getElementById('progress');
          var progressbar = document.getElementById('progressbar');
          function updateProgress() {
            if( !== 'none') {
              var width = parseInt(progress.offsetWidth+((progressbar.offsetWidth-progress.offsetWidth)*.15));
              if(width > (progressbar.offsetWidth * .95)) {
                width = parseInt(progressbar.offsetWidth) * .5;
     = width + 'px';
              window.setTimeout("updateProgress()", 1000);
 = 0;
 = 0;
 = 'block';
      <iframe src="javascript:''" id="__gwt_historyFrame" tabIndex='-1' style="position: absolute; width: 0; height: 0; border: 0"></iframe>
        <div style="width: 22em; position: absolute; left: 50%; margin-left: -11em; color: red; background-color: white; border: 1px solid red; padding: 4px; font-family: sans-serif">
          Your web browser must have JavaScript enabled in order for this application to display correctly.
    <script type="text/javascript" language="javascript" src="myapp/myapp.nocache.js"></script>

public class AppPresenterImpl extends ...
  // ...
  protected void revealInParent() {
    DOM.setStyleAttribute(RootPanel.get("loading").getElement(), "display", "none");, this);
// ...

To return the main html before the java application starts, the main html file needs to be a static file, as App Engine serves static files from dedicated servers that are separate from the java application servers. Previously I used the code that was suggested in the wiki for XSRF protection, however this would no longer work as my main html file will be static and served from a different server.

  • Send cookie to client attached to  .nocache.js

public class DispatchServletModule extends ServletModule {
  public void configureServlets() {
    serve("/myapp/" + ActionImpl.DEFAULT_SERVICE_NAME + "*")


  • Aggressively cache index.html and *.cache.*
  • I use gwt-math which puts some javascript files in /myapp/js/, this should be served statically
  • Don’t cache *.nocache.*
  • *.gwt.rpc is required for gwt-rpc serialization
<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="">
    <include path="index.html" expiration="30d" />
    <include path="myapp/**.cache.*" expiration="30d" />
    <include path="myapp/js/*.js" expiration="30d" />
    <include path="myapp/*.gwt.rpc" />
    <include path="myapp/*.nocache.*" />

Using a combination of the above techniques has improved my application so that:

  • Users get feedback almost instantly when they first browse to my application (about 0.4s according to Firebug)
  • The security cookie is still provided to the client (Firecookie shows the cookie was sent to the client in the headers and saved when was retrieved).
  • Aggressive caching settings means that everything that it makes sense to cache, is cached.

We’re going to use Maven

Well, we’re going to take a little longer to set up the project since we decided to use Maven !

Here are some words that Richard Allen posted on the Gwt-Platform group. This convinced us.

We have a large codebase with many projects that share a large amount of code housed in other projects. I used Ant for several years, but became frustrated with how much effort was required to maintain the whole build environment, and how I was regularly having to create custom solutions for things, like dependency management, that I felt should be the tool’s responsibility. I migrated all of our projects to Maven2 several years ago and have been very pleased. Maven is by no means perfect, so it will frustrate you at times. Maven lets you work at a higher level than Ant. Maven provides a lifecycle with phases such as compile, package, and integration-test, where as Ant provides low level tasks that you have to compose into the “phases” that Maven provides. Working at a higher level reduces your workload most of the time, but is a source of frustration when you need to work at a lower level. However, you can simply use the maven-antrun-plugin to run a set of Ant tasks when you want to work at a low level. And you can always write your own plugins to do anything you want. You can also write plugins in Groovy, which we have found to be easier. BTW, Maven3 is adding some nice scripting capabilities.

Maven has greatly reduced the overall maintenance of our build environment, as well as provided many features we didn’t have with Ant. Maven draws a lot of information from your POM files, and there’s much more to Maven than simply a build tool. Here are some of the benefits I believe you would derive from using Maven.

  • Very powerful dependency management. Maven makes it easy to handle your dependencies on third-party libraries, as well as dependencies on other projects that you maintain. Tools like m2eclipse and the maven-dependency-plugin, as well as the dependency reports generated by the maven-project-info-reports-plugin are invaluable when you want to see all your projects’ dependencies, their versions, and the licenses for your third-party dependencies. The dependency reports are great for open source projects because they provide your users (or potential users) an easy way to see what your project depends on while being very simple for you to produce and maintain.
  • Consistent project structure. Sure, you could devise your own project structure that you consistently used among all of your projects, but Maven already provides one that works well, and anyone that has used Maven before will immediately understand your project layout. Like I said, we have many projects, and it’s great that our developers can switch between projects without having to learn something new about the build environment. I love it when open source projects that I use also use Maven, because I can immediately build their project or import it into Eclipse. If they use Ant, it’s a toss up. Some are easy to build and import, others aren’t. There is no consistency.
  • Simple release management. I haven’t used Maven with Mercurial, but I see it supports it. Having used Maven with Subversion, I know Maven makes it very simple to make a release of your project and publish it to a Maven repository for public access, making your release process consistent and easy, as apposed to the error-prone process that many projects use. Maven’s release tools will ensure your code is committed to your source control and that your code passes all of its tests before making a release, and will automatically update the version numbers in the POM files for you. Additionally, you can create a report of changes from your source control system and/or a report of the fixed issues from your issue management system, like JIRA, that went into the release. This is where you start to see that Maven is a whole lot more than just a build tool.
  • Simple integration with unit testing tools and static analysis tools. Maven makes it easy to run your unit tests and integration tests, generate test coverage reports, run static analysis tools such as Checkstyle, PMD, FindBugs, JavaNCSS, and JDepend, and publish those reports to a website. These tools can be helpful to gage the overall quality of your code.
  • Simple reporting and website generation. I’ve already mentioned some Maven reporting capabilities, but Maven also has a general website generation tool. You can write a website in a wiki-like language and pull in all the reports that you generated. Some other reports that are important for projects to publish, which Maven makes easy, are Javadocs, browsable source code, and information on the project’s license, mailing list, source code repository, issue tracking system, the Maven plugins used for building the project, and the list developers.
  • Repository manager. The concept that Maven uses of storing dependencies and associated metadata in a repository instead of a source control system is a huge benefit. You can use a repository manager to cache all third-party dependencies that you get from the Internet to provide your group a stable repository, deploy your own projects (and custom
    Maven plugins) for other developers in your company to use, and even restrict what versions and libraries developers can pull into projects by making the build only get its dependencies from the repository manager.
  • Now, as for using Maven with Eclipse, you have three options. You can use one of two Eclipse plugins, m2eclipse or Eclipse IAM, or you can use the maven-eclipse-plugin to generate Eclipse projects. I have never used Eclipse IAM. My experience with m2eclipse is that it is nice for a small set of projects, but if you have a large multi-project structure like we do, then m2elipse consumes too much resources. So, I install m2eclipse for some of its tools, like seeing a hierarchy of the Maven dependencies for a project, and autocomplete while editing a POM file, but I do not import our projects as Maven projects into Eclipse. Instead, I use the maven-eclipse-plugin to generate all the Eclipse projects, and then I import them as existing Eclipse projects. We use a hierarchical structure for multiple projects, which is what Maven suggests, and so all I have to do is point Eclipse at the top directory and it will find all of the generated projects. The only primary drawback to this approach, as apposed to using m2eclipse, is that you have to re-generate your Eclipse projects if you add or remove a dependency. However, the process is very fast, and you simply have to refresh a project that you have already imported. Some day, I expect m2eclipse or Eclipse IAM to be efficient enough to just use them.

    Hope that helps.


That was a great and complete answer to our question and thanks to him, we finally made our mind !

Thanks Richard and everyone else that took the time to answer either here or on Gwt-Platform group.

Unit testing for dummies

Lately I asked one of the most generous Gwt-Platform contributors, Brendan Doherty, to write a small article about unit testing for dummies and, well, he didn’t really do what we had in mind. Still I think he said everything that needs to be said, judge for yourself:

  1. Watch as many videos as you can find on youtube by Miško Hevery, as well as these presentations. I regularly listen to him when driving in my car.
  2. Read everything ever written on the Google Testing blog.
  3. Read for information on how gwt-platform provides assistance when writing your presenter unit tests.

Repeat until you are no longer a n00b.

While it’s not really a tutorial, there’s a lot of information, I’m sure a lot of you will find number one and two pretty instructive (and number three pretty useful!)

UiHandlers and supervising controller

In our last post we told you how to reference your presenter (aka supervising controller) within your view in an elegant and simple way. However, we used a slightly provocative title that may lead you to think we are no longer doing MVP. Let’s get that out of the way: even though we added one arrow to the MVP diagram of Martin Fowler, this new pattern will look and feel perfectly MVP-esque to you. In fact, some people at Google added this arrow long before we did!

What does it mean to you? It means your view is still dumb (sorry, passive, we don’t want to hurt her feelings) enough that you can often afford to test only your presenters. Really, the only thing you’ll notice is an important reduction in the number of smelly anonymous classes and your love story with UiBinder will blossom!

That being said, we already told you how to use the pattern and even gave some tools to automate the process with Gwt-Platform. We decided not to use injection for connecting the presenter to the view, mostly because it would have caused an explosion in the number of class implementations. At that point we felt the user should probably make his own implementation to his liking, injecting a Provider<MyUiHandlers> if desired.

Now let’s explain why we used this pattern and take a look at what is MVP:

As you can see there’s a direct link between the view and the presenter used for forwarding events. We felt, while reading google mvp part 2, that this pattern was doing exactly what we needed to clean things up: delegating events to the presenter.

In the old approach, the view would let the presenter access either the real widgets (bad) or a simple interface such as HasClickHandlers (better). Then the presenter would bind a handler to this object and would be directly notified of any UI interaction. Since each one of these bindings require you to write a cumbersome anonymous class, a complex view would quickly generate a LOT of boiler plate in its presenter.

Instead of doing this, the new approach lets you handle events directly in the view, mapping them to methods in the presenters. If you’re using a 1-to-1 mapping, this does not add any logic to your view. But where does the savings come from? Aren’t you simply moving all these anonymous classes to the view? This is where @UiHandler comes into play! This new annotation is a real boilerplate saver: it automatically binds a widget event to a method from the view class. The only thing left to do is to invoke the corresponding method in the presenter class.

If reducing boilerplate is not a good enough reason for you, there is another important benefit of passing the presenter to the view. Hooked? Sorry, this will have to wait for a future post… Meanwhile, don’t hesitate to give us feedback or to propose subjects!

Reversing the MVP pattern and using @UiHandler

EDIT: This post has been slightly edited to follow the new naming convention used in Gwt-Platform.

Through usage, we have found that the second MVP pattern proposed by Google could save us a lot of tedious anonymous classes. This approach mainly consists of creating an interface that your presenter implements and which lets your view access some of its methods. This technique can be readily used with Gwt-Platform, but it is lacking documentation. So now is the time to explain it properly!

The first thing you’ll notice is that the latest version of GWTP introduces some interfaces and abstract classes that makes it easy for you to use this pattern:

  • The HasUiHandlers interface is used to indicate that your view participates in the pattern. A view that implements this interface needs to have uiHandlers, that is, a set of methods it can use to initiate complex actions in the presenter.
  • UiHandlers is a marker interface used to define your controls, you inherit from it and define all the methods your view will need to use.
  • The abstract class ViewWithUiHandlers inherits from ViewImpl and is the straightforward implementation of HasUiHandlers. Your view can inherit from it to save you some typing.
  • The abstract class PopupViewWithUiHandlers is the same as the precedent but inherits from PopupViewImpl. Use it for your dialogs that participate in the pattern.

Now don’t be confused by all these tools. You’ll see that using the pattern is quite straightforward. First you need to create an interface that extends UiHandlers and add all the methods your view needs to call. We usually call that interface MyUiHandlers and place it inside the view to keep things organized:

public interface MyUiHandlers extends UiHandlers {
  void onSave();

Your presenter then needs to implement this interface:

public class ExamplePresenter extends Presenter<ExamplePresenter.MyView, ExamplePresenter.MyProxy>
    implements MyUiHandlers {
  public void onSave() {

Then you have to connect these controls to your view. This is done by letting MyView extend HasUiHandlers and by calling setUiHandlers(impl) within your presenter’s constructor to finalize the connection:

public class ExamplePresenter extends Presenter<ExamplePresenter.MyView, ExamplePresenter.MyProxy> implements MyUiHandlers {
  public interface MyView extends View, HasUiHandlers {
  ExamplePresenter(final EventBus eventBus, final MyView view, final MyProxy proxy) {
    super(eventBus, view, proxy);

Be careful: since the view is instantiated before the presenter, the setUiHandlers(impl) method will be called after the view’s constructor has executed. This means you cannot refer to the presenter within your view’s constructor. Also, it’s important to call setUiHandlers() early, otherwise you might run into situations where your view needs to access a control when it doesn’t yet have access to them. Just to be on the safe side, you should probably check for null before invoking any control method.


The last step is to let your view extends ViewWithUiHandlers or PopupViewWithUiHandlers instead of ViewImpl or PopupViewImpl. Then you’re ready to use your controls via getUiHandlers(). As a result, using the wonderful @UiHandler annotation is now very easy:

public class ExampleView extends ViewWithUiHandlers<ExampleView.MyUiHandlers> implements MyView {
  void onSaveButtonClicked(ClickEvent event) {
    if (getUiHandlers() != null) {

That’s it, you now have a powerful, easy to read and versatile way of using your MVP elements without giving more responsibilities to your view and without breaking the MVP pattern. Your presenter still does all the heavy lifting and your view is still pretty dumb so testing should be a breeze!