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.
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!
SELECT Author, COUNT(*) as NumArticlesFROM MagazinesGROUP BY AuthorORDER BY NumArticles;SELECT Author, COUNT(*) as NumBooksFROM BooksGROUP BY AuthorORDER BY NumBooks;
SELECT Author, NumPublications, PubTypeFROM ( 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;
CREATE TRIGGER IF NOT EXISTS RemoveAuthorAFTER DELETE ON BooksBEGIN DELETE FROM Authors WHERE Author NOT IN (SELECT Author FROM Books);END;
var divs = document.getElementsByTagName("div"); for (var i=0; i < divs.length; i++) { var div = document.createElement("div"); document.body.appendChild(div); }
