When I first started at Google, we were building a Java ME email client for the phones of the day. It's an excellent product - still the fastest, slickest way to get your Gmail on many devices because of Java ME's widespread penetration. Yet it always bothered us that this client didn't really leverage the core strength of the desktop Gmail platform: sheer ease of access from anywhere, and constant updates and improvements. To use the client, you have to figure out how to install it and possibly navigate confusing network permission pop-up dialogs, and improvements could only be rolled out a few times a year in upgrades that required every user to download and reinstall their software.
The mobile team started thinking about how we could bring the benefits of the server-side approach to these clients. We started thinking about a world where we could deliver a GUI specified in XML to a Java ME client, enabling us to iterate on the server side and deliver new features that could delight users when they were ready, rather than on a lengthy release cycle. I was especially struck by a friend who said "What I like about Gmail is that it just constantly keeps getting better. It's like waking up to a new little present from Google each month!" We wanted our mobile users to feel the same way, so we felt the logical thing to do would be to build a general client that could be controlled by the server.
Not too long after, the team first saw the new Android browser. Still in its early stages, the Android browser was built on the latest version of WebKit and could render desktop pages with ease. The XHTML, images, JavaScript, and CSS that could be rendered on this platform presented great potential for building very high-end web applications. However, this was ages before Android was due to ship and Android would only be one of many mobile platforms.
Those drawbacks aside, we couldn't help but think that new browsers in Android's league would eventually become a reality. These powerful browsers could have the kind of functionality we needed to build top-notch, offline user interfaces that didn't need to be "installed" by users or "upgraded". Gmail could be Gmail: a constantly evolving way to handle lots of email quickly and efficiently. The only fly in the ointment was the need for Gears: users would have to download a browser plug-in, and most web browsers on mobile devices don't even support that. What we really needed was for Gears to inspire innovation in HTML itself, so that the whole web could move forward.
Enter HTML5. We're very excited about the evolving HTML5 standard because it enables mobile and desktop website designers to deliver the advantages of client-side and server side development to their users simultaneously! New APIs let web applications start offline and store data on the client. The canvas API lets you draw complex user interfaces, or you can use advanced CSS tricks to get the browser to render a rich UI. In addition, the W3C Geolocation API is being adopted and implemented by browser developers, enabling entire new categories of web applications to be built. The benefits are clear: you can develop fantastic new applications, benefit from server-side analytics and iteration to deliver features that your users want, and know that offline functionality keeps things running as the user moves in and out of coverage. Your users can enjoy fast, capable web apps that they can access from any device, without the need to copy their data from place to place or worry about installing software or being online.
We decided to build new versions of mobile Gmail and mobile Calendar on top of this functionality. First, we built a small javascript wrapper around the database functionality in HTML5 and Gears. This wrapper abstracts away the differences between the two APIs, so that our applications are supported on the broadest set of browsers possible while older browsers get updated with implementations of the new offline APIs. We noticed that we weren't the only ones thinking about this: a quick search shows that other developers saw the similarities too. The main difference between the Gears database API and the HTML5 database API is that the Gears API is synchronous, requiring separate worker threads to do the database calls, while the HTML5 database API uses callbacks and is asynchronous. With the wrapper built, we knew our code would run on all high-end mobile browsers today, and look forward to even more distribution as everybody implements HTML5.
We knew we could apply various approaches to building better experiences for Gmail and Calendar. The key principle we kept in mind is an age-old one: KISS. Simply caching responses in the database for re-use is surprisingly effective: you can get a lot of improvement with just a read-only environment. This approach worked well for Calendar, where usage is predominantly read-only and we can rely on the user being online to make edits.
For Gmail, more complexity was needed. A queue of user actions needs to be maintained in the database (in case the user runs out of battery or powers down for their flight). Later, when the device is back online, it can execute that queue of mails to send, archive or delete, and so on.
Having the ability to store your data and actions offline isn't much good if you can't start the application while offline. So besides making use of the database API, we needed a way to get the application itself loaded without an internet connection. The HTML5 specification comes to the rescue here, with an application cache that is capable of storing all resources in your web app so that the browser can load them while offline. This API has just one small drawback: once you've decided you're going to override how HTTP GET works to fetch resources from the application cache, you also commit to never issuing a GET for a resource the cache doesn't know about. The specification contains methods for extending what URIs the cache knows exist, but these entry points are not widely implemented in production browsers. Instead, it's important to use HTTP POST requests for all dynamic data, since POST requests are never cached and therefore do reach the network.
The end result is an incredible thing: a web app that loads offline, and lets you read your Gmail or view your events provided the data have previously been cached. The experience is seamless as you ride the subway or the bus through terrible coverage: your data are ready, quickly, all the time. To see the new Gmail for mobile web app, go to gmail.com from an Android-powered device or iPhone (OS 2.2.1 or above).
Of course we didn't get there without a few hard knocks. As an evolving standard, HTML5 has been fast-changing target and we've skinned our knees and bruised ourselves along the way. So rather than just deliver the fruit of all those bumps and scratches to end users in our own products, we decided we wanted to write a few blog posts to share what we've learned so that others can take advantage of HTML5 as well. In addition, we look forward to opportunities like our upcoming developer conference, Google I/O (May 27-28 in San Francisco, CA) where we'll be hosting a few sessions, to meet you in person and share demos and know-how.
Whether or not you can make it out to Google I/O, stay tuned to the blog for upcoming posts with examples such as how to avoid making your databases too large, handle upgrades gracefully, and tune performance.
No comments:
Post a Comment