Jason Grigsby’s DOs and DON’Ts of Mobile Strategy

Last week Jason Grigsby visited Google as part of our Web Exponents speaker series which highlights innovations in web technology. Jason is a tech leader in mobile web development. In addition to spotting trends in the mobile space, Jason is at the front lines building mobile apps at Cloud Four. His humorous and informative talk includes technology recommendations and insightful examples from the world of mobile. Check out the video of the talk below. You can also download the slides.

Jason’s mobile strategy counterexamples include Chanel (they have an iPhone app but their website is unusable on the iPhone) and the difficulties of finding an Apple Store on the iPhone. His DOs and DON’Ts are:

DOs:

1. Know your customers and what devices they use.
2. Look beyond native apps to mobile web, SMS & MMS.
3. Apps for your most loyal customers add value.
4. Consistent experience across devices and offline.
5. Understand mobile context.

DON’Ts:

1. Don’t assume customers have downloaded your app.
2. Don’t rely on Flash.
3. Don’t make finding store locations & hours difficult.
4. Simple to use does not mean dumb.
5. Don’t forget that the ‘U’ in URL stands for Universal. (He goes on to point out that it really stands for Uniform.)

These all ring true for anyone with experience building for mobile. The hard part is figuring out the right solution for providing the right experience for desktop as well as diverse mobile devices. Jason gives a glimpse into the key features of a solution:

• integrated image resizing
• video conversion and resizing
• separation of content from markup so content can be used in native apps
• prioritization of content based on context
• full-featured APIs

The challenge in my opinion is in the steps of breaking out content from markup and determining which content is appropriate for a given device. We need frameworks that better support these ideas, but there’s still a lot of heavy design work on the developer’s shoulders. Jason points to NPR as an example of a large site that has successfully implemented this architecture. Check out Jason’s talk to find out more, and also check out some of the other videos in the Web Exponents playlist.

By Steve Souders, Performance Evangelist

Let's make the mobile web faster

This week, we've been celebrating all things mobile across Google. Of course, this wouldn't be complete without a component for mobile web developers! Two months ago we asked you to make the web faster. Now, we've asked the Google Mobile team for some best practices, tips, and resources for mobile web development, and we've come up with a few things we wanted to share. "Go Mobile!" with our Make the mobile web faster article.

By Jeremy Weinstein, Google Webmaster

Gmail for Mobile HTML5 Series: CSS Transforms and Floaty Bars

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week, I'll talk about different ways to animate the floaty bar.

Even from the earliest brainstorming days for our new version of Gmail for iPhone and Android-powered devices, we knew we wanted to try something novel with menu actions: a context-sensitive, always-accessible UI element that follows conveniently as a user scrolls. Thus, the "floaty bar" was born! It took us a surprisingly long time, experimenting with different techniques and interactions, to converge on the design you see today. Let's look under the covers to see how the animation is achieved. You may be surprised to find that the logic is actually quite simple!


Screenshots of the floaty bar in action

In CSS:

.CSS_FLOATY_BAR {
 ...
 top: -50px;  /* start off the screen, so it slides in nicely */
 -webkit-transition: top 0.2s ease-out;
 ...
}

In JavaScript:

// Constructor for the floaty bar
gmail.FloatyBar = function() {
 this.menuDiv = document.createElement('div');
 this.menuDiv.className = CSS_FLOATY_BAR;
 ...
};

// Called when it's time for the floaty bar to move
gmail.FloatyBar.prototype.setTop = function() {
 this.menuDiv.style.top = window.scrollY + 'px';
};

// Called when the floaty bar menu is dismissed
gmail.FloatyBar.prototype.hideOffScreen = function() {
 this.menuDiv.style.top = '-50px';
};

gmail.floatyBar = new gmail.FloatyBar();

// Listen for scroll events on the top level window
window.onscroll = function() {
 ...
 gmail.floatyBar.setTop();
 ...
};

The essence here is that when the viewport scrolls, the floaty bar 'top' is set to the new viewport offset. The -webkit-transition rule specifies the animation parameters. (The 'top' property is to be animated, over 0.2s, using the ease-out timing function.) This is the animation behavior we had at launch, and it works just fine on Android and mobile Safari browsers.

However, there's actually a better way to achieve the same effect, and the improvement is particularly evident on mobile Safari. The trick is to use "CSS transforms". CSS transforms is a mechanism for applying different types of affine transformations to page elements, specified via CSS. We're going to use a simple one which is translateY. Here's the same logic, updated to use CSS transforms.

In CSS:

.CSS_FLOATY_BAR {
 ...
 top: -50px;  /* start off the screen, so it slides in nicely */
 -webkit-transition: -webkit-transform 0.2s ease-out;
 ...
}

In JavaScript:

// Called when it's time for the floaty bar to move
gmail.FloatyBar.prototype.setTop = function() {
 var translate = window.scrollY - (-50);
 this.menuDiv.style['-webkit-transform'] = 'translateY(' + translate + 'px)';
};

// Called when the floaty bar menu is dismissed
gmail.FloatyBar.prototype.hideOffScreen = function() {
 this.menuDiv.style['-webkit-transform'] = 'translateY(0px)';
};

Upon every scroll event, the floaty bar is translated vertically to the new viewport offset (modulo the offscreen offset which is important to the floaty bar's initial appearance). And, why exactly is this such an improvement? Even though the logic is equivalent, iPhone OS's implementation of CSS transforms is "performance enhanced", whilst our first iteration (animating the 'top' property) is performed by the OS in software. That's why the experience was unfortunately somewhat chunky at times, depending on the speed of the iPhone hardware.

You'll see smoother looking floaty bars coming very soon to an iPhone near you. This is just the first in a series of improvements we're planning for the mobile Gmail floaty bar. Watch for them in our iterative webapp, rolling out over the next couple of weeks and months!

By Joanne McKinley, Software Engineer, Google Mobile

Previous posts from Gmail for Mobile HTML5 Series:
HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
Suggestions for better performance
Cache pattern for offline HTML5 web application
Using timers effectively
Autogrowing Textareas
Reducing Startup Latency

Gmail for Mobile HTML5 Series: Reducing Startup Latency

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week, I'll talk about how modularization can be used to greatly reduce the startup latency of a web app.

To a user, the startup latency of an HTML 5 based application is critical. It is their first impression of the application's performance. If it's really slow, they might not even bother to wait for the app to load before navigating away. Even if your application is blazing fast after it loads, the user may never get the chance to experience it.

There are several aspects of an HTML 5 based application that contribute to startup latency:

1. Network time to fetch the application (JavaScript + HTML)
2. JavaScript parse time
3. Code execution time to fetch the data and render the home page of your application

The third issue is up to you! The first two issues, however, are directly correlated with the size of the application. This is a tricky problem since as your application matures, it will have more features and the code size will get bigger. So, what to do? Modularize your application! Split up your code into independent, standalone modules. Consider splitting each view/screen of your application and implement each new feature as its own module. This is only half the story. Now that you have your code modularized, you need to decide which subset of these modules are critical to load your application's home page. All the non-core modules should be downloaded and parsed at a later time. With a consistent code size for your startup code, you can maintain a consistent startup time. Now, let's go into some nitty gritty details of how we built an application with lazy-loaded modules.

How to Split Your Code into Modules

Splitting an application into individual modules might not be as simple as you think. Code that serves a common purpose/functionality should be grouped together and form a module (comparable to a library). As mentioned earlier, we selected which modules are critical to the home page of the app and which modules can be lazy-loaded at a later time. Let's use a Weather application as an example:

High Level Functionality:

• A "Weather in my Favourite Cities" home page
• Click on a city to view the cities entire week forecast
• Weather data comes from an external web service

Possible Module Separation:

• Weather data model
• Weather web service API
• Common UI widgets (buttons, toolbars, navigation, etc)
• Favourite Cities page
• City Weather Forecast page

Now let's say your users want a "breaking news" feature. No problem: just put the page, the news data API and the data model into a new module.

One thing to keep in mind is the dependency order of your modules. For modules that have many downstream dependencies, it might make sense to include them as part of the core modules.

How to Lazy Load the Modules

Option 1: Script as DOM

This method uses JavaScript to insert SCRIPT tags into the HEAD's DOM.

<script type="text/JavaScript">
  function loadFile(url) {
    var script = document.createElement('SCRIPT');
    script.src = url;
    document.getElementsByTagName('HEAD')[0].appendChild(script);
  }
</script>

Option 2: XmlHttpRequest (XHR)

This method sets up XmlHttpRequests to retrieve the JavaScript . The returned string should be evaluated in the XHR callbacks (using the eval(string) method). This method is a little more complicated but it gives you more control over error handling.

<script type="text/JavaScript">
  function loadFile(url) {
     function callback() {
      if (req.readyState == 4) { // 4 = Loaded
        if (req.status == 200) {
          eval(req.responseText);
        } else {
          // Error
        }
      }
    };
    var req = new XMLHttpRequest();
    req.onreadystatechange = callback;
    req.open("GET", url, true);
    req.send("");
  }
</script>

The next question is, when to lazy load the modules? One strategy is to lazy load the modules in the background once the home page has been loaded. This approach has some drawbacks. First, JavaScript execution in the browser is single threaded. So while you are loading the modules in the background, the rest of your app becomes non-responsive to user actions while the modules load. Second, it's very difficult to decide when, and in what order, to load the modules. What if a user tries to access a feature/page you have yet to lazy load in the background? A better strategy is to associate the loading of a module with a user's action. Typically, user actions are associated with an invocation of an asynchronous function (for example, an onclick handler). This is the perfect time for you to lazy load the module since the code will have to be fetched over the network. If mobile networks are slow, you can adopt a strategy where you prefetch the code of the modules in advance and keep them stored in the javascript heap. Only then parse and load the corresponding module on user action. One word of caution is that you should make sure your prefetching strategy doesn't impact the user's experience - for example, don't prefetch all the modules while you are fetching user data. Remember, dividing up the latency has far better for users than bunching it all together during startup.

For an HTML 5 application that takes advantage of the application cache to reduce startup latency and to serve the application offline, there are a few caveats one should be aware of. Mobile networks have decent bandwidth, but poor round trip latency, so listing each module as a separate resource in the manifest incurs quite a bit of extra startup latency when the application cache is empty. Also, if one of the module resources fails to be downloaded by the application cache (e.g. disconnected from network), additional error handling code needs to be written to handle such a case. Finally, applications today have no control when the application cache decides to download the resources in the manifest (such a feature is not defined in the current specification of the draft standard). Typically, resources are downloaded once the main page is loaded, but that's not an ideal time since that's when the application requests user data.

To work-around these caveats, we found a trick that allows you to bundle all of your modules into a single resource without having to parse any of the JavaScript. Of course, with this strategy, there is greater latency with the initial download of the single resource (since it has all your JavaScript modules), but once the resource is stored in the browser's application cache, this issue becomes much less of a factor.

To combine all modules into a single resource, we wrote each module into a separate script tag and hid the code inside a comment block (/* */). When the resource first loads, none of the code is parsed since it is commented out. To load a module, find the DOM element for the corresponding script tag, strip out the comment block, and eval() the code. If the web app supports XHTML, this trick is even more elegant as the modules can be hidden inside a CDATA tag instead of a script tag. An added bonus is the ability to lazy load your modules synchronously since there's no longer a need to fetch the modules asynchronously over the network.

On an iPhone 2.2 device, 200k of JavaScript held within a block comment adds 240ms during page load, whereas 200k of JavaScript that is parsed during page load added 2600 ms. That's more than a 10x reduction in startup latency by eliminating 200k of unneeded JavaScript during page load! Take a look at the code sample below to see how this is done.

<html>
...
<script id="lazy">
// Make sure you strip out (or replace) comment blocks in your JavaScript first.
/*
JavaScript of lazy module
*/
</script>

<script>
  function lazyLoad() {
    var lazyElement = document.getElementById('lazy');
    var lazyElementBody = lazyElement.innerHTML;
    var jsCode = stripOutCommentBlock(lazyElementBody);
    eval(jsCode);
  }
</script>

<div onclick=lazyLoad()> Lazy Load </div>
</html>

In the future, we hope that the HTML5 standard will allow more control over when the application cache should download resources in the manifest, since using comments to pass along code is not elegant but worked nicely for us. In addition, the snippets of code are not meant to be a reference implementation and one should consider many additional optimizations such as stripping white space and compiling the JavaScript to make its parsing and execution faster. To learn more about web performance, get tips and tricks to improve the speed of your web applications and to download tools, please visit http://code.google.com/speed.

Previous posts from Gmail for Mobile HTML5 Series

HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
Suggestions for better performance
Cache pattern for offline HTML5 web application

By Bikin Chiu, Software Engineer, Google Mobile

Gmail for Mobile HTML5 Series: Autogrowing Textareas

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of what we've learned in a brief series of follow-up blog posts. This week I'll talk about autogrowing textareas for entering large amounts of text.

When composing a long message in a web app, regardless of whether it's on a desktop or a mobile device, you really want to see as much of your draft as possible and make use of all the available screen space.

One of my biggest gripes are fixed-size textareas that restrict me to only a couple lines of visible text when my screen is actually many times larger than the size of the textarea.

In today's blog post, I'll share a JavaScript solution for textareas that automatically grow (vertically) to the size of the content. They make composing long messages much easier and, for all those iPhone users out there, takes away the need to scroll with the dreaded magnifying glass! We're working on getting this into Gmail for mobile but here it is now as a teaser of things to come.





Measuring the height of the content

The first step is to detect when the content has changed. Some solutions on the net recommend using a timer (see our previous post to find out more about timers) to check if content has changed. However, that approach is not ideal on a mobile device, where both battery life and processor power are limited.

Instead, we will listen for key-up events from the browser. This guarantees that we only measure the textarea when the content has actually changed.

<textarea id="growingTextarea" onkeyup="grow();"></textarea>

The second step is to actually measure the height of the content. There are solutions on the net that recommend keeping a copy of the content in a div and measuring the div to get the height; however, due to memory and processor limitations on a mobile device, those solutions don't scale well when the content gets large (and it's also hard to replicate textarea line wrapping behavior exactly in a div).

Therefore we will make use of the scrollHeight and clientHeight properties. For our purposes, scrollHeight is the height of all the content while clientHeight is the height of the content that's visible in the textarea (for more precise definitions, see scrollHeight and clientHeight)

function grow() {
  var textarea = document.getElementById('growingTextarea');
  var newHeight = textarea.scrollHeight;
  var currentHeight = textarea.clientHeight;
…
}

One limitation of using scrollHeight and clientHeight is that we aren't able to shrink the textarea when content is deleted. When all the content of a textarea is visible, the scrollHeight is equal to the clientHeight. Therefore we aren't able to detect that our textarea is actually larger than the minimum size required to fit all the content (please do leave a comment if you think of a solution that doesn't require re-rendering the page).

Growing the textarea

To grow the text area, we modify the height CSS property:

if (newHeight > currentHeight) {
  textarea.style.height = newHeight + 5 * TEXTAREA_LINE_HEIGHT + 'px';
}

Notice how we only change the height if newHeight > currentHeight. Depending on the browser, changing the height (even if it's to the same value) will cause the page to re-render. On a mobile device, we want to try our best to minimize the number of operations.

Also, we grow the textarea by five lines every time we grow. From a UI perspective, this reduces the amount of jitter when composing a message but, from a performance perspective, this reduces the number of times we need to re-render the page.

(Quick note for developers implementing this for a browser with scrollbars: you might want to modify the CSS overflow property to preventing the scrollbar from appearing and disappearing as you grow your textarea)

The complete solution

Growing textareas are easy to implement and they make composing long messages infinitely more usable. So go out there add it to all your web apps!

<script>
// Value of the line-height CSS property for the textarea.
var TEXTAREA_LINE_HEIGHT = 13;

function grow() {
  var textarea = document.getElementById('growingTextarea');
  var newHeight = textarea.scrollHeight;
  var currentHeight = textarea.clientHeight;

  if (newHeight > currentHeight) {
     textarea.style.height = newHeight + 5 * TEXTAREA_LINE_HEIGHT + 'px';
  }
}
</script>
<textarea id="growingTextarea"
          onkeyup="grow();">
</textarea>

Previous posts from Gmail for Mobile HTML5 Series

HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
Suggestions for better performance
Cache pattern for offline HTML5 web application

Using timers effectively

By Casey Ho, Software Engineer, Google Mobile

Gmail for Mobile HTML5 Series : Cache Pattern For Offline HTML5 Web Applications

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow-up blog posts. This week, I'll talk about the cache pattern for building offline-capable web applications.

I recently gave a talk (preserved YouTube here) about the cache pattern and the Web Storage Portability Layer (WSPL) at Google I/O. It was exciting getting to give a talk at the Moscone Center as previously I had only ever been one of the audience members. The conference seemed to go by in a blur for me as I was sleep-deprived from getting the WSPL to "just good enough" to actually be released. (And some ofyou have already pointed out that I missed several bugs.) In my talk, I provided a general overview of the cache pattern and this post expands on the handling of hit determination and merging server and local changes.

The cache pattern is a design pattern for building an offline-capable web application. We implemented the cache pattern to make Gmail for Mobile tolerant of flaky wireless connections but the approach is generally applicable. Here's how it works. Consider a typical AJAX application. As shown in the diagram, we have a web application with a local model, view and controllers. The user interacts with theapplication and the controller dispatches XmlHttpRequests (XHRs for short) to the server. The server sends asynchronous requests to the application which it inserts into the model.

As shown in this next diagram, in the cache pattern, we insert a cache between the application and the server. Having done so, many requests that would otherwise require a round-trip to the network.

A software cache like this one shares a great deal conceptually with hardware caches. When designing the cache used in Gmail for mobile, we used this similarity to guide our design. For example, to keep our cache as simple as possible, we implemented a software equivalent to a write-through cache with early forwarding and LRU eviction. The cache pattern in general (and consequently our implementation) has four important data flows as shown in the diagram.

• Cached content bound for the UI.
• Changes made to the cache by the user in the UI. These need to be both reliably sent to the server and updated locally in the cache so that reads from the cache for UI updates show the state including user changes.
• The changes recorded in the cache need to be sent upstream to the server as the network connection is available.
• Changes made to the server (like email delivery in the case of Gmail) need to be merged into the contents of the cache.

As shown in the diagram we also need a place to actually write the data. We use the WSPL library to write a cache implementation portable across both Gears and HTML5 databases.

To actually implement these four data flows, we need to decide on a hit determination mechanism, a coherency strategy and a refresh approach.

Hit Determination

At its heart, a cache is a mapping from keys to values: the UI invokes the cache with a key and the cache returns the corresponding element. While this sounds pretty simple, there is an additional source of complexity if the application wants to provide the user with summary listings of some subset of all values available from the server. To provide this feature, the cache needs to contain not only "real" data values but additional "index" values that list the keys (and possibly user-visible summaries) for "data" values. For example, in Gmail for mobile, the cache stores conversations as its "real" data values and lists of conversations (such as the Inbox in Gmail for Mobile) as its "index" values. Keys for index values are computed specially to record what subset of the complete index is cached locally. For example, in Gmail for Mobile, while a user's Inbox may contain thousands of conversations, the cache might contain an index entry whose data values lists metadata for only conversations 1000 through 1100. Consequently, Gmail for Mobile's cache extends keys with the cached range so that a request for metadata for conversations 1101 through1110 would be considered a cache miss.

Coherency and Refresh

Perhaps the most complex aspect of the cache implementation is deciding how to get updated content from the server and how to merge server updates with changes made locally. A traditional hardware cache resolves this problem by only letting one processor modify its a cache at a time and have the memory broadcast any changes to all the other caches in the system. This approach cannot work here because the Gmail server can't connect to all of its clients and update their state. Instead, the approach we took for Gmail for Mobile was for the client device regularly poll the server for alterations.

Polling the server for changes such as new email or the archiving of email by the same user from a different device implies a mechanism for merging local changes with server side changes. As mentioned above, Gmail for Mobile is a write-through cache. By keeping all of the modifications to the cache in a separate queue until they have been acknowledged, they can be played back against updates delivered from the server so that the cache contains the merge of changes from the server and the local user. The following diagram shows the basic idea:

The green box in the diagram shows the contents of the cache's write buffer changing over time and the cloud corresponds to the requests in-flight to the server with time advancing from left to right in the diagram. The function names shown in the diagram are from the simplenotes.js

example file in the Web Storage Portability Layer distribution. Here, the user has applied some change [1] and the cache has written it to the write buffer and has then requested new content resulting in query [Q]. The cache prefixes the outstanding actions from the write buffer to the query. Action [1] is marked as needing a resend on some sort of network failure.

Later, the user makes change [2] to the UI which causes the cache to append it to the write buffer in the applyUIChange call. Later still, another query is made and so, the cache sends [1][2][Q] to the server. In the mean time, the user makes yet another change [3]. This is written to the write buffer. Once changes [1] and [2] are acknowledged by the server along with the new cache contents for query [Q], changes [1] and [2] are removed from the write buffer. However, to keep the cache's state reflecting the user's changes, change [3] is applied (again) over top of the result for [Q].

Simplifying the implementation of this reapplication stage is the most important benefit of implementing a write-through cache. By separating the changes from the state, it becomes much easier to reapply the changes to the cache once the server has delivered new content to the cache. As discussed in a previous post, the use of SQL triggers can greatly improve database performance. Whether updating or re-updating, triggers are a great way to make the application of changes to the cache much more efficient.

Cached Content To the UI

The first of the four data flows is delivering content to the UI is reasonably easy: query the cache for the desired content and when the query completes, forward the request to the UI. If you look at the getNoteList_ function from the simplenotes.js example code included in the WSPL distribution, you'll see that the delivering cached content to the UI has the following basic steps:

perform hit determination: deciding if the requested cache contents are actually in the cache.

• create a database transaction, and while in the transaction
• query the database for the desired key
• accumulate the results
• then outside of the transaction, return the result to the UI.

Changes From The UI

The second flow (applyUiChange) is recording changes made by the user to the write buffer. It has a very similar structure

• create a database transaction, and while in the transacation
• write the change to the write buffer
• wait for a trigger to update the state of the cache.

Updates Bound For The Server

As discussed above, once the changes have been written to the write buffer, they still have to be sent to the server. This happens by prepending them to queries bound for the server. The fetchFromServer from the example is responsible for this. As might be familiar by now, the flow is

• create a database transaction and while in the transaction
• query the write buffer for all the entries that need to be sent to the server
• accumulate the entries
• then outside the transaction, send the combination of changes and query to the server

Changes From The Server

Finally, we need to merge the changes from the server into the cache as is done in the insertUpdate method from the example. Here the flow is as follows:

• create a database transaction and while in the transaction
• update the directory
• write the new content into the cache
• touch the changes in the write buffer that need to be re-applied to the cache
• wait for the trigger to complete its update
• then, outside of the transaction, send the response to the UI if it was satisfying a cache miss.

That's a brief intro to the cache architecture as found in Gmail for mobile. We're continuing to improve our implementation of this basic architecture to improve both the performance and robustness of Gmail for mobile. Please stay tuned for follow on blog posts.

Previous posts from Gmail for Mobile HTML5 Series
HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage
Suggestions for better performance

By Robert Kroeger, Software Engineer, Google Mobile Team

AdSense for Mobile Applications Beta

Are you developing free iPhone or Android applications? With our new beta product - AdSense for Mobile Applications, you can monetize your mobile applications by showing contextually targeted ads and/or placement targeted ads alongside your application content. We provide you with iPhone and Android SDKs and example applications that request and display AdSense ads. Our SDKs also support DoubleClick ads.

You can show 320x50 text and image ads linked to HTML webpages in your application. These ads are targeted to the keywords that you send us in the AdSense (or DoubleClick) ad request. The keywords must be relevant to your application content. If your application content is loaded from a webpage that is customized for iPhones and Android handsets, then you can also send us the webpage URL for us to target ads. The ads may also be placement targeted which means an advertiser can specifically target to your application.

Our iPhone SDK is compatible with iPhone OS 3.0, and our Android SDK is compatible with Android 1.5 SDK. The SDKs include a library that can be linked in to your application which exposes methods to fetch and show ads. You must place a maximum of one ad per screen at the top or bottom (see the screenshot from the Backgrounds iPhone application). When a user clicks on the ad in your application, you can choose whether the user should view the advertiser's website in iPhone Safari or a full-screen UIWebView on the iPhone. For Android applications, our API defaults to opening the advertiser's website in the native browser.

To get started with monetizing your iPhone or Android application, sign up today on the AdSense for Mobile Applications website. We can't wait to have you join our beta network!

By Jennifer Lin, Software Engineer, Google Mobile Team

Gmail for Mobile HTML5 Series: Suggestions for Better Performance

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow-up blog posts. This week, I'll talk about a few small things you can do to improve performance of your HTML5-based applications. Our focus here will be on performance bottlenecks related to the database and AppCache.

Optimizing Database Performance

There are hundreds of books written about optimizing SQL and database performance, so I won't bother to get into these details, but instead focus on things which are of particular interest for mobile HTML5 apps.

Problem: Creating and deleting tables is slow! It can take upwards of 200 ms to create or delete a table. This means a simple database schema with 10 tables can easily take 2-4 seconds (or more!) just to delete and recreate the tables. Since this often needs to be done at startup time, this really hurts your launch time.

Solution: Smart versioning and backwards compatible schema changes (whenever possible). A simple way of doing this is to have a VERSION table with a single row that includes the version number (e.g., 1.0). For backwards-compatible version changes, just update the number after the decimal (e.g., 1.1) and apply any updates to the schema. For changes that aren't backwards compatible, update the number before the decimal (e.g., 2.0) at which point you can drop all the tables and recreate them all. With a reasonable schema design to begin with, it should be very rare that a schema change is not backwards compatible and even if this happens every month or so, users should get to use your application 20, 30 even 100 times before they hit this startup delay again. If your schema changes very infrequently, a simple 1, 2, 3 versioning scheme will probably work fine; just make sure to only recreate the database when the version changes!

Problem: Queries are slow! Queries are faster than creates and updates, but they can still take 100ms-150ms to execute. It's not uncommon for traditional applications to execute dozens or even hundreds of queries at startup – on mobile this is not an option.

Solution: Defer and/or combine queries. Any queries that can be deferred from startup (or at any other significant point in the application) should be deferred until the data is absolutely needed. Adding 2-3 more queries on a user-driven operation can turn an action from appearing instantaneous to feeling unresponsive. Any queries that are performed at startup should be optimized to require as few hits to the database as possible. For example, if you're storing data about books and magazines, you could use the following two queries to get all the authors along with the number of books and magazine articles they've writen:

SELECT Author, COUNT(*) as NumArticles
FROM Magazines
GROUP BY Author
ORDER BY NumArticles;

SELECT Author, COUNT(*) as NumBooks
FROM Books
GROUP BY Author
ORDER BY NumBooks;

This will work fine, but the additional query will generally cost you about 100-200 ms over a different (albeit less pretty) query like:

SELECT Author, NumPublications, PubType
FROM (
  SELECT Author, COUNT(*) as NumPublications, 'Magazine' as PubType, 0 as SortIndex
  FROM Magazines
  GROUP BY Author
  UNION
  SELECT Author, COUNT(*) as NumPublications, 'Book' as PubType, 1 as SortIndex
  FROM Books
  GROUP BY Author
)
ORDER BY SortIndex, NumPublications;

This will return all the entries we want, with the magazine entries first in increasing order of number of articles, followed by the book entries, in increasing order of the number of books. This is a toy example and there are clearly other ways of improving this, such as merging the Magazines and Books tables, but this type of scenario shows up all the time. There's always a trade-off between simplicity and speed when dealing with databases, but in the case of HTML5 on mobile, this trade-off is even more important.

Problem: Multiple updates is slow!

Solution: Use Triggers whenever possible. When the result of a database update requires updating other rows in the database, try to do it via SQL triggers. For example, let's say you have a table called Books listing all the books you own and another called Authors storing the names of all the authors of books you own. If you give a book away, you'll want to remove it from the Books table. However, if this was the only book you owned by that author, you would also want to remove the author from the Authors table. This can be done with two UPDATE statements, but a "better" way is to write a trigger that automatically deletes the author from the Authors table when the last book by this author is removed. This will execute faster and because triggers happen asynchronously in the background, it will have less of an impact on the UI than executing two statements. Here's an example of a simple trigger for this case:

CREATE TRIGGER IF NOT EXISTS RemoveAuthor
AFTER DELETE ON Books
BEGIN
  DELETE FROM Authors
  WHERE Author NOT IN
    (SELECT Author
     FROM Books);
END;

We'll get into more detail on triggers and how to use them in another performance post to come.

Optimizing AppCache Performance

Problem: Logging in is slow!

Solution: Avoid redirects to the login page. App-Cache is great because it can launch the application without needing to hit the network, which makes it much faster and allows you to launch offline. One problem you might encounter though, is that the application will launch and then you'll need to hit the network to get some data for the current user. At this point you'll have to check that the user is authenticated and it might turn out that they're not (e.g., their cookies might have expired or have been deleted). One option is to redirect the user to a login page somewhere, allow him to authenticate and then redirect him back to the application. Regardless of whether or not the login page is listed in the manifest, when it redirects back to your application, the entire application will reload. A nicer approach is for the application itself to display an authentication interface which sends the credentials and does the authentication seamlessly in the background. This will avoid any additional reloads of the application and makes everything feel faster and better integrated.

Problem: AppCache reloading causes my app to be slow!

Solution: List as few URLs in the manifest as possible. In a series of posts on code.google.com, we talked about the HTML5 AppCache manifest file. An important aspect of the manifest file is that when the version gets updated, all the URLs listed in the file are fetched again. This happens in the background while the user is using the application, but opening all these network connections and transferring all that data can cause the application to slow down considerably during this process. Try to setup your application so that all the resources can be fetched from as few URLs as possible to speed up the manifest download and minimize this effect. Of course you could also just never update your manifest version, but what's the point of having rapid development if you never make any changes?


That's a brief intro to some performance considerations when developing HTML5 applications. These are all issues that we ran into ourselves and have either fixed or are in the process of fixing in our application. I hope this helps you to avoid some of the issues we ran into and makes your application blazing fast!

We plan to write several more performance related posts in the future, but for now stay tuned for next post where we'll discuss the cache pattern for building offline capable web applications.

By Derek Phillips, Software Engineer, Google Mobile

Previous posts from Gmail for Mobile HTML5 Series
HTML5 and Webkit pave the way for mobile web applications
Using AppCache to launch offline - Part 1
Using AppCache to launch offline - Part 2
Using AppCache to launch offline - Part 3
A Common API for Web Storage

Android: Now beaming I/O videos and presentations to the world

Google I/O was one of Android's biggest events of the year, with a Mobile track that focused primarily on all things Android, and 22 developers showcasing some of their great Android applications at the Google I/O developer sandbox.

For those of you who missed I/O or could not make all the Android sessions, we're excited to release session videos and presentations from the Mobile track online and free to developers worldwide.

At this year's I/O, we wanted to help developers further optimize their applications for the Android platform by creating better user experiences. Romain Guy explored techniques for making Android apps faster and more responsive using the UI toolkit. Chris Nesladek discussed the use of interaction design patterns in the Android system framework to create an optimal user experience. Since mobile application development is inextricably tied to battery performance, Jeff Sharkey provided an insightful look at the impact of different application features and functionalities on battery life. Taking the mobile experience further, T.V. Raman and Charles Chen discussed building applications that are optimized for eyes-busy environments, taking advantage of the Text-to-Speech library, as well as new UI innovations that allow a user to interface with the device without needing to actually look at the screen.

We also offered a few sessions on building compelling and fun apps that take advantage of the Android media framework and 2D and 3D graphic libraries. Chris Pruett discussed the gaming engine that he built and used as a case study to explain best practices and common pitfalls in building graphics-intensive applications. David Sparks lifted the hood on the infrastructure by diving into Android's multimedia capabilities and expanding on how to use them to write secure and battery-efficient media code.

We also had several sessions that meditate on challenges, best practices, and philosophies for writing apps for Android. Dan Morrill demonstrated multiple techniques for developing apps for Android in different scenarios, to help developers make the right decisions on the right techniques for writing their apps. Joe Onorato talked to developers about leveraging Android's ability to support multiple hardware configurations to make their applications run on a wide variety of devices without the overhead of building a custom version for each. Justin Mattson talked about advanced usage of Android debugging tools in his session and presented real-world examples in which these tools were used at Google.

Lastly, Robert Kroeger returns from the frontlines of launching Gmail Mobile Web for iPhone and Android's offline capabilities and shares the team's experiences in using a portable write-through caching layer running on either HTML 5 or Gears databases to build offline-capable web applications.

We hope these session videos and presentations are helpful to all Android developers out there. Don't forget to check out our newly announced Android Developer Challenge 2 - we look forward to seeing your passion, creativity, and coding prowess come together in the great apps you submit in this next challenge!

By Azhar Hashem, Google Developer Products

Gmail for Mobile HTML5 Series: A Common API for Web Storage

On April 7th, Google launched a new version of Gmail for mobile for iPhone and Android-powered devices. We shared the behind-the-scenes story through this blog and decided to share more of our learnings in a brief series of follow up blog posts. Over the last few weeks we've talked about how to use the AppCache functionality of HTML5 to launch an application offline. We discussed the impact that AppCache can have on your mobile web applications, as you enable users to launch your app faster in the face of flaky or slow internet connections. This week, I'll talk about how we're using both HTML5 Structured Storage and the Google Gears Database to make devices tolerate flaky network connections.



Although these technologies allow web applications to cache user data on the mobile device and perform data modifications locally, HTML5 Structured Storage uses an asynchronous model, where the Google Gears Database uses a synchronous model. This difference makes it difficult to develop an application on top of both platforms. We dealt with this problem by creating the Web Storage Portability Layer (WSPL) for Gmail. Coming soon under a liberal open source license to code.google.com/p/webstorageportabilitylayer, WSPL provides a common API that supports an identical asynchronous programming model for both platforms by using a worker thread in Gears. Let's take a look!

The WSPL consists of a collection of classes that provide asynchronous transactional access to both Gears and HTML5 databases. It can be used to execute nested statements within callbacks, create statement templates, and optionally control the synchronous/asynchronous modes of the Gears Database Wrapper. There are five basic classes.

google.wspl.Statement - A parametrizable SQL statement class
google.wspl.Transaction - Used to execute one or more Statements with ACID properties
google.wspl.ResultSet - Arrays of JavaScript hash objects, where the hash key is the table column name
google.wspl.Database - A connection to the backing database, also provides transaction support
google.wspl.DatabaseFactory - Creates the appropriate HTML5 or Gears database implementation

Let's take a look at how we can use this API to perform a simple query, starting with the creation of a Database. Note that you'll need to provide a URL to the worker file hosted from your domain.

var database = google.wspl.DatabaseFactory.createDatabase('db name', 'http://yourdomain/dbworker.js');

You can then execute SQL statements without worrying about the specifics of HTML5 and Gears. Refer to the recent blog posts about AppCache to find steps you can follow to see your database contents using sqlite3.

var statement = google.wspl.Statement('SELECT col from test_table;');
database.createTransaction(function(tx) {
  tx.executeAll([statement], {onSuccess: function(tx, resultSet) {
    // Statement succeeded.

    for(; resultSet.isValidRow(); resultSet.next()) {
      window.console.info(resultSet.getRow()['col']);
    }
  }, onFailure: function(error) {
    // Statement failed.
  }}); 
}, {onSuccess: function() {
    // After transaction commits, before any other starts.
}, onFailure: function(error) {
    // After transaction fails, before any other starts.
}});

I've found that using the Gears database asynchronously will nicely split up the JavaScript execution, allowing event handlers and other code to execute between the callbacks. This can improve the responsiveness of your application if you're using long transactions. You can also use SQL triggers to avoid the read-modify-write pattern that causes "ping ponging" between threads -- either the main thread and Gears worker or the main thread and the HTML5 SQL thread.

That's all I'll show you for now, but you can look for more details about the Web Storage Portability Layer at Google I/O, May 27-28 in San Francisco where we'll be presenting a session on the architecture of a generic application using HTML5. We'll also be available at the Developer Sandbox and are looking forward to meeting you in person. Stay tuned for the next post where we'll talk about improving the performance of HTML5-based web applications.

By Matthew Bolohan, Software Engineer, Google Mobile

Using the Google Static Maps API and HTTP Geocoder to power Lonely Planet's mobile travel guide

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 Ken Hoetmer of Lonely Planet.

Lonely Planet has been using Google Geo APIs since 2006 - you can currently find them in use on destination profiles at lonelyplanet.com , in our trip planner application , in our hotel and hostel booking engine , on lonelyplanet.tv , and in our mobile site, m.lonelyplanet.com . I could talk for hours about any of these sites, but in preparation for Google I/O and my talk at the Maps APIs and Mobile session, I'll spend this post discussing our use of the Google Static Maps API and the HTTP geocoding service on m.lonelyplanet.com.

Our mobile site's primary feature is highlighting points of interest (POIs) around you, as selected by Lonely Planet. The site is browser based and targeted at a baseline of devices. This accessibility is great for on the road, but because of this choice, we can't obtain precise user locations via a location API. Instead, we've asked our users to self-select their location by entering it into a free form text field when they first arrive at the site. This location is then posted to our server, geocoded on the back end by forwarding the text to the Google HTTP geocoding API, and then used to either set the user's location or return a list of options for disambiguation.

Knowing the user's position, we then forward the position and a radius in kilometers to our Content API's POI proximity method, returning a list of points within range, in order of proximity. Once we have the POIs, we need to present them on a map, relative to the user's location. This is where the Google Static Maps API comes in. We can't rely on the availability of Flash, JavaScript, and Ajax, but the Static Maps API enables us to serve a JPEG map by simply providing our list of POI geocodes, a few bits about labeling markers, and a height / width (which we calculate per device by querying screen sizes from WURFL) as query parameters to a URL. Below the map we put a few links for switching the map between (road)map, satellite, hybrid, and terrain base maps.

That gives us a basic map, but what if the user wants to look a little farther to the north or east? To enable this, we augmented the map with a lightweight navigation bar (north, south, east, west, zoom in, zoom out), with links to new static maps that represent a pan or zoom action. Here's how we generated the links:

Let's say our page has a static map of width w pixels, height h pixels, centered at (lat,lng) and zoom level z.

$map_link = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$lng}&zoom={$z}";

Then, we can generate north, south, east, and west links as follows (this example assumes the existence of a mercator projection class with standard xToLng, yToLat, latToY, lngToX routines):

// a mercator object
$mercator = new mercator();

// we'll pan 1/2 the map height / width in each go
 
// y pixel coordinate of center lat
$y = $mercator->latToY($lat);

// subtract (north) or add (south) half the height, then turn
 back into a latitude
$north = $mercator->yToLat($y - $h/2, $z);
$south = $mercator->yToLat($y + $h/2, $z);


// x pixel coordinate of center lng
$x = $mercator->lngToX($lng);

// subtract (west) or add (east) half the width, then turn back into a longitude
$east = $mercator->xToLng($x + $w/2, $z);
$west = $mercator->xToLng($x - $w/2, $z);

So that our north, south, east, west links are:

$north = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$north},{$lng}&zoom={$z}";
$south = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$south},{$lng}&zoom={$z}";
$east = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$east}&zoom={$z}";
$west = "http://maps.google.com/staticmap?key={$key}&size={$w}x{$h}&center={$lat},{$west}&zoom={$z}";

Of course if you're serving a page knowing only a list of points and their geocodes, then you don't have a zoom level value for calculating the map links. Thankfully, mercator projection implementations often offer a 'getBoundsZoomLevel(bounds)' function, which serves this purpose (create your bounds by finding the minimum and maximum latitudes and longitudes of your list of geocodes). If your implementation doesn't provide this function, it's not complicated to write, but I'll leave that to the reader (hint: find difference in x and y values at various zoom levels and compare these to your map width and height).

As mentioned earlier, I'll be joining Susannah Raub and Aaron Jacobs to delve deeper into maps and mobile devices at Google I/O. In addition, Matthew Cashmore (Lonely Planet Ecosystems Manager) and I will be meeting developers and demoing our apps in the Developer Sandbox on Thursday, May 28. We'd love to meet you and we'll be easy to find - simply follow the noise to the jovial Welshman.

Guest Post by Ken Hoetmer, Lonely Planet

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 quirksmode.org. 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

QR Codes now available on the Google Chart API

By Hiroyuki Komatsu, Google Chart API team

You can easily render 2D bar codes, known as QR Codes, with the Google Chart API, along with pie charts and bar graphs. If you haven't seen a QR Code before, you are looking at one on the right hand side (To see more, do an image search for "QR Code".)

QR Codes are a popular type of two-dimensional barcode. You can encode URLs, contact information, etc. into a black-and-white image like the one on the right. A QR-Code-enabled device can later scan the image and read back the original text. Learn more about QR Codes from Google Print Ads. If you don't have a reader Google also offers a QR Code decoder library: Zebra Crossing (ZXing).

This is how you can creating these with the Google Chart API:

Simply, there is a new chart type, qr, with attributes to tell the service what to produce:

cht=qr
chl=<text>
choe=<output>

<text> is text for the QR code. This must be url-encoded in UTF8. Note the space between hello and world is written as %20 in the following example.
<output> optionally specifies how the text is encoded into bytes in the QR Code. If this is not specified the default of UTF-8 is used. Available options are: Shift_JIS, UTF-8, or ISO-8859-1.

For the details, please read the full documentation.

Google Developer Podcast: Picasa Web and Google Gears for Mobile

By Dion Almaer, Google Developer Programs

Using iTunes?

I had the pleasure of taking a trip back to my home land of England to meet up with the team behind the Google Gears for Mobile product.

As someone who loves Web development, it is an exciting proposition to be able to use the Web platform to be able to develop applications on the mobile.

This release enables you to use the Gears 0.3 APIs on Windows Mobile devices. With this new version, not only do you have access to the Database, LocalServer, and WorkerPool APIs, but you can also create desktop shortcuts. Considering the disconnected nature and latency issues inherent to the mobile networks, these APIs allow you to deliver more responsive applications that can hide some of the problems.

Today, we saw the release of a new mobile version of Picasa Web Albums that uses these features. I got to sit down with Joe Walnes, tech lead of the mobile Picasa team. Joe and his team built both the Gears-enabled version of Picasa for the phone as well as the iPhone version that allows you to sit on the Tube and still flip through your family photos.

Joe tells us about his experience building the Gears application.



I have also put together an audio podcast consisting of interviews with not only Joe, but other members of the Gears team.

First, I talk to Charles Wiles, the Product Manager of the Google Gears for Mobile team. He gives us a high level view of the project in general, and this launch in particular. We also discuss the native abilities of Gears on the mobile, widget platforms, and future Gears developments.

Second, we hear from two engineers on the project, Dave Burke and Andrei Popescu. They go into detail on the platform, how you architect mobile Web applications, how you develop and debug applications, new APIs such as the Location API, and how Android fits in to the picture.

Finally, we hear again from Joe Walnes.

I am really excited about the prospect of building rich mobile applications using Web based technology.

You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).

Power up your mobile web applications

By Charles Wiles, Product Manager, Google Mobile Team

It's a mobile zoo out there. If you've ever tried coding up a mobile client application, you've probably noticed that the huge variety of mobile operating systems makes it tough to build rich applications that work on every device. We face the same challenges. But what if developers could deploy applications directly to mobile browsers rather than develop native applications? That would simplify the development process, as developers could use the same coding skills to create mobile applications. Even better, if these mobile web applications could work offline, users would be able to use them when they are disconnected from the network.

Developers, look no further. Today we're announcing the launch of Google Gears for mobile, a mobile browser extension for creating rich web applications for mobile devices. The first version is now available for Internet Explorer Mobile on Windows Mobile 5 and 6. It's a fully functional port of Google Gears v0.2 that can be used to develop offline capability into your mobile web applications. You can also create slick and responsive applications by hiding latency issues through controlled caching of data and storage of information between sessions. We're also working to bring Google Gears for mobile to Android and other mobile platforms with capable web browsers.

There are already a handful of Windows Mobile web apps that use Google Gears for mobile, such as the personal finance service Buxfer and online applications provider Zoho.  Read more about these applications and how they use Google Gears for mobile on the Google mobile blog.

For more on the vision for Google Gears for mobile and its origins, watch this video.

Dreamweaver Tools for Google

By Sean Owen, Google Mobile Search

We keep making more services available to mobile users; in addition to Google Mobile Search, you will find that Google News, Google Maps, and more have had a mobile presence for a while. So, we want to make it easy for developers to link to and use these services in mobile web sites. I'm therefore pleased to note that we've collaborated with WebAssist to add new mobile tools to their Dreamweaver Tools for Google plugin. The newly-released version 2.0 of this free tool includes, among other things, one-click access to embedding Google Maps, News, Mobile Search, and Send-to-phone in a page.