Parallel to the rise in importance of mobile apps comes increased emphasis on certain mobile platform services—geolocation, data service aggregation and home screen widgets, to name a few. Most of these are well understood by both consumers and developers, yet one sticks out as a challenge to both: offline access to app data. Business stakeholders almost always request support for offline usage scenarios at the beginning of a project, yet it is often nonexistent at the end. Why? The pain (and associated cost) of developing and testing the various facets of offline services causes this phenomenon. Yet offline services provide immense value to users; the ability to use the app absent network connectivity simply scratches the surface.
Offline Support Comes In Three Flavors
Not every offline support requirement is identical. Some situations require a simple client-side cache of content to be browsed without a network connection, while others require a full store-and-forward transactional architecture. The unique flavors of offline are roughly differentiated by their support, or lack thereof, for back-end conflict resolution. Synchronization often introduces a scenario where a mobile device’s local version of a record is updated, but by the time the update is sent to the back-office service, the data there has also changed. This results in a conflict—which record should be used, the more recent server data or the incoming client data from a previous synchronization?
Mobile developers can employ three common techniques for providing offline app support:
1. Client-side read-only cache: When app users simply need to read content while disconnected, client-side caching is the simplest way
to go. This allows the mobile app to bind the app’s user interface to a local data model and update the user interface when the local model changes. A great example of this type of offline support is Trane’s MAP app. The app, built by Cynergy (now part of KPMG), allows a salesperson to produce a quote for a customer while in the field. Pricing data updates at known intervals and the salesperson will not be updating it from their device.
2. Last write wins: ‘Last write wins’ is a better approach when offline app users need to add task creation, item updates or deletions in addition to reads. In cases where changes are infrequent and don’t come from multiple endpoints, robust conflict resolution policies aren’t critical. An example of this approach is an app that enables employees to update their internal social network, e.g., Chatter or Yammer. Submitting a status update is not dependent on previous updates to the server that may be overwritten.
3. Complete transactional synchronization: Follow this pattern when an app needs robust offline functionality while maintaining transactional integrity with back-end data stores or updates from different users or device channels. Building on the previous scenario, this allows for full mobile functionality along with fine-grained control of back-end conflict resolution. An example of this most comprehensive approach is an ERP approval process that must account for updates that may impact the approval justification while the mobile user is offline.
Building a robust offline solution may be the most difficult development challenge in mobile, as mobile apps requiring network connectivity for baseline functionality limit a company’s brand appeal and growth. Most emerging markets, and many developed ones, have areas where cellular connections are constrained at best. Apps smoothly employing offline functionality will differentiate brands as showing concern and understanding for all customers, regardless of their network context.
