Stop refreshing a journey after the rider leaves it
Opening several saved journeys starts several permanent refresh loops. The app continues polling all of them in the background and occasionally displays the wrong result.
- Focused work estimate
- 1h 45m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Mobile lifecycle · Resource management · Async state
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 Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection.
Setup prerequisites
- Synthetic timetable with explicit time zones and service dates
- Departure, alert, and permission adapters with failure fixtures
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
Acceptance criteria
- Only the visible journey owns an active foreground refresh loop.
- Backgrounding pauses polling and foreground return performs one bounded freshness check.
- Late results from a departed journey cannot update the active journey.
Implementation constraints
- Use lifecycle-aware cancellation plus request identity; do not request a background location service for refresh.
Verification to include
- Switch among three journeys and inspect that only one loop remains active.
- Background during an in-flight request and return after expiry; exactly one fresh check occurs and stale results are ignored.
Deliverables
- Lifecycle-aware refresh coordinator and request-count tests
Rollout and recovery
Pilot with a short foreground session trace; disable automatic refresh if loop ownership regresses and keep manual refresh.
Value of the work
For the engineer: Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design.
For the team: Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data.
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.