Google Web Toolkit Blog

New insights into web application performance

2009-11-04T10:23:00.000-08:00

I've sometimes thought that optimizing web applications is as much a science as dowsing. (No offense intended, dowsers of the world — but you have to admit it's a hard thing to explain even when it does work out.) Even when you are completely willing to invest time and energy into optimizing an application, how do you actually go about it?

Our team, along with everyone else in the world who cares about web application performance, has had to essentially guess at where time goes inside the browser. We've spent countless hours debating each others' wild-eyed speculations as to the true sources of latency afflicting a wide variety of applications. Indeed, web apps can be slow for all sorts of opaque and unintuitive reasons. Don't be fooled into thinking that bloated, slow JavaScript is the only culprit. We've seen pathological situations in which a few seemingly insignificant CSS tweaks can improve performance by a factor of 5 or more. Another dark gem: rearranging a mere few lines of JavaScript that were inadvertently calling DOM-related methods in an unfortunate sequence (which caused multiple redundant layouts) turned a life-negating 5 second operation into a sprightly 50 millisecond blink of an eye. That one took 5 days to find the offending 4 lines of JavaScript and then about 3 seconds to actually make the code change. #nowiamwaybehindingooglereader

We couldn't take it anymore. We decided we had to find a way to transform the witchcraft of optimizing web apps into a legitimate engineering task, once and for all.

My team began working on a series of changes to WebKit and Chrome to collect precise metrics on where time is, in fact, going within the browser. When, exactly, does layout occur? How long does each layout take? Can layout happen synchronously while my JavaScript is executing, or is it deferred? How much time is spent on CSS selector matching? How long does parsing (versus executing) JavaScript take? Does the process of actually painting pixels on the screen take much time? We instrumented the browser way deep down inside to produce a stream of such metrics, being very careful to keep observer effects to a minimum.

Happily, we've managed to land these changes into both WebKit and Chrome over the last several weeks. Soon you'll see the first examples of tools that make these metrics available to web developers using WebKit-based browsers. Of course, we have a lot more instrumentation planned, but the ball is really rolling now thanks to lots of help from the friendly folks on the WebKit and Chrome teams (especially Pavel Feldman and Timothy Hatcher). We've gained many new insights, some of which I mentioned in my Measure in Milliseconds talk at Google I/O earlier this year. When you see these metrics yourself for your own web apps, you'll likely be surprised — and you'll almost certainly wonder how anyone tried to write high-performance code without this sort of insight. Be sure to keep an eye on the Chrome Dev Channel and the WebKit nightly builds for new Inspector features based on our work.

The enterprise (apps) in your pocket

2009-10-19T15:08:00.000-07:00

When building great enterprise apps for our users many of us often first target the desktop user. Did you know that GWT lets you just as easily build great user interfaces for your mobile users?

Modern mobile phones such Android based devices and the iPhone ship will powerful web browsers which use the same Webkit rendering engine which GWT already supports and increasingly includes great capabilities like geo-location and offline storage.

Today's guest blog post is from Navin Kumar, CTO of Socialwok who has offered to share some of their experiences around building mobile apps for the enterprise.

If you have an enterprise story you'd like share please send me an email.

--

Google Web Toolkit (GWT) is a great set of open source tools for developing powerful Ajax-enabled web applications. Socialwok uses GWT on top of Google App Engine to provide a feed based group collaboration service for Google Apps users. GWT makes development more efficient, particularly for Java developers who work on both the front-end and the back-end. Since we use Java language support for Google App Engine, this is true for us. By using the Java programming language, GWT can make you more efficient in many other ways too. For example, after spending a couple of months developing the desktop web version of Socialwok, we developed the mobile HTML 5 web version in four days.
To see the desktop web version of Socialwok go to http://socialwok.com/ and use any existing Google Apps domain email address to login.

Once you have created your socialwok network, you can now access the mobile web version by pointing your mobile web browser to http://app.socialwok.com/. Login using your google apps domain email address.

Here are a few pointers based on our experience in creating Socialwok's desktop and mobile web versions:

1. Think about the devices you want to support.

75% of iPhone users say they browse the web more often from their iPhone now more than they ever did before. 40% of them browse the web more often from their iPhone than their own desktop. Hence, it is important to have a mobile web version of your application for different mobile web devices like iPhone and Android. Socialwok mobile web version supports mobile browsers based on the Webkit codebase like the iPhone's Safari and Android mobile web browsers. The first step was therefor to fix the user.agent in our module's .gwt.xml file to speed up compile time by having GWT only compile the Webkit permutation:

<set-property name="user.agent" value="safari">

Of course, during development we enjoy GWT's quick edit-refresh-test model thanks to Development Mode (formerly Hosted Mode) which lets us test our code in a real browser while executing and debugging in Java.

Another thing to note is that with Mobile Safari on the iPhone and the Android Web Browser, you are now allowed to use webkit-specific CSS for mobile devices. This allows you to use native accelerations that include transitions, border images, as well as natively-created gradients. Here's an example of CSS used to create a native accelerated transition.

.menuPanel {
width: 100%;
\-webkit-transition: opacity 500ms ease-out 100ms;
}

Look for more info here. While the information is specific to the iPhone, the same rules do apply and work well on the Android browser as well.

2. Optimize for the screen that your users are using.

iPhone and Android devices use very powerful touch screen user interfaces. The user interface for all the iPhone applications is pretty well-defined; it involves a navigation header at the top, the content in the middle, and maybe a footer at the bottom. If you're thinking in GWT widgets, you should be thinking VerticalPanel or FlowPanel. These are the widgets of choice for the mobile web GWT developer.

Screen real estate on mobile phones is precious. You have to optimize the amount of visible content on the screen. Try to make things "expand" when you click on them. For example, in Socialwok, when someone clicks a post from the listing screen, a new screen is given to the user with only the single "opened" post that lists all the attachments, comments, and other pieces of information right there.

Unlike the desktop version, instead of one single widget for the feed item, we need one widget for the feed listing, and one "feed item" panel, that contains the single update along with the corresponding comment thread.

Finally, understand that your users are looking at the mobile as a "complement" to your desktop version.

While they might end up using the mobile version more often, they expect it to mirror the desktop interface in basic ways. This is actually great because you have already developed your widgets using Java, and porting them to the mobile is only a matter of changing CSS classes, and removing a few unnecessary UI elements.

3. Share as much code as possible between versions.

This is the most important reason why mobile development can be done rapidly. All of GWT's HTTPRequest, marshalled JavaScriptObject, and other non-UI code is shared between the mobile web and desktop web versions. This concept is important in general for any GWT application that uses multiple EntryPoint modules. The great thing about this is that the Java programming language makes this possible by it's own definition. OOP developers tout code sharing all the time, and you should follow their advice nonetheless. This page in particular is very useful to understanding how to organize your GWT code.

I hope the above pointers help you get started on desktop to mobile web development on GWT. For more information on Socialwok and GWT, check out Google's developer GWT profile on Socialwok on YouTube.

Finally, here are some useful classes and libraries you can use for GWT mobile web development:

ImmutableResourceBundle - A great set of tools that was started in the GWT incubator project but has now made their way in the mainline GWT trunk development (soon to be known as ClientBundle). ImmutableResourceBundle is the followup to the great ImageBundle interface. Both seek to reduce greatly the number of round-trip times used by browsers to download cacheable resources such as images, CSS, and other resources. The mobile browser is even more limited than the desktop browsers when it comes to downloading simultaneous resources, so the use of data: URLs and CssBundle are used heavily by the mobile version of Socialwok.

FlowPanel - Unlike desktop browsers which are more optimized for
tags that GWT uses for its CellPanel-based layout controls, mobile browsers like Safari and the Android browsers perform much better with

tags. Layouts also seem to be more predictable with these tags than the others on the mobile phone.

GWTQuery - Ray Cromwell's excellent port of JQuery to GWT provides most of the JQuery functionality to allow you to modify CSS, and perform other actions with ease. In the case of the mobile web interface, there are times when it is definitely necessary to modify CSS dynamically, and this library will make that process much easier on you as a developer.

GWT Google APIs (Gears) - Google Gears is a browser plugin installed in the Android Web Browser used to provide extra functionality, particularly offline support which is very import for mobile browsers which don't always have a permanent connection. Google provides a GWT library that can be used to access the Gears plugin.

-- Navin Kumar, CTO, Socialwok

Building Enterprise web apps in the cloud

2009-10-08T22:04:00.000-07:00

An important decision to make when building a web application is how to coordinate state between client and server. This includes how to create appropriate representations of your data to send over the wire.

There are many possible approaches. I'd like to present a straightforward one from Jerome Breche, CEO of TimZon, who was kind enough to share it with us today.

When we started our first GWT project (TimZon.com), we found out that one of the major benefits of using GWT is its ability to transfer complex object data structure between client and server through the RPC mechanism. So when we initiated our second project (SnapABug.com) combining GWT and Google App Engine, we were very excited by the prospect of passing datastore objects directly though RPC.

We quickly realized that this is not very practical. First one of our JDO objects includes images binary representation that we wouldn’t want to communicate through RPC. And then while making the JDO class serializable for GWT RPC may seem like a simple task, it created all kind of new problems since the JDO class will have to be configured as transient (using detachable = "false") and we would still need to copy the object when passing it through the RPC. Instead we decided to simply create intermediary classes for the data objects used only for RPC communication. This way we can exactly control and optimize the data payload used by the RPC both for size and speed. On the JDO side, we simply created a getter and setter function to translate the JDO data into an RPC data format.

Here is an example of how this works in client side code.

1. Employee class: contains JDO objects definition and getter and setter to translate them to GWT RPC serializable format
@PersistenceCapable(identityType = IdentityType.APPLICATION) public class Employee {
@PrimaryKey @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY) private Long id; @Persistent private String name; @Persistent private String email; @Persistent private Blob image; /**
* Constructor * @param name * @param email */ public Employee(String name, String email) { this.name = name; this.email = email; } /** * Set Employee from RPCDataEmployee */ public void setRPCDataEmployee(RPCDataEmployee employee) { name = employee.name; email = employee.email; } /** * @return Employee data in RPC format */ public RPCDataEmployee getRPCDataEmployee() { RPCDataEmployee employee = new RPCDataEmployee(); employee.name = name; employee.email = email; return employee; } }

2. RPCDataEmployee class used by GWT RPC calls

public class RPCDataEmployee implements IsSerializable {
public String name; public String email; // Note: image Blob not included in RPC payload }

Here is an example of how this works in the server

3. RPCDataEmployee server service implementation
public RPCDataEmployee getEmployee(String email){ RPCDataEmployee employee = new RPCDataEmployee(); // create data store connection PersistenceManager pm = PMF.get().getPersistenceManager(); // query datastore to get emmployee data String query = "select from "
+ Employee.class.getName()
+ " where email == "
+ email;
List employees =
(List) pm.newQuery(query).execute();
if (employees.size() == 1) { // record found employee = employees.get(0).getRPCDataEmployee(); } else { // do something else... }
pm.close();
return employee; }

While I am sure there are many other ways to achieve a similar result, maybe even avoiding duplicating the data classes, this solution was the easiest for us to get going quickly, keep our code very maintainable and control the amount of data exchanged between client and server.
There is also a very interesting discussion about this subject on the GWT Google Group.

-- Jerome Breche, CEO & Founder of TIMZON, LLC

If you would like to share your experiences with GWT and Google App Engine, either privately or on this blog, I'd like to hear from you.

Making AJAX Crawlable

2009-10-08T14:17:00.000-07:00

At the recent Search Marketing and Expo East Conference (SMX) several members of the Google Web Toolkit team delivered a presentation on making AJAX enabled web apps crawlable. This presentation included a proposal that is currently in the works which aims to solve the fundamental problem that it is difficult to index AJAX enabled web apps and therefore their searchability suffers. If you care about SEO in your GWT apps, check out the post on the Google Webmaster Central Blog and let us know your thoughts.

GWT helps developers innovate in the enterprise

2009-10-05T15:29:00.000-07:00

I had an opportunity to sit down with TechCrunch50 Demopit winners and creators of Socialwok, a cloud based application which mixes Google Apps and a unique set of social capabilities to make their customers more productive, both at their desks and on the road via their mobile web client. They chose Google App Engine for scalability and hassle free web hosting and Google Web Toolkit to maximize their productivity so that they could focus on creating a great web experience for their users. You can watch the interview here.

Riding the Google Wave

2009-09-30T18:45:00.000-07:00

Today our colleagues down under began inviting the first 100,000 users to preview Google Wave. We are very proud of the work that they have done and are quite pleased that GWT has helped make Google Wave a reality. You can read more in yesterday's Google Wave Backstage - Q&A with Dhanji Prasanna at InfoQ.

In fact the Wave team has told us that they would have not been able to build the user interface you see today without GWT. That's a great testament to our mission statement which reflects our focus on developer productivity and user performance, delivering a great AJAX experience across all major browsers. Also, with only 10-15% additional effort GWT allowed the team to build a user interface dedicated for mobile devices browsers.

Of course there's still much to do before Google Wave rolls out for everyone. If you weren't one of the developers who participated in the developer preview or helped build one of the many samples perhaps there's an extension you would like to build. Check out the Google Wave API Documentation to find out how you can get started with GWT and Google Wave.

Congratulations to the Google Wave team on achieving this milestone and we look forward to continuing to work together.

GWT Community Updates

2009-09-25T09:00:00.000-07:00

Community announcements

GWT on the go with gwt-mobile-webkit: A new project is underway started by a developer in the GWT community that provides GWT API bindings to HTML 5 features supported by Mobile WebKit. While the project more closely follows the WebKit implementation for HTML 5 features and other WebKit libraries, other browsers are also supported for various HTML 5 APIs. Check out the project homepage for more details.

GWT Gadgets riding the Wave: The Google Wave Gadget API is an awesome way to leverage the power of Wave in your gadgets. Thanks to the efforts of yet another great GWT community member, you can now more easily use the Google Wave Gadget API in your GWT developed Gadgets using the cobogwave project. This library builds on the existing GWT Gadgets support available in the Google API Libraries for GWT project.

GWT-GData v 1.10.1 released: Developed through the guidance of the GWT team, GWT community contributors and the main project lead, Bobby Soares, the gwt-gdata project recently had its 1.10.1 release. This is a nice library to access many of the GData APIs from Google Analytics to Google Maps Data. The full list of supported GData APIs can be found on the project page.

GWT-MVC 0.3 released: The MVC pattern has proven its usefulness in the domain of web application development time and time again. If this pattern is a good fit for the project you're planning or currently working on, you may want to check out the gwt-mvc project, which provides a layer of abstraction to make MVC modeled development easier in GWT.

GWT-Connectors 1.7 released: The gwt-connectors project is a really cool tool for developers who need to connect boxed components with connectors, and now includes connectors with arrow tips. You can check out the demo here, and if you like what you see and need it for your application, check out the project page for more information.

GWT 1.7.1 release fixes Mac OS X Snow Leopard issues

2009-09-23T10:14:00.000-07:00

If you don't use Mac OS X 10.6 (Snow Leopard), the GWT 1.7.1 release shouldn't interest you much -- you shouldn't see any changes. If you do use Mac OS X 10.6, good news. Running GWT with Java 6 has become simpler. Download it here.

What's in the point release

GWT's hosted mode uses the Standard Widget Toolkit (SWT), which only supports 32-bit operation. Hosted mode must therefore also run a 32-bit version of Java. Mac OS X 10.5 (Leopard) shipped with a 32-bit Java 5 and a 64-bit only Java 6. Java 5 was compatible with the 32-bit SWT bindings, so the GWT SDK directed users to use Java 5 only. With the Snow Leopard release, Apple only includes Java 6, but it now runs in both 32-bit and 64-bit modes.

In short, you can now run GWT on Snow Leopard using the Java command line argument -d32 without further modification. The GWT SDK no longer directs you to only use Java 5, and the ant scripts (including scripts generated by the webAppCreator tool) have been updated to include the -d32 flag where necessary. Also, Linux users will see a more informative error message when a non-32-bit Java runtime is used..

Delivering faster, richer GWT applications to your users

2009-09-22T20:25:00.000-07:00

GWT has always been about providing a better experience for your users. Today GWT received a helping hand with the release of an early version of Google Chrome Frame, an open source plug-in that brings HTML5, a faster JavaScript engine and other open web technologies to Internet Explorer.

You're probably wondering how your users can take advantage of Google Chrome Frame. Simply add the following tag to the <head> section of your application's HTML page, just like you would for any other web application:

  <meta equiv="X-UA-Compatible" content="chrome=1">

As you probably know GWT automatically builds a different version of your application for each major browser. It uses a special selection script to launch the version which has been specifically optimized for the user's browser and personal settings.

Now you might be wondering how your existing apps will behave when your IE users with Google Chrome Frame installed visit your site. Will GWT try to launch the IE version or the WebKit version of your application?

GWT's selection script detects your browser's rendering engine so that it can launch a version of your app which is optimized for your browser. When the Google Chrome Frame plug-in is installed and the meta tag is present the WebKit rendering engine is used instead of the IE rendering engine. Since your app's existing selection script already recognizes WebKit based browsers it will know to launch a version of your app which has been optimized for Google Chrome Frame. If you don't include the meta tag or if your users don't have Google Chrome Frame installed the GWT selection script will still know to launch the IE version of your app.

In other words, your existing GWT apps are already setup to work with Google Chrome Frame. All you have to do is add the meta tag to your HTML pages.

If you like'd to encourage your IE users to install Google Chrome Frame or would simply like to learn more you can checkout the Google Chrome Frame developer docs.

Hydro4GE — a PaaS built with GWT

2009-09-02T17:41:00.000-07:00

Introduction

From time to time we like to share experiences from fellow developers with you. It's a pleasure to present you today with this guest blog post by Geoff Speicher, Chief System Architect of Hydro4GE.

Overview

Hydro4GE (pronounced hy-dro-forge) is a Platform-as-a-Service (PaaS) for building online database applications. Building a powerful tool for developers itself requires a powerful toolkit to meet developers' expectations of a development environment: a highly-interactive, rich user interface (UI) with emerging features such as database schema visualization via interactive, scalable graphics. This article describes our experience in using GWT to rewrite our old HTML+AJAX UI to deliver all of these features with a polished look and solid performance.

Building the UI

When we set out to rewrite the UI using GWT, a quick inventory of available widgets was in order. Our initial reaction was similar to what some others have expressed: that the native GWT widget library did not have quite the same breadth or flair as some third-party libraries such as ExtJS or SmartGWT. However, experimentation with these libraries proved that they are also fairly heavy in weight, and noticeably impacted the application's performance both in its initial download and its interactive responsiveness.
The reason is simple: these generic JavaScript libraries, though highly optimized, are still just that — generic. It is unrealistic for these libraries to achieve the same level of efficiency as code that is produced by the GWT compiler. For this reason, we wanted to avoid the use of external JavaScript libraries when possible.
After some careful consideration and a more detailed analysis of our needs, we discovered that we only needed a small handful of widgets that GWT didn't already provide, and all but one of those (covered in the next section) were easily built using Composite. There is already an excellent blog entry for building Composites, so we will not cover that topic here. The visual styling of both the native and Composite widgets was easy to customize thanks to GWT's liberal and logical use of CSS classnames.
As a quick demonstration, it's pretty impressive what a difference you can achieve by building a few simple Composite widgets and tweaking some of the default styles. Compare the default styling of an input form with one modified by a few simple customizations:

GWT Default Styles & Widgets

Customized for Hydro4GE

If you have not already jumped on the bandwagon, Firefox+Firebug is an indispensable tool for inspecting HTML and tweaking CSS. Thanks to this and the flexibility of the GWT library, we were able to achieve the polished look that we wanted without much work and without sacrificing performance.

Building a Widget from an External Library

What about the one widget that we couldn't build using Composite? We want to use vector graphics to generate scalable diagrams depicting database structure and user interaction for systems you build with Hydro4GE. There are a small handful of vector graphics libraries out there for GWT, but all of them require concessions that we are not willing or able to make. The Google Web Toolkit Incubator's GWTCanvas does not support text rendering (due to a limitation of HTML canvas), and although projects such as abstractcanvas attempt to overcome this limitation, text cannot be rotated and precisely scaled.
In this section, we will show you how to integrate with Raphael, a lightweight JavaScript library for cross-platform vector graphics. Raphael side-steps the HTML canvas issue by using SVG on supported platforms, and Microsoft VML on Internet Explorer. Raphael does everything we need to build our diagrams, except for one thing: integrate directly with our GWT code.
We achieved this integration through two levels of abstraction: (1) a JavaScript Overlay Type to provide a zero-overhead interface to the underlying JavaScript API, and (2) a GWT Widget to wrap the overlay with a more Java-friendly API, resulting in a first-class Widget that will operate side-by-side with native GWT Widgets. Let's have a look at the details for this two-part implementation, starting with the Overlay class.

The Overlay

The RaphaelJS class is nearly an exact replica of the underlying Raphael API. This is made necessary by the restrictions that GWT enforces on JavaScriptObject types, so the implementation is fairly uncreative: one method per Raphael method. Many of these methods appear in the nested class Shape, which represents the type returned by most of the native Raphael methods. The basic idea for the class is:

class RaphaelJS extends JavaScriptObject {
  protected static class Shape extends JavaScriptObject {
    public final native Shape rotate(double degree, boolean abs) /*-{
      return this.rotate(degree, abs);
    }-*/;
    public final native Shape scale(double sx, double sy) /*-{
      return this.scale(sx, sy);
    }-*/;
    public final native Shape translate(double dx, double dy) /*-{
      return this.translate(dx, dy);
    }-*/;
    // ...
  }

  /**
   * factory method
   */
  static public final native RaphaelJS create(Element e,
      int w, int h) /*-{
    return $wnd.Raphael(e, w, h);
  }-*/;

  public final native Element node() /*-{
    return this.node;
  }-*/;

  public final native Shape circle(double x, double y, double r) /*-{
    return this.circle(x,y,r);
  }-*/;

  public final native Shape rect(double x, double y,
      double w, double h) /*-{
    return this.rect(x, y, w, h);
  }-*/;

  // ...
}

The Widget

The Overlay bridges the gap between GWT and Javacript, but the Widget is what truly makes the library useful to our application. Since the Widget does not have the restrictions of the JavaScriptObject Overlay, we have the freedom to define our own API as an adaptor to the Overlay.

public class Raphael extends Widget {
  private RaphaelJS overlay;

  public class Shape extends Widget {
    protected RaphaelJS.Shape rs;
    protected Shape(RaphaelJS.Shape s) {
      setElement(s.node());
      rs = s;
    }
    public Shape rotate(double degree, boolean isAbsolute) {
      rs.rotate(degree, isAbsolute);
      return this;
    }
    public Shape scale(double sx, double sy) {
      rs.scale(sx, sy);
      return this;
    }
    public Shape translate(double dx, double dy) {
      rs.translate(dx, dy);
      return this;
    }
    // ...
  }

  public class Circle extends Shape {
    public Circle(double x, double y, double r) {
      super(overlay.circle(x, y, r));
    }
  }

  public class Rectangle extends Shape {
    public Rectangle(double x, double y, double w, double h) {
      super(overlay.rect(x, y, w, h));
    }
    public Rectangle(double x, double y, double w, double h, double r) {
      super(overlay.rect(x, y, w, h, r));
    }
  }

  public class Text extends Shape {
    public Text(double x, double y, String str) {
      super(overlay.text(x, y, str));
    }
  }

  // ...

  public Raphael(int width, int height) {
    Element raphaelDiv = DOM.createDiv();
    setElement(raphaelDiv); 
    overlay = RaphaelJS.create(raphaelDiv, width, height);
  }  
}

This implementation defines separate classes that represent the different types of objects (Circle, Text, Rectangle) developers can append to a drawing. A possible alternative implementation might simply expose the underlying JavaScript API as a native GWT widget — in the end, you can write an API that suits your needs.
We chose this implementation because it allows us to implement scalable drawings through inheritance, resulting in custom classes that can be instantiated and appended to any Panel. For example, to create a fullscreen drawing that contains a single, centered circle of radius 20:

public class MyDrawing extends Raphael {
  public MyDrawing(int width, int height) {
    super(width, height);
    Circle c = new Circle(width/2, height/2, 20);
    // Raphael automatically appends the Circle to this drawing
  }
}

public class MyApp implements EntryPoint {
  public void onModuleLoad() {
    MyDrawing d = new MyDrawing(Window.getClientWidth(),
        Window.getClientHeight());
    RootPanel.get().add(d);
  }
}

This is a trivial example, but it clearly demonstrates the simplicity that can be achieved by integrating an external JavaScript library as a Widget. To the consumers of this library, there is no difference between using it (a third-party Javascript library) and the native GWT widget library. That's a powerful statement, and a testament to the GWT design team.

Communicating with the server

With the UI visually complete, it was time to move on to integration with the backend. Our existing backend was implemented in PHP, and we did not want to rewrite it in Java just to support GWT-RPC. Without native support for GWT-RPC calls to a PHP backend, we needed a flexible and efficient communication framework to accomplish the equivalent task. We chose JSON for its simplicity and solid support in both GWT and PHP, but ultimately we learned that regardless of the efficiency of the encoding, it's still easy to make design mistakes that will lead to inefficient communications.
First, we need to get the client and server talking to each other. Making JSON-encoded client requests from GWT is made trivial by using the RequestBuilder class in conjunction with JSONObject, and handling JSON on the server with PHP is easily accomplished using Zend Framework, which provides the Zend_Json class for encoding/decoding JSON, and Zend_Controller for handling and routing requests. This provides the framework we need to tie into our PHP code running on the server.
Having addressed the encoding and handling of requests, our attention turned to dealing with the size and frequency of requests. The whole point of making AJAX requests was to transfer little bits of data instead of re-sending an entire HTML document, but we found a break-even point where the payload became so small that the request frequency was the limiting factor. At one point, we had gotten so carried away breaking up information into atomic pieces that the overhead of each request was exceeding 90% of the total time to complete the request, leaving less than 10% of the time to actually process and transfer the payload.
The reason this can happen is pretty straightforward. Over any network connection, there is a minimum amount of time necessary for the HTTP request/response to live its lifecycle. This is compounded by the two-connection browser limit plus overhead imposed by the network stack and connection latency. The net effect of all this is that if you dispatch one hundred requests in rapid succession, each of which contains only a few hundred bytes of payload data, it would take nearly one hundred times as long to complete all one hundred requests as it would take to transfer the entire payload (tens of kilobytes) in one request. In terms of real-world figures, this translates to a 300 or 400 millisecond time for completion, as opposed to 30 or 40 seconds!
This lesson reminds us that when you write software, you must always design for the limitations of the platform, even when you have great tools at your disposal. In this case, to write efficient web software with GWT, you need to make every HTTP request reach its fullest potential by maximizing its effects.
We achieved this by modeling each request as a collection of atomic commands. In this simple model, each command can return a set of data, and is associated with one or more response data handlers. The commands are processed on the server within a database transaction so that the entire request either succeeds or fails as a single unit without leaving the database in an inconsistent state.
This abstraction allows us to queue up many physical database operations into one logical JSON request, not only improving performance but also allowing us to handle the results in a modular way that involves less code than a typical GWT request callback. In this sense we have actually managed to reduce the complexity of the asynchronous HTTP request for this specialized case. For example, take the code that handles selection of user roles from the Hydro4GE database:

  public class SelectRoleHandler implements DatabaseRequest.Handler {
    public void handle(DatabaseRequest.Result result) {
      for (int row=0; row < result.getRowCount(); row++) {
        JSONObject data_row = result.getRowValues(row);
        Role r = new Role(data_row);
        // process role...
      }
    }
  }

Compare this to the code that you would typically write for an HTTP request callback:

  public class SelectRoleCallback implements RequestCallback {
    public void onError(Request request, Throwable exception) {
      Window.alert("Couldn't retrieve JSON");
    }

    public void onResponseReceived(Request request, Response response) {
      if (200 == response.getStatusCode()) {
        JSONArray data_set =
            JSONParser.parse(response.getText()).isArray();
        if (data_set != null) {
          for (int row=0; row < data_set.size(); row++) {
            JSONObject data_row = data_set.get(row).isObject();
            Role r = new Role(data_row);
            // process role...
          }
        }
      } else {
        Window.alert("Couldn't retrieve JSON ("
            + response.getStatusText() + ")");
      }
    }
  }

Besides being easier to understand (and half as many lines!), the Handler code has the advantage over the Callback in that multiple independent handlers can be attached to a single request in order to achieve separation of responsibility in handling each response. In addition, each handler is isolated from the results of other commands in the same request, so that there is no confusion over which results you are handling. This example does not even introduce the complexity of handling multiple command responses in the typical RequestCallback code, but the Handler code supports it implicitly by its nature.
These concepts can and should be applied to GWT-RPC or any other communications encoding. The implementation details are different, but the spirit is the same: make every HTTP request really count.

Conclusion

The techniques I have demonstrated here can be used equally effectively in both new and existing projects. Whether you are trying to build a slick UI, wrap an external library, or talk to a server, I have only scratched the surface of what is possible with GWT. I am especially looking forward to GWT 2.0 for continued improvements on some of the topics covered here, made possible by some exciting upcoming features such as UiBinder and CssResource.
In short, I am pretty excited about GWT and Hydro4GE, and I hope you are too. Be sure to check out the sneak peek of Hydro4GE to see a demo of our GWT UI in action!
Geoffrey C. Speicher, MS is a Software Engineer at Software Engineering Associates and the Chief System Architect of Hydro4GE.

GWT for Enterprise Developers

2009-08-12T22:48:00.000-07:00

Do you use GWT -or are thinking seriously about using it- to develop your internal or public facing web applications? Do you work in a corporate setting or otherwise collaborate with multiple developers on a single web app? If their answer is yes to either of these questions perhaps we can share.

I'd like to share with you

I will be giving a talk called Google Web Toolkit for the Enterprise Developers at JBoss World 2009 in Chicago, September 1-4. I hope to share practical tips and lesser known, yet really useful features in GWT. While the talk will focus primarily on corporate development scenarios, the content will most certainly be useful if you're the most valuable member of a one person team. I hope to see you there. Don't forget to bring your questions.

Will you share with us?
Not everyone develops the same. In fact the same people may adopt different development styles as they move between teams. Different tools also work differently depending on the team and the project. I'd like to get to know your teams a little bit better and understand how GWT development happens for you. If you're willing to share with me please send me an email.

Seesmic duplicates their Adobe Air interface on the web with GWT

2009-08-12T15:25:00.000-07:00

Recently I was shown a demo of Seesmic Web, an application that lets you manage multiple streams and Twitter accounts. The demo was very cool and notable because Seesmic's related product is Seesmic Desktop, implemented in Adobe Air. Seesmic Web replicates the desktop functionality, but on the web using GWT.

The team chose GWT to build Seesmic Web, and I was curious to hear about their experience. In case it helps others in the process of evaluating GWT for building web apps, here is the response I got back from Johann Romefort, CTO at Seesmic.

The choice of using GWT was nearly natural once we defined the need for a very dynamic "single page" application.

Our Flex developers found themselves in a known environment (Eclipse) - developing a webapp with a strongly typed language. It took them 2 weeks to learn the GWT Framework - together with the Java language itself!

We were delighted to see the number of high quality libraries already available, as well as the vivid community around GWT. Finally, the determination of Google to keep the project updated was a convincing factor for adopting this technology.

From the beginning, we started using a MVC framework to keep our code well-structured, and it soon paid itself off in development. The predictability of the framework was a big plus: you write code, you reload, it works. All the bugs we encountered were documented, so finding workarounds was pretty straightforward. We were a bit anxious about legacy Javascript bridging, but JSNI proved to be a very easy way to use 3rd-party libraries.

We started development with version 1.5.3 of GWT and we just ported the app to 1.7. The porting process was a breeze and we’re very happy to be able to use the Eclipse plug-in for GWT.

I guess one area of departure is that we did not follow the classical RPC way for our server-side interactions. Instead, we built a REST API to keep our back-end services agnostic from the client used. We’re using Restlets to interact with our REST API, which once again worked flawlessly, as expected.

Our overall experience using GWT has been very positive. The fact that we develop in Java has a lot of advantages, such as being able to use java debugging tools - instead of just Firebug - if you’re in pure JavaScript. GWT has a few things we would like to see, like being able to load code dynamically instead of compiling everything in a large .js file, but it seems that GWT2.0 will bring forth some new possibilities.

Separating View and Presenter code for better testability

2009-08-11T15:18:00.000-07:00

The Google Testing blog has a post on testing GWT applications. Specifically the post talks about testing best practices and the use (or non-use) of GwtTestCase. It's worth checking out, especially if you are interested in better testability and architecture. To learn more about the MVP pattern mentioned, watch Ray Ryan's Best Practices for Architecting your GWT App talk at Google I/O.

GWT Community Updates

2009-07-28T12:09:00.000-07:00

Community announcements

GWT-in-the-Air (and in Yahoo! BrowserPlus^TM): Thomas Broyer, one of our GWT contributors and a regular on the forum, has been working on the GWT-in-the-Air project over the last year. The project provides an Adobe AIR version of your GWT application, making it ready to run in the browser or on the desktop. Thomas has most recently added support for Yahoo! BrowserPlus^TM as well, which allows you to add desktop capabilities to your GWT app.

GChart 2.6 released: John Gunther recently announced the GChart 2.5 release, which adds a GWT canvas rendering option for better looking charts and graphs.GChart 2.6 was also published recently which fixes deprecated event listener calls and other bug fixes. Check out the live demo and examples if you're interested in using it for your own GWT application.

An early look at Spring4Gwt: Dustin Mallory has recently created a new project called spring4gwt, which, as you may have guessed, offers a way to integrate GWT with the Spring framework. The project is still in its early stages, but aims to offer both exported Spring services to the GWT client and DI that works specifically for Spring components.

GWT-cs - Springifying your GWT application code: We've seen integrating with Spring, but what if you wanted to develop your GWT client-side code in a Spring-like fashion? In comes the newly started GWT-cs project for just such a use case. With this library, you can develop your GWT client-side application structure using Spring-like bean configuration in an XML format.

Uploading with GWTUpload: While the FileUpload widget in GWT core provides one part of the key to uploading files in your GWT applications, the server-side component and it's interaction with the client-side form submission is often the part developers get stuck on. Using GWTUpload, you can get file uploads ready in just a few steps. You also get other nifty features like progress bars showing file upload progress (file size, bytes transferred).

New Articles on the GWT homepage

We've recently published new articles on the GWT homepage, including:

Using GWT with Hibernate: A tutorial articles that explains step-by-step how to integrate GWT with Hibernate using one of various integration strategies, while discussing the pros and cons of each approach.
Testing Methodologies Using Google Web Toolkit: An article describing how to design your GWT application test-first, using principles of Test-Driven Design and the Model-View-Presenter (Passive View) pattern.

These articles were created to address the many inquiries we've seen on integration and testing topics, so hopefully they will be helpful to you if you're at the point of making integration or design decisions in your GWT project. Also, many of these articles were written in collaboration with the GWT developer community, so if you have any articles or topics that you would like us to consider for publishing on the GWT homepage, feel free to get in touch with us.

Google Web Toolkit 1.7 Now Available

2009-07-23T08:34:00.000-07:00

GWT 1.7 is a minor update that adds better support for Internet Explorer 8, Firefox 3.5, and Safari 4. Each of these new browser versions introduced at least one change that negatively impacted compiled GWT modules, so we recommend that you do update to GWT 1.7 and recompile your existing applications to ensure that they work well with the latest versions of browsers. No source code changes on your part should be required.

Normally, a minor update such as this would have been named 1.6.5 (the previous latest version of GWT was 1.6.4), but we did add the value "ie8" to the "user.agent" deferred binding property, which could impact projects using custom deferred binding rules that are sensitive to that property. Thus, we went with GWT 1.7 rather than GWT 1.6.5, to indicate that you may need to pay attention to that change. Details are in the release notes.

In every other respect, this is just a bugfix release, so in the vast majority of cases, the update-recompile process should be nearly effortless.

Download Google Web Toolkit 1.7

Introducing the Debug Panel for GWT

2009-07-15T16:57:00.000-07:00

The primary intent of the Debug Panel for the Google Web Toolkit (GWT) is to provide the developer of a GWT application performance data about the application as well as tools to debug the client side application code. Web applications built with GWT run mainly in the client's environment, over which the developer has little control or access. The Debug Panel provides tools to the developer to help lift the shroud over the client environment to help diagnose problems, help tune and improve performance as well as assist with application testing.

As with any application, testing and quality assurance is important to a GWT application. Because a GWT application is user facing, performance testing is very important. However, measuring the performance of an application running in a browser is not easy. With all the moving parts of the client code - RPCs, DOM updates, etc. - and the fact that with GWT you are no longer writing JavaScript, it can be hard to locate bottlenecks. Automating the performance tests and getting accurate numbers on RPC response time is even harder. This is where the Debug Panel for GWT comes into the picture. It is an external library that can easily be added to any GWT Web application and will provide you with that performance data, an insight into what goes on behind the scenes and help you automate the whole thing, too.

Here is a sample screenshot of the Debug Panel in action:

Here, the Debug Panel shows us the statistics of an invocation of the EchoService as well as the startup times. It is clear from the example that RPC finished quickly. It shows that the slowest component was waiting for the server to respond at 121ms. While serializing the request and deserializing the response both took 19ms, updating the UI with the data returned from the server only took 2ms. These are the kinds of numbers you would want to see!

Here is another example screenshot of the Debug Panel:

This time, the application was run in Hosted Mode and there was an exception during the RPC. Once you compile your application to JavaScript, the stack trace will be a JavaScript stack trace of course. The exception panel in the Debug Panel is also an example of the extensibility of the Debug Panel. As a GWT application developer, you can add your own panels to the Debug Panel that are customized to your application. The Debug Panel provides you with a framework to display your application's debug data as well as a lightweight component to add to your main application, so it can communicate the relevant data to the Debug Panel, without affecting runtime performance much.

In fact, you can plug the Debug Panel into an existing application without changing the application's code. This also means that there is no change required in the compiled JavaScript. Therefore, you can serve your GWT web application both with the Debug Panel enabled, to internal IP's for example, or disabled for everybody else.

Check out an online example of the Debug Panel, check out the example's source to see how easy it is to use or check out the Google Code project for more information.

Pascal Muetschard, Software Engineering Team

Come hear about GWT at the Googleplex tomorrow night (June 16, 2009)

2009-06-15T18:36:00.000-07:00

For those of you in and around Silicon Valley, I'd like to invite you to see my Google Web Toolkit presentation titled "GWT Overview and Feature Preview" at the Silicon Valley Web Java User Group. I'll start with an overview of current GWT features and functionality. Towards the end I'll cover some of the features you can expect to see in GWT 2.0, many of which you can try out now if you don't mind creating your own builds. Of course there will be plenty of time for Q&A and some time to network with other developers in the community.

The meeting will be in the usual place on the Google campus. Please register here (http://www.meetup.com/sv-web-jug/calendar/10012641/). If you can't make this particular meeting, you can catch up on GWT when you have a moment by watching any of the Google I/O GWT session videos and slides you missed. If you live further away, you could always start a local Google Technology User Group.

Hope to see you there.

GWT Community Updates

2009-06-11T17:04:00.000-07:00

Community announcements

Gilead GWT adapter for Google App Engine: Bruno Marchesson, creator of the Gilead (aka Hibernate4GWT) library, has created another adapter - this time for GWT applications running on App Engine. It is still in its early stages, but this may be useful to those looking to build their applications using GWT and Google App Engine and who don't mind hammering on fresh code.

Vaadin 6 (formerly IT Mill Toolkit) releases: The IT Mill team has come out with the latest release of their toolkit built using GWT technology. Vaadin offers a different take on Ajax application development that employs server-driven architecture with widgets composed of both client and server-side components. Their latest release is available on their new site.

SmartGWT out of beta with v1.1 release: Sanjiv Jivan has been hard at work getting the SmartGWT library ready for its out of beta release. It includes many useful new features that you might be interested in checking out.

Google I/O 2009 - Caught on video

GWT at Google I/O: In case you missed it, we've captured all the GWT sessions at Google I/O on video, including the keynote presenting Google Wave (built with GWT).

GWT Developers at Google I/O: A few external developers who use GWT also stopped by I/O and participated in the Developer Sandbox. Despite all the hustle and bustle around the sandbox area, we managed to talk to some of them on video about their development experience. Some of those we talked to include:

We also talked to many other developers using Google Technologies to create some great applications.

New GWT App Gallery posted (check it out)

2009-05-28T09:30:00.000-07:00

A couple months ago, we asked the community to tell us about their GWT applications and their experience developing them. We were greatly pleased to see many responses, and lots of neat applications. In fact, we had so many responses that we needed a better way to showcase and share them with the community.

Introducing the new GWT Application Gallery to save the day, now posted on the GWT homepage. Improving on the earlier GWT Application Gallery, the new gallery adds more features to make community interaction easier and application entries more meaningful. Here are some of these new features that you can look forward to:

An easier way to submit entries for any GWT-related tools or application that you would like to share with the community
A comment and rating system for others in the GWT community to rate your applications
More screen real estate for application screenshots and thumbnails for your application entry
Searchable tags that you can apply to your GWT application entry

We already have a number of entries both from the previous app gallery and newer entries from respondents to our call out a few months ago, and we'd love to hear from you too. So please, check out the new GWT App Gallery to see the kind of great applications the community has been developing, share your opinions through the comments and ratings feature, and add your own applications to the gallery.

As a sidenote, Google I/O is in full swing. In the spirit of sharing applications and development experiences, we've organized a Developer Sandbox area this year where third party developers who have used Google developer products can showcase their applications and talk about how they've created them. If you're attending Google I/O, drop by to check out some of these products live. I'll be around that area as well, so please come by to say hello.

Google API Libraries for GWT - May 2009 Release

2009-05-07T15:22:00.000-07:00

By Eric Ayers, Google Web Toolkit Team

We are pleased to announce updates to the Google API Libraries for the Google Web Toolkit project. The Google API Libraries for GWT project allows GWT developers to access some of Google's popular JavaScript APIs. This release contains new bindings for two libraries:

Google AJAX Loader API - Allows dynamically loading an API from GWT code
Google AJAX Language API - Provides translation, transliteration, and language detection services

These libraries each come with sample code and Javadoc documentation.

In addition, other libraries have been updated. Highlights include:

UI Styling and full GoogleBar support for the Google Maps API.
Ajax Loader support integrated with Search, Maps, Language, and Visualization.
Formatters support, new event types, and new OrgChart features added to bindings for Google Visualization API.
Bugfixes for the Gears API wrappers, for a full release of support for Gears 0.4 features.
Locked Domain feature added and improved performance for the Gadgets API.

These updates are now available for download at the Google API Libraries for GWT project hosted on Google Code.

GWT and Maven - Playing Nicely Together Since 2008

2009-05-04T13:55:00.000-07:00

StudyBlue is an academic social networking application, built with GWT, that helps students study smarter, faster. To manage the build process during the development of their application, the StudyBlue team uses the Maven build system. Chris Klundt and Hicham Bouabdallah from StudyBlue have kindly dropped by to share their tips on getting GWT and Maven to play nicely together.

Maven is a great resource that allows developers to enable dependency management within their GWT web applications. While a complete description of Maven's dependency management is beyond the scope of this article, we encourage you to read more here . Essentially, Maven allows you to modularize your GWT project, separating the reusable pieces of code (i.e. Custom Widgets or Data Transfer Objects) into their own projects while maintaining versioning. In addition, Maven allows you to incorporate several different modules without having to write/maintain a complex Ant build file.

Modularization

When developing your application you may quickly realize that it would be beneficial to separate large pieces into separate modules for easier management and reusability. We have multiple internal applications that use the same Data Transfer Objects and Custom Widgets. In our case, we found that separating these two pieces into separate modules made everyone's life easier. In order to accomplish this, we created two separate Maven modules, studyblue-data and studyblue-widgets.

Your resulting project hierarchy will look like this once its all hooked up:

Each of the new modules (data and widgets) look similar to the main project because they contain a gwt.xml file, however their project structure looks like this:

+ studyblue-data/
  + src/
    + main/
      + java/
        + com.studyblue.data/
          Data.gwt.xml
        + com.studyblue.data.client/
          Data.java
          ...
      + resources/
    + test
      + java/
      + resources/
  pom.xml

Your Data.gwt.xml file would look like this:

<module>
  <!-- Inherit the core Web Toolkit stuff. -->
  <inherits name="'com.google.gwt.user.User'/">     
  <source path="client">
</module>

Your Data.java file would be empty in most cases:

package com.studyblue.data;

import com.google.gwt.core.client.EntryPoint;

public class Data implements EntryPoint {
  
  public void onModuleLoad() {
  
  }
}

As per usual, your source code goes under the com.studyblue.data.client package. We created an additional project for studyblue-widgets similar to the one above. At this point, you should have three projects open in your Workspace (your main web app, your newly created data module, and your newly created widget module). Once you've organized your code, it's time to hook it up with your core web application via a few hooks with Maven and the gwt.xml files.

Connecting to Maven

So what is that pom.xml file all about? The first step is downloading the GWT-Maven plugin for Eclipse (which takes care of most of the heavy lifting) http://gwt-maven.googlecode.com/svn/docs/maven-googlewebtoolkit2-plugin/index.html . Once you've installed the plugin, you're ready to organize your pom.xml files (one each for: data, widgets, web app).

Our studyblue-data pom.xml file looks like the combination of the following:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xsi="http://www.w3.org/2001/XMLSchema-instance" schemalocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">

  <modelversion>4.0.0</modelversion>
  <groupid>studyblue</groupid>
  <artifactid>studyblue-data</artifactid>
  <version>1.1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
  <name>studyblue gwt data</name>

This is the portion that indicates how the jar should be created. The jar's title is "[artifactId]-[version].[packaging]". The parts in red, you would subsitute with your own information. *Note: We use -SNAPSHOT to notify Maven that the jar should be updated on every build (see below).

  <repositories>
    <repository>
      <id>gwt-maven</id>
      <url>http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/</url>
    </repository>
  </repositories>

  <!--  include pluginRepository and repository for GWT-Maven -->
  <pluginrepositories>
    <pluginrepository>
      <id>gwt-maven-plugins</id>
      <url>http://gwt-maven.googlecode.com/svn/trunk/mavenrepo/</url>
    </pluginrepository>
  </pluginrepositories>

The repositories tag tells your project where to download the gwt jars (servlet, user, etc). The pluginRepositories tag tells your project where to download the Maven-GWT plugin.

  <build>
    <plugins>
      <plugin>
        <artifactid>maven-compiler-plugin</artifactid>
        <configuration>
          <source>1.6</source>
          <target>1.6</target>
        </configuration>
      </plugin>
      <plugin>
        <artifactid>maven-eclipse-plugin</artifactid>
        <version>2.5.1</version>
        <configuration>
          <additionalprojectnatures>
            <projectnature>org.maven.ide.eclipse.maven2Nature</projectnature>
          </additionalprojectnatures>
          <additionalbuildcommands>
            <buildcommand>org.maven.ide.eclipse.maven2Builder</buildcommand>
          </additionalbuildcommands>
        </configuration>
      </plugin>
    </plugins>
    <resources>
      <resource>
        <directory>src/main/java</directory>
        <includes>
          <include>**/client/**</include>
          <include>**/*.gwt.xml</include>
        </includes>
      </resource>
    </resources>
  </build>

The build tag tells Maven what Java version you want your jar to be compiled into (1.6 in this case). The resources tag lets your project compiler know which java files should be included in the jar (i.e. ALL YOUR CODE).

  <properties>
    <gwtversion>1.5.3</gwtversion>
  </properties>

The properties tag allows us to set a variable (gwtVersion) so Maven knows which version of GWT it needs to download when compiling. When it's time to upgrade, just change the version and the rest takes care of itself.

  <dependencies>
    <dependency>
      <groupid>com.google.gwt</groupid>
      <artifactid>gwt-user</artifactid>
      <version>${gwtVersion}</version>
      <scope>provided</scope>
    </dependency>
  </dependencies>

The dependencies tag tells your project which jars you need to compile. In the case of the studyblue-data and studyblue-widgets modules, we reference the GWT user jar, so we need to include it. Notice it takes use of the gwtVersion variable. There are six different types of scope. The three most important are "runtime", "provided" and "compile". Runtime means "I don't need it during compilation of the jar, but I do need it when the jar is executed." Provided means "The project that depends on this module will provide the jar". Compile means "This module needs the jar immediately for compilation".

In this case, we plan on connecting the studyblue-data and studyblue-widget modules to our main web app, which will "provide" the necessary GWT jars for these modules.

    <dependency>
      <groupid>studyblue</groupid>
      <artifactid>studyblue-data</artifactid>
      <version>1.1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>

If one module needs to reference an additional module (i.e. studyblue-widgets depends on studyblue-data), you could insert the above code into studyblue-widget dependencies.

  </project>

Don't forget to close your project tag :) Make sure you generate the appropriate pom.xml for your widgets module as well.

Deployment

Alright, so you've separated your data and widgets from your main app. You built two projects and included a pom.xml file in each. Now it's time to build studyblue-data and studyblue-widgets into jars so you (and your teammates) can use them as necessary.

This part is super easy, just open command prompt or terminal and navigate to the project's root folder. Type the following:

  mvn clean deploy

That's it. Your project will be compiled with all the necessary libraries and is available for consumption by you and your teammates under the title entered above (studyblue-data-1.1.0-SNAPSHOT.jar and studyblue-widget-1.1.0-SNAPSHOT.jar).

Putting It All Together

So, you now have the two jars available, and you could just simply add them to your main web app's classpath. However, if you enable Maven on your main web app, you'll be able to take advantage of Maven's dependency management. This way you'll be able to download updated jars instantly and automatically. Additionally, assuming your main web app project is Mavenized you can include the GWT jar dependencies (servlet, user, etc) in the web app automatically.

To do this, you need to insert the following into your main web apps pom.xml below the properties tag:

  <profiles>
    <profile>
      <id>gwt-dev-windows</id>
      <properties>
        <platform>windows</platform>
      </properties>
      <activation>
        <activebydefault>true</activebydefault>
        <os>
          <family>Windows</family>
        </os>
      </activation>
    </profile>
    <profile>
      <id>gwt-dev-mac</id>
      <properties>
        <platform>mac</platform>
      </properties>
      <activation>
        <os>
          <family>mac</family>
        </os>
      </activation>
    </profile>
    <profile>
      <id>gwt-dev-linux</id>
      <properties>
        <platform>linux</platform>
      </properties>
      <activation>
        <os>
          <name>Linux</name>
        </os>
      </activation>
    </profile>
  </profiles>

The profiles tag allows our developers to use whichever GWT jars are necessary for their operating system (takes care of Windows vs. Mac vs. Linux automatically :) ). No more keeping copies of all GWT jars and native libraries in your project folder.

Finally, modify the dependencies section to look like this:

  <dependencies>
    <dependency>
      <groupid>com.google.gwt</groupid>
      <artifactid>gwt-servlet</artifactid>
      <version>${gwtVersion}</version>
      <scope>runtime</scope>
    </dependency>
    <dependency>
      <groupid>com.google.gwt</groupid>
      <artifactid>gwt-user</artifactid>
      <version>${gwtVersion}</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupid>com.google.gwt</groupid>
      <artifactid>gwt-dev</artifactid>
      <version>${gwtVersion}</version>
      <classifier>${platform}-libs</classifier>
      <type>zip</type>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupid>com.google.gwt</groupid>
      <artifactid>gwt-dev</artifactid>
      <version>${gwtVersion}</version>
      <classifier>${platform}</classifier>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupid>studyblue</groupid>
      <artifactid>studyblue-data</artifactid>
      <version>1.1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupid>studyblue</groupid>
      <artifactid>studyblue-widgets</artifactid>
      <version>1.1.0-SNAPSHOT</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>

Notice here that the <scope> for the GWT jars is "compile", which ensures they are downloaded during compilation of the web app and "provided" to the dependent modules studyblue-data and studyblue-widgets. The GWT servlet jar is only needed when the web app is executed, so we choose "runtime" here.

Don't forget your gwt.xml

In order to make sure that our main web app knows about studyblue-data and studyblue-widgets we have to include the following lines in our main app's gwt.xml file:

<inherits name='com.studyblue.data.Data' />
<inherits name='com.studyblue.widgets.Widgets' />

Reflecting Updates In Your Modules

During development, we want our main web app to reflect changes that we make in the modules (studyblue-data and studyblue-widgets), everytime we build the project. This way every developer who is working on a project that references the modules (including our main web app), can get the latest build of the jars. We use the Maven keyword "-SNAPSHOT" when versioning our modules during development (i.e. studyblue-data-1.1.0-SNAPSHOT). Snapshot is a special version that indicates a current development copy. With a SNAPSHOT version, Maven will automatically fetch the latest SNAPSHOT every time you build your project. For rapidly moving code, this can be a necessity, particularly in a team environment. When you are ready to release the code, you finalize the version by removing "-SNAPSHOT".

To update your SNAPSHOTS before executing hosted mode or compilation, run this command in your project's root directory:

mvn clean --update-snapshots

Running Hosted Mode and Compiling

As long as your Maven dependencies are added to your project's classpath, you can execute hosted mode and GWT-Compile without worry. At StudyBlue, we use the Maven plugin for Eclipse (http://m2eclipse.sonatype.org/update/ ) to add all our Maven dependencies to our classpath, update snapshots and for editing the pom.xml files.

Conclusion

Maven can be tricky to setup, but once you've got it connected to your GWT project, you'll be amazed at how efficient and modular your application can become.

Widget Best Practices / Widget Building

2009-05-01T17:48:00.000-07:00

Developers often asked what's the best way to go about building custom widgets. There are of course a number of best practices to consider when answering this question. In this post I'll highlight a few I like to start off with.

Prefer composition to inheritance. Unnecessarily exposing implementation details is generally a bad idea, and it's no different when you are building custom widgets. In GWT terms, this means that your custom widgets should typically extend Composite.

// Here the HorizontalPanel implementation is exposed
// Others may come to depend on the presence of one or more inherited methods public class OverExtendedWidget extends HorizontalPanel {
  public OverExtendedWidget() {
   //...
  }
}

// The use of HorizontalPanel is a hidden implementation detail
// We are free to change the implementation without affecting others public class ConservativeWidget extends Composite {

  private final HorizontalPanel panel;

  public ConservativeWidget() {
   panel = new HorizontalPanel();
   initWidget(panel);
   // ...
  }
}

Conservative API. Extending Composite also ensures that you do not inadvertently expose methods inherited from the parent classes into your new widget's API. Doing so can quickly lead to other classes depending on not only your class' implementation, but also the implementation of any parent classes. Remember, you can always add to your API. It's generally impossible to take anything away without introducing a breaking change.

public class LabeledTextBox extends Composite {

  // Be wary of multiple constructors as they can quickly get out of hand
  public LabeledTextBox(String labelText) {
   // ...
  }

  public LabeledTextBox(String labelText, boolean hideUserEnteredText) {
   // ...
  }

  public LabeledTextBox(String labelText, String textBoxText, boolean hideUserEnteredText) {
   // ...
  }

  // Only expose getters and setters if you have a use case for them
  public void setLabelText(String labelText) {
   // ...
  }
  public String getLabelText() {
   // ...
  }
}

Recycle and reuse. When your widgets repeat themselves try to avoid mirroring that repetition in your implementation. Often it is better to compose your new widget out of smaller, reusable widgets. This can both reduce widget complexity and allows improved testability. In a future post we'll explore widget design trade offs and lighter weight alternatives to widget composition to ensure the best possible user experience, which is GWT's ultimate mission (see GWT's mission statement for details).

public class LoginPanel extends Composite {

  private final VerticalPanel container;

  // We've decomposed the Label/TextBox pair into a separate LabeledTextBox widget class
  private final LabeledTextBox usernameTextBox;
  private final LabeledTextBox passwordTextBox;

  private final Button loginButton;

  public LoginPanel() {
   container = new VerticalPanel();
   initWidget(container);

   usernameTextBox = new LabeledTextBox("Username");
   container.add(usernameTextBox);

   passwordTextBox = new LabeledTextBox("Password", true);
   container.add(passwordTextBox);

   loginButton = new Button("Login");
   container.add(loginButton);
  }

  @Override
  protected void onLoad() {
   super.onLoad();
   usernameTextBox.setFocus(true);
  }
}

Design for real use cases. Instead of just imagining how your API might be used, you should write actual use cases that you want to support. You can start with a few lines of code which construct and use your new widget. Once you get the hang of it, you may want to consider test-driven development, a software development method whereby you write failing tests before you implement the features and functionality to make those same tests pass. While it may feel odd to write code that uses non-existent classes and/or interfaces and doesn't even compile, it can really help to flush out design problems early on. This should also help you with your 'Conservative API' efforts since the compiler will only complain about methods you actually try to use. As a bonus you can use your IDE to help you stub out your code. Eclipse, for example, provides many different kinds of Quick Fixes.

Eclipse Quick Fix offers to create a new Java class for you.

Eclipse Quick Fix can add missing methods or make other code changes for you.

Use Style. Your widgets should have a default look and feel. Your widgets should also allow for easy styling so that they will fit in with the rest of the page they live on. Providing CSS class names to key DOM elements in your widget is a good start. Setting a (primary) style name in the constructor is generally a good practice as well. This allows a designer to easily use different class names for different instances of your widgets on the same page. Browse the source for some of the out of the box GWT widgets to get an idea on how to do this.

public class RadioButton extends CheckBox {

  public RadioButton(String name) {
   // ...
   setStyleName("gwt-RadioButton");
  }

  // ...
}

Clean up after yourself. If you do extend Widget directly, use onLoad()/onUnload() rather than onAttach()/onDetach() to perform any DOM attachment setup or detachment cleanup. Any JavaScript references, such as event listeners, should be cleaned up in onUnload() to avoid memory leaks. Those same references should be setup in onLoad() rather than in the widget constructor. See for example the Checkbox source code. Recall that the widget life-cycle consists of three stages (1) construction, (2) attach to DOM, (3) detach from DOM. The most common life cycle for a widget is simply 1→2. Since GWT is all about building AJAX applications, many of your widgets will at least see a 1→2→3 life cycle. Widgets that move around the DOM as they are manipulated on the page will likely see a 1→2→3, 2→3, 2→3, ... life cycle. A common way to be tripped up by life cycles is when you, say, move your initialization code from widget construction to the onLoad() method without realizing that onLoad() is called each time your widget is (re)attached to the DOM.

  // This method is called when a widget is attached to the browser's document
  @Override
  protected void onLoad() {
   setEventListener(inputElem, this);
   // ...
  }

  // This method is called when a widget is detached from the browser's document
  @Override   protected void onUnload() {
   // Clear out the inputElem's event listener (breaking the circular
   // reference between it and the widget); avoid memory leaks
   setEventListener(inputElem, null);
   // ...
  }

I hope you enjoyed reading a few high level best practices for widget design. In a follow-up post we'll continue to look at widget design through the eyes of the GWT compiler.

Finally, I hope you join us at Google I/O where we will have a number of sessions dedicated to GWT and plenty fellow developers to talk to, both on the conference room floor and in the developer sandbox.

GWT Community Updates

2009-04-30T09:27:00.000-07:00

Community announcements

Need a diagramming component in your GWT app? Now you can have one, thanks to the gwt-connectors project developed by Robert Waszkowski. The gwt-connectors project, which uses Fred Sauer's gwt-dnd, allows you to create components, drag them around, connect them together, and then drag some more (with connectors redrawn appropriately). It's really quite fun, you should give it a try.

HtmlUnit 2.5 released: For many, using JUnit TestCase and GWTTestCases to test their GWT applications is enough to sleep easy at night. However, in some cases, you want to test app navigtation flows in an automated way. For these cases, HtmlUnit comes to save the day. The HtmlUnit framework allows you to write tests that navigate through your application, fill forms, access attributes and values and so forth, and includes support for GWT.

A SimpleGesture goes a long way: A developer at IT Mill Toolkit decided to use his 10% time to build something really neat - a gesture-recognizing widget. Using SimpleGesture, you can capture mouse gestures in a given widget and trigger an associated action. You should give the demo a try if you want to see it in action, and look up the source code if you want to code it into your own applications. It turns out that this widget also works quite well with a Wiimote.

More fun stuff

Google I/O: The Google I/O website has been updated with new sessions, speakers and developer sandbox participants . It will be a great event for those who want to learn the latest about Google developer products or who want to mingle with other developers who are in the field and have built applications using Google technologies. We're hoping to see you there!

Introducing GWT 1.6 and friends

2009-04-07T15:31:00.000-07:00

Starting today, there is a simpler way to use the Java^TM language to develop and deploy world-scalable web applications. We are very happy to announce today:

Google Web Toolkit 1.6,
An early look at Google App Engine for Java, and the brand-new
Google Plugin for Eclipse that supports a productive integration of the two.

What does this mean for you? It is easier than ever to create sophisticated web applications entirely in the Java language with Google Web Toolkit while working productively in Eclipse. And the moment you're finished, with only a few button clicks you can upload and publish your application to the world on App Engine.

In GWT 1.6, we've tried to make common tasks simpler while making it possible to do even more advanced things. If you're brand new to GWT, some of this is going to sound like gibberish, so you'll also want to take a look at the Product Overview as a gentler introduction.

Direct support for war output and related tools

GWT 1.6 changes the conventions for project organization to center on the standard Java web archive deployment structure. This new war support makes it easier to introduce GWT modules into existing web applications. It also makes GWT development more flexible by allowing hosted mode to work easily with any standard servlet container.
In conjunction, there is a new webAppCreator tool which replaces the older projectCreator and applicationCreator tools. It is a unified, war-aware tool that can quickly create a working GWT module, configuration files, source files, and an ant build file that you can use as a starting point for your own code.
And, of course, it's pretty easy to create a war directory layout that you can upload to App Engine.

Hosted mode and compiler enhancements

Hosted mode has been enhanced to take advantage of the new war-centric project structure to provide additional conveniences. For example, the new "Restart Server" button reloads server-side code without you having to restart your debugger, which can save you time when you're developing RPC services. Also, for you GWT experts out there using hosted mode with your own custom servers — if you know what "-noserver" is, I'm talking to you — you'll be glad to know that hosted mode integration "just works" now; generated resources such as bundled image files are automatically recreated when you refresh the hosted browser. This, too, can help speed up your development cycle.
Hosted mode has also been modified to work smoothly with EMMA's offline instrumentation, so that you can easily generate code coverage reports. If you're an Eclipse user, in addition to using the new Google Plugin for Eclipse, you should also look at EclEmma, which makes it easy to enable code coverage for any launch configuration.
Finally, the GWT compiler has gone parallel. It can compile multiple output permutations in parallel using the new -localWorkers flag, which can speed up web mode compiles noticeably on multi-core machines. In more elaborate build systems, it is also possible now to do parallel distributed compiles using the new compiler lifecycle classes Precompile, CompilePerms, and Link.

New widgets and a shiny new approach to event handling

A big change that you will surely notice is GWT's overhauled event handling. The new Handler pattern for managing widget events is easier to understand and more succinct than in previous releases. Widget writers can also easily create their own custom events.
The customizable and internationalized DatePicker is now a standard widget, and the new LazyPanel helps you speed up your code by delaying the creation of widgets until they're actually needed.
There's also a new API for triggering browser native events programmatically, which is a real boon for unit testing.

As usual, there are many more improvements than we can list above. The issue tracker has the full list of changes. We hope that these new features in GWT 1.6 will seem like only the beginning, though, as you start to using GWT alongside the new Google Plugin for Eclipse and deploying your code on App Engine. There's lots more to come on how these technologies work together to help you do cool new stuff faster.

Last but not least, the GWT team will be at Google I/O on May 27-28, giving in-depth sessions on GWT and eager to hear your feedback on these new features. We hope you'll join us.

Download Google Web Toolkit 1.6

Google Plugin for Eclipse™ — Peanut Butter to Eclipse's Chocolate

2009-04-07T14:27:00.001-07:00

Eclipse™ is a delicious Java™ IDE. However, developers using it to create Google Web Toolkit (and now Google App Engine for Java) web applications have found themselves wanting better integration.

That's why we are very happy to announce the first release of the Google Plugin for Eclipse. Not only does the plugin make it easier to work with App Engine for Java and GWT; it also makes projects using both easier. A few key features:

New Web Application Wizard
Quickly create web applications that use GWT and/or App Engine. Your new application is fully configured and ready to go.

Run/Debug Web Application
With a single click, you can run or debug your web application locally. No more command-line headaches!

Google App Engine for Java
Deploying your application to the cloud is easy with the deploy wizard...

As-you-type validation ensures that your code is compatible with App Engine.

Google Web Toolkit
We've enhanced Eclipse's Java environment to integrate seamlessly with GWT:

Recognition of inline JavaScript (JSNI): syntax highlighting, auto-indenting, Java Search and Refactoring integration
GWT compiler shortcuts and configuration UI
Wizards to create entry points, modules and HTML pages

Ready to dig in?