Mobile app development / DIJION
What should a mobile app do when the connection drops?
A practical plan that separates offline reading, local drafts, pending submissions and reconnection.
A phone displaying a connection indicator does not guarantee that a particular request can finish. Weak Wi-Fi, a tunnel and an unavailable service can produce different outcomes. Design around the task instead of treating offline use as a warning banner. This guide describes an illustrative application, not offline features of a specific Dijion product.
Model connectivity and available data together
An initial launch with no content is different from showing previously loaded information. When older content remains available, explain its freshness. When no local data exists, explain why loading is unavailable rather than presenting an empty result.
Scroll the table horizontally to see all columns.
| Connection | Local data | Suggested behavior |
|---|---|---|
| Available | Available | Show current local content and refresh when appropriate |
| Available | Missing | Show loading and define a failure path |
| Unavailable | Available | Show the last content and its freshness limitation |
| Unavailable | Missing | Explain that the initial load needs a connection |
This is a planning aid, not a universal architecture. An operation requiring current information may not safely proceed using older data. Consider the consequences of acting on stale information for each data type.
Make separate decisions for reads and writes
Reading content and changing server data carry different risks. A note may be saved locally, but a message cannot truthfully be described as delivered without the required acknowledgement. Separate Draft saved, Waiting to send and Sent.
Automatically queuing every write is not always appropriate. An expired booking or a share the person no longer wants should not silently execute when connectivity returns. Define expiration, cancellation, duplicate protection and the user’s expectation before adding a queue.
Make the state visible with accurate language
Scroll the table horizontally to see all columns.
| State | Message | Meaning |
|---|---|---|
| Older content | Showing the last saved content. | No promise of current information |
| Local draft | Draft saved on this device. | No claim that it reached the server |
| Queued submission | Waiting to send. Sending will continue when connected. | Only appropriate for a real queue |
| Unknown result | We could not confirm that sending completed. | Neither success nor failure is assumed |
Check the implementation before approving the wording. If closing the app deletes the draft, Saved on this device may be misleading. A displayed update time should represent the actual data update, not merely the moment the screen opened.
Treat reconnection as its own flow
Decide which data synchronizes first and how changes affect the current task. Replacing an entire screen while someone edits a form can lose the effort that offline handling was meant to protect.
When two devices change the same record, define a conflict policy. Last-write-wins may suit some simple content and lose important data elsewhere. Consider history, merging or an explicit user decision according to the model. Use the outcome of the request rather than the connectivity indicator as evidence of completion.
Test four interruption moments
- Disconnect before the initial screen loads; loading should not continue forever.
- Disconnect after entering data but before submitting; preserve the input.
- Disconnect after the request begins; explain an unconfirmed outcome accurately.
- Close and reopen while an operation is pending; the state should match actual persistence.
Include reconnection in every scenario. Repeated connection changes can reveal duplicate submissions and timing problems. Use controlled test records rather than real payments or personal information.
Create a shared design and engineering contract
For each critical operation, document its read source, write acknowledgement, local persistence, timeout, cancellation and conflict behavior. Compare interface wording against those decisions. Android’s offline-first guidance explains local and network data sources; choosing a write policy still requires the application’s context.