Plan a field-service app for connection loss
Define what is stored offline and how the app handles changed jobs when it reconnects.
Define the permitted offline work
For an offline entry, the app must distinguish local capture from successful transmission to the office. Decide for each task whether reading, drafting or a binding completion is allowed without a network. An app need not permit every write offline to remain useful during connection loss.
The Android documentation distinguishes write strategies and discusses conflicts on reconnection. What matters for planning is the business meaning of displayed states: a local draft is not the same as a confirmed save on the server.
Example: keep the note, clarify the cancellation
This scenario is entirely fictional. The device knows job AU-64 at version v7. A specialist enters a completion note offline. Meanwhile, dispatch cancels the job on the server, creating v8. In this example, authorised clarification may allow the note to be stored as additional information without reversing the cancellation.
Situation | Local state | Expected behaviour |
|---|---|---|
Enter a note offline | Draft on the device | Show “Saved on this device only”; do not report successful completion. |
Close and reopen the app | Unsent draft | In the planned reopening test, the draft is available and editable. |
Connection returns | Draft based on an older state | Check the changed server state, show the conflict and keep the note; do not overwrite cancellation automatically. |
Authorised clarification and confirmed save on the server | Note accepted as additional information | Show acceptance; the job remains cancelled. |
This is a list of expected results, not a report of executed tests. A network icon or a sent request is not enough to establish the final state. It requires confirmation that the server has actually stored the intended change.
Check the entire path back to the server
Keep the known version for reconciliation. A later device-clock time alone does not decide which change is correct for the business. Define the conflict rule and the role authorised to decide unresolved cases. Also prevent retries from creating the same note more than once.
Check current permissions on the server when resending. OWASP calls for permission checks on every request. An earlier login does not automatically authorise every later change. Clearly display a missing login or rejected save.
Also agree on local access rules and behaviour on logout, device replacement or deletion of app data. Include disconnection, reopening, conflict and retry in the trial. This makes it clear where work has only been prepared and where it has been accepted as committed.
Sources
Read more
All articles
Software Development with ASES
Custom software, web and mobile apps