Mobile development
Designing mobile apps for unreliable connections
A connection can disappear halfway through an ordinary task. Someone might be reading on a train, filling in a form in a crowded building, or opening an app before Wi-Fi is available. Decide how that experience should work while the product is still being designed.
Choose what must keep working
List the app’s core tasks and decide which ones should remain available without a network. A reading app could keep downloaded material available. A notes app could allow a person to create and edit a local draft. An action that needs a server decision may need to wait.
Android’s offline-first architecture guidance describes using local and network data sources, with the local source supplying the data read by the app. That is a useful starting point when planning an Android app whose essential reading experience must survive a lost connection.
Name the state people are actually in
‘Saved on this device’ and ‘Synced to your account’ describe different outcomes. Make that difference visible where it matters. If a user has entered something valuable, they should be able to tell whether it is stored locally, waiting to upload, or available on another device.
Avoid replacing a useful screen with a full-page connection error when existing content can still be shown. A small status message can explain that the content may be out of date and offer a retry without interrupting reading.
Plan how changes meet again
Reconnecting is part of the feature. Decide what happens when a queued change reaches the server, when the same record was edited elsewhere, and when a retry repeats an action. The appropriate policy depends on the data: merging two notes is a different problem from confirming a booking.
Write these decisions down before implementation. For each action, specify whether it can be queued, whether a person can cancel it, and what they see if it is rejected. Where a conflict cannot be resolved safely, preserve the person’s input and ask them to choose.
Test the interruption, not just the launch
Start a task online, disconnect before saving, close the app, and reopen it. Then reconnect and inspect the result. Repeat while a request is in progress and while another device changes the same information.
The aim is a predictable experience: people can keep doing the tasks you promised, understand what has been saved, and recover their work when something goes wrong. Define that promise narrowly enough to deliver it well.