
Mobile devices in the wilderness: unreliable networks and scarce power
In the areas of the developed world where most of us live, power is plentiful and easily accessible, and a good internet connection is rarely far away. This often isn’t the case outside of these areas, and upon straying away from them we see how poorly many devices and apps manage. This is a collection of observations from my travels to remote parts of the UK, Scandinavia, the Alps, and the Himalayas.
I hope that sharing them will encourage device and app to bear in mind the non-urban-developed-world use case, and consider using the many technologies we have at hand for building good offline experiences — both in apps and on the web.
External power isn’t always plentiful
The device may be charging from a power pack, or a small solar panel attached to a backpack. Many power-saving features/modes are automatically suspended while charging, causing postponed background work to begin — wasting power.
Not all functionality needs the network
Users expect installed apps to be functional while offline, especially features that don’t logically need to send or receive data. Quite a few apps however appear to be very thin layers on top of the APIs that they communicate with, which can’t do anything useful offline.
Not all functionality needs the network right now
Some features do need the network at some point in order to be useful, but they don’t need it at the moment of user interaction. Sending a text message or an email are prime examples — the user shouldn’t be expected to keep an eye on network availability and manually retry once a connection is available.
Another example is data syncing. The Garmin Connect app is unable to sync track data from GPS watches (which have limited memory) without an internet connection. Most users would reasonably expect it to be able to sync with the watch offline, and forward the data to the online portal later when a network connection is available. This looks like a glaring omission from such an outdoor-oriented device/app, which is reasonably likely to be used in the wilderness for a few days.
The network may not be back for a long while
There’s no point in continuous scanning for a signal using the mobile radio on maximum power, draining the battery in the process. Some devices are better than others on this; I assume the better ones use some kind of backoff strategy.
The workaround is to turn on airplane mode, but that leaves it to you to turn it off periodically to check if there’s a signal.
The network may be working. Or is it?
Offline modes and behaviour seem to be often triggered by the presence of a network connection. This is conveniently queryable from native and web APIs. It is however prone to false positives — a connection to a network (mobile, or Wi-Fi), doesn’t necessarily imply a working connection through to the internet. This can prevent offline functionality from kicking in, so further checks/monitoring is needed.
The network may work, but unreliably
Requests can fail moments after others have succeeded, and if tried again there’s a reasonable chance that they’ll succeed. The key is to allow retrying, either automatically or by the user.
If they don’t succeed however, previous or cached data can be shown. This requires not discarding cached data any earlier than successful completion of requests.
The network may work, but slowly
When a request doesn’t complete within a certain amount of time, it’s common to timeout — give up on it, and show an error message. “Taking too long to load”, for example. On slow networks however, too short a timeout period can prevent the user from retrieving any data. Longer, increasing, timeouts should be used for retry requests. The user would prefer to wait, over not getting any data at all.
Taking care of offline data
Some apps allow data to be downloaded in advance at the request of the user, specifically for later offline use. This is common in mapping applications.
The user is likely relying on such data, so care must be taken to avoid losing the data or rendering it useless. A true example of the latter is an app quietly auto-updating to a new version, which used a newer data format. This necessitated re-downloading all the data, which I only realised the next time I tried to use it offline.
Explicit consent for system updates
Installing a system update is a risky and power-hungry operation, which is unlikely to be urgent or of great benefit, and in the worst case could render the device unusable. When the user is relying on the device (to an extent), it’s therefore especially important not to install them automatically. They should require explicit consent beforehand, and not even be scheduled to happen automatically with an option to postpone.
Usual good request/caching practices help
These contribute to a better experience in the face of most of the above conditions. They include not re-requesting the same data over and over again, only requesting the data that’s actually needed, and using compression.
Device features for conserving data
Marking Wi-Fi connections as “metered” avoids their used in the background to download data or app/system updates. This is useful for bought allowances, or hot-spots. Unlike with mobile networks, where data caps are more common, this is left to the user’s initiative/knowledge. The default is that it’s fine to slurp large low-importance downloads over them.
Data saver (or similarly named features), restrict background applications from using data. As well as reducing usage, this avoids contention with the app the user is currently using. Whatever the user is doing is more important than anything else the device or any app wants to do for itself.
Conclusion
On encountering these scenarios, as a software developer I always thought “we can do better than that”. And many apps do.
Developing a good offline experience does take some effort beyond error handling and caching good practices. For some, it may be that the effort isn’t justified for the sake of a minority of users a small proportion of the time. Some of these scenarios from the wilderness do however occur where we live: tunnels, aircraft, rural not-spots, and buildings of certain constructions.