The Offline Experience in the Enterprise

As the enterprise mobile ecosystem continues to mature across industry verticals the mobile apps built to deliver business value on the go become more and more relevant. And with them comes the one unique challenge most consumer apps don’t need to worry as much about: the offline experience.

No matter if an app is built to monitor inventory across stores, provide patient info in hospitals or remote care centers, manage projects at a construction site or sell to farms, there is no guarantee a web connection will be available nor that the connection speed will be reliable enough to support your needs. We know this as “offline mode” and we need to talk about how to address it and how to best control your app’s behavior when connectivity is an issue.

Firstly, offline or poor connectivity in the field should always be included in your early discussions around technical and business requirements. Here is a quick cheat-sheet to help you scope your offline requirements:

  • What is the business value of investing in an offline strategy?
  • Do all the data models need to be available offline?
  • How often do the offline models need to be updated?
  • Do you need to create a set of conflict resolution rules?
  • How sensitive is the data?
  • Buy vs Build (vs Already-Bought)

Once you understand the initial requirements around your offline needs, the next step is to evaluate which strategy best suits those needs.

Fully Offline-Operational

A good solution for critical data that doesn’t require frequent updates (e.g. a price catalog that gets updated weekly). This usually involves a synchronous process for sending and receiving data so you must be cognizant of the amount of data in motion and maintain the ability to roll back if a connectivity issue occurs. Also, it wouldn’t hurt to load-test your backend in the case of simultaneous syncing by multiple users. As for the expiration date of information stored on the device, this can either be controlled by the database or on a per model basis. Regardless, policies may easily be set which force the user to sync.

Usually, apps built in accordance with this model won’t connect to the server unless a specific action happens. All transactions will be restricted to the local database, potentially also providing the added benefit of yielding a more performant app than one which must wait for the server to respond.

Online with Offline Support

This approach assumes the user is always online. A loss of connectivity will cause the app to revert to a local database. The moment connectivity is restored the app will sync those offline records back to the server. The basic recommendation for loading data in this case is to block the UI and use a loading indicator only when data importance is really high. All other functions should load in the background so as not to block the UI for the user.

One edge-case (though common to this approach) is that users may realize the offline transactions are faster (since there is no waiting—compared to the milliseconds required to process an HTTP request), prompting them to use the app in airplane mode and potentially causing issues with your strategy.

Online Only

This approach is ideal when you just can’t leverage offline use for your field app, either due to the sensitivity of the data or due to the rate of updates required. This may negatively impact your user experience or the availability/reliability of your data, so our recommendation for this strategy is to make the best of a bad situation by handling low (or no) connectivity gracefully. Be frank and open with users. Provide ample feedback. Let them know what is going on, why they can’t access the data, and what do they need to do to continue working. Note: if you’re interested in learning more about error message best-practices, check out this entertaining piece by one of our strategists.

Mixed Strategies

The three options above define a starting point for supporting limited connectivity. The specifics of your business requirements and data will dictate whether you should leverage a combination of these strategies—based on specific modules within your app or data models that have specific constraints to support offline. It is also entirely valid to incorporate multiple approaches within the same app.

Conflict Resolution Strategies

Regardless of which offline strategy is most appropriate for your app, you should be aware that conflicts will most likely persist and that rules must be defined to manage these conflicts. For instance, opting for a ‘Fully Offline-Operational’ or an ‘Online with Offline Support’ approach will usually require the user to sync their local database to the server and pull any changes.

Another consideration is the strategy you employ to resolve any conflicts. The most common strategies are: ‘Client Always Wins’, ‘Server Always Wins’ or ‘Last Update Wins’, but you may choose to extend your approach to ‘User Decides’ or even opt to go with a ‘Custom Algorithm’.

Enabling offline support for a mobile app is one of the most challenging phases of app development. Thankfully, plenty of information is available to help you formulate the best solution. Countless developers have already faced this problem so you shouldn’t feel like you need to reinvent the wheel. But you must remember to factor in additional time for developing and testing the various scenarios.

Data Caching Strategies

Similarly, if needed, you will also need to establish a set of requirements to define the cache rules.

Caching data in the local database can be done through any approach so you may want to consider this alternative as a way to enable faster loading, but it’s fair to say that just because you have a cache mechanism in place doesn’t necessarily mean your app is “offline-ready.”

Tools and SDK exist to support a client cache (or you can build your own) but keep in mind that in any case you must still define your cache expiration date. This date may be unique for every model in the local database or can be at the database level. Don’t forget to consider the user who logs out of your application. Should the cache persist or should you delete it? And if it persists, what happens when another user logs in on the same device?

Don’t forget this one basic rule:

Just because you can do it, doesn’t mean you should do it. Most commonly the organization already employs a set of tools that enables some offline capabilities but there may not be much value in implementing it if your data is so critical that not being up to date can create more consequences than benefits.

At Propelics we fully understand the benefits of having an offline strategy to make field apps successful (and conversely, the consequences of not having one). So if you are currently building an app or need to evaluate offline solutions for your use cases, feel free to contact us now to consult with a Solutions Architect or Enterprise Architect.

Share on

Facebook sharing Linkedin sharing button Twitter sharing button

Ready to get started?

Enter your information to keep the conversation going.
Location image
4 Sentry Parkway East, Suite 300, Blue Bell PA, 19422

Email Image

Phono Image610 239 8100

Location Image4 Sentry Parkway East, Suite 300, Blue Bell PA, 19422
Phono Image610 239 8100