Tell technicians which work orders are available offline
The assignment list looks ready in the depot, but opening a work order downstairs produces an endless spinner. Distinguish listed work from fully downloaded details.
- Focused work estimate
- 1h 15m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Offline UX · Mobile state · Error handling
Estimated field mix
- Mobile100%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
The fictional Vale facilities team services equipment in basements with poor reception. Technicians receive assigned work orders, record checks, and attach synthetic equipment photos. The practice app uses an on-device database and a stub sync service; background location tracking is excluded.
Setup prerequisites
- Synthetic work orders and a revisioned sync contract
- An emulator with controllable connectivity and app lifecycle
Preceding work
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Each order states whether required details are cached, downloading, or unavailable offline.
- Opening an uncached order offline shows a recoverable explanation.
- The app shows the last successful download time without presenting cached data as current.
Implementation constraints
- Use a connectivity adapter for fixtures; an online signal does not guarantee the API is reachable.
Verification to include
- Download an order, disable connectivity, and open its cached details.
- Open a listed but uncached order offline and simulate a reachable network with a failed API; neither path spins indefinitely.
Deliverables
- Offline-availability presentation and connectivity fixture cases
Rollout and recovery
Pilot with a small depot dataset; retain read-only cached access if download status regresses.
Value of the work
For the engineer: Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows.
For the team: Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.