A change saved on a phone appears on screen before the server receives it. The synchronisation protocol tracks the operation from its local database write through server acknowledgement. It retains delivery state so the operation can be retried after an interruption.
Consider an illustrative equipment-tracking application that records an observation and a photograph, with the record also available through a web interface. The design must preserve the same operation across interrupted connections, repeated delivery attempts and different devices. This example describes a possible architecture, independently of any particular product.
Save an operation before sending it
The phone stores the observation in a local database. The screen reads that database and indicates whether the operation is saved on the device, awaiting delivery or confirmed by the server. Losing connectivity therefore does not erase work already saved. This separation between local data, network exchanges and the interface follows the Android architecture for offline-first applications.
The same local transaction records the observation and the operation to transmit. Both writes succeed or fail together, keeping the synchronisation task with the captured data. The photograph can be transferred separately with its own identifier and delivery status. The observation remains available while the attachment is uploading.
Recognise another attempt at the same operation
A request can reach the server without its response reaching the phone. After an interruption, the application may therefore be unable to tell whether the write happened. Retrying is necessary; creating a second observation would be incorrect.
In this example, every operation receives an identifier before its first transmission. The server stores that identifier with the write result and recognises subsequent attempts. The retention period for this record must cover the period during which the phone can retry. Removing it too soon would reintroduce the risk of duplicates.
Recognition does not replace permission or content checks. An identifier already associated with an observation must not silently be reused for a different change. The API contract defines the response to an identical retry and to a request carrying different content.
Handle concurrent changes
Now suppose the record changed through the web interface while the phone was working with an older copy. The server needs a way to detect that situation. An expected version accompanies the change; if it no longer matches, the write can be rejected for comparison. HTTP preconditions, including If-Match, provide a standard mechanism for this check.
Two new observations can be retained separately. When two devices modify the same record, the protocol can merge independent fields. Contradictory values remain as a conflict for explicit resolution. A rule based only on the latest timestamp can overwrite a change and depends on clock synchronisation.
The interface translates these rules into understandable states. A locally saved observation, a photograph being uploaded and a conflict requiring review are different situations, rather than variations of one error message.
Verify the complete journey
Tests simulate a connection loss after the server write, a restart before acknowledgement, duplicate delivery and concurrent edits. They verify that one operation produces one observation, local data remains available and a conflict that cannot be merged is shown to the user.
The protocol connects the phone, API and other applications through a shared definition of a write. That definition makes it possible to add another device or interface without introducing competing interpretations of the same record.