No Connection? No Problem.

Note: This is part 1 of a multi-part blog post regarding offline support with mobile applications. This is a big topic with various approaches.

The promise of mobility has always been the ability to be connected wherever you are. In reality, connectivity outside of controlled environments like the home or office is far less reliable or predictable. The true test of mobility is not whether your app has network connectivity in the field but rather if your app can perform its tasks when it does not. This is especially true for the class of apps that fall into the field apps category. Apps that are in this category are typically utilized by field technicians, domain specialists and employees that don’t typically find themselves in full signal network environments. Basically the real world outside of the office setting.

When setting out to design and build apps for field use, it is important to start thinking about offline from the start. This is the one key difference between mobile apps and their browser app equivalents. Chief amongst those differences is the assumption that the network is always available and fast. For web browser-based apps this is a reasonable assumption. For mobile apps it is not. Mobile apps cannot make assumptions about the stability, quality, or existence of a user’s network connection. To insulate the app from the unpredictable nature of network connections, a good data management and transfer strategy needs to be employed. At the core of an app’s offline capabilities lies the ability to *synchronize* data collected or changed while an app is in a disconnected state.

Identifying and selecting the correct sync mechanism to use is imperative to building a robust and effective offline app. The sync options available for apps run across a spectrum. At one end you have completely custom, “roll-your-own” sync implementations and at the other end you have “off-the-shelf” sync solutions. We will discuss a few of these options that fall within this spectrum in depth and explore some of the benefits and drawbacks of each in this and subsequent blogs on this topic.

Sync Frameworks

There are a number of sync frameworks, libraries, and services available to developers to choose from that provide pre-packaged solutions. Utilizing these off-the-shelf solutions typically means less coding, easier integration of sync features and support from either commercial providers or open source projects and communities.

When looking at using a third-party sync solution you can also select a full “sync-as-a-service” solution which has the benefits of not requiring any infrastructure management. All the major sync service providers have mobile SDKs which make coding and integration easier which should shrink your app’s time-to-market. Outsourcing your infrastructure does come with some costs which vary depending on usage and SLAs. The main drawback to these sync services is that your app’s domain model and requirements need to match what the sync providers offer. If you are building an new “greenfield” app, this may not be an issue. However, if you are integrating a legacy application with a complex data model, you will likely not be able to fully embrace these frameworks.

Full Sync Frameworks

If you can model your domain for a NoSQL environment, then sync providers like Cloudant and CouchBase might be the right fit. If your data needs to be relationally structured, something like Azure Mobile Service’s sync support might be the right choice. The hosting for these options comes at a cost, but will likely be far less than attempting to build your own version.

Sync Libraries

If you find that you need to have more control over how the data is managed and stored or how conflict resolution is handled, then moving to a third-party library might be the best option. Development is still easier since apps are still written against sync frameworks so developers aren’t left writing lots of code but, when necessary, the ability to extend and provide custom implementations and business logic is available. Examples of these types of frameworks are Ensembles which provides the sync functionality to your CoreData-backed apps but requires adapters to be written to the backing data stores. The nice thing about Ensembles is that it ships with iCloud and DropBox adapters and provides examples on how to write a custom adapter to suit your needs. Another option is OwnCloud which is an open-source project which provides client and server libraries to allow sync functionality to be added between backend servers and apps.

Roll You Own

These solutions work well when your app, domain and project requirements allow for it but that is not always the case. Some of SPR’s clients have had legal or regulatory requirements that have prevented cloud-based solutions from being used. Other clients have required us to build a sync layer on top of large legacy database systems — and some even on mainframes. For these cases, we had to develop custom sync solutions. The benefits of writing your own sync framework is that you can highly customize the solution to your problem domain. Traditional problems like conflict resolution can be tailored for the app’s needs and there is no magic occurring behind the scenes which may leave you guessing what is going on with the processing of data.

However, in terms of risk and complexity, writing a custom sync solution are extremely difficult. A custom solution will involve writing and testing large amounts of code which will slow time to market. Once the system is written and in production, a custom solution may be hard to maintain over time as the decisions and unique constraints of the implementation may be difficult for new or other developers to pick up on.

Next Part

In the next part of this blog series we’ll go into the nuances of using each of the approaches noted above. There’s not always a clear-cut solution for each project. Careful planning and research needs to be done when selecting one of these approaches. Lack of research and proper expectation-setting can lead to project overruns or, even worse, project failures.

Contributor: Kevin McMahon