Friday, April 30, 2010

[Gd] New Google Web Elements released

| More

Google Code Blog: New Google Web Elements released

Today we've added four new Google Web Elements: Sidewiki, Checkout, Wave and Virtual Keyboard. These are all designed to help you quickly and easily integrate Google products into your website.

Sidewiki element
Google Sidewiki makes it easy for visitors of your website to share helpful information with each other. Unlike regular comments, all Sidewiki entries are ranked by usefulness so that the best ones are shown first. The element was built entirely on the Sidewiki API and can be customized in many ways to fit into your site. Sidewiki originally launched as a feature of Google Toolbar and as a Chrome extension - this element is our newest step in making Sidewiki more open and accessible across the web. If you'll be using the element on your site, let us know via @googlesidewiki on Twitter!

If you're looking for a way to add commenting to an otherwise static page, the Google Sidewiki element gives you an easy and simple way to collect and display comments about a page. One of the new and exciting features of the Sidewiki element is that it allows visitors to leave a comment even if they do not have Sidewiki or Google Toolbar installed. Like all Sidewiki entries, the comments in the element will be ranked to show the most useful items more prominently.

Checkout element
The Google Checkout element allows you to quickly and easily create an online store using a spreadsheet. Once you have a Google Checkout merchant account, you just have to add details for each item you're selling into a Google Spreadsheet, then use the wizard and copy/paste the code into your website. The element is compatible with Blogger, Google Sites, iGoogle, and personal websites where HTML can be modified, but doesn't require any programming skills or experience. In fact, you can get your first online store up and running in under five minutes.

Wave element
The Google Wave element enables you to quickly drop a wave -- a shared workspace -- onto your own website. The wave could be used for many different things, including: encouraging collaborative discussion among the visitors, or as a means of publishing content on the page. For deeper integrations of waves onto your own site, please check out the recently improved Wave Embed API. For more information on embedding waves, see the Google Wave Developer Blog post.

Virtual Keyboard element
Adding a virtual keyboard to your site just got easier with the Google Virtual Keyboard element. After choosing a keyboard layout, copy and paste the HTML into your page and voila, a virtual keyboard will be able to enter characters into any text input or text area on your page. If you've never heard a virtual keyboard, it's an on screen keyboard which translates the input from one keyboard layout to another and it allows users to type their own languages on foreign keyboards or by clicking the on screen display.

Google Web Elements are great for folks who don't have much time or experience. However, even for advanced developers, elements are a great starting point, as most are backed by an underlying API to give you even more control over the content or look and feel. Take a look at all of the elements at and stop by our help forum if you have any questions.

By Jeff Scudder and Adam Feldman, Google Web Elements Team

[Gd] New Site Search features, upgrades for Adobe Creative Suite 5

| More

Google Custom Search: New Site Search features, upgrades for Adobe Creative Suite 5

The just-released Adobe® Creative Suite 5 (CS5) now includes a new Community Help application, powered by Google Site Search. It’s an Adobe AIR®-based companion that’s automatically installed as part of any new Adobe CS5 product.

Launched directly from the Help menu of any CS5 product, the Community Help application provides a customized search experience across about 3000 sites. Customers can find fast answers with powerful new options to focus results just on Adobe content, community content, developer resources, and even code samples.

The Adobe development team used the XML API to integrate search results and also create unique innovations such as Code Search. Formerly known as Blueprint (demonstrated at Google I/O last year) this new search option allows Adobe Flash® and Flex developers to search for relevant code samples so that they can write better code, faster.

Community Help can also be used as a standalone application. To give Community Help a try, you can download it from

To learn more about how Adobe Community Help uses Site Search, see our blog post on the Google Enterprise Blog.

Posted by: Rajat Mukherjee, Group Product Manager, Search

[Gd] Embed API Improvements: Viewing public waves without a wave account

| More

Google Wave Developer Blog: Embed API Improvements: Viewing public waves without a wave account

We recently introduced a new API for embedding waves, which includes a powerful new feature: anonymous, read-only access to public waves. Prior to this launch, webmasters could embed waves into their sites, but visitors could only see the content of the embedded wave if they had a Google Wave account, were logged in, and had access to that particular wave. Now, all waves with (or a properly configured Google Group) as a participant can be embedded in a website so their content can be read by those who don't have a wave account (or simply aren't logged in).

You can view an example of this below or see it in action by visiting the KitchenSinky walkthrough documentation.

The new embed API also provides some optional parameters, like the ability to display participants in the the header panel or to include the toolbar. With an embedded wave, users are able to discuss topics in realtime and even catch up by playing back the exchange. Additionally, it provides a mechanism for staying involved in the conversation without requiring the user to constantly check the host site for updates.

To get started with the API, please visit the tutorial and consult the API reference.

If you're just interested in quickly getting a wave embedded on your site, you can simply make the wave and then get the code to paste into your site using the new Wave Element.

As you're diving in, here are a few ideas for ways to make use of embedded waves:

  • Use a wave to do live-blogging (or "live-waving" as we call it) about breaking news. You can provide up-to-the-second commentary for an election, earnings call, sporting event, or product announcement -- and even combine points of view from multiple bloggers into a single wave.
  • Display realtime RSVPs to an event with the Yes/No/Maybe gadget. Participants can also add comments for everyone to see.
  • Publish documentation or other articles via embedded waves. It's easy to update and readers can simply follow the wave to stay in the loop on changes. For example, we publish the Wave API release changelog as an embedded wave.
  • Take advantage of the active robots API and create waves programmatically for embedding in a variety of sites, such as a private messaging system for a social network, a shared collaborative workspace in a productivity tool, or as a customer support system.

We hope you find this new API and this new level of access useful, and we have more improvements to the embed API on the way. For example, at the moment, embedded waves do not work in Internet Explorer (even with Google Chrome Frame), but we will be resolving that issue.

We look forward to seeing what you come up with. If you have questions or comments, please discuss in the forum.

Posted by Dhanji R. Prasanna, Software Engineer, Google Wave team

[Gd] GTAC!

| More

Google Testing Blog: GTAC!

Yes I know, I've been quiet. Seriously heads down shipping products and developing what I think are some pretty cool new testing ideas and tools. Perhaps GTAC will be the chance for you to judge that for yourselves. Perhaps it will be worth the wait.

I hope I am invited to speak at GTAC. (Is this an appropriate forum for such lobbying? Should I open it up to a vote on whether I should or should not be there? I am happy not going as India is a long trip, but this is GTAC we are talking about!) There are a number of things that will be ready to either debut or, if I am lucky, open source by then.

Would you like to see a Chrome extension to display bug, test case, coverage and other information as an overlay on top of your web app UI? Imagine being able to see bugs at their exact location on the UI, report bugs by simply right-clicking the errant part of the web page, see footprints where test cases (automated and manual and across multiple testers) have been and lots more useful information. Are you tired of querying databases to see these things and just want your test data as a cellophane wrapper around your web app UI? If you were at STAR this week, you got a preview. But that presentation is already out of date.

Would you like to be able to write automated test cases that can control your web app, your browser and the operating system they are running on? Well if that stack contains Chrome and Chrome OS, you can do it with a new web test framework we are developing. Would you like to do all of this with Java Script? Sound like magic? Well I think the Web Test Framework is appropriately named: WTF.

Would you like to see a record and playback facility that records directly to Java Script and is actually built-in to your browser? A R/P tool that handles AJAX and won't get confused by self-updating web pages? That stores recordings directly into a test case management system that is accessible to the world?

Would you like to hear about the extensive library of testing tours we have developed and how our manual testing strategy across the web-app/Chrome/Chrome-OS stack is shaping up?

These are some of the things that have kept me from this blog. Forgive me. I will report on them here and, with a little pressure directed toward Sujay The Decider perhaps demo them at GTAC.

Thursday, April 29, 2010

[Gd] A tale of two (and more) apps

| More

Google Web Toolkit Blog: A tale of two (and more) apps

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

Robert's original post

I love crossword puzzles.

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

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

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

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

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

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

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

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

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

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

Quick colophon:

Wave for GWT via CoboGWave:

Gadget Support:

Gin, Guice for GWT:

Data binding, local storage and JSON serialization:


[Gd] Google APIs + HTML5 = A New Era of Mobile Apps

| More

Google Code Blog: Google APIs + HTML5 = A New Era of Mobile Apps

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. This guest post is written by Adrian Graham, co-founder of who will give us a demo inside the Developer Sandbox.

When building nextstop's HTML5 mobile app, we were able to leverage a powerful combination of HTML5 and Google API's to build a mobile web experience that we believe rivals what we could have built natively. For more on our mobile app, check out this post -- here we will just focus on the technologies that made this experience possible.

Lately HTML5's video features have gotten a lot of attention, but it's three other HTML5 features that we've found most useful for mobile web development.

1. Prefetching using LocalStorage: It's no secret that mobile data networks are slow but by putting a bit of thought into what users will tap on next, and prefetching that data in the background you can build a dramatically faster user experience. It's possible to do limited forms of prefetching using plain old JavaScript, but using the localStorage key/value storage built into HTML5, we're able to store much more data and therefore prefetch more aggressively.

If you're using a recent version of Chrome or Safari or on an iPhone 3 or Android 2 phone and want a sense of what prefetching feels like, try clicking the left and right arrows here (you can ignore the warning you will see in Chrome and Safari).

2. Geolocation: Using the geolocation features built into HTML5 (and available on iPhone 3 and Android 2), we're able to connect you with local information based on the GPS in your phone, so all you have to do is launch the app to see nearby recommendations. I wish it were a bit faster, but it sure beats entering an address or zip code -- and it's super easy to hook into as a developer.

3. App Caching: The last HTML5 feature that we heavily rely on is the application cache. If a cache manifest file is specified, the browser won't re-download files unless the content of the manifest file has been updated. This may not sound like a big deal, but the latency of cellular networks can be long enough that requesting multiple files at startup can slow down your app by 10 or 20 seconds. Ideally, you'd put all your static JavaScript, CSS, and image files in the manifest file, so users never have to wait for them to be downloaded more than once.

As excited as we are about HTML5, things get even more interesting when you combine these technologies with Google APIs.

1. Google Maps API V3: Google Maps V3 has been rewritten from the ground up to better support modern mobile web browsers, and it shows. We were able to build a map interface into our mobile app that is nearly as full featured as our main site, including support for dynamic updates when the user pans and gestures like pinch to zoom on the iPhone. Coupled with the Geolocation support in HTML5, we can easily show users where they are in relation to the recommendations on the map. A year ago, this would have required writing a fair amount of native code. Today it can be done in the browser and works on both Android 2 and iPhone 3 devices.

2. Google Analytics: Since we prefetch most of our content, we end up rendering mobile pages using JavaScript. This makes tracking things like page views a little more tricky than a typical website, since we're not requesting an HTML file for each page view (and the App Cache can further complicate matters). We planned on building a custom mobile analytics system, but we decided to try running Google Analytics in the mobile web browser instead. Using the _trackPageview method (with a URL corresponding to each mobile "page" generated by Javascript) has worked surprisingly well and has had minimal performance impact. Best of all, if you're already using Google Analytics on your main site, you see all your mobile analytics in the same place. This lets you do things like easily compare the time on site for a mobile visitor and a desktop visitor. (Here's one data point if you're wondering whether or not to build a mobile web version of your site: visitors spend over twice as long using our mobile HTML5 app as they do on our website.)

3. Google Local Search API: Coupled with HTML5 geolocation, the Google Local Search API becomes even easier to use. For instance, the nextstop app lets users add places that they like to nextstop's database. In a desktop browser, we have no choice but to ask the user to type in some words and do a local search. However, on the phone, we can show users a list of nearby places by passing the local search api the user's current position. More often than not, no typing is required to locate the place you'd like to add.

If you can't already tell, we're pretty excited about the future mobile apps running inside a browser. As mobile web browsers and web APIs continue to evolve, we expect more and more people to hop on the HTML5 bandwagon as a cross-platform way to build powerful mobile apps.

We'll be at Google I/O in May and would love for you to stop by our demo station in the Developer Sandbox and share any questions, tips, or tricks you have related to HTML5 mobile development. And in the meantime, if you have a great idea for an HTML5 app based on nextstop's data, we encourage you to check out our API.

By Adrian Graham, co-founder of

Wednesday, April 28, 2010

[Gd] Multitasking the Android Way

| More

Android Developers Blog: Multitasking the Android Way

[This post is by Dianne Hackborn, a Software Engineer who sits very near the exact center of everything Android. — Tim Bray]

Android is fairly unique in the ways it allows multiple applications to run at the same time. Developers coming from a different platform may find the way it operates surprising. Understanding its behavior is important for designing applications that will work well and integrate seamlessly with the rest of the Android platform. This article covers the reasons for Android's multitasking design, its impact on how applications work, and how you can best take advantage of Android's unique features.

Design considerations

Mobile devices have technical limitations and user experience requirements not present in desktop or web systems. Here are the four key constraints we were working under as we designed Android's multitasking:

  • We did not want to require that users close applications when "done" with them. Such a usage pattern does not work well in a mobile environment, where usage tends to involve repeated brief contact with a wide variety of applications throughout the day.
  • Mobile devices don't have the luxury of swap space, so have fairly hard limits on memory use. Robert Love has a very good article covering the topic.

  • The available APIs must be sufficient for writing the built-in Google applications, as part of our "all applications are created equal" philosophy. This means background music playback, data syncing, GPS navigation, and application downloading must be implemented with the same APIs that are available to third party developers.

The first two requirements highlight an interesting conflict. We don't want users to worry about closing their apps, but rather make it appear that all of the applications are always running. At the same time, mobile devices have hard limits on memory use, so that a system will degrade or even start failing very quickly as it needs more RAM than is available; a desktop computer, with swap, in contrast will simply start slowing down as it needs to page RAM to its swap space. These competing constraints were a key motivation for Android's design.

When does an application "stop"?

A common misunderstanding about Android multitasking is the difference between a process and an application. In Android these are not tightly coupled entities: applications may seem present to the user without an actual process currently running the app; multiple applications may share processes, or one application may make use of multiple processes depending on its needs; the process(es) of an application may be kept around by Android even when that application is not actively doing something.

The fact that you can see an application's process "running" does not mean the application is running or doing anything. It may simply be there because Android needed it at some point, and has decided that it would be best to keep it around in case it needs it again. Likewise, you may leave an application for a little bit and return to it from where you left off, and during that time Android may have needed to get rid of the process for other things.

A key to how Android handles applications in this way is that processes don't shut down cleanly. When the user leaves an application, its process is kept around in the background, allowing it to continue working (for example downloading web pages) if needed, and come immediately to the foreground if the user returns to it. If a device never runs out of memory, then Android will keep all of these processes around, truly leaving all applications "running" all of the time.

Of course, there is a limited amount of memory, and to accommodate this Android must decide when to get rid of processes that are not needed. This leads to Android's process lifecycle, the rules it uses to decide how important each process is and thus the next one that should be dropped. These rules are based on both how important a process is for the user's current experience, as well as how long it has been since the process was last needed by the user.

Once Android determines that it needs to remove a process, it does this brutally, simply force-killing it. The kernel can then immediately reclaim all resources needed by the process, without relying on that application being well written and responsive to a polite request to exit. Allowing the kernel to immediately reclaim application resources makes it a lot easier to avoid serious out of memory situations.

If a user later returns to an application that's been killed, Android needs a way to re-launch it in the same state as it was last seen, to preserve the "all applications are running all of the time" experience. This is done by keeping track of the parts of the application the user is aware of (the Activities), and re-starting them with information about the last state they were seen in. This last state is generated each time the user leaves that part of the application, not when it is killed, so that the kernel can later freely kill it without depending on the application to respond correctly at that point.

In some ways, Android's process management can be seen as a form of swap space: application processes represent a certain amount of in-use memory; when memory is low, some processes can be killed (swapped out); when those processes are needed again, they can be re-started from their last saved state (swapped in).

Explicitly running in the background

So far, we have a way for applications to implicitly do work in the background, as long as the process doesn't get killed by Android as part of its regular memory management. This is fine for things like loading web pages in the background, but what about features with harder requirements? Background music playback, data synchronization, location tracking, alarm clocks, etc.

For these tasks, the application needs a way to tell Android "I would explicitly like to run at this point." There are two main facilities available to applications for this, represented by two kinds of components they can publish in their manifest: broadcast receivers and services.

Broadcast Receivers

A BroadcastReceiver allows an application to run, for a brief amount of time, in the background as a result of something else happening. It can be used in many ways to build higher-level facilities: for example the AlarmManager allows an application to have a broadcast sent at a certain time in the future, and the LocationManager can send a broadcast when it detects interesting changes in location. Because information about the receiver is part of an application's manifest, Android can find and launch the application even if it isn't running; of course if it already has its process available in the background, the broadcast can very efficiently be directly dispatched to it.

When handling a broadcast, the application is given a fixed set of time (currently 10 seconds) in which to do its work. If it doesn't complete in that time, the application is considered to be misbehaving, and its process immediately tossed into the background state to be killed for memory if needed.

Broadcast receivers are great for doing small pieces of work in response to an external stimulus, such as posting a notification to the user after being sent a new GPS location report. They are very lightweight, since the application's process only needs to be around while actively receiving the broadcast. Because they are active for a deterministic amount of time, fairly strong guarantees can be made about not killing their process while running. However they are not appropriate for anything of indeterminate length, such as networking.


A Service allows an application to implement longer-running background operations. There are actually a lot of other functions that services provide, but for the discussion here their fundamental purpose is for an application to say "hey I would like to continue running even while in the background, until I say I am done." An application controls when its service runs by explicitly starting and stopping the service.

While services do provide a rich client-server model, its use is optional. Upon starting an application's services, Android simply instantiates the component in the application's process to provide its context. How it is used after that is up to the application: it can put all of the needed code inside of the service itself without interacting with other parts of the application, make calls on other singleton objects shared with other parts of the app, directly retrieve the Service instance from elsewhere if needed, or run it in another process and do a full-blown RPC protocol if that is desired.

Process management for services is different than broadcast receivers, because an unbounded number of services can ask to be running for an unknown amount of time. There may not be enough RAM to have all of the requesting services run, so as a result no strong guarantees are made about being able to keep them running.

If there is too little RAM, processes hosting services will be immediately killed like background processes are. However, if appropriate, Android will remember that these services wish to remain running, and restart their process at a later time when more RAM is available. For example, if the user goes to a web page that requires large amounts of RAM, Android may kill background service processes like sync until the browser's memory needs go down.

Services can further negotiate this behavior by requesting they be considered "foreground." This places the service in a "please don't kill" state, but requires that it include a notification to the user about it actively running. This is useful for services such as background music playback or car navigation, which the user is actively aware of; when you're playing music and using the browser, you can always see the music-playing glyph in the status bar. Android won't try to kill these services, but as a trade-off, ensures the user knows about them and is able to explicitly stop them when desired.

The value of generic components

Android's generic broadcast receiver and service components allow developers to create a wide variety of efficient background operations, including things that were never originally considered. In Android 1.0 they were used to implement nearly all of the background behavior that the built-in and proprietary Google apps provided:

  • Music playback runs in a service to allow it to continue operating after the user leaves the music application.

  • The alarm clock schedules a broadcast receiver with the alarm manager, to go off at the next set alarm time.

  • The calendar application likewise schedules an alarm to display or update its notification at the appropriate time for the next calendar event.

  • Background file download is implemented a service that runs when there are any downloads to process.

  • The e-mail application schedules an alarm to wake up a service at regular intervals that looks for and retrieves any new mail.

  • The Google applications maintain a service to receive push notifications from the network; it in turn sends broadcasts to individual apps when it is told that they need to do things like synchronize contacts.

As the platform has evolved, these same basic components have been used to implement many of the major new developer features:

  • Input methods are implemented by developers as a Service component that Android manages and works with to display as the current IME.

  • Application widgets are broadcast receivers that Android sends broadcasts to when it needs to interact with them. This allows app widgets to be quite lightweight, by not needing their application's process remain running.

  • Accessibility features are implemented as services that Android keeps running while in use and sends appropriate information to about user interactions.

  • Sync adapters introduced in Android 2.0 are services that are run in the background when a particular data sync needs to be performed.

  • Live wallpapers are a service started by Android when selected by the user.


[Gd] More Blogginess

| More

Android Developers Blog: More Blogginess

Hello everyone, and welcome to a rare (in this space) blog about blogging. My name is Tim Bray, and I’m the new editor of this Android Developers’ Blog. I am only a student of Android, but I’m a veteran blogger, I’m part of the Android team, and they’ve given me a pretty free hand to find and publish the interesting stories. I’m expecting to enjoy this and hope you will too.

The work on Android is done at various places around the world, but in Mountain View, California there’s a building on the Google campus with an Android statue in front of it, positioned among dessert-themed sculptures that illustrate the major platform releases to date.

As of now, this blog has a header image taken from where some of the Android work happens, behind the statuary looking out. There are a ton of places on the Internet where you can read people’s opinions about what’s happening next with Android, and a lot of them are good. The one you’re reading now is the one that’s written from the inside looking out.


This space has been used mostly in a just-the-facts press-release-flavored way and, while that’s been useful, I thought it could be livelier. Because, even after only a few weeks’ exposure to what’s going on here, I’ve discovered that there are a ton of interesting Android stories, and while some of them probably have to be secrets, there are more than enough we can tell to crank up the interest level here.

I offered this opinion internally, loudly and repeatedly, and Android management surprised me by coming back with “OK, it’s your problem now.”


I’m not going to write everything here; I’m going to track down the people who actually do the creative Android-building work and get them to tell their own stories. I will bend over backward to make sure the articles have the voices of the people who write them.

We will go on being a source for hard opinion-free just-the-facts Android news. But I’d like to surround each burst of that with a cluster of reportage about what it means and how we think it will affect the Android communities.

The immediate future is going to be pretty intense, because we’re only a few weeks away from Google I/O, and I don’t think that I’m telling any secrets when I say that there will be Android-related announcements at that event. So the problems that come with the new job probably won’t include scaring up content.

The first new-flavor post is going to be on a currently-hot subject, multitasking and background processing, written by an engineer at the center of the Android universe.

Wish me luck, and stay tuned!


[Gd] Discover v2009: Error handling in BulkMutateJobService.

| More

AdWords API Blog: Discover v2009: Error handling in BulkMutateJobService.

In our previous blog post, we discussed how v2009 error handling works in synchronous APIs. In this blog post, we cover asynchronous error handling in BulkMutateJobService. If you are new to BulkMutateJobService, check out our introductory blog post and article.

Due to its asynchronous nature, error handling in BulkMutateJobService is slightly different than in other services. Instead of throwing an ApiError object, BulkMutateJobService returns FailureResult or BatchFailureResult objects as its operation results. These objects in turn contain the relevant ApiErrors. BulkMutateJobService processes the operations within an operation stream in multiple atomic batches. If there is even one faulty operation in a batch, it causes the other non-faulty operations in the batch to fail as well. When a batch of n operations fails, you will get one FailureResult and n - 1 BatchFailureResults as results for the failed batch of operations. The FailureResult object will always be first in the batch, and will contain one ApiException object. The ApiException contains all the errors for the entire batch of operations, just like for other services. This will be followed by n - 1 BatchFailureResults, which can be viewed as placeholders, one for each operation in the batch.

For instance, assume that you are trying to create the following 9 text ads in a single OperationStream. For the purposes of this example, assume that the system processes operations in batches of 3. The errors are highlighted in red.

Destination Url

New York Budget Hotel
Clean and close to subway.
Students save 20%!

Book New York Hotel Deals
Research your New York Stay. Deals
up to 70% from

Hotels In New York
Book your hotel room online at a
lower price via!!

Excessive punctuation in description2

Manhattan Best Hotel
Experience the Best of Manhattan
For Rates As Low As $239/Night.

Missing schema in destination url.

New York City Hotels Discount
Discounted Rooms in New York City.
Get Lowest Rates Available Today.

New York City Hotels
Stay Smart in New York NY.
Free internet & breakfast bar.

70% Off New York Hostels
Why Pay More? From $10 We Guarantee
Lowest Prices - From 1 Night

Stylish New Hotel in NYC
Enjoy Four-Star Amenities & Service
Chelsea/Fashion District. Book Now!

Budget Lodging in NYC
Comfortable, Clean Modern Economy
Hotel.Great Downtown Location!

When BulkMutateJobService processes these operations, it will return the following results:

Result[0]: FailureResult.
ApiException.errors has one ApiError
PolicyViolationError @ operations[2]
Result[1]: BatchFailureResult, operationIndexInBatch = 1
Result[2]: BatchFailureResult, operationIndexInBatch = 2

Result[3]: FailureResult.
ApiException.errors have 1 ApiError
AdError.URL_NO_SCHEME @ operations[0]
Result[4]: BatchFailureResult, operationIndexInBatch = 1
Result[5]: BatchFailureResult, operationIndexInBatch = 2

Result[6]: ReturnValueResult, successfully created Ad.
Result[7]: ReturnValueResult, successfully created Ad.
Result[8]: ReturnValueResult, successfully created Ad.

As shown in the results above, there is a 1:1 correspondence between the number of operations and number of results. You can get the successful operations by scanning the return value for results which are not FailureResult or BatchFailureResult (operations 6, 7 and 8 in this case). Then, scan through the results to locate FailureResult objects (which always appear at the beginning of the failed batch) to get the operation that actually failed (operations 2 and 3 in this case). You can now pick the failed operations that do not correspond to the ones obtained from FailureResult, and make a new job for them (0, 1, 4, 5). Note that the OGNL path in FailureResult is relative to the batch and not the operationstream, so you have to offset it by the index of FailureResult to get the failed operation (e.g. Results[3] is a FailureResult and its OGNL path is operations[0], so the failing operator in the original list is 3 + 0 = operations[3]).

A BulkMutateJob may also return the following error results, even though they're not common:

LostResult: This happens when BMJS has lost results for some of a job's operations. You can recover from this error by checking numFailedOperations and numUnprocessedOperations for the job. If both are zero, or if the number of errors in ApiError matches numFailedOperations, then the operations were successful, but the results are missing. In any other case, you have to retrieve the entities that were targeted by the operations and see if the operation actually succeeded or not.

UnprocessedResult: This indicates that the mutate operation was not processed. This could happen because the workflow implementation prevented the operation from being processed (e.g. the operations exceed API quota). You can recover from this issue by checking the job status, making sure that you have sufficient API quota left, and simply retrying the operations in a new job.

In an upcoming blog post, we will cover the most common errors you may get in v2009, and how to address them. We've included support for error handling in all of our client libraries to help get you started, so please try it out and share your feedback with us on the forum or the projects' issue trackers.

-- Anash P. Oommen, AdWords API Team

[Gd] The API v2 Robots Have Risen: Check them out!

| More

Google Wave Developer Blog: The API v2 Robots Have Risen: Check them out!

We launched the new Robots API (v2) last month, and since then, we've seen a a slew of new and interesting robots from Google Wave developers -- proving that robots can now be used in more ways than ever before.

We want to share some examples here, to give you a taste of the possibilities:

Pushy: This robot accepts any form of HTTP post and adds the content as a new message on the wave. It has special handling for the post-commit hooks on github and googlecode. The developer created this robot because he uses Google Wave at his company, and he wanted a way to have waves be updated based on their github project activity I've personally been using it to subscribe to updates on our google-wave-resources project. You can check out the source code from the samples gallery, and install it from the gallery wave.

docXwave: This robot imports .docx (Microsoft Word) files into a wave, converting the formatting and even tables, using a table gadget. The developer is a part of Plutext, a group of developers working on various Microsoft Word related efforts and an open source OpenXML file converter python module. You can install it from the gallery wave.

Ferry: This robot exports Google waves to Google documents, letting you specify if you want to continually export, and if you want to export everything or just the root blip. This is useful for people that want to export to a Google doc for the printing, exporting, or extra formatting capabilities. You can install it from the gallery wave.

robot-robot: The robot lets you write code inside a wave, and run that code as a robot on another wave. This means that you can get started playing around with the APIs, without having to setup an App Engine account and your own project. I'm looking forward to using it for live demos and codelabs. You can check out the source code from the samples gallery, and install it from the gallery wave. You might also be interested in "as-a-robot", another robot-writing robot from a different developer. Great developers think alike!

Mr. Ray: This robot makes it possible to use wave with people not on wave - you add their emails via a gadget, and the robot emails them a static copy of the wave. When they reply in the static interface, it syncs the reply back into the wave. It's a fantastic use of the proxying for feature in the new API, and of course, the active API. It's also incredibly useful - I'm using it to plan an event with high school friends, who are all highly addicted to their email system of choice. You can install Mr. Ray from the gallery wave.

If you're working on your own API v2 robots, be sure to share them in the forum and in the extensions gallery. We look forward to seeing what your creative minds come up with.

Posted by Pamela Fox, Developer Relations

Tuesday, April 27, 2010

[Gd] Smartsheet’s Success on the Google Apps Marketplace

| More

Google Code Blog: Smartsheet’s Success on the Google Apps Marketplace

A couple weeks ago I was up in Seattle talking about the Google Apps Marketplace with local SaaS companies. I was happy to be joined by Smartsheet, Concur and Skytap and even more excited when they all talked about their success on the Marketplace.

We’ve invited Smartsheet to talk about their success on the Google Apps Developer Blog and their founder, Brent Frei, has written an excellent post which I hope you’ll all take the time to read. He talks about how they decided to launch on the Marketplace, their technical evaluation, development process and the results they’ve achieved.

Here’s a graph that tells much of the story-- it shows their new customer leads (excluding pay-per-click-ads):

Here’s the post with their full story on the Google Apps Developer Blog:
Smartsheet - Inside Google Apps Marketplace

For more details on launching your app on the Marketplace, see our
developer site.

By Ryan Boyd, Google Apps Marketplace Team

[Gd] Stable Update: Bug and Security Fixes

| More

Google Chrome Releases: Stable Update: Bug and Security Fixes

Google Chrome has been released to the Stable channel on Windows.

This release fixes the following issues:
  • Google Chrome was not using the correct path for the Java plugin for Java Version 6 Update 20.
  • was much slower on JavaScript benchmarks than (Issue 42158)

This release also fixes the following security issues:
Please see the Chromium security page for more detail. Note that the referenced bugs may be kept private until a majority of our users are up to date with the fix.
  • [$1000] [40445] High Cross-origin bypass in Google URL (GURL). Credit: Jordi Chancel.
  • [40487] High Memory corruption in HTML5 Media handling. Credit: David Bloom of Google Security Team.
  • [$500] [42294] High Memory corruption in font handling. Credit: wushi of team509.

If you find issues, please let us know:

--Mark Larson, Google Chrome Team

[Gd] Smartsheet - Inside Google Apps Marketplace

| More

Google Apps Developer Blog: Smartsheet - Inside Google Apps Marketplace

Editor's Note: Brent Frei is founder and chairman at SmartSheet. Smartsheet makes an online project management solution that employs a spreadsheet-like interface on top of a powerful work automation engine. We invited SmartSheet to share their experience with the Google Apps Marketplace.

The Challenge

Last summer, the Smartsheet team had what I expect is a fairly typical Software as a Service (SaaS) company priorities discussion: should we integrate with one of the big application marketplaces? Here are some of the questions we considered:
  1. Are our customers asking for it?
  2. Will it give us access to a significantly larger lead flow?
  3. Do the people that use these apps typically pay for them?
  4. Would our target customer expect to find our type of tool there?
  5. What does the competition look like on each platform?
  6. What is the scope of the development effort?
Then, do the answers to any of these choices outweigh the benefits of the alternatives on our broader list of priorities?

Decision Time

Google Apps seemed to rank highly across all 6 criteria. Of the dozen major application marketplaces competing for ISV mindshare, Google Apps seemed to be the most natural 'upstream app' from Smartsheet. Google Apps customers were most likely to 'look next' toward solutions that are addressed by our application.

Weaving SmartSheet collaboration and workflow features in amongst the Google Apps was a very natural fit for our users. As you can see in the video, the familiar spreadsheet-like interface and direct access from the Google menu bar makes Smartsheet an effective companion app. The integration of Smartsheet with Google Apps turns the combination into the company's operating software.

It was therefore fortunate that the Google Apps APIs proved to be just as natural a fit. Well done, well documented, easy to implement and, as we later discovered, solid developer support.

The Details

Once the decision was made, we dedicated one senior architect and one product manager to designing and delivering the integration. It required about 4 days of technical investigation to validate the design concepts. The Google Apps API documentation and developer support were first rate, which made the delivery nearly as easy as the design.

Virtually every part of Google's application stack had a natural fit within our customer's common workflow.

  1. Universal Navigation and Single Sign-on
  2. Move Data to and from Google Spreadsheets
  3. Attach Google Docs to Any Row
  4. Open any attached file as a Google Doc
  5. Synchronize Contacts
  6. Display & Manage dates between Sheets & Calendars
  7. Share individual parts of the sheet via Gmail
We divided the development into two phases based largely on the availability of the specific Google Apps APIs. Mail and Calendar were phase 2, everything else was phase 1. We had a single, mostly dedicated developer for the effort.

Stage 1

We first implemented single-sign-on via OpenID and Google Docs API integration using OAuth for standard Google Accounts. This included data import/export, attaching Google Docs to rows, uploading office documents to Google Docs, and importing Contacts. We then extended this integration to support Google Apps users. These features were rolled out in Q3 of 2009, well in advance of the Google Apps Marketplace launch. It took a senior developer roughly 6 weeks to implement this first stage. With the core integration features completed, we were able to quickly implement new Apps Marketplace functionality, including Universal Navigation and the Licensing API, as they were made available in the sandbox.

Stage 2

We are developing full-featured Google Calendar integration, utilizing both the Google Calendar Data API and Calendar Event Gadgets, to be delivered in May 2010. Gmail integration will follow quickly, utilizing both the OAuth access to IMAP and SMTP and Gmail Contextual Gadgets. With the experience we have integrating other APIs, the development of these features is greatly simplified, as the infrastructure – implementation of OpenID, OAuth, and the GData Java Client Library – is already in place.

The Mechanics

We chose to enter three variations of Smartsheet into the Google Apps Marketplace: two mainstream solutions and one emerging technology solution.

  1. Smartsheet Sales Pipeline for Google Apps
  2. Smartsheet Project Management for Google Apps
Emerging Technology:
  1. Smartsheet Crowdsourcing for Google Apps
The decision to start with the Project Management and Sales Pipeline applications was based on the belief that they would have the broadest appeal to two Google Apps customer types: Small Businesses and Large Scale Education customers.

We included Smartsheet Crowdsourcing as a test of an entirely unique product that pushes an emerging trend.

The Results

Google Apps Marketplace has performed very well across several of Smartsheet's key performance indicators.

Strong Leads - the percentage of signups that accrue a statistically significant quantity of behavioral actions within the application. A strong lead is highly correlated with an eventual paying customer.
Convert to Paid - the percentage of total leads that eventually become paying customers.
Average MRR - Monthly Recurring Revenue is the average monthly spend of the leads that become paying customers.

The statistics are fantastic, and have improved the profitability of our customer acquisition programs significantly. Today, we get "free" leads generated by SEO, PR and buzz (Non-Paid). These are the Holy Grail source of profitable customers. We add $2,160 a month in recurring revenue for every 1,000 leads that come in via non-paid channels. At $1,740 a month per 1,000 leads, Google Apps Marketplace is also a very profitable channel that brings up the overall averages (subtract the 20% Google is planning to charge for Apps customers).

None of the statistics above matter without lead volume to power them. That's where the Google Apps Marketplace really makes these numbers sing. We've seen a very meaningful increase in high quality, non-paid lead flow directly attributable to Google Apps customers.

Our customers cite Smartsheet's tight integration with Google's Data APIs as a key factor in their decision to purchase. A common theme emerging in the feedback is reflected in this comment from a manufacturing company president: "Smartsheet is making the Docs component of Google Apps more useful to our team."

Moving Forward

Customer requests for features and enhancements to our Apps integration have already started pouring in. They are great guideposts toward attracting a larger percentage of these great Apps users.

The Google Apps Marketplace is a rich source of customers, so staying above the noise as it attracts more ISVs will be a priority. We're confident we can continue refining our product and services to deliver a superior solution. And, we'll count on the Google team to value customer success and application utility as primary criteria for rating and ranking the vendor directories.

By Brent Frei, Smartsheet

[Gd] Atlanta GTUG Meeting Tonight

| More

Google Web Toolkit Blog: Atlanta GTUG Meeting Tonight

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

When: 04/27 @ 7pm EDT

Where: Google Atlanta


Monday, April 26, 2010

[Gd] Google acquires Labpixies

| More

Google Code Blog: Google acquires Labpixies

Not everyone likes to start their day with just a search box and logo (no matter how cool it is!). Many users want email, videos, news, weather, games, and other information to be at their fingertips each time they open up a browser window. We launched iGoogle in 2005 to address this need by providing a truly personalized homepage with access to any RSS feed and well over a hundred thousand gadgets.

One of the first developers to create gadgets for iGoogle was Labpixies. Over the years, we worked closely together on a variety of projects, including the launch of a number of global OpenSocial based gadgets. Recently, we decided that we could do more if we were part of the same team, and as such, we're thrilled to announce the acquisition of Labpixies.

The team will be based in our ever-growing Tel Aviv office and will anchor our iGoogle efforts across Europe, the Middle East, and Africa. We are looking forward to working with Labpixies to develop great web apps and leverage their knowledge and expertise to help developers and improve the ecosystem overall.

In the meantime, have fun trying to beat me at Flood-It!

By Don Loeb, iGoogle Team

[Gd] Now available: Schedule for Google I/O sessions & office hours

| More

Google Code Blog: Now available: Schedule for Google I/O sessions & office hours

If you’re attending Google I/O next month, you’ve likely taken a gander at this year’s sessions and made a mental note of ones you’d like to attend. (Or if you’re like Julio Menendez, you’ve already made a list)

We’ve just posted our session schedule so you can now start planning out your two days at I/O. We’ve also got a few more things in the works to help you plan your agenda, including:

  • Session agenda builder to create a customized agenda you can port to your personal calendar. (Google Calendar, iCal, Outlook)

  • Google I/O Android app you can download to your Android device so you can easily reference the I/O schedule, star sessions, look at a map of the venue, and find other event info while you’re walking around Moscone West.

  • Google Wave will be in full force at I/O as a channel for discussion and live notes during I/O. Stay tuned for more information on how to use Wave at the event.

We’ll let you know as these agenda planning features go live. Be sure to check @googleio for the latest updates.

In addition, we’ve also posted our Office Hours schedule. Google engineers will be on hand to answer any questions you may have about the products and technologies featured at I/O. We’ll be holding office hours for Android, App Engine, Chrome, Closure Compiler / Closure Library, Enterprise, Developer Docs, Geo, Go, Google APIs, Google Project Hosting, GWT, Social Web, and Wave.

24 days left until I/O - let the countdown begin!

Posted by Christine Tsai, Google Developer Team


[Gd] Rich snippets go international

| More

Official Google Webmaster Central Blog: Rich snippets go international

Webmaster Level: All

As part of our efforts to make search results more useful to our users around the world, we’re announcing the international availability of rich snippets. If you’ve been following our blog posts, you already know that rich snippets let users see additional facts and data from your site in search results.

For example, we recently launched rich snippets for recipes which, for certain sites, lets users see quick recipe facts as part of the snippet and makes it easier to determine if the page has what they are looking for:

We’ve had a lot of questions on our blogs and forums about international support for rich snippets - and we know that many of you have already started marking up your content - so today’s announcement is very exciting for us.

In addition to adding support for rich snippets in any language, we have published documentation on how to mark up your sites for rich snippets in the following languages: simplified Chinese, traditional Chinese, Czech, Dutch, English, French, German, Hungarian, Italian, Japanese, Korean, Polish, Portuguese, Russian, Spanish, and Turkish. (You can change the Help language by scrolling to the bottom of the help page and selecting the language you want from the drop-down menu.)

We encourage you to read the documentation to take advantage of the different types of rich snippets currently supported: people profiles, reviews, videos, events and recipes. You can also use our testing tool (in English only, but useful to test markup in any language) and start validating your markup to make sure results show as you would expect.

Finally and as you’ve probably heard by now (several times), we’re taking a gradual approach to surface rich snippets. This means that marking up your site doesn’t guarantee that we’ll show rich snippets for your pages. We’re doing this to ensure a good experience for our users; but rest assured we’re working hard to expand coverage and include more web pages.

Written by Kavi Goel, Pravir Gupta, and Yu Watanabe

[Gd] New features in YouTube Direct v2.0

| More

YouTube API Blog: New features in YouTube Direct v2.0

We're happy to announce the release of YouTube Direct v2.0. This release includes substantial upgrades that will make it easier for developers to test and customize the platform. In addition to the backend changes, we've also fixed a number of reported bugs and added these brand new features:

  • Support for photo submissions.
  • Support for secure AuthSub.
  • Support for viewing and editing YouTube captions for any video submitted. All caption languages are supported.
  • Support for multiple YouTube Direct uploader embeds (for different assignments) on a single page.
  • Pre- and post-submission text is now configurable on a per-assignment basis.
  • Users can now select from a pre-populated list of the most recent 50 videos in their account when uploading an existing video.

If you're currently using v1.0, we encourage you to download the latest release and upgrade your deployment. Please read detailed release notes and documentation on the new features as well.

We've seen YouTube Direct used in many interesting applications so far and we hope that this new release will enable more creative and engaging campaign around videos and photos through your sites. If you have feedback on YouTube Direct, please visit our YouTube APIs Developer Forum and drop us a line. To receive announcements in the future, please subscribe to the YouTube API Annoucement list.

Amanda Surya, YouTube API Team