Offline-first mobile apps significantly improve the user experience and overall usefulness of apps. There is plenty to consider when designing and architecting offline functionality into your apps. Most apps benefit from some form of offline capability. Having your app rely less on connectivity will enhance functionality, improve stability and increase performance.
Cache vs. Sync
When considering design, the first question you will want to ask is whether your app demands read-only offline cache or bi-directional read-write sync. There are many factors which play into which option you will want to choose. Make sure you work closely with users and stakeholders to determine the primary use cases as a starting point. Remember to start small and build out, analyse usage patterns and keep in touch with users, always make sure you’re building the right thing before you focus on building the thing right.
Timeliness of Data
The next question is more nuanced, timeliness of data, or when to pull new data from your backend. Again, context matters, you will need work with your users to determine timeliness for each piece of data.
Here is what I use to define timeliness, it’s roughly based on dimension types in data warehousing.
|0||Static data||SI units, elements|
|1||Data that changes infrequently||Head office address, countries|
|2||Semi-frequent; user modifiable data||Reference data, chemicals, regions|
|3||Frequently updated data||Customer list|
|4||Near real-time data||Active support queue|
|5||Real-time data||Market data|
Now that we have a definition of timeliness, let’s work on what that practically means, here’s another chart which describes when data should be loaded for each type.
|One time/ship with app package||0|
|Check for updates at launch||1, 2|
|Check on interval – background||1, 2|
|Check on interval – foreground||3, 4, 5|
|Check at screen load||2, 3, 4|
Data Retrieval Strategies
Next up, what do we pull? Here are a few data retrieval strategies, you likely don’t want to use the same retrieval strategy for all data, but will need to determine which strategy to employ on a per-model basis:
- All records
- Filtered record set
- Single record
Priority is crucial, user invoked requests should always take precedence over background operations. You will want to make sure your users get their data as quickly as possible. Furthermore, you will need to ensure your retrieval code checks network conditions to avoid unnecessary timeouts and errors.
As you can see, there is a lot to consider. This is only the tip of the iceberg. There is plenty more to discuss, next time, we will discuss handling conflicts and logging.