An employee records a visit, takes two photos and returns to the office to discover that “saved” meant saved only on the phone. That small wording difference can become a substantial acceptance dispute for a field application. Offline operation therefore needs a more precise description than a tick beside a feature in a proposal.
Start with what employees must accomplish during an interruption and what may wait for connectivity. Opening downloaded information, creating a record, editing a shared record and uploading a photo are four different operations. A proposal may include some and exclude others without making that distinction obvious in its title.
Describe the working day in three moments
Consider a fictional representative checking product displays at customer sites. The representative downloads a visit list in the morning, records notes and photographs where reception is weak, then sends the results when connectivity improves. The example excludes cash collection and real-time inventory approval; either would need additional rules if required.
Divide the day into before, during and after disconnection. What must be downloaded beforehand? Can the representative add an unplanned visit? When may a supervisor consider it received? These questions let an app developer estimate work against defined data rather than assuming a continuous connection.
A requirements card for each operation
- Available locally: visible fields and lists, the age of the latest update and limits on data stored on the device.
- Allowed changes: creation, amendment or deletion, and actions requiring a connection before permission is given.
- Status indication: saved on device, awaiting transmission, received by server or requiring intervention, with each state defined.
- Conflict rule: who reviews different edits to the same record and what must never disappear silently.
- Attachments: their number, size and status separate from text, and what happens when upload remains incomplete.
- Session boundaries: treatment of pending work on logout, account switching or permission expiry.
This is a proposal preparation card, not a promise that every operation should work without a network. Preventing final approval while disconnected may be appropriate, while allowing a draft for later review. Employees should understand that boundary before using the application in the field.
Conflicting edits need a business decision
In the example, a supervisor changes visit instructions while the representative adds a note to an older copy. Should both the instructions and note survive? Is review required? Should particular fields become uneditable after download? Ask the developer to demonstrate the case with test data instead of simply promising that the latest version will appear.
Android's guide explains reads, writes and synchronization in applications designed for interrupted connectivity. Firestore documentation describes a last-write-wins policy for multiple changes to the same document. That is a product behavior, not an automatically suitable business rule for every app. Assess it against information you do not want another edit to overwrite.
Separate photo arrival from visit arrival
Text may arrive while a photo remains pending. Agree whether supervisors see a complete visit or one missing attachments, and how the representative identifies a file requiring another upload. Discuss data consumption, device storage and replacing a photograph before upload finishes, using the actual intended device types.
A connection indicator alone should not establish success: the network may return while a particular service fails. Request a screen showing the meaningful outcome of the operation, with the note remaining traceable after the application closes and reopens. Local retention and data protection require design decisions, particularly on shared devices.
Six tests before accepting offline operation
- Download a test list and disconnect; check what opens and what is shown as unavailable.
- Create a visit with a note and two photos, close the application and reopen it before connectivity returns.
- Restore the network briefly, then disconnect again; observe text and photo states without a misleading completion message.
- Edit the same record from another account and verify the agreed conflict policy.
- Test session expiry or account switching with pending work under an approved policy preserving access boundaries.
- Compare the supervisor's view with the device and record any exception and its resolution path.
Run the tests on the devices and operating systems named in the proposal. One device does not establish that all phones behave identically. Assign responsibility for monitoring pending records after launch. Synchronization without a way to understand stalled work leaves an operational burden on employees.
For broader requirements, consult the mobile proposal component map. The construction daily report application guide covers a specialist form lifecycle. When requesting a field application from Nextwave, attach the card and interruption tests so their impact appears in scope, duration and cost.
Synchronization references
The Android offline-first guide and Firestore offline data documentation were opened on 3 November 2026. They support general technical distinctions and the stated product policy, not a technology stack recommendation or a guarantee to preserve every data type.