Author Archive

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.

As you may have heard from our announcement this morning, registration for Google I/O is now open. In addition to publishing access to registration, we've also included event details on the I/O website.

We already have quite a few Google Web Toolkit I/O sessions and Developer Sandbox demos lined up, and we expect this number to grow over the coming months. Here's a partial list of the GWT sessions that are already listed on the I/O website:

• GWT + HTML5 can do what?!
• Architecting GWT applications for production at Google
• Measure in milliseconds redux: Meet Speed Tracer
• Faster apps faster: Optimizing apps with the GWT Compiler

Over the next couple of months, we'll be adding new GWT sessions and more GWT Developer Sandbox participants to the I/O website. For updates on when new content is added, follow @googleio on Twitter.

Registration for Google I/O (at the early bird rate of $400) is open as of today. We hope you'll be as excited about this year's I/O as we are, and we look forward to seeing everyone in May.

Google I/O
May 19-20, 2010
Moscone West, San Francisco
http://code.google.com/io

Inevitably, as your app grows, you will find areas that involve consuming large amounts of textual data and performing some action as a result. You may be handling a JSON response, a serialized GWT RPC payload, or HTML that has been rendered on the server. In any case, you're a test-driven developer and you know that you have a handful of automated tests just wanting to be applied. The example below is one way of constructing such tests. And while it's not rocket science per say, it's so simple and useful that we felt compelled to tell others about it.

So let's say you're doing some server-side rendering, and somewhere in your code you most likely have a permutation of the following:

DOM.createDiv().setInnerHTML(foo);

Once inserted, you might apply some style, inject some values into the resulting HTML, etc.. Basically with the DOM structure in place, the rest of your app can move and do its thing. And "its thing" is often the more complex part, which begs for a test case. You want to make sure the "thing" it's doing is the right thing.

So at this point you happily code up a few GwtTestCase(s) and suddenly realize two things. One, "foo" can be really long, is a pain to maintain in code, and is ultimately polluting your test cases. Two, "foo" is most likely to change as your app grows, whereas your test cases shouldn't. Wouldn't it be nice if you could abstract "foo" away into a file that you load into your test cases, just as you do with other non-GWT test cases? Well, the good news is that you can. Much like other resources (e.g. ImageResource, CssResource, etc...), GWT has a mechanism for embedding text files into your app by specifying an associated TextResource within a ClientBundle. For example:

public interface TestResources extends ClientBundle {

  @Source("com/google/gwt/example/test/ExampleTest.dat")
  TextResource foo();

}

Here Example.dat would contain the HTML that I want load into my test case, and given that it's strictly for testing purposes you'll notice that I've added it under the "example/test" folder. At this point we have a ClientBundle from which we can grab the contents of our Example.dat file. In order to do something meaningful with this, we'll use it in a newly constructed GwtTestCase:

public class ExampleTest extends GWTTestCase {

  TestResources resources;

  public String getModuleName() {
    return "com.google.gwt.example.Example";
  }

  public void gwtSetUp() {
    resources = GWT.create(TestResources.class);
  }

  public void testFoo() {
    DOM.createDiv().setInnerHTML(resources.foo().getText());
    /*
     * insert complex code to be tested
     *
     */
    }
  }
}

Using this technique we've managed to keep our test cases clean, and centralized any test data changes within ExampleTest.dat rather than the ExampleTest source code. So clean, so simple, and hey, it even works when you want to load up some JSON data to test with.

GWT 2.0.2 has been released and is available for download here:

http://code.google.com/webtoolkit/download.html

This was a minor release that includes the following fixes:

• Standard.css missing new layout styles (#4429)
• Using a PopupPanel in Internet Explorer without a history IFrame throws a NullPointerException (#4584)

GWT 2.0.3 has been released and is available for download here:

http://code.google.com/webtoolkit/download.html

This was a minor release that includes the following fixes:

• Using a PopupPanel in Internet Explorer without a history IFrame throws a NullPointerException (#4584)
• Opera support for History is not working (#3956)

It's been a while since we've put together what's been going on in the GWT community, and there's no time like the present to do so. Below are a handful of updates and new releases that have taken place over the past few months.

Smart GWT 2.1: Smart GWT, a framework that provides enhanced widgets that can coexist on both your client and server, has released a 2.1 version. Below are some of the key features of this release:

• GWT 2.0.3 compatible
• New Graphite theme
• Support for widgets in ListGrid cells
• Support for Checkbox TreeGrid with cascade selection and tri-state checkboxes (selected, unselected, partial)
• Significant improvement in ToolStrip appearance
• Improved Print support with fine grain control over what widgets and data appears in print view
• Support for Flash, ActiveX, Applets and SVG as Smart GWT widgets
• Various performance improvements

GWT Designer 7.3: Instantiations announced an upgrade to version 7.3 of its popular graphical user interface (GUI) building product, GWT Designer™. GWT Designer v7.3 stays in sync with the major new release of the open source Google Web Toolkit (GWT) version 2.0, adding support for the new GWT 2.0 Development Mode, Layout Panels, Widgets and more. The upgrade includes the following features:

• GWT 2.0 Development Mode Support – provides the ability to debug your project with the browser of your choice. Includes multi-browser debugging, allowing you connect to multiple browsers in a single debugging session and network support, plus a view to embed development mode logging messages directly into an Eclipse view.
• Layout Panels - Employ all new GWT 2.0 Layout Panel types. Layout Panels offer a predictable, constraint-based layout system on top of standard CSS to help you reliably create a desired layout.
• Widgets - Enjoy greater design flexibility with support for all new GWT 2.0 in-line widgets (Label, HTML and Hyperlink).
• Enhanced Ext GWT (GXT) Support – Utilize added support for GXT 2.1 and un-typed GXT events.

RaphaelGWT: The Hydro4GE team has open sourced their RaphaelGWT project. RaphaelGWT allows you to integrate GWT with Raphael, a lightweight JavaScript library for cross-platform vector graphics.

Gilead Update: Gilead, an Open-Source framework for seamless integration of Hibernate and GWT, has released an updated version of its project that contains the following features:

• Predefined remote services
• A new specific transport annotation (@LimitedAccess) to implement custom access to entity fields (role based for example)
• Lazy property checking on the GWT side, to know if a null association on client side was already null on server or just lazy but not loaded (and thus replaced with null by Gilead)
• A ConfigurationHelper class, to limit Gilead configuration to one line of code

GWT MVC 0.4: The GWT MVC project, aimed at creating a layer on top Google Web Toolkit's widget library capable of implementing RIAs in easier and more conceptually guided way based on Model-View-Controller design pattern, has released version 0.4.

GWT Service Resolver: The gwtserviceresolver project has been added to Google code. Similar to gwt-dispatch, gwtserviceresolver allows you to minimize the code changes that are necessary as you add new RPC services.

GWT Mosaic: The GWT Mosaic project has added some tutorials to help developers wire up UiBinder-based elements with GWT Mosaic Actions.

The new crop of HTML5 web browsers are capable of some pretty amazing things, and several of our engineers decided to take some 20% time to see how far we could push them. The result? An HTML5 port of Id's Quake II game engine!

We started with the existing Jake2 Java port of the Quake II engine, then used the Google Web Toolkit (along with WebGL, WebSockets, and a lot of refactoring) to cross-compile it into Javascript. You can see the results in the video above -- we were honestly a bit surprised when we saw it pushing over 30 frames per second on our laptops (your mileage may vary)!

It's still early days for WebGL, so you won't be able to run it without a bleeding edge browser, but if you'd like to check out the code and give it a whirl yourself, you can find it here. Enjoy!

If you're interested in building large scale applications the MVP way, you may want to checkout the latest addition to our articles section: Large application development and MVP - Part II.

In this follow-up article, we look into how techniques such as UiBinder and code splitting work in conjunction with an MVP-based app, as well as how to create complex and optimized UIs, without moving too much code into your views.

If you're in the Atlanta, GA area and interested in Google technologies, you should come down/over/up to the Google Midtown office for tonight's GTUG meeting. The first meeting was fun and positive, with lots of great discussion around GWT, App Engine, Android, and the state of technology overall. Tonight should be just as good, with the following agenda sketched out:

• Rick Thomas -- Wave Development
• David Chandler -- GWT and App Engine
• Lightning Talks
• General Discussion

When: 04/27 @ 7pm EDT
Where: Google Atlanta

Robert Cooper gave a great lightning talk at our recent Atlanta GTUG meetup, where he discussed using a single codebase to target multiple mediums (e.g. Android, Facebook, Wave, etc.). This post was taken from his original post, which is a good read, providing sound pointers as to how you can maximize audience reach with minimal code changes.

Robert's original post

I love crossword puzzles.

In the time before time, I would stop at my local coffee shop and purchase a copy of the New York Times. I would flip to the crossword and with the classic "double fold" begin the crossword puzzle. Mobile devices soon took over the world, and subscribing to the electronic version soon made much more sense than killing all those trees. Last fall, I switched from the orchards of Cupertino to an Android device, alas, there was no good way for me to do the New York Times puzzle on my way to work anymore. Time to start a project.

I developed the original version of Shortyz for Android (named in honor of, and with apologies to, Will Shortyz of the NYT) in about three weekends. It had a number of usability issues and was rough around the edges, but it was "Good Enough for Me." Unfortunately, because of stolen laptop I lost some progress on the source and my market signing key (yeah, I know). So I decided to "do it right." Forgoing the Android classes I implemented my own two-dimensional scrolling, touch handling and rendering code. Now I am quite happy with the results.

Life is good. I am doing crosswords all the time! Enter other people. Pam Fox from Google emails me and asks about a version for Google Wave. Josh Marinacci of Palm IMs me and asks for a WebOS version. To borrow from jwz: "Some people when faced with a problem say, 'I'll use GWT.'" Unlike other technologies, I still only had one problem.

The new Shortyz code was much cleaner. I had implemented a Playboard class as the Controller of my MVC application and was completely independent of the UI code. I moved my IO classes out of the same package as my

Model classes, created a .gwt.xml file, and like that, I had the core of a GWT application. Implement a new UI and I am good to go.

Starting with my Android code, I had a playable web application in about five hours. Not bad, but like the first version of the Android code, I had some annoying usability issues and it was a little sluggish. After another day of work, I changed the UI code from using a play->render cycle like the Android app to use a more traditional MVC data binding system (based on Gwittir), and the performance problems were mitigated.

The next step was to take the web app and make it work everywhere! This is where Gin, a Google Guice DI for GWT apps, was key. My initial web app used a client side persistence mechanism to store play data (HTML5 LocalStorage, Gears, DOM Persistence, Flash). This works great for a standalone web app or a gadget, but for a Facebook version or Wave, I need alternative strategies. For my iGoogle version and Wave, I also need to make requests through the gadget.io API. Gin and Guice made this a breeze. Each of my versions simply becomes a new EntryPoint (or Gadget) class, a new Injector, and a new Module definition.

The real challenge came developing the Wave version. While Apache Shindig makes doing local development of Gadgets easy, there isn't an equivalent local harness for Wave gadgets, so you end up having to do a full build and deploy cycle to work on it. There are also some things that aren't clear from the Wave API docs that creep up, such as the maximum size allowed for the State object. After a solid 40 hours of work, though, I had a co-op play Wave gadget with player colors, remote cursors and nice playback support on the Wave.

So what is the take away here? "Extreme Source Compatibility" is a real thing. This is a Java application running on "Everything But The Java Platform" with the bulk of the code easily reused. Each subsequent version of the app took only a few hundred lines of code to get running. There are some important things to keep in mind. First, making sure your business logic and data models without dependencies on lots of external code is important. Since my Model layer was simple POJOs and my Controller layer pretty much just java.lang and java.util, there was a zero-hour ramp up time to make it work. Cleanly separating this code is also important. Since my input handling code and UI code was cleanly separated, this was much easier than it could have been to do the port. Finally, Guice rocks. While a lot of us in the "enterprisey" world understand the testability advantages of using a DI framework, many rarely have to provide lots of alternate implementations of classes. When you need it, though, it is amazingly handy to have a simple way to re-compose your whole application. Best of all, bugs I fixed in the core library while working on the web version rolled right into the original Android version unmodified.

As an interesting aside: GZipped, the GWT version is about the same size as the Android version; both are less than ~100K for the download. Custom code for each version makes up about 10% of the total LoC, with the exception of the Wave version where it is closer to 25%.

Quick colophon:
Wave for GWT via CoboGWave: http://code.google.com/p/cobogwave/
Gadget Support: http://code.google.com/p/gwt-google-apis/
Gin, Guice for GWT: http://code.google.com/p/google-gin/
Data binding, local storage and JSON serialization: http://code.google.com/p/gwittir/