Friday, May 1, 2009

[Gd] Widget Best Practices / Widget Building

| More

Google Web Toolkit Blog: Widget Best Practices / Widget Building

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();


    // ...



  • 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();


    usernameTextBox = new LabeledTextBox("Username");


    passwordTextBox = new LabeledTextBox("Password", true);


    loginButton = new Button("Login");




  protected void onLoad() {





  • 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) {

    // ...



  // ...


  • 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 12. Since GWT is all about building AJAX applications, many of your widgets will at least see a 123 life cycle. Widgets that move around the DOM as they are manipulated on the page will likely see a 123, 23, 23, ... 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


  protected void onLoad() {

    setEventListener(inputElem, this);

    // ... 


  // This method is called when a widget is detached from the browser's document 

  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.

[Gd] Survey says...

| More

Official Google Webmaster Central Blog: Survey says...

Webmaster Level: All

Many thanks to the more than 1,600 people who filled out our survey in February. You gave us your feedback on the Webmaster Central Blog, Google Webmaster Tools, the Webmaster Help Forum, and our Webmaster Central videos on YouTube.

You told us what you like and want to see more of:
  • Webmaster Central gives users insight into Google: "[I like] being able to access, communicate, and see how my sites relate to Google."
  • Webmaster Central provides high quality information: "What I have enjoyed most of all, is reading Google's guidelines for webmasters, which is on-point with what I have been telling customers about SEO."
  • Webmaster Central collects several useful tools in one place: "It's an innovative central hub for all the tools supported and provided by the industry leader Google, for free."
We also learned about what you don't like and where we could be doing better. Our top finding is that beginner webmasters (about 20% of the survey respondents) are less satisfied than intermediate or advanced webmasters with Webmaster Central. Open-ended comments suggested that new webmasters want basic, less technical information from us. A common feedback that we received: "Many users like myself are not of the hi-tech, IT-savvy variety and prefer simplicity, whether we create a website for information or to generate revenue." Based on your responses, we've planned some new resources like a series of how-to videos especially for new webmasters (coming soon to YouTube).

We take your feedback seriously and will continue improving Webmaster Central and our other webmaster sites. Again, thanks for your participation in the survey. We want Webmaster Central to continue being a useful resource for you.

Written by Carolyn Wei, User Experience Researcher

[Gd] Submit a Talk for Ignite Google I/O

| More

Google Code Blog: Submit a Talk for Ignite Google I/O

Ignite is a series of geek nights started by Brady Forrest of O’Reilly Radar and Bre Pettis of Makerbot Industries that has since spread around the world. The nights combine a Make contest (like a popsicle stick bridge-building contest) and a series of fast-paced, short-form tech talks. To check out past Ignite talks, view the videos at

At Google I/O, we'll be doing a one hour Ignite on the first day of the conference (May 27). In typical Ignite fashion, these talks will each be 5 minutes long with 20 slides and only 15 seconds a slide (they auto-advance). We want to hear your cool ideas, hacks, lessons, and "war stories". What do you want to talk about?

We're looking for speakers to participate, so if you're interested in submitting a talk, sign up via the form below.

Submit your talk for Ignite Google I/O

Submission Deadline: May 11th
Speaker Notification (rolling): May 12th

We’re taking submissions from everyone — whether this is your first time or whether you’ve done an Ignite talk before. Once we've chosen the speakers, we'll be sharing who they are after May 12. Stay tuned!

Guest Post by Brady Forrest, O'Reilly Radar

Thursday, April 30, 2009

[Gd] Widget Design Guidelines

| More

Android Developers Blog: Widget Design Guidelines

Since the beginning of the year, the Android UI team has been hard at work on the Android 1.5 release. Starting today with widgets, we would like to share some of our evolving Android design principles with you.

Widgets are a new feature that application developers can use to promote a small sample of the most relevant dynamic data from their applications on the Home screen. We've designed widgets to fit within our Home screen grid framework, which means you and your designer can create a widget within a 4x1, 3x3, or 2x2 grid cell, depending on the space you need for an at-a-glance summary of information from your application. To illustrate the preferred ways to design widgets for the home screen, we've assembled Widget Design Guidelines.

We're also providing the original artwork assets and source files that we used to create the widgets bundled with Android 1.5. If you want your widgets to match the platform in terms of appearance, use the templates that are available throughout the Widget Design Guidelines.

For more technical information around widgets, take a look at Jeff Sharkey's blog post as well as the AppWidgets documentation.

We've only just begun to scratch the surface of what's possible using widgets. We're looking forward to seeing how far you can extend our work!

One last thing: in the coming weeks, we'll be rolling out more articles and presentations that demonstrate design best practices for Android. For example, if you've ever wanted to learn how to create and be consistent with iconography on Android, stay tuned: we'll be posting sample guides and templates.

Learn about Android 1.5 and more at Google I/O. Members of the Android team will be there to give a series of in-depth technical sessions and to field your toughest questions.


[Gd] PPK: The Open Web Goes Mobile

| More

Google Code Blog: PPK: The Open Web Goes Mobile

Last week I was privileged to host PPK (Peter-Paul Koch) for a Google tech talk entitled "The Open Web Goes Mobile". Most developers building web apps have benefited from PPK's browser compatibility research hosted on his well known site Now, fortunately, PPK is turning his attention to the world of mobile web devices. To no one's surprise, browser compatibility on mobile devices is even worse than it is on the desktop. Or as PPK puts it on his opening slide "Hell is other browsers". Check out his slides or watch the video here.

PPK starts by identifying the four main problems with getting web sites to work well on mobile clients: small memory, small display, flaky browsers, and flaky connections. Memory is an area for more research, especially benchmarking. PPK offers some suggestions for dealing with a small display, including using media queries in CSS (@media all and (max-width: 300px) {}) and offsetWidth in JavaScript.

Mobile browsers themselves are flaky when it comes to advanced CSS and JavaScript. But PPK finds that even basic stuff, such as font-style: italic, has to be verified. As a result of his testing, PPK categorizes mobile browsers into three levels of compatibility:
  • top level: Android WebKit, Safari, Opera Mobile
  • mid level: S60 WebKit, Blackberry, Opera Mini
  • bottom level: NetFront, IE Mobile
Obviously, this is not an exhaustive list of mobile clients. PPK also mentions OpenWeb, Nokia S40, Palm Blazer, Iris, Bolt, Skyfire, Obigo, Fennec, and Teashark. This is the challenge in developing for the mobile web - there are a large number of clients and they exhibit diverse compatibility behavior.

When it comes to flaky connections, PPK points out that your connection speed is affected by the activity of the people around you. It's unlikely that this is going to change any time soon, so it's important to reduce the size of your downloads as much as possible. The problem is that caching on mobile devices isn't always reliable.

The impact of flaky connections can be mitigated by saving your core files on the mobile device. W3C Widgets offers a solution for achieving this. They're local applications written in HTML, CSS, and JavaScript that run inside the mobile browser. Ajax is used to download what's required: data. An advantage of using W3C Widgets is that, if the specification gets wide adoption, widgets will run across multiple mobile devices, and companies won't have to build a custom application for each target device. Right now, W3C Widgets work in Vodafone and Nokia S60 phones and Opera/T-Mobile phones for Windows Mobile, so evangelism to other mobile devices is needed. But the possibility of sharing applications across phones is compelling, for both the user experience as well as reduced development costs for mobile app developers.

By Steve Souders, Performance Evangelist

[Gd] Who's @ Google I/O - spotlight on AJAX and Google Data APIs

| More

Google Code Blog: Who's @ Google I/O - spotlight on AJAX and Google Data APIs

There are over 60 Google APIs across a wide range of products and technologies. The AJAX APIs include Google Search, Language, Maps, FriendConnect, and Visualization APIs. The team recently launched v2 of the AJAX APIs Playground, an app designed to show interactive code samples for some of our coolest Javascript APIs. The Google Data APIs provide a simple standard protocol for reading and writing data on the web and are used by many products including YouTube, Calendar, Picasa Web Albums, and as of last week, Analytics.

Google I/O will feature many sessions covering the AJAX and Google Data APIs. Here are a few of the developers who'll be leading sessions and/or demoing at the Developer Sandbox:
  • Redfin
    Redfin is an online brokerage site for buying and selling homes. Redfin uses the Google Maps, Charts, and Feeds APIs. Redfin actively talks about the behind-the-scenes development decisions, which can be found at the Redfin Developer Blog. (For example, they blogged about why they switched to the Google Maps API) Sasha Aickin, Engineering Manager, will be speaking on a session called Performance Tips for Geo API Mashups.

  • Lonely Planet
    Lonely Planet is known by travelers for producing informed and honest travel advice. Lonely Planet uses the Google Maps Javascript API to power interactive maps on, the Google Static Maps API on its cross-device mobile site,, and OpenSocial, App Engine, and Android in products soon to be launched. Ken Hoetmer, Lonely Planet's neogeographer in residence, will be speaking on a session called Maps APIs & Mobile.

  • Adobe
    Introduced with Adobe Creative Suite 4, Adobe Community Help utilizes Google Custom Search (a product which also supports the AJAX APIs) to aggregate the most relevant help content from the broader community. By integrating search directly within the application workflow, users can find answers to their software questions no matter where those answers may be found. Currently, Adobe is exploring ways of expanding Custom Search to include code samples directly within Adobe development environments for products like Flash and Flex. (Read Adobe's blog post about Adobe Community Help)

  • LuckyCal
    LuckyCal is a calendaring application which utilizes several of the Google Data APIs to create a dynamic calendar experience. They authenticate using OAuth to retrieve data from the Calendar and Contacts Data APIs. Based on where you'll be, who you know and what you like, LuckyCal finds events that are relevant to you. LuckyCal has also created a Google Gadget and uses the Maps API (both for UI and for Geocoding) extensively.

    The Eye-Fi Card stores photos & videos like a traditional memory card, and fits in most cameras. When you turn your camera on within range of a configured Wi-Fi network, it wirelessly transfers your photos & videos to either your computer or services like YouTube, Picasa Web Albums, etc via the YouTube and Picasa Web Albums Data APIs.

  • Vast Rank
    Vast Rank is a college ranking website that utilizes the Google Maps API in their interactive ranking map (where visitors see rankings based on what is in view on the map). With the Client Location API, Vast Rank’s personalization engine can weigh the visitor’s location into the criteria used to suggest interesting colleges to the visitor. Vast Rank creator Jon Kragh will be leading a session, Using AJAX APIs to Navigate User-Generated Content.

  • 280 North
    280 North's application, 280 Slides, enables users to easily create web-based presentations. With the AJAX Search API and Google Data APIs, 280 Slides builds in the ability to search Google for images and YouTube for videos and drag media directly into a presentation. 280 North is also the creator of Cappuccino, an open source JavaScript-based web development framework. Check out co-founder Ross Boucher's videos where he talks about 280 Slides' implementation.
Finally, a friendly reminder that early (discounted) registration for Google I/O ends this Friday, May 1. Visit to sign up and learn more about sessions and demos that'll be in store this year.

*Follow us for the latest I/O updates: @googleio.

By Christine Tsai, Google Developer Products

[Gd] Since the beginning of the year, the Android UI team has been

| More

Android Developers Blog: Since the beginning of the year, the Android UI team has been

Since the beginning of the year, the Android UI team has been hard at work on the Android 1.5 release. Now we want to share some of our evolving Android design principles with you—starting today with widgets.

Widgets are a new feature that application developers can use to promote a small sample of the most relevant dynamic data from their applications on the Home screen. We've designed widgets to fit within our Home screen grid framework, which means you and your designer can create a widget within a 4x1, 3x3, or 2x2 grid cell, depending on the space you need for an at-a-glance summary of information from your application. To illustrate the preferred ways to design widgets for the home screen, we've assembled Widget Design Guidelines.

We're also providing the original artwork assets and source files that we used to create the widgets bundled with Android 1.5. If you want your widgets to match the platform in terms of appearance, use the templates that are available throughout the Widget Design Guidelines.

For more technical information around widgets, take a look at Jeff Sharkey's blog post

as well as the AppWidgets documentation.

One last thing: in the coming weeks, we'll be rolling out more articles and presentations that demonstrate best practices for Android. For example, if you've ever wanted to learn how to create and be consistent with iconography on Android, stay tuned: we'll be posting sample guides and templates.

We've only just begun to scratch the surface of what's possible using widgets. We're looking forward to seeing how far you can extend our work!

Posted by Chris Nesladek, Interaction Designer / Android

[Gd] Dev Update: UI Tweaks and crash fixes

| More

Google Chrome Releases: Dev Update: UI Tweaks and crash fixes

Google Chrome has been released to the Dev channel.  

It includes a number of fixes and a couple UI tweaks.  For example, if you have searched from in the past, start typing in the omnibox, press the Tab key then a search term and suggestions and past searches will appear for Wikipedia.  Other fixes include:

  • [r14196] Scrollbars, Home/End work again in Gmail (Issue: 10009)
  • [r14377] Flash (and other plugins) can be installed without restarting the browser. (Issue: 10574)
  • [r14137] Fix hang seen in plugin process, including the new O3D plugin. (Issue: 10711)
  • [r13934On some sites text disappears or is never drawn. For example, on Google Calendar, the titles for all day events do not display. (Issue: 9904)
Detailed release notes are available.  You can find out about getting on the Dev channel here:

If you find new issues, please let us know by filing a bug at

--Jonathan Conradt
Google Chrome Program Manager

[Gd] Google Webmaster Help Forums in more languages

| More

Official Google Webmaster Central Blog: Google Webmaster Help Forums in more languages

Traditionally when we launch a new communication channel, we also give the shareholders a chance to introduce themselves. We did so when we opened webmaster help communities for European webmasters almost two years ago, and also more than a year ago, when we were able to expand and add groups in three more languages. Last December we were very happy to announce the re-launch of two of our Help Forums in a new and cool look and feel.

Today, we're happy to announce that we keep on increasing the global dialogue with webmasters, opening an Arabic and a Czech/Slovak Webmaster Help Forum. Furthermore, we would like to highlight the support we offer in Chinese, Japanese, and Korean. While we've offered support to Chinese webmasters for a little more than a year, the Japanese and Korean forums are only a few weeks old. Keeping with tradition, the guides monitoring our new forums would like to introduce themselves to the global webmaster family:

Arabic Webmaster Help Forum

مرحبا! My name is Adel and I'll be monitoring the Arabic Webmaster Help Forum. I'm originally from Beirut, Lebanon. After finishing computer science studies, I joined Google, some 18 months ago.

Besides working on search quality in Arabic and building a community on our forum, I enjoy traveling and listening to really loud heavy metal music; sometimes I get to do both at the same time! ;-)

I am looking forward to a lot of questions regarding Arabic Google Search and of course ranking and indexing issues on your sites to come. I hope I'll see you there soon!
- Adel

Czech/Slovak Webmaster Help Forum

Zdravím! I am Marcel, the Google Guide on the Czech/Slovak Webmaster Help Forum. I am originally from Slovakia. After graduating in New Media and Industrial Design, it took me some time and traveling around the globe before moving to Dublin and eventually joining Google some 3 years ago.

Ever since, I've been working in different teams. I was lucky to be part of the AdSense team where I participated in launching AdSense for Content for Czech and Slovak. Since my transition to Search Quality, I enjoy working on improving the quality of our natural search results in Czech, Slovak, and Polish.

Besides my work I have a few more passions, such as listening to live music in Irish pubs, challenging my collleagues in occasional Soulcalibur skirmishes on Playstation and testing burger places all over the world :-) If you want to discuss any of these topics or maybe something about your sites, please join the community. I am looking forward to meeting you there :-)
- Marcel

Chinese Webmaster Help Forum

你好! Hi from the Chinese Webmaster Help Forum team! The Chinese Webmaster Help Forum has received great support from webmasters since its launch in March 2008. In March 2009, the Chinese Webmaster Help Forum moved to a new system with many more user-friendly features for better information sharing. It has become a good platform for webmasters to share their knowledge of Google search and Webmaster Tools and to communicate with Google.

The Chinese Forum now has 6 Google Guides: Xiang (降龙十巴掌), Eric (趙錢孫李), Marina (小馬過河), Chris (城镇), Hyson (草帽路飞), and Fa (法人戴表). We are from many different provinces of mainland China. When not spending time in the forum, we enjoy playing ping-pong and foosball in the office. A few of us are huge video game fans. You may learn more about us when you participate in the forum :)

A big thank you to everyone who has taken part in forum discussions! We hope to see both familiar faces and newcomers join in the Chinese Webmaster Help Forum!
- Xiang (降龙十巴掌), Eric (趙錢孫李), Marina (小馬過河), Chris (城镇), Hyson (草帽路飞), and Fa (法人戴表)

Japanese Webmaster Help Forum

こんにちは! Hello from the Japanese Webmaster Help Forum team! Our names are Nao ( なお ), Kaede ( 楓 ), Haru ( ハル ), and Kyotaro. We are the four guides working in Google Search Quality for Japanese. We've just launched our forum on March 6th.

All of us were born in Japan and grew up here. Nao has also lived in Greece, the Netherlands, and New York. Haru is from the west side of Japan, which is known for its talkative culture and traditional Japanese comedy. Maybe you will read Haru's unique communication on our forum :)

As for our interests, we love eating and drinking! Between posting on the forum, we enjoy Google's excellent lunches and sweets a lot. After working, of course, we sometimes go out for a drink with our team members :) Kaede knows all the nice bars in Tokyo.

Nao and Kyotaro love Sumo wrestling. We've watched two tournaments this year with Googlers from other locations. Haru, of course, loves watching comedies!

We are really excited and happy to see many users joining our forum and sharing tips with each other. Looking forward to seeing you there!
- Nao ( なお ), Kaede ( 楓 ), Haru ( ハル ), and Kyotaro

Korean Webmaster Help Forum

안녕하세요! Hello everyone, my name is Joowon and I work in Google Search Quality for Korean. I was born in Germany and lived in Korea for a few years before moving to Hawaii, California and New York to attend high school and college. After all that traveling, I'm only fluent in Korean and English, with a bit of proficiency in Japanese. Some of the interests I've developed over the years are design, wine, cooking, yoga, and sustainability issues.

Currently I'm back in Seoul and enjoying the dynamic atmosphere here, with lots of interesting people and great food. The Korean Webmaster Help Forum was launched only a few weeks ago, and I'm very much looking forward to talking to all of you. See you in the forum!
- Joowon

Hello world! ;) I am Andrew and I am part of the Search Quality team in Seoul. I grew up in a port city in the southern part of Korea. Ironically, I don't eat seafood because it looks scary to me :( Many of my friends and colleagues love to make jokes about that, but I still don't eat any seafood yet. Playing drums, traveling and photography are my main interests. Currently I'm a drummer of "Spring Fingers", the first band of Google Korea, and we'll have our first concert at the end of April!

I love playing around with web technologies/APIs and find it very exciting to exchange information and ideas on the web. The Korean Webmaster Help Forum was recently launched and I hope to see you there!
- Andrew

If you're curious about our Webmaster Help Forums in other languages, please feel free to peak in. Here's a list of our currently monitored Webmaster Help Forums: Arabic, Chinese, Czech/Slovak, Dutch, Danish, English, Finnish, French, German, Hebrew, Hungarian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, Swedish, and Turkish.

Written by Joowon Ahn, Andrew Baek, Adel Saud, Kaspar Szymanski, Kiyotaka Tanaka, Fa Wang, Reid Yokoyama, and Marcel Zavacky, Search Quality Team

[Gd] GWT Community Updates

| More

Google Web Toolkit Blog: GWT Community Updates

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 sessionsspeakers  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!


[Gd] Google Location Services now in Mozilla Firefox

| More

Google Code Blog: Google Location Services now in Mozilla Firefox

With recent launches like Google Latitude and Google Toolbar with My Location, it's clear we think location-based services are useful and fun! We also want developers everywhere to be able to use location to build cool new features and applications.

I'm pleased to announce that Google's Location Service (the same service which powers the My Location feature in many Google products), is now the default location provider in Mozilla Firefox 3.5 beta 4. This means that developers can, with users' permission, gain access to their approximate location without requiring any additional plug-ins or setting configurations. It just works!

Mozilla Firefox 3.5 beta 4 uses the W3C geolocation API, a standard being adopted by many major browsers, so you won't have to branch code in the future.

For web developers, using geolocation services in Firefox is easy! Here's a simple example to get you started:

function getLocation() {

function displayLocation(loc) {
var locDiv = document.getElementById("locationDiv");
locDiv.innerHTML = "lat: " + loc.coords.latitude + ", lon:" + loc.coords.longitude;


<a href="#" onClick="getLocation()">Click here to display location</a><br>
<div id="locationDiv"></div>
When your site calls getCurrentPosition, a drop down will ask the user permission to get his or her location. Upon acceptance of the request, the callback function you specify will run with the machine's approximate location contained in the loc parameter. Here's a screenshot of the permission dropdown:

We hope you find the new and useful ways to use the new geolocation capabilities of Firefox!

By Jonathan McPhie, Google Mobile Team

Wednesday, April 29, 2009

[Gd] Chromium Tech Talks

| More

Chromium Blog: Chromium Tech Talks

Since starting work at Google, I've formed a deep appreciation for the number of high quality talks we have access to here (both technical and not). Reading code and documentation is pretty much unavoidable when you're a developer, but you really can't beat hearing directly from the expert's mouth on topics that you're interested in.

Last Wednesday, 5 Chromium experts gave mini tech talks on subjects ranging from the network stack to hacking on WebKit. Armed with 2 video cameras, a microphone, and a whiteboard, we did the best we could to capture these talks and make them available to Chromium developers around the world. Whether you're a seasoned Chromium contributor or just getting started, I think these videos have a lot to offer.

Here's a rundown of the videos:

Darin Fisher talking about Chromium's multi-process architecture
Brett Wilson talking about the various layers of Chromium
Dimitri Glazkov talking about hacking on WebKit
Ben Goodger talking about Views (and how to write good tests for them)
Wan-Teh Chang and Eric Roman talking about Chromium's network stack (and its history)

I hope these are just the first of many tech talks we can offer to you, the Chromium community.

Posted by Jeremy Orlow, Software Engineer

[Gd] Tech Talks on the Guts of Chromium

| More

Google Code Blog: Tech Talks on the Guts of Chromium

As a developer, one of the coolest things about working on the Google Chrome web browser is that there's very little difference between being a Googler working on it and being an external contributor. Most development happens via public wikis, mailing lists, bugs, and code under the Chromium project. Chomium's openness is something we take a lot of pride in.

Last Wednesday 5 of Chromium's top contributors gave tech talks on a wide range of very technical topics. Given our commitment to openness, it shouldn't surprise you that we went to great lengths to film them. None of us had filmed a tech talk before, but through a great team effort we were able to capture some really great presentations. If you're interested in the guts of Chromium's code base, I encourage you to check them out:
By Jeremy Orlow, Software Engineer

Tuesday, April 28, 2009

[Gd] Survival techniques for acceptance tests of web applications (Part 1)

| More

Google Testing Blog: Survival techniques for acceptance tests of web applications (Part 1)

By Julian Harty

Automated tests are often touted as a solution for software testing, and effective automated tests certainly have their place and can deliver vital confidence in the software being tested. However, many tests fail to deliver value, either now or in the future, and there are plenty of projects whose automated tests are broken, forlorn, and unloved – cluttering up projects and wasting time and resources.

How to create acceptance tests

Tests need to do something useful to survive. Automated tests should help the team to make the next move by providing justified confidence a bug has been fixed, confirming refactored code still works as intended, or demonstrating that new features have been successfully implemented. (See Alistair Cockburn’s discussion, referenced in the “More Information” section below, on intermediate work products – do they remind? inform? or inspire?) There should be sufficient tests – neither more nor less: more increase the support burden, fewer leave us open to unpleasant surprises in production.

Acceptance tests must meet the needs of several groups, including the users and the developers. Long-lived tests must be written in the language of each group, using terms users will recognize and a programming language and style in which the developers are competent.

We create tests by modelling the purpose of a test from the user’s perspective: send a message, order a book, etc. Each test is decomposed into individual actions: to send a message, a user must be logged in, select the compose message icon, specify one or more recipients, type a minimum of either a subject or a message, then select Send. From this list of actions, create a skeleton in the programming language of choice and create a method name that reflects each action. Show these to both the users and programmers and ask them to tell you what they think each step represents. Now is a great time to refine the names and decide which methods are appropriate: before you’ve invested too much time in the work. If you wait until later, your natural protective instincts will make it harder for you to accept good suggestions and make useful changes.

For each method, we need to work out how to implement it in code. How could an automated test select the compose method icon? Do alternative ways exist? An understanding of HTML, CSS, and JavaScript will help you if you plan to use browser automation tools. All the visible elements of a web application are reflected in the Document Object Model (DOM) in HTML, and they can be addressed in various ways: the directions from the root of the document to the element using xpath; unique identifiers; or characteristics possessed by the elements, such as class names, attributes, or link text. (Notes: navigation using xpath is much slower than using IDs; and IDs should be unique.)

Some actions can be initiated using JavaScript running in the browser. For devices such as the iPhone, changes in orientation when the phone is rotated are triggered this way (see Handling Orientation Events in the Safari Reference Library).

Typically, automated web application tests use JavaScript, either directly or indirectly, to interact with the web application being tested.

Utilities such as recording tools can help reduce the effort required to discover how to interact with the web application. The open-source test automation tool Selenium ( includes a simple IDE record and playback tool that runs in the Firefox browser. Recorded scripts can help bootstrap your automated tests. However, don’t be tempted to consider the recorded scripts as automated tests: they’re unlikely to be useful for long. Instead, plan to design and implement your test code properly, using good software design techniques. Read on to learn how to use the PageObject design pattern to design your test code.

Two of the tools I find most useful are Firebug (, a Swiss Army knife for the Web Browser, and Wireshark (, a network protocol analysis tool with a distinguished pedigree. Firebug is extremely useful when learning how to interact with a web application or debug mysterious problems with your tests when they seem to be misbehaving. I encourage you to persist when learning to use these tools – it took me a while to get used to their foibles, but I wouldn’t be without either of them these days.

Homogenous languages and tools

Several years of experience across multiple project teams have taught us that the tests are more likely to survive when they’re familiar and close to the developers. Use their programming language, put them in their codebase, use their test automation framework (and even their operating system). We need to reduce the effort of maintaining the tests to a minimum. Get the developers to review the automated tests (whether they write them or you do) and actively involve them when designing and implementing the tests.

Typically, our acceptance tests use the xUnit framework; for example, JUnit for Java projects (see A good source of inspiration for creating effective tests is Gerard Meszaros’ work (see

Effective test designs

By using effective test designs, we can make tests easier to implement and maintain. The initial investment is minor compared to the benefits. One of my favourite designs is called Page Objects (see PageObjects on the Google Code site). A PageObject represents part or all of a page in a web application – something a user would interact with. A PageObject provides services to your test automation scripts and encapsulates the nitty-gritty details of how these services are performed. By encapsulating the nitty-gritty stuff, many changes to the web application, such as the reordering or renaming of elements, can be reflected in one place in your tests. A well-designed PageObject separates the ‘what’ from the ‘how’.

Another effective test design is based on three simple words: ‘given’, ‘when’, and ‘then’. As a trio they reflect the essential elements of many tests: given various preconditions and expectations, when such-and-such happens, then I expect a certain result.

// Given I have a valid user account and am at the login page,

// When I enter the account details and select the Enter button,

// Then I expect the inbox to be displayed with the most recent email selected.

The previous code consists of three programming comments that are easy for users to read. The actual programming code is entered immediately below each comment. Programming concepts such as literate programming are intended to make the code almost as readable as the textual comments.

Isolate things that change from those that don’t. For example, separate user account data from your test code. The separation makes changes easier, faster, and safer to implement, compared to making updates in the code for each test.

Gaining Skills

Writing automated tests may be easy for some of you. In my case, I started with some simple example tests and tweaked them to suit my needs. I received boosts from working with more experienced practitioners who were able to correct my course and educate me in how to use various tools effectively. I recommend pairing with one of the developers of the software to be tested when you face a new testing requirement. Their intimate knowledge of the code and your understanding of the tests can form a potent combination. For instance, by working with one of the developers on a recent project, we were able to implement bi-directional injection of JSON messages and capture the responses from the server to test a key interaction between the server and client that was causing problems in production.

I encourage you to try out examples, tweak them, experiment, and plunge in to writing your first automated tests. Learn about AJAX – it underpins the web applications. And learn from more experienced practitioners – I’ve added some links at the end of the article to some of the people I respect who write great acceptance tests, including Antony Marcano and Alan Richardson.

Part 2 of this series, to be posted soon, helps you create more specialized tests (for example, to emulate mobile web browsers) and gives advice on how to increase the utility and effectiveness of your tests.

Further Information

Intermediate work products

‘The intermediate work products have only one real purpose in life: ‘‘to help the team make their next move’’.’ ‘An intermediate work product might be measured for ‘‘sufficiency” — was it sufficient to remind, inform or inspire? Any amount of effort or detail beyond sufficiency is extraneous to the purpose of the team and the purpose of the work product.’ Cooperative game manifesto for software development (Alistair Cockburn)
Cooperative game manifesto for software development at

JUnit info

JUnit in Action, available from Manning Publications Co. (2nd edition, early access or 1st edition)

JUnit Recipes, by J. B. Rainsberger with Scott Stirling, available from Manning Publications Co.

Firebug info

Introduction to Firebug on Estelle Weyl’s blog, "CSS, JavaScript and XHTML Explained"

Firebug tutorials in the Firebug Archive at Michael Sync's blog

Fun with Firebug Tutorial on the Google Code site

WebDriver info

webdriver on the Google Code site

AJAX resources

Bulletproof Ajax—An incredibly good book on how to write good AJAX code. It starts with the basics and builds reliably and clearly from good foundations. The DOM manipulation code is relevant for implementing your acceptance tests in tools such as WebDriver.

Building a web site with Ajax —Again, a book that starts simple and builds a simple application step by step.

Acceptance tests are more A+S than T+G (Antony Marcano, in his blog at
A+S => Activities + Specific
T+G => Tasks + General

Alan Richardson: any and everything. For example, see:
A generalised model for User Acceptance Testing and
A little abstraction when testing software with Selenium-RC and Java, both at the Evil Tester blog


[Gd] AdWords API v2009 Sandbox Launch

| More

AdWords API Blog: AdWords API v2009 Sandbox Launch

Hello all,

As we mentioned in our December blog post "A preview of 2009 API changes," we've been hard at work on re-building the AdWords API to offer our developers improved speed, functionality, and flexibility.

Today, we're announcing the launch of the API 2009 sandbox, so you can begin experimenting with the latest version of the AdWords API. We're using a new version naming convention to highlight the significant differences between this version, called AdWords API v2009, and v13.

There are several key differences in how API v2009 works:

  • More operations in a single call: We're changing the way services
    are constructed so that you'll be able to accomplish more work per
    call. Specifically, operations will accept a variety of modifiers
    acting on elements across ad groups. For example, you'll be able to
    add, update, and delete keywords across ad groups, all within a single
  • Lower costs: We will reduce API units consumed for the new
    asynchronous methods, and are exploring other ways to improve the
    value you get from the AdWords API by lowering costs and increasing
    efficiency of quota use. The v2009 sandbox is free to use, and once
    these services are in production, they will be tied to a new rate
    sheet that lowers the average cost of an operation. The new rate sheet
    will apply only to API v2009, and will be launched when v2009 goes
    into production.

Most AdWords functionality is available in the core services we
exposed today:

  • AdGroupAdService
  • AdGroupCriterionService
  • AdGroupService
  • CampaignCriterionService
  • CampaignService
  • CampaignTargetService

Forthcoming features include:

  • Asynchronous calls: We'll offer asynchronous calls, which will allow
    you to work with large sets of data faster and more easily. Instead of
    having to wait for our system to fully complete your request before
    you can make another one, you'll be able to make another call as soon
    as the API service confirms that it's received your previous call. No
    more waiting for large requests to be finished. (Synchronous methods
    will still be supported as well).
  • Partial failure acceptance: We plan to support partial failure, so
    large posts aren't rolled back due to a few errors. This allows you to
    keep moving forward with development and not have to re-do the same

We'll release the remaining features needed for full AdWords parity in the coming months. Forthcoming features include: Reporting, Keyword tools, MCC functionality, and change history.

How to access the API v2009 Sandbox:
The API v2009 Sandbox does not charge for quota, and will accept your current Google account login. In addition, the backend database for the v2009 Sandbox is shared with the v13 Sandbox environment. This means that any existing campaigns, ad groups, ads, and keywords that
you created under your login email using the v13 Sandbox will exist in the v2009 Sandbox. Please remember that the sandbox is a testing and development environment. The changes made here will not impact your live AdWords account. You can read more about Sandbox best practices here:

What comes next:
We plan to launch the core functionality of API v2009 on our production servers in about 2 months, with the remaining functionality needed for AdWords parity released over the following 3 months. During that time, both AdWords API v13 and v2009 will be fully supported. We'll begin the sunset period for v13 once we've reached feature parity in API v2009. Since we're introducing more changes than usual, we'll extend the normal 4-month sunset period for v13, so it won't sunset until sometime in early 2010.

Documentation for the API v2009 sandbox is available on our codesite at:

We hope you'll kick the tires of our new API and give us plenty of feedback. We've established a special email address for you to share your thoughts: We look forward to your comments, suggestions and questions.

Thank you,

Doug Raymond
Product Manager, AdWords API

[Gd] Lombardi Blueprint: Client side code, server side execution with GWT

| More

Google Code Blog: Lombardi Blueprint: Client side code, server side execution with GWT

This post is part of the Who's @ Google I/O, a series of blog posts that give a closer look at developers who'll be speaking or demoing at Google I/O. Today's post is a guest post written by Alex Moffat, Chief Engineer - Blueprint, Lombardi Software

Lombardi has been using Google Web Toolkit (GWT for short) since January 2007 to build Lombardi Blueprint, an online, collaborative business process modeling and documentation tool. The client part of Blueprint is completely written using GWT and runs in any modern browser, that is IE6 and anything later, such as IE7, IE8 or Firefox. One of the biggest advantages of Blueprint is that it's easier to learn and quicker to use than a pure diagramming tool like Visio and it's more effective because it's focused on process mapping.

One of the things we do to make Blueprint more effective is automatic diagram layout. This allows the user to focus on describing their process instead of worrying about object positioning and line routing. You can see this in action in the video below as objects are added to the diagram.

Remember, this is JavaScript compiled by GWT from Java code, but it's as fast as, or faster than, anything you could write by hand, compact, and much, much, easier to maintain. The ability to use the excellent tooling available for Java is one of the great advantages of GWT.

One of the goals for our automated layout routines is to generate a flow diagram that looks like it was produced by a human. When the algorithms don't get it quite right, Blueprint also supports hinted layouts so that the user can drag and drop hints about where one object should be positioned in relation to another. Working out what the final layout should be and where the lines should go for large diagrams can be computationally expensive.

Modern browsers have very fast JavaScript engines. For these systems, there are no problems. However, we still need to support the browsers our customers use, which may not necessarily be the fastest or most up-to-date.

This is where GWT gives us a unique benefit. We can implement our algorithms in Java and compile this implementation twice, once with GWT to produce JavaScript to run on the client and once with javac to produce JVM bytecode to run on the server. This lets us use the much faster JVM if we need to without having to create, and maintain, separate client and server layout implementations. There's no other toolkit that makes this possible, never mind easy.

Blueprint client code continuously measures how long it takes to perform the layout and routing operation in the browser. If this exceeds our threshold value, then the code dynamically switches to trying a server side layout. We call the server code with GWT and the data structures returned, via the GWT serialization mechanism, are of course the same ones produced by the layout when executed on the client. The time required for a server layout is also measured, which includes both the execution time and any network delays so we account for the different connection experiences people have. After the first server layout, Blueprint chooses whichever method, client or server, has the lowest average elapsed time. I'm still amazed by how easy this was to implement.

Damon Lundin and I will be talking at Google I/O this year about how we built Blueprint, both what we do technically with GWT to get high performance and how we organize development so that we can make the most effective use of GWT. We look forward to meeting fellow GWT developers in person!

By Alex Moffat, Chief Engineer - Blueprint, Lombardi Software