Designing for intermittent connectivity

A great deal of software is built and tested on fast, stable connections, then deployed to people working in places where the network comes and goes. The result is familiar: an application that works during a demonstration and frustrates everyone in the field. Treating connectivity as an edge case is the root cause, because the fix is architectural rather than cosmetic.

Offline is a normal state, not an error

The first decision is where the authoritative copy of data lives while a user is working. If the answer is "the server", then every action requires a round trip and the application stops being useful the moment the connection does. If the answer is "the device, until it can synchronise", the application keeps working and the network becomes something that happens in the background.

That second choice has consequences you have to accept deliberately. Two people can now change the same record while neither can see the other's work, so the system needs an answer for what happens when both changes arrive.

Deciding how conflicts resolve

• Last write wins is simple and silently destroys data — acceptable only where records are genuinely owned by one person
• Append-only models avoid most conflicts by recording events rather than overwriting state, at the cost of a more complex read path
• Field-level merging works when different people reliably edit different parts of a record
• Explicit review queues put a human in the loop, which is often correct for data that matters

There is no universally right answer. What matters is choosing consciously, and making sure the people using the system understand what happens to their work when two devices disagree.

Synchronisation has to survive being interrupted

A sync that assumes it will finish will eventually corrupt something. Connections drop mid-transfer, applications get closed, and devices run out of battery. The practical requirements are unglamorous: send changes in batches small enough to complete on a weak connection, make every operation safe to retry so a partial upload does not produce duplicates, and keep an ordered queue on the device so that nothing is lost when a request fails.

Assume every synchronisation will be interrupted at the worst possible moment, and design so that the worst outcome is a delay rather than lost work.

Tell the user the truth about their data

People trust a system that is honest about its state. Show clearly whether something is saved on the device only or confirmed by the server, how long ago the last successful sync happened, and how many items are still waiting. Users tolerate delay well. What they do not tolerate is discovering days later that a form they submitted never arrived.

Budget for the device and the data

Field applications frequently run on inexpensive Android devices with limited storage and metered data. That constrains real decisions: how many images to cache, whether to send full records or only changes, how aggressively to compress. Testing exclusively on modern hardware over office wifi will hide every one of these problems until the software is in use.