[GH-ISSUE #9] Implement tracking selection using the official time OR distance rule #8

New Issue

2026-10-23T18:09:15+02:00

jayanezj commented

2026-10-23 18:09:15 +02:00

Originally created by @jayanezj on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/jayanezj/traccar-client-macos/issues/9

Goal

Select and persist continuous-tracking positions using the agreed official defaults and OR semantics.

Scope

Default to 300 seconds, 75 metres and medium requested accuracy; keep angle and heartbeat disabled.
Accept the first available location, then select when elapsed capture time OR displacement from the last accepted position reaches its configured threshold. The last accepted point may still be queued.
Keep original timestamps and accuracy. Do not add the withdrawn 120-second freshness or 1,000-metre maximum-accuracy filters or fabricate fresh timestamps for cached fixes.
Persist a selected tracking position before scheduling upload. Editing interval, distance and requested accuracy must update the service predictably.
Treat automatic stationary optimization as a separate capability; this issue must not infer it from lack of incoming updates.

Acceptance criteria

Time-only, distance-only and both-trigger cases select positions; neither-trigger cases do not.
The first position is selected without requiring prior movement.
Network loss does not change the selection anchor or cause selection relative only to the last successful upload.
Pause stops automatic selection/acquisition; manual operations remain separate.
No periodic fresh location is claimed merely because 300 seconds elapsed; actual timestamps and availability govern input.

Validation

Test with a deterministic location stream and clock, including repeat fixes and relaunch state. Verify actual Mac acquisition separately; synthetic filter tests do not prove energy efficiency or precision.

Add or extend this feature's meaningful deterministic tests in the CI workflow from PROTO-002 as part of the same implementation, without waiting for the final milestone. Keep physical-Mac checks explicitly manual.

References

Pinned official source references for implementation comparison; mobile APIs are not assumed available on macOS.

Dependencies

Originally created by @jayanezj on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/jayanezj/traccar-client-macos/issues/9 ## Goal Select and persist continuous-tracking positions using the agreed official defaults and OR semantics. ## Scope - Default to 300 seconds, 75 metres and medium requested accuracy; keep angle and heartbeat disabled. - Accept the first available location, then select when elapsed capture time **OR** displacement from the last accepted position reaches its configured threshold. The last accepted point may still be queued. - Keep original timestamps and accuracy. Do not add the withdrawn 120-second freshness or 1,000-metre maximum-accuracy filters or fabricate fresh timestamps for cached fixes. - Persist a selected tracking position before scheduling upload. Editing interval, distance and requested accuracy must update the service predictably. - Treat automatic stationary optimization as a separate capability; this issue must not infer it from lack of incoming updates. ## Acceptance criteria - [ ] Time-only, distance-only and both-trigger cases select positions; neither-trigger cases do not. - [ ] The first position is selected without requiring prior movement. - [ ] Network loss does not change the selection anchor or cause selection relative only to the last successful upload. - [ ] Pause stops automatic selection/acquisition; manual operations remain separate. - [ ] No periodic fresh location is claimed merely because 300 seconds elapsed; actual timestamps and availability govern input. ## Validation Test with a deterministic location stream and clock, including repeat fixes and relaunch state. Verify actual Mac acquisition separately; synthetic filter tests do not prove energy efficiency or precision. Add or extend this feature's meaningful deterministic tests in the CI workflow from [PROTO-002](https://github.com/jayanezj/traccar-client-macos/issues/2) as part of the same implementation, without waiting for the final milestone. Keep physical-Mac checks explicitly manual. ## References Pinned official source references for implementation comparison; mobile APIs are not assumed available on macOS. - [Official source 1](https://github.com/traccar/traccar-client/blob/c189d52f0bf464d18bebaff48b0fac15fc8cd1e2/lib/preferences.dart) - [Official source 2](https://github.com/traccar/traccar-client-sdk/blob/a297767642e98193eb7939cbb4d54c101ff23610/core/src/commonMain/kotlin/org/traccar/client/Config.kt) - [Official source 3](https://github.com/traccar/traccar-client-sdk/blob/a297767642e98193eb7939cbb4d54c101ff23610/core/src/commonMain/kotlin/org/traccar/client/LocationFilter.kt) ## Dependencies - [PROTO-004](https://github.com/jayanezj/traccar-client-macos/issues/4) - [PROTO-008](https://github.com/jayanezj/traccar-client-macos/issues/8)

jayanezj added this to the M4 - Reliable tracking and persistence milestone 2026-10-23 18:09:15 +02:00

jayanezj added the area:tracking type:feature priority:high labels 2026-10-23 18:09:15 +02:00

jayanezj added type:feature and removed type:feature labels 2026-10-30 18:01:09 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jayanezj/traccar-client-macos#8