The History and Future of Google Web Toolkit

I’ve eagerly anticipated this blog post. There is a lot I have wanted to say about GWT in the past year, and Ray Cromwell says it all in this candid and optimistic Google I/O session.

Highlights

• There are over 100k active GWT developers world-wide
• GWT 2.5 RC1 is now available with many code size improvements and some long-awaited new features (SourceMaps, SuperDevMode, and Elemental)
• Google is moving from gatekeeper to peer among equals on the newly formed GWT steering committee
• GWT trunk is now open for commits by external parties (no Googler intervention required)
• Sencha has released GXT 3, a major refactoring built on true GWT
• Vaadin will be offering commercial support for GWT
• Mgwt is awesome (Mobile GWT, works with Phonegap)

Markers

• 12:05 Introducing SourceMaps and SuperDevMode
• 25:40 Future of GWT
• 29:45 Michael Mullany, Sencha
• 39:58 Joonas Lehtinen, Vaadin
• 49:30 Q&A

Summary

I think it’s obvious to everyone that the GWT team at Google has shrunk significantly over the last year; nevertheless, GWT 2.5 demonstrates that GWT is still moving forward at Google as well as in the open source community. I think enterprises will be especially interested in Vaadin’s first-ever commercial support for GWT, and Sencha GXT customers will likewise be glad to see Sencha on the GWT steering committee. As a mature framework, GWT may not attract the attention and resources associated with the Next Big Thing, but at the same time, GWT 2.5 is better than ever for building large-scale rich Web apps and cross-platform mobile apps in the enterprise.

Troubleshooting App Engine-connected Android projects with c2dm

Google Plugin for Eclipse has a wizard to create an Android project with App Engine back end including client push (c2dm). The official tutorial is quite good, but after spending the better part of a day trying to get the Cloud Tasks sample up and running again, I thought it might be useful to post a few tips.

General Tips

• Sign up for c2dm first. Remember the package name and use it when running the Eclipse wizard! The package name is required, and once you choose the package name on c2dm sign-up, it is nowhere visible later. Be patient–it may take an hour or even a day to activate your account.
• Sign in to Eclipse with the c2dm account name you’ll use (see lower left corner–if not visible, you need Google Plugin for Eclipse). It’s easy to forget this, but Debug As | Local App Engine Connected Project requires you to be signed in.

Run on a Phone With the GAE Dev Server

In this scenario, the phone and dev server must be on the same network! Easiest way is to connect to the same wi-fi router. USB cable does nothing. Be aware that most public wi-fi routers don’t allow devices to contact each other, so it will probably work best at home or on your company’s guest wi-fi network.

• Ensure that phone and dev server are on the same wi-fi network. Disconnect both from any VPNs.
• Add -bindAddress 0.0.0.0 to your Web project’s Run Configuration | Program Arguments. This will start the server listening on all addresses, not just the default localhost (which the phone can’t see).
• When you choose Debug As | Local App Engine Connected Android Application, GPE hardcodes your machine’s IP address in assets/debugging_prefs.properties. This is where the Android app looks up the address of the server.
• You can launch/debug the Android app and the Web app independently; however, if your server IP address changes, you must again Debug As | Local App Engine Connected Android Application in order to update the IP address in assets/debugging_prefs.properties.
• In case you wondered, the Android and Web projects are associated in a file in the Android project. You can find it in .settings/com.google.gdt.eclipse.mobile.android.prefs. To associate a different App Engine project with an Android project, simply edit this file and refresh the project.
• If you’re using the GWT dev mode browser plugin, you can still connect to 127.0.0.1. If you connect to the address shown in Development Mode tab (your machine’s network IP address), you may need to allow the address in the dev mode browser plugin. Click the GWT icon in the address bar to do this.
• Make sure you log in to the Web app as the c2dm user, not the default test@example.com.

Run on a Phone Against the Production App

In the production scenario, you’re using real c2dm so the phone doesn’t have to be on wi-fi at all.

• Edit Setup.java and change APP_NAME and SENDER_ID to match your GAE app id and c2dm account.
• Change app id in appengine-web.xml to match your GAE app.
• Deploy to App Engine with your c2dm account.
• Force sign in to GAE app by going to [prod_url]/tasks/. This triggers the security constraint in web.xml to get logged in to GAE. After logging in, you’ll get an error page, but that’s OK. Then go to [prod_url]/ and Say Hello to App Engine. If logged in, you should see a success message.
• If you’ve previously connected an account on a phone to this production app, go to GAE datastore viewer and delete all records.
• In Eclipse, Debug as | Remote App Engine Connected Android project
• On the phone, you’ll be prompted to connect an account. Use your c2dm account. If you have previously connected a different account, go to Menu | Accounts | Disconnect in the app and reconnect.

The CloudTasks project still has a few issues. Feel free to log them in the tracker.

Is the mobile Web ready for business app developers?

Disclaimer: these thoughts are my own, not necessarily those of my employer.

I recently attended A Night with Sencha and Ted Patrick, and it got me thinking more about the mobile web. Mobile developers are clearly hungry for cross-platform solutions like Sencha and Titanium, and HTML5 promises significant cross-platform compatibility. (Action game developers, you can stop reading now because you already know that the high-performance mobile Web is not there yet. In fact, many folks I talked to last week at GDC are not even using the Android SDK, but rather the Android Native Development Kit to port games from iOS in C.)

Having said that, the mobile web for business app developers is arguably the easiest way to develop mobile apps, period, even without the side benefit of cross-platform compatibility. Why?

• Web development frameworks is a rich and mature space. There are dozens of well-established popular frameworks on both client and server for MVC, CSS, JSON, etc. We’ve been doing Web development for almost 20 years now.
• Web design tools abound. Although IDEs for native apps offer design & layout functionality, more designers are familiar with tools like Dreamweaver for HMTL+CSS. Firebug and Chrome DevTools are the ultimate WYSIWYG editors. Who wants to learn another style language when you’ve finally conquered CSS (kicking and screaming)?
• Mobile browsers, like their desktop cousins, offer great tools for design and debugging (such as Safari Web Inspector and remote debugging with Chrome Beta for Android). Tools like the Window Resizer Chrome extension let you quickly test your app in a variety of different resolutions.
• Frameworks like Sencha do a lot of the heavy lifting around RPC, local storage, dynamic UI creation & data binding. These things take a lot of work to do correctly in a native app.
• You don’t have to worry as much about device compatibility. Mobile browsers aren’t perfect and there are still compatibility gaps (see mobilehtml5.org), but most players in the ecosystem are motivated to ensure that the browser runs well on all devices. The ecosystem is probably less concerned with your apartment finder app. Provided you’re using standard browser features, the browser vendor bears much of the testing burden.

So why does anyone write native apps?

• Monetization, of course. But you can wrap your app in a WebView. As far as I know, WebViews aren’t an issue in any of the app markets with the possible exception of Apple, and according to Ted Patrick, Apple has been good about letting WebView apps in “once they get to know you and find that your app is reliable.” YMMV.
• Native look and feel. Sencha / jqTouch does a convincing job with this on iOS. I haven’t seen it on Android.
• Performance. I already mentioned this with respect to fast-moving games, but most business apps don’t use Canvas or a lot of CSS transitions. And with care, even large apps that manage a lot of data (like mobile GMail for the Web) can be snappy.
• Hardware access. With HTML5, you can get the user’s location and even the accelerometer, but not the camera. At least not yet. But for most business apps, location is all you need.
• Integration with the OS. If your app needs a ContentProvider or background Service or handles Intents, then you do indeed need a native app. Several well-known apps are succeeding with a hybrid approach, however, by using WebViews for rendering and native Services for data access. This simplifies the UI design as noted earlier while retaining other advantages of the platform.
• Finally, native apps let you write code in something other than Javascript. Of course, you could try GWT or Dart and compile to JS, too. Ironically, many of the native cross-platform solutions also require you to write your app in Javascript.

Over the next few weeks, I’ll be porting my listwidget app to native Android and mobile Web using a variety of technologies. I’ll keep you posted.

HTML5 and GWT @ Rich Web Experience

Here are the slides from my HTML5+GWT talk at Rich Web Experience:

Building Mobile and Enterprise Apps with HTML5 and GWT

The talk is very similar to the combined GWT and Dart talk I gave at SenchaCon last month, which you can find at www.dartlang.org/slides/.

Google Plugin for Eclipse now open source

This is pretty big news for the GWT community and should make it easier for GWT frameworks to build tooling for Eclipse. Witness JBoss, who was working on GWT integration even before the announcement. Congrats to the GPE team!

DART slides from SenchaCon

I thoroughly enjoyed SenchaCon this week in Austin, TX, where I presented Building Modern Web Apps with HTML5 and DART. Overall, I was very impressed with the quality of the developers at SenchaCon. It was a special treat to meet Darrell Meyer and Sven Brunken, lead developers for Ext GWT. In the last year, Ext GWT has undergone a huge refactoring to do things more consistently with vanilla GWT (including Cell widgets and the Appearance pattern), and now makes advanced use of these as well as the new AutoBeans framework. I regret not meeting Darrell, Sven, Colin, and team sooner, as they are clearly sophisticated GWT developers who understand the innards of GWT quite well and have taken pains in the last year to make Ext GWT more interoperable with mainline GWT, including throwing away some of their previous work when GWT rolled out with the same functionality unanticipated. I frequently get asked about GWT consulting and am delighted to learn that Sencha has a growing professional services team knowledgeable about GWT as well as all things browser. This is not an official endorsement, but Sencha certainly appears to be one of the few companies capable of handling large GWT projects.

I had lots of fun watching developers interact with the Chromebooks on display in the Chrome booth. Many folks mentioned getting one for their kids or grandmas this Christmas (“and give yourself the gift of no tech support”). I am personally more attracted to the Chromebook than tablets, but that’s mostly because I’m so keyboard-focused (the trackpad on the Samsung Chrombook, by the way, is one of the better I’ve used apart from a Mac–I haven’t tried the Acer Chromebook yet). One place where a tablet would excel is crammed in the back of an airplane, where there’s not really enough room to open my 15″ MacBook Pro. Speaking of which, flights are much more bearable with a laptop and wi-fi. I think I’m addicted to work.

Back to Dart. I regrettably did not leave any time for questions, but was pleasantly surprised at feedback from JS developers after my talk who expressed frustration with Javascript’s lack of typing and scoping and were cautiously optimistic about Dart as a better way to build large-scale apps in the browser. I also met folks who are currently building large apps in JS by compiling from ActionScript. The fact that people are doing this (along with compiling from Java using GWT) definitely points to the need for better languages in the browser.

 

First thoughts on Dart from a GWT developer

I consider myself more of a tools & frameworks guy than a language geek so I’m more likely to groan than gush over a new language for the Web.

However, as I dug into Dart a bit working on a couple of the samples, I have to say I caught a bit of the same fire that I felt when I first encountered Google App Engine and GWT. Dart is fun. Coming from a GWT / Java background, I found it easy to get started.

Here are a few of my favorite things about Dart so far:

1. Closures. You can register an event handler as simply as
   element.on.click.add((Event e) { window.alert('You clicked'); });
   Already, I don’t miss the clutter of anonymous inner classes.
2. Functions can be passed by reference. You can define
   myClickHandler(Event e) { ... }
   and then just write
   button.on.click.add(myClickHandler);
3. Function type aliases are a compact way to create your own callback types.
4. Optional typing. At first I thought I wouldn’t like this. However, as the Ruby community has long pointed out, Java is full of redundancy. Why write
   String[] values = new String[] {"a","b","c"};
   when
values = ['a','b','c'];
   will do?
5. Getters and setters. If you define methods using the get or set keywords, Dart will invoke them when you reference a field using dot notation. That is, some.property automatically invokes some.getProperty();.
6. Constructor initializers. If an argument has this. before it in a constructor argument list, the field with that name will automatically be initialized with that argument’s value. So a constructor that simply assigns arguments to fields can be written on one line:
   Point(this.x, this.y);
7. The Dart DOM and HTML libraries provide convenient and mostly transparent access to the DOM. Thus, you can easily use static layout in an HTML file and call document.getElementById(). The Canvas code in the Sunflower and Spirodraw samples is almost identical to the corresponding Javascript.
8. document.query(id_or_class) and .queryAll() work very similar to jQuery. These are part of the Dart HTML library, which offers convenient access to the DOM.

Thanks to all the syntactic sugar, Dart code is quite a bit smaller than the corresponding GWT app. My GWT sunflower app required very little modification to run in Dart, and the Dart code for the app went from 96 lines to 58 lines. Better still, I replaced the GWT SliderBar widget (almost 1000 lines of Java) with just a few lines of static HTML (my apologies to Firefox users: FF doesn’t support <input type=”range”> yet). Spirodraw was reduced from ~500 lines to ~300 lines, and the control panel layout is completely static HTML, which makes it easier to read.

Of course, it’s very, very early for Dart. GWT is a mature toolkit with a solid IDE (Google Plugin for Eclipse, among others), mature frameworks for RPC, MVP, etc., and a large open source community. But based on first looks, Dart is a promising new way to write Web apps. If browser vendors implement the Dart VM natively, it will rock! Chrome seems pretty likely to do this, at least. Until then, you can use dartc to produce JS for any modern browser. Hopefully, the editor (demo’d in the GOTO conf keynote this morning) will ship soon and make it easy for everyone to get started with Dart.

See also

• Official Dart language site
• Dart code samples (including ported GWT samples Sunflower and Spirodraw)
• Idiomatic Dart (great intro to Dart features)

GWT performance tip: watch out for String.split()

GWT benchmarking inside Google shows that due to intentional emulation of the differences between Java and JS regex, GWT’s emulated implementation of String.split() is about an order of magnitude slower than the native split on all browsers. On Chrome, it can be up to 1000x slower (6000 ms vs. 6 ms) if the strings are large enough (>1 MB in benchmark testing). This isn’t likely to be noticeable in many real-world applications, but if you happen to be doing a lot of String manipulation in GWT, you should consider using JS native methods instead.

Fibonacci fun with GWT

I’ve posted a new GWT Canvas demo at gwt-sunflower.appspot.com. Works in all modern browsers and IE>=9. You may need to refresh the page after loading due to a bug in the SliderBar that I haven’t dug into yet.

Like the previous demo, the math provides the fun. Each time you move the slider, the app clears the canvas and draws dots 1…n, where n is the number of seeds shown in the slider. The position of each seed n is computed using the equations in polar form shown above the figure. The key to the geometry is the golden angle (represented by Φ), which is simply the golden ratio as a fraction of a circle, where the golden ratio is approximated by the quotient of two successive Fibonacci numbers (example: 55 / 89 ≈ 0.618). The basic algorithm to fill the seed head (mathematically speaking, not biologically) is a dial going around and around like the hands of a clock, but counterclockwise in this example. Every time the dial reaches a multiple of the golden angle (0.618 x 360° ≈ 222.5°), a seed pops out. The distance of the seed from the center (r) is proportional to the square root of the seed number.

At any given time in the flower’s “growth,” the number of spiral arms apparent at the outer edge is a Fibonacci number (0,1,1,2,3,5,8,13,21,34,…). The number of spiral arms going in the opposite direction is the next nearest Fibonacci number. This property is true of real sunflowers and in fact, most flowers in the daisy family. See, for example, this tiny wildflower I photographed with my “poor man’s macro lens,” an extension tube. The diameter of the flower was less than half the width of my pinky fingernail.

In order to improve graphical performance, the app uses a coordinate space which is only half the actual pixel size (example: 200×200 vs. 400×400). HTML5 Canvas automatically scales the virtual coordinate space to fill the actual pixel space.

Here’s the essential GWT code.

  /**
   * Draw the complete figure for the current
   * number of seeds
   */
  private void drawFrame() {
    front.clearRect(0, 0, maxD, maxD);
    for (int i=0; i<numSeeds; i++)
    {
      double theta = i * PI2 / PHI;
      double r = Math.sqrt(i) * SCALE_FACTOR;
      double x = xc + r * Math.cos(theta);
      double y = yc - r * Math.sin(theta);
      drawSeed(x,y);
    }
  }

  /**
   * Draw a small circle representing a seed centered at (x,y)
   *
   * @param x Center of the seed head
   * @param y Center of the seed head
   */
  private void drawSeed(double x, double y) {
    front.beginPath();
    front.setLineWidth(2);
    front.setFillStyle("orange");
    front.setStrokeStyle("orange");
    front.arc(x, y, SEED_RADIUS, 0, PI2);
    front.fill();
    front.closePath();
    front.stroke();
  }

The entire source code is available via the link below the figure.

Enjoy!

Google I/O 2011 Highlights

This was my first year at Google I/O, and what a way to start! Besides speaking 3x, I was involved with the GWT Developer Sandbox, GWT Office Hours, and a GWT mini summit the night before I/O for the GWT Developer Sandbox exhibitors and GWT framework authors. The months leading up to I/O were very stressful, but the end result was well worth the effort.

You came for the code

The defining moment for me this year was 10:15am Tuesday, the first presentation after the first keynote. This was the moment of truth we’d all been waiting for. People inside and outside Google had been asking for months, “Did I/O sell out in 59 minutes because people just want the free stuff, or did they come for the code?” As I looked over an audience of 300+ people in a room that seated 239 assembled to hear about Highly Productive GWT, the answer was obvious: you came for the code (watch the first 45 sec of the session to hear the audience confirm it).

All of the GWT sessions (filter for Developer Tools track) were packed, many of them standing room only. Besides giving the latest tips on performance and showing off the latest tools, the GWT team demo’d lots of bleeding edge coolness in GWT: mobile development, game programming (hello, disgruntled avians!), and RequestFactory tooling for native Android apps. It was an exciting year for GWT developers.

I/O is more than a clever name

Google I/O is all about the developer community. Despite the mythical status of many, Google engineers and open source contributors are real people, too, and I/O is the premier place to get acquainted, give feedback, and get help. Besides meeting the session speakers, each product team holds Office Hours for 3 hours each day staffed by engineers, where hundreds of folks got their technical questions answered and hob-nobbed with others in the community.

Said one long-time GWT community member:

The discussions I had there were both a great learning experience and an important source of ideas and motivation. Networking with the extended GWT community was very nice. I feel like I could get working right away with Jeff Larsen, Pierre Coirier, Hilbrand Bouwkamp and others whom I only met via forums before the I/O.

I likewise enjoyed meeting many folks in the GWT community whose names you’ll recognize from the GWT group: Philippe Beaudoin and Christian Goudreau (gwt-platform), Pierre Coirier (mvp4g), Stephen Haberman (gwt-mpv), Jeff Larsen, Jeff Schnitzer (objectify-appengine), and many others. How did they all get to I/O, you wonder? Many were invited to take part as speakers or Sandbox exhibitors. Some made it a point to sign up as soon as registration opened, and others engaged in heroic measures (Pierre was one of 10 winners in the Last Call for I/O contest). My own path to I/O was extreme, as it involved getting hired by Google last year It was a tremendous privilege to serve one of the most talented and enthusiastic developer communities in the world. Besides meeting well-known participants in the community, I also enjoyed meeting the mostly invisible developers who build with GWT every day, learning about the creative and powerful things you’re doing with GWT, listening to your pain points, etc. In the age of everything digital, there is still no substitute for putting a face to a name and getting the story behind the story.

GWT Developer Sandbox

Besides the GWT sessions and Office Hours, the GWT Developer Sandbox (filter for Developer Tools) was a great place to meet companies using or supporting GWT and to pick the brains of fellow GWT developers. The GWT team selected a wide range of companies to participate this year, from public-facing apps (DayZipping, Broadcastr, LoseIt.com) to B2B (BookedIn, GBST) to enterprise and tools/frameworks (JBoss, Apptio, Vaadin). Check out their Web sites and get some ideas for your own apps. There’s a lot going on in the GWT universe.

Related Product Highlights

I was pretty focused on GWT this year, but there were lots of other exciting announcements and sessions for developers: App Engine backends, full-text search, and Pipeline API (map reduce), all of which I hope to dig into before next year’s I/O. Sessions on PageSpeed and Chrome DevTools are required viewing for Web developers who care about performance and productivity. NFC with Android is a promising new technology for all kinds of apps like mobile payments with Google Wallet. And of course, Chromebooks are expected to greatly accelerate the demand for rich Web apps in the cloud. It’s a great time to be a GWT and App Engine developer!

Geek Fest

Nothing says “happy geeks” like the Google I/O 2011 photos, so I’ll conclude with that. Huge thanks to all the GWT developers who attended this year’s I/O and made it the best GWT event ever!