Google Web Toolkit Blog

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?

GWT Community Updates

2009-04-02T10:02:00.001-07:00

It's about that time again. We've had a lot of activity in the community since the last update that we'd like to share. Check them out below:

Community announcements

Spreading the word: The community is lucky to have a number of active members who blog, present and contribute to GWT. They are often a great resource for more news about GWT than can be tracked in our own single blog. Check out some of these GWT gems below:

onGWT: maintained by Didier Girard, it's constantly updated with tidbits of news relating to GWT.
Roughian Examples : Ian Bambury has created a site that gives a different take on how GWT components fit together. There is also a free email course available!

IT Mill Toolkit 5.3.0 production release ready: The folks at IT Mill have worked hard to create IT Mill Toolkit - a set of technologies and tools that allow you to develop Ajax applications using Google Web Toolkit based, server-side binded widgets. Check out their latest production release announcement for more details.

GWT Articles section revamped: We've been working on updating and enriching articles on various GWT topics. The latest addition treats the topic of testing methodology using GWT. Please check out the new articles and let us know what you think of them. Also, if there is a topic that you are an expert on that you would like to write about, get in touch with us.

More fun stuff

Google I/O: Google's developer conference is just around the corner. If you're planning on attending, you're still in time for early bird registration prices! There are going to be some great GWT sessions presented at this year's conference that you won't want to miss. We're hoping to see you there!

Google Web Toolkit 1.6 RC2 Now Available

2009-03-30T19:00:00.000-07:00

The Google Web Toolkit engineering team is happy to announce that the second Google Web Toolkit 1.6 Release Candidate is now available from the project download page for you to try out. (The first GWT 1.6 Release Candidate was announced a couple of weeks ago on the the GWT Developer Forum.)

New Project Structure in GWT 1.6

GWT 1.6 introduces a new project structure based on the standard J2EE web archive (war) format. We believe this will make it much, much easier to add a GWT module into an existing web app or otherwise mix GWT with other technologies. For more details, check out the updated standard directory and package layout for GWT 1.6.

New EventHandler System

The event system has been updated to be more in line with Java norms, making it both easier to use and easier to write your own widgets. This also paves the way for making events easier to extend in the future. Have a look at the new EventHandler and HandlerManager classes to get a sense for how they work. We've also added new methods for triggering real native browser events.

New Widgets

The new DatePicker and DateBox widgets allow your users to select a date from a calendar. The new LazyPanel widget makes it easy to delay the creation of certain sections of your application until they are first accessed, improving startup performance.

For full details, be sure to check out What's New in GWT 1.6?, and then download the release candidate and give it a whirl. Let us know what you think in the GWT Developer Forum.

Tell us about your GWT applications and prototypes

2009-03-27T14:28:00.000-07:00

A common question that is asked when developers and IT managers first consider Google-Web-Toolkit is: Who's using it? There are a number of places where you can find a partial answer such our own App Gallery or the Google Code blog. The community has started its own lists as well, such as those here, here and here.

While we encourage you to share directly with the GWT community in the user forum, we realize some of you may prefer to give feedback more privately, perhaps because your company policies require you to. If you have a story you would like to share, we would love to hear about it. Just send me an email.

I look forward to hearing about your GWT projects and experiences.

Giving your GWT Application a Voice

2009-03-04T16:20:00.000-08:00

Jason Freeman recently created Piano Etudes, an audio-enabled GWT application integrated with Flash. We're happy to say that Jason had a chance to stop by to talk about the development strategy he used to add audio to Piano Etudes. Check it out below.

As a faculty member at the Georgia Tech Center for Music Technology, I recently developed Piano Etudes, a musical application built with GWT, along with a student of mine, Akito Van Troyer. Since Piano Etudes is about music, audio was a top priority for us throughout the development process. In this post, I’d like to share what we’ve learned from our experiences with audio and GWT and explain how we implemented audio functionality.

There is currently no built-in audio support in GWT; nevertheless, it’s fairly simple to add audio to a GWT app. Several audio APIs for GWT exist in various stages of development, including Fred Sauer’s gwt-voices, CodeLathe’s GWT SoundManager, Jeffrey Miller’s gwt-sound, and the sound classes in the GWT Incubator. Most of these libraries in turn rely upon the Flash Sound API instead of the inconsistent audio support found natively in web browsers.

For Piano Etudes, we found it easier to build our own GWT classes to support the audio features we needed, instead of using one of the APIs listed above. We wrote JSNI methods to access Scott Schiller’s SoundManager2 Javascript Sound API. SoundManager2, which similarly relies upon Flash, is a clean and elegant API that Scott has been fanatically supporting and updating. A couple of the GWT audio libraries also use SoundManager2, though they only support a subset of its API.

Regardless of how you choose to implement audio in your GWT app, we've discovered a few key principles while working on Piano Etudes that you may want to consider:

Keep your audio code in separate Java classes
Tune your application to avoid timing problems with audio
Identify complex audio rendering and move it from the client to the server when necessary

Keep your audio code separate

Because audio support in GWT is rapidly evolving, the API you choose to use today may not be the one you use a year from now. So it’s essential to wrap your audio functionality in your own audio classes. Then if you change implementations later, you’ll only have to tweak a few classes instead of auditing your entire code base.

For Piano Etudes, we created two GWT Java classes to handle all audio functionality. These are the only classes in our code base that assume a particular audio implementation and are also the only classes that contain JSNI methods.

One class, called SoundManager, includes static JSNI methods for initializing SoundManager2 and configuring its global parameters.

For example, Soundmanager.setDebugMode() will enable or disable debugging:

public native void setDebugMode(boolean b) /*-{
  $wnd.soundManager.debugMode = b;
}-*/;

Each instance of our other class, called Sound, represents a single audio file to be played back in GWT. This class wraps methods such as play, pause, stop, getting and setting panning, and getting and setting playback position.

It was important for us to hide SoundManager2’s implementation details from the rest of our GWT code. Both SoundManager2 and parts of our GWT application code have their own bookkeeping, so there is potential for bad cross usage if the code isn't kept separate. For instance, SoundManager2 requires that an ID string be assigned to each sound object, and it uses that ID in many of its methods. Our Sound class handles this ID string internally and privately. The constructor method generates a unique ID string for each instance of the Sound object:

public Sound(String fileName) {
  soundID = CustomIDGenerator.getUniqueId();
  
  // additional initialization code
}

The Sound object then uses this ID in other methods. For example:

public native void stop() /*-{
  $wnd.soundManager.stop(this.@net.jasonfreeman.pianoetudes.client.sound.Sound::soundID);
}-*/;

There is no need for any other application code to be aware of this ID string; they are able to use instances of Sound in a more object-oriented, implementation-neutral manner.

Tune your application for well-timed audio

In Piano Etudes, the timing of audio events is important. Typically, each measure of moveable music is stored as a separate audio file, so when audio files do not play back at the correct times, there is an audible gap or jump between measures of music. Audio timing is similarly important in applications where sound effects are triggered by user actions or where multiple audio files must play back together in sync.

Neither Javascript nor Flash are famous for precise timing, so there is an upper bound on timing precision within GWT as well. But there are a few strategies that do improve precision:

Optimize GWT code. The performance of your audio code can be affected by sluggish code elsewhere. We use a combination of Java and Javascript profiling tools to isolate hot spots and resolve performance problems. It’s also important to realize that even if your app doesn’t feel sluggish, it may still suffer from performance problems that affect audio. For example: I once found a bug in a conditional statement that had turned O(n) code into O(n²) code. Even though the problem was not noticeably slowing down the GUI widget with which it was associated, it was degrading the timing of audio events.

Beware of silent gaps at the beginning and end of MP3 files. These are often created in the encoding process and can cause unwanted delays in audio playback. Use an encoder, such as LAME, that supports a "nogaps" option.

Preload your sound files. When timing is important, create your sound objects and load your audio files in advance. If you wait to do so until the moment you are ready to play them, there will be a noticeable delay the first time each sound is played. In SoundManager2, the "autoLoad" flag will force audio files to load in advance.

Know when it’s time to move server side

Both Flash and GWT have limited capabilities when it comes to audio. You can play sounds, jump around within sounds, combine them together, query waveform data, and perform other basic tasks. Newer versions of Flash do support some sample-level manipulation of audio data, but it would be tough to use these features from JavaScript or, by extension, from GWT. (In fact, it’s tough to use these features at all in their present form.)

So what if your GWT app requires advanced audio features such as sample-accurate timing, sound synthesis, digital signal processing, or mixdowns to audio files? You could implement audio functionality in a Java applet instead of through Flash, taking advantage of a Java-based audio API such as JSyn, JavaSound, or Minim to access additional features unavailable in GWT. But if you’re like me, the headaches associated with Java applets are one of the reasons you’re using GWT in the first place, so that is not an enticing solution.

Fortunately, there is another alternative: render your audio on the server. This successfully avoids the limitations of client-side systems, though it does introduce other issues related to scalability, latency, and bandwidth. While it’s not a universal solution, it is a valuable strategy for your toolbox.

Here’s a simple use case: in Piano Etudes, we wanted users to be able to download the music they created as an MP3 file. In GWT and Flash there is no obvious way to render an audio file to disk or to convert it into an MP3. So instead, we handle this task server side.

When a user clicks a button to download the MP3 of their music, GWT sends a representation of that music to the server; for each audio track, it describes the audio clips in the track and the timings of those clips. We post the data as JSON via HTTP to a PHP script, but this could be done just as easily via any other client-server communication paradigm supported in GWT. Here’s some code for the client side:

FormPanel mp3Form = new FormPanel("_blank");
HorizontalPanel panel = new HorizontalPanel();
Hidden mp3Data = new Hidden("data", timeline.getAsJSON());
panel.add(mp3Data);
mp3Form.setWidget(panel);
mp3Form.setAction(URL.encode(SERVER_SCRIPT_URL));
mp3Form.setMethod(FormPanel.METHOD_POST);

This code snippet submits a JSON array to the server representing the audio clips and timings for each track of music. The JSON data is sent as a hidden field in an HTML form. The result obtained from the server (the MP3 file) is returned to a new web browser window, keeping the GWT app open in the current window.

When the server-side script receives the data from the client, it processes that data to create and run a simple script in a computer-music language called RTCmix. (Classic scripting languages for computer music, such as CSound and RTCmix, are great for rendering audio server-side.) The audio file output by the RTCmix script is then converted to an MP3 using LAME, and that file is returned to the client browser, which downloads it. Here is a simplified excerpt from our PHP script (our entire script is only 100 lines of code):

// initialize the rtcmix script
$audio = tempnam("/tmp", "PianoEtude"); // output file
$script = "set_option(\"AUDIO_OFF\", \"CLOBBER_ON\")\n"; // non-real-time
$script .= "rtsetparams(44100, 2)\n"; // sampling rate and number of output channels
$script .= "rtoutput(\"$audio\")\n"; // output to temp file
$script .= "load(\"" . $CMIX_LIB_PATH . "\")\n"; // library path for rtcmix

// create an rtcmix command to place each audio clip
$timeline = json_decode($data);
foreach ($timeline as $track) {
  $insertPoint = 0;
  foreach ($track as $soundObject) {
    $soFileName = $soundObject[0];
    $soDur = $soundObject[1];
    $script .= "rtinput(\"$soFileName\")\n";
    // insert the audio clip into the output audio file
    $script .= "STEREO($insertPoint, 0, DUR(), 0.5, 0.5, 0.5)\n";
    $insertPoint += $soDur;
  }
}

// execute the rtcmix script
$scriptFile = tempnam("/tmp", "script");
$handle = fopen($scriptFile, 'w');
fwrite($handle, $script);
fclose($handle);
$cmd = "$rtcmix < $scriptFile";
$result = shell_exec($cmd);

// convert to MP3
$mp3File = tempnam("/tmp", "mp3");
$cmd = "$lame $audio $mp3File";
$result = shell_exec($cmd);
// return result
readfile($mp3File);

You can also use client-side and server-side audio together. For example: instead of just having the web browser download this server-generated MP3 file to disk, our GWT app could use a client-side audio API to play it back inside of the app.

Let your GWT application be heard

By using a variety of GWT or Javascript APIs to connect with the Flash Sound API, you can add rich audio features to your GWT apps; for more advanced functionality, GWT apps can communicate with a server to render audio remotely. Regardless of the exact implementation(s) you choose, keeping your GWT app optimized and your audio code structurally isolated will ensure that audio performs well in your app and can incorporate future improvements to audio support in the browser

GWT Community Updates

2009-02-19T09:37:00.000-08:00

A couple of months ago, we put the spotlight on the GWT community to highlight some of the great things that have been going on. Since then, there has been a lot of new activity to talk about, so we'd like to share these announcements with you below:

Community announcements

GWT Server Library (GWT-SL) 0.1.5b Released: The GWT-SL library provides developers with a way to easily use GWT with the Spring framework. In this latest release, the library provides support for integration with Gilead (formerly known as hibernate4gwt) and has been updated to work with GWT 1.5.3, and also includes many other new features and improvements.

Gilead 1.2.1 Released: Gilead lets you export persistent entites from the JVM to the outside world. For GWT, it means easy integration with Hibernate. This maintenance releases includes support for Maven support and comet4gwt among other new enhancements. If you use Hibernate, or any other of the new technologies Gilead now supports, check out the library on their project page.

Dependency Injection in GWT: You may already be familiar with GIN (GWT INjection), a dependency injection library that integrates GWT with the Guice framework. However, in case you wanted to try a new flavor of guice (pun intended), you may want to take a look at the recently introduced suco library, which offers its own guice-style dependency injection technique.

emite 0.4.6 Released: emite is an open-source library that implements an XMPP communication protocol and provides hooks for GWT integration. This means you can now make your GWT applications more chatty using this library. If you want to have your users chatting over and about your GWT application, this library might be worth checking out.

More fun stuff

Google I/O: Google's developer conference is coming back again this year at the Moscone Center in San Francisco, California. If you attended last year, you'll know that lots of great talks and impromptu chats with Google engineers await. Like last year, the conference will feature a handful of awesome GWT related talks, not to mention members of the GWT team onsite to answer all your questions. Check out the registration page if you'd like to meet some of us in person.

Upcoming AJAX panel - JQuery, Dojo, YUI, GWT, and MooTools at the Googleplex

2009-02-13T10:13:00.000-08:00

Community meetups are a great way to meet new people with similar passions and interests as your own. It's also a great place for the community to exchange ideas. Often you get an interesting presentation to boot.

In fact, for those of you interested and within reasonable traveling distance, the Silicon Valley Web Builders and the Silicon Valley JavaScript Meetup Group have organized an exciting AJAX Panel next week on February 18th 2009. There will be representatives there from YUI, Dojo, MooTools, JQuery and of course GWT. There's a lot of interest, so be sure to sign up before the event fills up.

I've also been talking with the SV-GTUG (Silicon Valley - Google Technology User Group) organizers about doing a GWT presentation at an upcoming meeting. We don't have a firm date yet, but I'd like to start collecting your questions and suggestions for material you'd like to see covered. You can vote on other people's ideas or post your own questions here.

Finally, if you know about or organize a local user group that has developers interested in GWT, let me know. I'd like to hear about your group, and perhaps there's a way we can help make your meetings even more compelling.

Google API Libraries for GWT Update

2009-02-06T09:45:00.000-08:00

By Eric Ayers, Google Web Toolkit Team

Another round of updates is ready for the Google API Libraries for Google Web Toolkit (GWT). This update brings bug fixes and new features to three of the existing libraries. The Google Visualization API Library for GWT moves from a release candidate to a public release with a few bug fixes. The Gadgets API Library for GWT now supports GadgetAds , gadget based internationalization and an important bug fix for Windows developers using GWT hosted mode. The Google Maps API Library for GWT now includes support for the GAdsManager and reverse geocoding support. We are also announcing a major update to the Gears API Library for GWT to support the Gears 0.4 feature set, which includes Geolocation, HTTP Request, Desktop and Blob support.

This release is exciting to me not just for the new features that have been added, but also for the number of new contributors to the libraries from the open source community. Special thanks to Mark Renouf for contributing Gears 0.4 support, and all those that filed issues and contributed patches.

You can find the new libraries ready for download on Google Code.

GWT Advocacy

2009-01-16T09:57:00.000-08:00

I'm a huge fan of GWT and have been since its public release in 2006. I have spent a fair amount of my spare time working with GWT by participating in the user forum and contributors forum, submitting patches to the issue tracker and maintaining open source libraries for GWT, including ones providing support for Drag and Drop (gwt-dnd), Logging (gwt-log) and sound (gwt-voices). GWT has gone through a number of exciting releases, with 1.5 easily being the most impressive release yet. You probably know that the team is fiercely working on the upcoming 1.6 release. Andrew posted a month ago about the new features slated for 1.6. As usual, I'm not sure if I'm more excited about what's in the upcoming release or all the possible things we can do next!

I'm pleased to announce that I have joined the Developer Relations team at Google as a Developer Advocate for GWT. Some of you may be wondering what a Developer Advocate does. The role has two parts. We are advocates for you, the developer, which is to make your voice heard within the product and engineering teams at Google. We also advocate broader use of Google Developer Products and APIs. Both roles work hand in hand. By listening to developer's needs I will be advocating to improve GWT as a product. A better product in turn helps increase adoption thereby growing the GWT community.

I look forward to spreading the word and to helping make GWT even better.

GWT Community Updates

2008-12-19T10:00:00.000-08:00

The GWT community is full of activity; so much so that it sometimes becomes difficult to keep track of! I thought it would be a good idea to try and gather some of this action in one place, so without further ado, here's what's going on in the GWT community!

Community announcements

Restlet 1.1.0 released: Using REST APIs with Servlets used to require wasted hours writing custom code. Fortunately, Restlet came along to take that pain away. Even more fortunately, Restlet integrates with GWT to make dealing with REST APIs a breeze. The team has recently announced their 1.1.0 release, might be worth a spin if you've exhausted yourself writing custom code and need some REST.

Hibernate4GWT (Gilead) 1.2 RC1: Hibernate is an extremely powerful ORM framework for the Java programming language. It has proven itself as an invaluable tool for those with tight data-to-domain mapping, and thanks to Hibernate4GWT, has become easily accessible to GWT application developers. Hibernate 1.2 RC1 (aka Gilead) is now available to download.

SmartGWT 1.0 released: SmartClient is a framework that allows you to not only utilize its widget library for your application UI, but also tie these widgets in with your server-side for data management. SmartGWT 1.0, combining both GWT and SmartClient, has been released thanks to the efforts of Sanjiv Jivan. Read more about it in Sanjiv's release announcement.

GWT Maven heaven: The gwt-maven project developed by Charlie Collins and fellow project members provides a way for developers using a Maven to easily integrate GWT into their build system. We also have Nicolas De loof who has been working on a GWT Maven plug-in in the Mojo project. We're happy to say that Charlie Collins and Nicolas De loof are now going to form GWT Maven heaven by integrating the functionality of both plugin together and hosting them on the Mojo project.

Put Your GWT App on Facebook in 10 minutes

2008-12-16T13:33:00.000-08:00

Jared Jacobs is the frontend lead at kaChing, a marketplace for investing talent. He had a chance to stop by and give us the lowdown on his team's successful port of their GWT application onto the Facebook platform. If you're looking to socialize your application on Facebook, read on for the steps to make it happen.

As you may know, social networks like Facebook, LinkedIn, and MySpace can be an excellent place to grow a new business. Most of the kaChing community first discovered us through friends using our Fantasy Stock Exchange Facebook app.

In this post, I'll help you get your GWT app running as a Facebook app. Believe it or not, it can be done in just two easy steps.

Create the Facebook App.
Follow the instructions on Facebook's Getting Started page to create and name your Facebook app. Accept the default settings for now.

Point your Facebook App at your GWT App.
Adjust these Facebook App settings:

Callback URL	Enter the URL of your GWT app's main HTML page. Tip: For a quick development cycle, run your server locally and use a localhost URL.
Canvas Page URL	Choose a path beneath apps.facebook.com for your Facebook app. Also select the Use iframe radio button.

And you're done! Visit the Canvas Page URL that you chose, and you'll see your GWT app running in Facebook. The rest of this post will suggest a couple of ways to integrate more fully, to better leverage the Facebook platform.

Getting rid of unwanted scroll bars

If your GWT app is too wide for the containing Facebook iframe and you can't stomach a horizontal scrollbar, then you need to make your app slimmer - at least when it's running inside Facebook. Facebook's width limit (currently 760px) is a hard limit.

If your GWT app is too tall, it'll be clipped and you'll see a vertical scrollbar along the right side. To fix this, you can specify a large fixed canvas height for your app using the CanvasUtil feature of Facebook's JavaScript Client Library. You can read the docs for more detail, but in practice it boils down to adding the following snippet to the body of your app's main HTML page:

<script type="text/javascript" 
  src="http://static.ak.facebook.com/js/api_lib/v0.4/FeatureLoader.js.php">
</script>
<div id='FB_HiddenContainer' 
  style='display:none;position:absolute;left:-100px;top:-100px;width:0;height:0'>
</div>
<script type="text/javascript">
  window.onload = function(){
    FB_RequireFeatures(['CanvasUtil'], function(){
      FB.XdComm.Server.init('some/path/to/xd_receiver.html');
      FB.CanvasClient.setCanvasHeight('2000px');
    });
  };
</script>

You should customize the highlighted parts. Here's a description of what's going on in the snippet above:

The first script tag loads FB_RequireFeatures, the entry point to the Facebook JS Client Library.
The FB_RequireFeatures call loads the CanvasUtil feature (the FB.CanvasClient object).
Before using FB.CanvasClient, we must set up a Cross Domain Communication Channel between your app's canvas window and the containing Facebook window. This means a) hosting Facebook's xd_receiver.html file somewhere on your server, b) telling the Facebook JS Client Library where to find it (hence the FB.XdComm.Server.init call), and c) adding an FB_HiddenContainer div to the body of your main HTML page to serve as the container for channel iframes.

If your app changes its height from time to time, you can ask the Facebook's JS library to check your canvas window's height at regular intervals and adjust the containing iframe's height to match. To do so, replace the FB.CanvasClient.setCanvasHeight call in the snippet above with:

FB.CanvasClient.setCanvasHeight('2000px',
function(){FB.CanvasClient.startTimerToSizeToContent()});

For more info on the CanvasUtil feature, including how to make the containing Facebook window scroll to a desired location, see this demo iframe app.

Accessing Facebook User Data

If a Facebook user is logged into Facebook when accessing your Facebook app, the app URL will include the user's Facebook ID in the query string as the fb_sig_user or fb_sig_canvas_user parameter, depending on whether the user has authorized your application. (See Authorizing Applications for more on the various request parameters.) You can use this Facebook ID, in conjunction with your app's ID and secret key, to request information about the user from Facebook using any of Facebook's various APIs. As a GWT app author, you are likely to be using a Java server, so consider using one of these Java Facebook clients. We use this open-source Facebook Java API.

For a high-level overview of Facebook's various APIs and their relative merits, I'd recommend a recent blog post by Facebook Platform engineer Charlie Cheever.

Get some Face time for your app

I hope this article helps you get your snazzy, snappy GWT apps to larger audiences. If you can afford the time investment, be sure to utilize social network integration points that can spur viral growth, such as invitations, profile boxes, and activity streams.

Spotlight On Developers Using Google Web Toolkit

2008-12-11T17:40:00.000-08:00

One of the best resources for developers looking for tips on building applications or learning about a new technology is to hear from other developers who have already been through the experience and built world-class applications. That's why we're happy to share videos of a few developers who used the Google Web Toolkit to build rich, sophisticated Ajax applications that have wowed audiences, won prestigious awards and are pushing the boundaries of what we've come to expect from a web application.

Check them out in our new Who's Using GWT page. In these videos, the developers explain how they used GWT to build their apps, their opinions on GWT overall, and tips and learnings from working with GWT. These videos include the developers behind:

GoGrid: the cloud computing infrastructure service provider that won "Best of Show" at the Linux World 2008 Product Excellence Awards.

Lombardi Blueprint: a business process mapping and diagramming tool that was used as a case study at this year's Google I/O conference.

scenechronize: a film and television production management application, presented at the Sundance Film Festival and Festival de Cannes in 2008.

Whirled: a social virtual world website, where users can keep up with friends, discuss on boards, and play a number of wildly entertaining mini-games.

We'd love to hear from others in the community. If you would like to share your experience developing GWT applications with the rest of the community, let us know in the forum.

What's ahead for Google Web Toolkit

2008-12-10T14:53:00.001-08:00

By Andrew Bowers, Google Web Toolkit Team

A lot of discussion occurs in the Google Web Toolkit contributors forum about development progress, feature requests, and the roadmap. We realize that many of you are very busy and would like to see a simple roadmap on the website, so we've updated "Making GWT Better" with our current plans.

As with any development work, its hard to exactly predict when things will land, so we've stayed away from specific dates and releases past the next one. You'll be happy to know that release 1.6 is well underway and on target for Q1 of 2009.

You can check for future updates in the Making GWT Better section of our website.

Release 1.6

Anticipated Time Frame - Q1 2009

New compiled file deployment structure

Easily compile into a war file structure, making it easy to deploy your compiled GWT application into standard servlet containers

Migration from Tomcat to Jetty hosted mode server

A more pluggable architecture for the hosted mode server will enable developers to use servlet containers other than Tomcat with the Hosted Mode browser

Uniform event handlers

Event handlers will be implemented in a uniform fashion across all widgets, with listeners deprecated

DatePicker, LazyPanel migrated in from incubator

New widgets from the incubator

String performance improvements

StringBuilder uses deferred binding to optimize string appends per-browser

Compiler performance improvements

1.6 will introduce parallel permutation compilations and other performance tweaks for faster compiles

Post 1.6

The following are features that are on our roadmap for releases post 1.6, but are in various states of development. As we reach the end of the 1.6 cycle, we'll update the roadmap with which features we are targeting for the next release.

Developer Guided Code splitting

Developer guided code splitting is a mechanism that allows developers to specify asynchronous split points in their code where the code base can be split and downloaded in different chunks. This is currently an R&D project but looks promising.

Analysis of compiled code, aka Story of your compile (SOYC)

Aims to give developers concrete information about their compiled JavaScript, such as which Java classes are generating the most JavaScript code.

In-browser hosted mode, aka Out-of-process Hosted Mode (OOPHM)

In-browser hosted mode will allow GWT developers to debug their apps within a browser rather than GWT's hosted mode browser

UI Binder

The UI Binder will allow the creation of UI elements in a declarative fashion. Watch for UI Binder to land in the GWT incubator soon.

Client Bundle

Client Bundle implements the power of deferred binding used in Image Bundle in a generic fashion so that it can be used on many resources. These include TextResource, ImageResource, and CSSResource

RPC performance improvements

Ongoing work to improve the performance of RPC

Visualizations in your GWT application

2008-12-09T09:41:00.000-08:00

By Eric Ayers, Google Web Toolkit Team

For those of you interested in creating visualizations in your Google Web Toolkit applications, we're happy to announce the Google Visualization API Library for Google Web Toolkit (GWT). This adds another library of Java language bindings for JavaScript APIs provided by Google, collectively known as the suite of Google API Libraries for Google Web Toolkit.

We're also releasing a General Availability build of the Google Maps API Library for GWT. This build contains a few bug fixes that contributors have reported. Thank you for reporting those, and please continue to report them in the issue tracker.

You can read more about the new Visualization API in the announcement on the Google Code blog.

GWT: No need to shortchange your style

2008-12-08T14:41:00.000-08:00

StudyBlue is an academic social networking application, built with GWT, that helps students study smarter, faster. StudyBlue has done a great job with their application styling and design, so much so that they are shooting for a Crunchie Award on Tech Crunch for Best Design 2008.

We're fortunate to have StudyBlue President Chris Klundt and Eric Wuebben, Creative Director for StudyBlue, share their experience styling their potentially award-winning application using GWT and well-planned CSS techniques. If you've ever wondered how you can turn your GWT project into the next most styling application on the block, read on below.

We've been approached by many programmers and designers alike that question how we got such a custom look using GWT. Our response is simple, "Use GWT to build the house, not to paint it." When you build a new house, you don't have your building contractor pick out the furniture, choose the color palette, or stencil the walls. Similarly, you shouldn't use GWT to inject all the "style" into your website. Instead, you rough it out with GWT and push the design to CSS.

Whether you're building a small widget to embed in an existing site, or you're building an entire web-application from scratch (that's us :-) ), we recommend the following three tenants to ensure maximum design efficiency and flexibility:

Know your design team

Keep all visual elements in the CSS

Deploy to a test environment

Know Your Design Team

Sticking with our home construction analogy, you might go about building a home by first having an architect envision a space, then having his apprentice detail the blueprints, before finally having a contractor build the house. Similarly, you should assemble a good design team before diving into the construction of your site with GWT. Chances are, if you are a strong Java programmer (i.e. "the GWT Programmer"), you are not as strong at CSS design and image slicing. You need to know what team members you have at your disposal, and what their strengths are. Once you're set with a Designer and a CSS Stylist (they may be the same person), we recommend you follow this general workflow:

Create a Photoshop image of the widget/site. This file should assume that "anything is possible" and be the ideal look for your widget/site.

Have the Web Designer slice the image into pieces that can be implemented using HTML Tables or DIVs. Even better if this stage can be accomplished with future flexibility in mind for mulitple uses, flexibility, etc...

Layout the "blueprint" in complete HTML. Create exactly what the HTML code should look like after the respective GWT application code renders the widget/site.

Begin building the layout using GWT. Remember to make mini-widgets out of every piece of reusable code.

Let's elaborate a bit on points 2, 3 and 4.

Part of knowing your team means understanding what your Web Designer's preferences are when it comes to using Tables or DIVs. GWT offers widgets that encompass both Tables (HorizontalPanel, FlexTable, etc.) and DIVs (FlowPanel, HTML, etc.). There are benefits and drawbacks to using each of them. For example, Tables might be good for vertical/horizontal centering or adding stability to a grid. They are poor for dynamic positioning, hover states, "rounded corners", etc. Whatever the case, both the GWT Programmer and the Web Designer should have an agreed understanding on which layouts (Tables or DIVs) are to be used and when it's appropriate to make exceptions. We prefer to do use DIVs, using FlowPanel much more often than HorizontalPanel or VerticalPanel.

Creating a "blueprint" is important for three reasons. First, it helps eliminate guess work from the GWT Programmer. An HTML "blueprint" can quickly be tested on all browsers to prove that the style renders to the structure as expected. Secondly, "blueprints" are an easy way to communicate between GWT Programmer and Web Designer without both parties having to be in the same room at the same time. Plus it makes it easy to assign blame when things don't look right :-). Finally, creating the "blueprint" will help you realize what looks in the original artwork are impossible to recreate on the site (hopefully none).

Note: Using the WebDeveloper plugin (or Firebug's Inspect) for Mozilla Firefox is a great way to inspect your final layout as a GWT Programmer, to make sure you match the "blueprint". More on this later.

Finally, when you start creating the layout in GWT, remember to break down each piece into a Composite class. Not every Composite you create will be reusable. Sometimes you have to make your widgets so specific that they can't be reused. That's OK, it's a common occurrence in UI programming. However, many widgets you can design to be reusable. One obvious example is "buttons" on your website.

Keep all visual elements in the CSS

We can't stress this point enough: PUSH YOUR STYLING TO A CASCADING STYLE SHEET (CSS). Just about everything you can do style wise can be done with CSS, so keep it that way.

BAD:

java

HTML randomText = new HTML("This is some random text in a DIV");
DOM.setElementProperty(randomText.getElement(), "color", "green");
DOM.setElementProperty(randomText.getElement(), "fontSize", "16px");

GOOD:

java

HTML randomText = new HTML("This is some random text in a DIV");
randomText.setStyleName("sb-TextWidgets-RandomText");

CSS

  .sb-TextWidgets-RandomText{
   color: green;
   font-size: 16px;
 }

So, what are we gaining by doing this?

Changing something as simple as color or font-size requires only a CSS update as opposed to redeploying the whole GWT code.

In the above case, we cut out one line of java code. When your application is 40,000+ lines, saving 1-4 lines for every single widget can greatly improve compile time and size.

The Web Designer can make style changes without ever having to look at or run Hosted Mode. (*assuming you have a good test environment - see below)

So let's look at a more complex example, a navigation bar with "hover" and "selected" states. Below you'll notice we've created reusable code for our "hover" and "selected" state that can be used by any widget that we want to implement "hover" or "selected".

Hover Class:

public class Hover {

    private static MouseListenerAdapter mla;

    public static MouseListenerAdapter getHoverMla(){
        if(mla == null){
            mla = new MouseListenerAdapter(){
                    public void onMouseEnter(Widget hoverableWidget){
                       hoverableWidget.addStyleDependentName("hover");
                    }
                    public void onMouseLeave(Widget hoverableWidget){
                        hoverableWidget.removeStyleDependentName("hover");
                    }
                };
        }
        return mla;
    }
   
    .
    .
    .
}

Selected Class:

public class Selected {

    private List<HTML> itemList;

    private ClickListener cl;
   
    public Selected(){

        itemList = new ArrayList<HTML>();

        cl = new ClickListener(){
            public void onClick(Widget selectedItem) {
                for(HTML item : itemList){
                    if(item.equals(selectedItem)){
                        item.addStyleDependentName("selected");
                    }
                    else{
                        item.removeStyleDependentName("selected");
                    }
                }
            }
        };
       
    }
   
    public ClickListener getSelectedCL(){
        return cl;
    }
   
    public void addItem(HTML item){
        itemList.add(item);
        item.addClickListener(cl);
    }
   
    public void removeItem(HTML item){
        itemList.remove(item);
        item.removeClickListener(cl);
    }
   
}

Navigation Bar Class:

public class NavBar extends Composite{

    public static String BLOG_HOME="http://blog.studyblue.com/";
   
    private int ID=1;
    private Selected selector;

    public NavBar(){
        super();

        selector = new Selected();
       
        FlowPanel holder = new FlowPanel();
        holder.setStyleName("NavBar-Holder");    
       
        holder.add(link("Blog",""));
        holder.add(link("About Us","about"));
        holder.add(link("Jobs","about/jobs"));
      
        setWidget(holder);
    }

    private HTML link(String text, String location){
        HTML ret = new HTML(text);
        ret.setStyleName("nav-item-"+ID);
        ret.addStyleName("nav-item");

        selector.addItem(ret);
        ret.addMouseListener(Hover.getHoverMla());
        ret.addClickListener(new ClickListener(){
            public void onClick(Widget sender){
               ///Open popup with blog page location
            }
        });

        ID++;

        return ret;
    }

}

CSS code:

.nav-item {
    background-image: url(images/nav.png);   
    background-repeat: no-repeat;   
    background-position: 0 0;   
    display: block;   
    height: 0px;   
    padding: 30px 0 0 0;   
    overflow: hidden;
}

.nav-item-1 { background-position: 0 0;        width: 65px; }
.nav-item-2 { background-position: -65px 0;    width: 90px; }
.nav-item-3 { background-position: -155px 0;   width: 65px; }

.nav-item-1-hover { background-position: 0 -30px; }
.nav-item-2-hover { background-position: -65px -30px; }
.nav-item-3-hover { background-position: -155px -30px; }

.nav-item-1-selected { background-position: 0 -60px; }
.nav-item-2-selected { background-position: -65px -60px; }
.nav-item-3-selected { background-position: -155px -60px; }

Image File (nav.png)

So, let's break down what is going on here. The NavBar is a Composite which is holding a FlowPanel ("holder"). This FlowPanel is a DIV which is going to hold our 3 links: "blog", "about us", and "jobs". Each one of these links is an HTML widget (i.e. a DIV). Inside the method "link" we first are creating each HTML with the appropriate text, setting its style name with a unique integer, adding an additional style name. From there, we add the link to our "selector" as well as add a "hover" listener. Finally, we add a ClickListener which initiates an action (in this case taking the user to the blog).

Some things to note:

Note the difference between "setStyleName" and "addStyleName". HTML widgets come default with "gwt-HTML" as the SET style name. When you call setStyleName(), you replace "gwt-HTML" with whatever you choose. This new SET style name is what is used when the method "addStyleDependentName" is called. addStyleName() simply just adds an additional style, which is not used for "addStyleDependentName".

In our case, the "hover" and "selected" style names were added dynamically using addStyleDependentName(). So, we needed to make sure that the SET style name was the complete identity (i.e. "nav-item-1"). addStyleDependentName() takes care of adding the additional style names (i.e. "nav-item-1-hover" and/or "nav-item-1-selected").

The additional style name, "nav-item" is added permanently onto each link, but is not the SET style name. Thus, it is always present, despite the addition/subtraction of style dependent names.

The Web Designer and GWT Programmer both know that all widgets will have a style DEPENDENT name of "hover" and "selected" (if necessary), which means the GWT Programmer can recycle the Hover and Selected code, and the Web Developer can anticipate what style names will be present for "hover" and "selected"

*CSS Tip: Loading all of the states (off, selected and hover) into the one nav.png image, helps prevent flickering when the user hovers or selects the link.

Without our CSS, the result would simply look like this:

Blog About Us Jobs

However, by adding a few style names, we are able to achieve a look like this:

We also streamlined our development by standardizing the use of stand-alone buttons on the site. That way, the GWT Programmer can create a button widget that can be reused depending on the size and color button needed. The widget uses DEPENDENT style names to produce small, medium, or large buttons colored with green, white, blue, or red that are preset in the style sheet and work for flexible content lengths.

Deploy To A Test Environment

It is really important to have a test environment for your Web Designer to mess with. As a GWT Programmer, you can't expect that your Web Designer will be able to run Hosted Mode. Also, until the GWT guys implement Out-of-Process Hosted Mode (OOPHM), you will definitely want to take a look at your product in all the major browsers before deploying to production. We run a Tomcat instance on a powerful box over at Amazon Web Services. Using SVN and Ant, we update all our code to the test machine, compile it, create a WAR and deploy it using one command. The key here is that this process takes over 6 minutes every time we want to deploy new code. Six minutes may not seem like that long, but when your Web Developer is waiting 6 minutes every time you need to make a small change to the layout, it gets annoying. So we implemented two ideas to help ease the pain.

First, if you take one thing away from this post, don't style using the GWT DOM class. Set your style names and let the CSS do the work. If we had put all the styles in the GWT code, it would take us 6 minutes to change the color of some trivial text, only to find out that we liked it better the old way (another 6 minutes).

Second, pull out your CSS files and images directory to some location outside your WAR. The idea here is that the Web Designer can manipulate the CSS and imagery without ever getting inside your WAR. This way, when its time to deploy new code, you don't overwrite the Web Designer's changes by replacing the CSS file and/or images on accident. This also helps with remote collaboration. The Web Designer gives the GWT Programmer the "blueprints", the GWT Programmer builds the app and deploys it to the test server, the Web Designer is free to make changes to the CSS and images while checking compatibility across all the browsers. Theoretically, you'd never have to be in the same room (although we don't prefer it that way).

Now get out there and build an awesome GWT house!

Profiling GWT application performance

2008-11-24T16:41:00.000-08:00

By Sumit Chandel, Google Web Toolkit Team

A couple weeks ago, I talked about On-demand widget creation in GWT, a technique you can use to improve the performance of your own GWT applications. What we detailed there was how to apply the technique and what benefits it yields, however we only briefly touched on when and where to apply the pattern.

Applying on-demand widget creation in your application requires a measured understanding of your GWT application's performance. Profiling your application is key to identifying performance hot spots that could be improved using the lazy load pattern or other performance tune-up techniques.

The two key data points to consider when profiling your application are slowdowns and memory usage. Here the term slowdown relates to how slow your application performs in terms of the JavaScript and DOM manipulations that are being processed to run the application. Obviously slowdowns are bad because they lead to sluggish user experiences and less users on your site. Memory usage is equally important as an application that leaks or consumes large amounts of memory is likely to slowdown or crash the user's browser, which also leads to users leaving your site, most likely preceded by profuse cursing.

In this post I wanted to share some tips you could use to profile your own GWT application to help plan your on-demand creation strategy or apply other performance improving code fixes.

Profiling application performance

One of the tools that I usually use to profile GWT applications is the FireBug plugin for Firefox. It has great support for profiling JavaScript performance, which you can use to help find hotspots in your code where certain widget creation calls are taking up too much time and would be better loaded on demand.

Don't try this out just yet! The GWT compiler takes care of optimizing and obfuscating the JavaScript generated from your GWT source, therefore if you tried to run the FireBug profiler over your application without first compiling your application with the -style PRETTY flag, you'll have a really hard time figuring out what you're profiling.

To re-compile your GWT application in PRETTY mode, simply tweak the MyApplication-compile script if you used the applicationCreator or change your GWT compile run configuration to pass the -style PRETTY mode flag to the compiler (e.g. for Linux -compile script shown below):

#!/bin/sh
APPDIR=`dirname $0`;
java  -Xmx256M -cp
 "$APPDIR/src:$APPDIR/bin:$APPDIR/../../gwt-user.jar:$APPDIR/../../gwt-dev-linux.jar"
 com.google.gwt.dev.GWTCompiler -style PRETTY -out "$APPDIR/www" "$@"
 com.google.gwt.sample.mail.Mail;

Once you've compiled in PRETTY mode, you should be able to use FireBug's JavaScript performance profiler with ease to help identify spots where you would want to load your widgets on demand rather than all at once. You can look forward to something like the screenshot below:

Yet another way to profile your application is to do it manually by setting start / finish timestamps before and after the component you care about profiling, respectively. For example, let's say I wanted to determine the initial load time for the phone book application we developed as an example in the last blog post. I would first set a timestamp in my host HTML page, way up in the <head> of the document to make sure that the timestamp is recorded right when the first resource is picked up.

<title>Phonebook</title>
<script language="javascript">
  window.startTime = new Date().getTime();
</script>
<iframe src="javascript:''" id="__gwt_historyFrame"
 style="border: 0pt none ; position: absolute; width: 0pt; height: 0pt;"></iframe>

Then I would add the finish timestamp right at the end of the onModuleLoad() method, which should allow me to get a good indication of how long it took to load the application from start to finish.

public void onModuleLoad() {
...
displayLoadTime();
}

private native void displayLoadTime() /*-{
$wnd.alert("Load time: " + (new Date().getTime() - $wnd.startTime));
}-*/;

A note about what's being measured here - there are some elements that are not included in this measuring technique that affect load time performance. For example, any external scripts that are required to load your application will not be factored into this measure by default; nor will any references to other external resources such as stylesheets. You can include these resources in your load time measurement by adding the corresponding tag in your module XML file so that they are loaded synchronously. Also, image fetches are not included in this load time measure (although you can use the ImageBundle to gather your images in a single download that you can time individually). What's more, any code that is executed in a DeferredCommand or an IncrementalCommand will not be picked up with this measuring technique.

Also, this measure captures the time it takes to execute code to load and display the widget, but not actually render it on the browser DOM with styles applied. Capturing that kind of measure would require far from trivial browser instrumentation.

That said, this measuring technique is still a good way to profile parts of your application and compare them to other implementations since you can accurately measure the time it takes to execute the code responsible for loading your widgets. You could set up the same load time measurement around any other widget creation method that you want to evaluate for on-demand loading. If you feel that setting up alerts to display the load time measurements is a little silly, you may want to take a look at Fred Sauer's gwt-log project, which allows you to log timestamps among other things while developing your GWT application.

Another note about manual timer measurements - there is a slight difference in timer resolution depending in which browser you're running the code above. However, the delta between browsers is usually less than 15ms, and not a humanly noticeable delay. Therefore this difference should be negligible as you collect data points to plan out your on-demand widget creation strategy.

Another thing to keep in mind is that aside from timer resolution differences, browsers do have different load times in general, so it's important to profile your application for each major browser you intend on supporting for your users.

Aside from the profiling techniques described above, there is always the old fashioned way of doing things - just trying it out and seeing how it feels. When something feels sluggish, chances are that it is and needs to be fixed. If you want to drill down to numbers, typically a delay greater than 0.8 seconds in load time is perceived by the user as a full second delay, and starts to qualify an application as sluggish.

Profile and proceed

Hopefully this post gave you some guidance on how to go about collecting data points about your application in order to plan strategies and fixes to improve performance. While some of the profiling techniques listed above should go a long way, the state of profiling tools around Ajax is still evolving and will take some time before becoming the rich environment developers may remember from days of old (desktop development).

A good place to get more tips about profiling and performance tune up techniques is on our very own GWT developer forum. We have tons of developers posting up there who have developed their own tricks to profile their GWT applications and improve performance, and they'd be happy to share their insights if you're looking for more ways to improve your own applications.