The useful starting point
Represent location freshness explicitly. A last-known position, a driver’s availability and the state of a ride are related pieces of information, with different meanings.
A last-known position is not a promise
A useful tracking interface needs to distinguish a recent update from an old one. Otherwise a marker can look authoritative even when the application has stopped receiving information.
Agree what the user should see during a gap and when the system should stop presenting a location as current. The right timing depends on the service and the available data; a smooth animation cannot substitute for that decision.
Use a freshness model people can understand
Illustrative example · sample display thresholds for explaining a design, not a promised tracking rate
For this exercise, call a position fresh at up to ten seconds old, delayed above ten and up to thirty seconds, and stale above thirty seconds. A real service must choose its own meanings and tests; the example simply makes the state changes visible.
| Observation | Age of the last known position | Sample display state | Ride and availability |
|---|---|---|---|
| A new position is received | 0 seconds | Fresh | Remain separate product states |
| No further update arrives | 15 seconds | Delayed | Do not infer a cancellation from the gap |
| The gap continues | 45 seconds | Stale / last known position | Follow the agreed operational handling |
| An older queued update arrives | Depends on when the location was observed | Inspect freshness instead of assuming “newly received” means current | Do not infer availability from the marker |
| A current update resumes | Evaluate the observation time | Recover according to the model | Reconcile with the current journey state |
A server receipt time tells you when information reached the server. It is not always the time the location was observed. Device timestamps can also have problems, so the freshness model needs an explicit account of the time information it trusts.
Keep three streams distinct
- 1Location and its freshness
- 2Driver availability
- 3Current ride state
- 4A coherent passenger and operations view
The diagram is a conceptual grouping, not a sequence of automatic state changes. A location update should not silently make a driver available, and a connection gap should not by itself complete or cancel a ride.
This is what separates the location engineering discussion from the broader ride-hailing product plan. One examines how a data stream behaves; the other defines the complete service across participants.
Test recovery on the devices that matter
Exercise the phone in the foreground and background, a permission change, a connection gap and a sequence containing delayed updates. Observe the displayed state as well as the received data.
After recovery, check that a person understands where the product is in the journey. A map that resumes movement while another screen shows an outdated ride state can still leave the experience inconsistent. Use the agreed acceptance scenarios to judge the whole result.
Keep availability separate from location
A driver can have a recent position without being available for a new request. A driver can also be part of an active trip while a connection is temporarily unavailable. Treating a location update as the sole definition of availability confuses different parts of the journey.
Define the information each service is responsible for, then decide how passenger, driver and operational views use it. This makes it easier to explain what should happen when one stream of information becomes uncertain.
Account for a mobile phone behaving like a mobile phone
Applications move into the background, devices lose connectivity and location permissions can change. These conditions need to be part of the test plan, not exceptions hidden behind a successful demonstration.
Android’s background-location guidance (opens in a new tab) describes permission considerations and limits affecting background updates. Platform behaviour should inform the product design and the tests on intended devices.
Test recovery as well as the gap
When updates resume, the product needs to return to a coherent view of the journey. Consider what happens to information received late and whether the next update is actually more recent than the one already displayed.
- Can a user tell how recent the displayed location is?
- What happens when updates stop during a ride?
- Does availability have its own clear meaning?
- Have background and permission changes been exercised?
- Does recovery leave each participant with an understandable state?
The mobile work behind the map
Our driver-application work includes background geolocation, battery-optimisation checks and keep-awake handling, as well as live location tracking in the wider platform. These are engineering concerns behind the visible passenger and driver experience.
They are why a useful review goes beyond watching a marker on a well-connected phone. It needs to consider device behaviour and what the product communicates when information becomes old or starts arriving again. The ride-hailing case describes the scope; the illustrative thresholds above are not a published performance claim for that system.
Common questions
Should driver availability come from the last location timestamp?
Availability and location freshness describe different things. Define each explicitly and decide how the product uses them together, including during gaps in updates.
Are ten and thirty seconds recommended production settings?
No. They are illustrative thresholds for the worked example. Suitable handling depends on the service, devices, platform behaviour, available data and the user task.