As I posted on the Google Gears Blog:
Omar Kilani of Remember The Milk took the time to write up his teams experience in Taking web applications offline with Google Gears.
The article moves past an introduction to delve into the design decisions around an offline-capable architecture, and user messaging and presentation of state. We learn why Omar decided to go with the explicit offline mode, and then the five steps to offline conversion:
- Ensuring resources are available offline
- Decoupling the application from the network
- Persisting data on the client
- Re-creating application state from persisted data
- Developing a synchronization strategy.
There is a lot to learn here.
From their architecture considerations:
RTM was designed as a client-side application from inception. The server-side portion of RTM is mainly used as a “dumb” data store, and the application periodically synchronizes with the server. In this case, using Gears to provide offline access was a natural fit, and was relatively quick to implement as we had some prior experience with data synchronization protocols.
There were some features of the online experience that could not be carried over to the offline mode. One of these was the Google Maps integration, in which users can geolocate their tasks and quickly visualize where their tasks are occurring in the real world. As Google Maps requires access to Google servers to fetch map tiles and data, and such a data set is quite large and thus hard to cache, this functionality is disabled once the user enters offline mode.
The undo feature of RTM is also unavailable in the offline version as this is a complex server-side operation (due to the multi-user nature of RTM and the ability to share tasks and lists). Instead, the user is presented with a dialog box asking for confirmation if they execute a destructive action such as delete. Undo functionality in offline mode is on the RTM roadmap, however.
To the decisions they made on showing the user information on whether they are online or offline:
A fundamental design decision is whether to implement offline support as “modal” or “modeless.” Choosing which style to implement will, in most cases, be dictated by the type of data the application works with and how much of that data will be available offline. One style is not necessarily superior to the other, and, for example, it’s much easier to implement a modeless style for tasks (in RTM) than it is for feed items (in Google Reader) based on the size of data items and the total data set alone.
Finally, we learn some tips and caveats from the RTM Gears implementation, including dealing with the LocalServer, the different types of offline, defensive coding, debugging, and coding with upgrades in mind.
Omar Kilani wraps it up in his conclusion:
By now, you should be itching to add offline support to your web application (we hope!). If you should take anything away from this article, it’s that taking your application offline isn’t as hard or complex as it may first seem, and that Gears is a joy to work with (and it’ll become even easier and more fun as the project matures and is used by more applications).
As for us at RTM, we couldn’t be happier with Gears. The speed at which we were able to provide offline functionality (four days from reading the documentation to a launchable implementation) is a testament to the quality, ease of use, and production-readiness of Gears. Many thanks to the Google Gears engineers for their foresight and for making this an open source project to which members of the Internet community can contribute.
Thanks to the Remember The Milk team for taking their application offline in record speed, and for taking the time to share their experience.
