Plan a field-service app that preserves useful work during connection loss, explains sync states, handles conflicting edits, and avoids duplicate submissions.
An offline-first business app does not need to approve every action without a server. A technician might read assigned visits and prepare a report in a basement with no reception, while reserving stock or approving an invoice requires a current shared record. Define what can be read locally, what remains a draft, and what becomes authoritative only after the system confirms it. Those boundaries are the foundation of a reliable promise.
Choose a promise that your team can test
Android's offline-first guidance distinguishes reading from writing and explains that offline reading does not require supporting every kind of offline write. Turn that distinction into a specific user promise rather than describing the whole product as available offline.
Consider a hypothetical air-conditioning maintenance company. A technician downloads assigned visits before leaving the office, then records observations and selects photographs during a visit with poor reception. The downloaded record helps them work, but cannot establish that a spare part is still available or an invoice has just been paid. Useful local work and current business authorization are different capabilities.
Classify actions by consequence
For each action, ask whether it needs fresh information, whether it can be reversed, and who is affected by duplication. A fault description can remain a draft. Allocating the final replacement unit needs a central decision. A schedule-change request can be prepared offline, but the proposed appointment must not look confirmed before the server accepts it. Buttons sharing one screen can still require different rules.
- Local reading: previously downloaded visits, with a visible last-update time.
- Local drafts: technician notes and selected photographs not yet submitted.
- Pending submission: a finished report that the technician has requested to send.
- Server decisions: inventory reservations, discounts, and final work-order closure.
Include these distinctions in your mobile app MVP scope. Start with one dependable visit workflow rather than promising every section works offline. Specify the first-run experience too: an app with no downloaded records cannot display a visit it has never received.
Explain the status of each report
A connection icon does not tell a technician whether their work is safe. Give the report its own states: saved on this device, waiting to send, sending, received by the system, and review required. Use text alongside color. If the report arrives before its photographs finish uploading, explain that attachments are still pending instead of marking the complete package as received.
Show the last server confirmation when it helps a decision, and let users retry without rewriting the report. If local saving fails, say so immediately rather than showing a success tick. The technician may close the device based on that message. Check Arabic, English, and Turkish status wording carefully so a translated draft label does not imply successful submission.
Retries need a server-defined identity
Suppose the server receives a report but the connection drops before the phone receives the response. Pressing send again must not create another report. Agree a stable operation identity with the server team, including its scope, how long outcomes are retained, and what happens if the same identity arrives with different content. Generating a random identifier on the phone alone does not provide duplicate protection.
A retry of the same submission should reuse that identity. An intentional change follows the agreed revision or new-operation rules. Where possible, check the stored result after an uncertain outcome rather than assuming nothing happened. Distinguish connection failures from rejected permissions or invalid fields that require user intervention. Endless retries are not a recovery strategy.
Resolve conflicts according to the business
Imagine a supervisor changes a visit while the technician is offline. On reconnection, should the phone replace the newer record? Define the answer by data type. In this example, another observation can be appended as a separate note, but reopening a closed work order requires an allowed status transition. A proposed address correction might need a supervisor to compare both versions.
Do not treat last-write-wins as a universal rule, especially when request arrival order differs from the actual work sequence. Preserve the record version on which an edit was based, and surface a conflict without silently discarding either contribution. Name the person responsible for resolving it. A wording disagreement and an inventory allocation conflict should not automatically receive the same treatment.
Protect data on shared devices
If technicians share a company tablet, the next user must not inherit the previous customer's photographs or drafts. Define logout behavior, including a warning about unsent work and a safe next step under the organization's policy. Keep previous-account drafts inaccessible to the next account; never submit them using a new user's authority. Decide how long addresses and photographs remain locally available and what appears in notifications.
The web.dev storage guide describes storage limits and conditions under which browsers may remove stored data. Browser storage is therefore not a guaranteed backup. Native apps also need a separate recovery plan for device loss or deletion: a local save does not establish that a recoverable copy exists elsewhere.
Test a difficult working day
- Open a downloaded visit offline, then try one never downloaded.
- Disconnect after server receipt but before the phone receives confirmation.
- Close the app during a photograph upload and resume without duplication.
- Edit one record on two devices and verify the agreed conflict outcome.
- Simulate full storage, denied photo access, and logout with pending drafts.
- Revoke a user's server permission and confirm queued work is not automatically accepted.
Add expected outcomes and decision owners to your app release checklist. During a small field pilot, examine stuck reports, duplicate attempts, and reasons for support requests. Expand the offline scope only after the initial workflow behaves predictably. When discussing application development, bring real task examples and an explicit definition of saved versus approved work.
Editorial note: This guide was prepared with AI assistance and reference to the linked official documentation. The maintenance scenario is hypothetical, not a client result or a guarantee against data loss.