HTML5 and WebKit pave the way for mobile web applications
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.
By Alex Nicolaou, Engineering Manager,
Google Mobile
