Tracker: map should open at your location; historical views center on the route's bounds (iOS + Android) #989

New Issue

2026-08-06T21:59:20Z

spikerj commented

2026-08-06 21:59:20 +00:00

Follow-up to #988. Opening the live tracker still shows the default Colorado camera until you press Record — but your location is where the activity is going to happen, so the map should open there.

Live tracker (both platforms): on open, center on the user's current location at a neighborhood zoom. Must NOT trigger a location-permission prompt (the prominent-disclosure flow stays tied to Record, per Play policy / existing iOS pre-prompt): if permission isn't granted yet, keep the default camera.
Historical activity views (route detail / analysis report): center on the route's bounding box once its points are loaded — already implemented on both platforms via fitToRoute (iOS detail + analysis views, Android RouteDetailScreen); verify it holds for the async server-loaded analysis view ("if it gets loaded").

Follow-up to #988. Opening the live tracker still shows the default Colorado camera until you press Record — but your location is where the activity is going to happen, so the map should open there. - **Live tracker (both platforms)**: on open, center on the user's current location at a neighborhood zoom. Must NOT trigger a location-permission prompt (the prominent-disclosure flow stays tied to Record, per Play policy / existing iOS pre-prompt): if permission isn't granted yet, keep the default camera. - **Historical activity views** (route detail / analysis report): center on the route's bounding box once its points are loaded — already implemented on both platforms via fitToRoute (iOS detail + analysis views, Android RouteDetailScreen); verify it holds for the async server-loaded analysis view ("if it gets loaded").

spikerj commented

2026-08-07 13:47:40 +00:00

Verified complete 2026-08-07 — closing. Not split: both platforms already shipped this, so there is nothing left to file in either mobile repo.

Code (live tracker opens at your location):
- iOS spikersoft-ios@c71650f (PR #8, commit 0872c6c) — TrackerMapView.swift:31 centerOnUserAtLaunch + the one-shot guard at :77 (guard centerOnUserAtLaunch, !hasCenteredOnUser, !wasFollowing, …), opted in only from TrackerView.swift:141. No permission prompt: unauthorized simply means no fix arrives and the default camera stays.
- Android spikersoft-android@366da31 (PR #6, commit 245fcae) — features/tracker/TrackerScreen.kt centers once on last-known/balanced-power location behind an explicit permission check; an in-progress recording's follow takes precedence.
Code (historical views centre on route bounds, incl. the async server-loaded analysis view — the bit the ticket asked to verify):
- iOS: RouteAnalysisView.swift:50 passes fitToRoute: true, and TrackerMapView.swift:135 re-fits whenever the point count changes (if state.fitToRoute, state.routePoints.count != lastFitCount) — so the fit happens when the async await load() finally delivers points, not only on first render. RouteDetailView.swift:17 likewise.
- Android: RouteDetailScreen.kt:102 fits on onMapReady, and :109-113 re-fits from a LaunchedEffect(r.id, r.points.size) with the comment "Redraw once loaded (map may already be ready)" — the same async-safe pattern.
Live: nothing runtime-observable from this box (native apps).

Not migrated: nothing left to do.

— Opus 5 Agent

Verified complete 2026-08-07 — closing. **Not split**: both platforms already shipped this, so there is nothing left to file in either mobile repo. - **Code (live tracker opens at your location):** - iOS `spikersoft-ios@c71650f` (PR #8, commit `0872c6c`) — `TrackerMapView.swift:31` `centerOnUserAtLaunch` + the one-shot guard at `:77` (`guard centerOnUserAtLaunch, !hasCenteredOnUser, !wasFollowing, …`), opted in only from `TrackerView.swift:141`. No permission prompt: unauthorized simply means no fix arrives and the default camera stays. - Android `spikersoft-android@366da31` (PR #6, commit `245fcae`) — `features/tracker/TrackerScreen.kt` centers once on last-known/balanced-power location behind an explicit permission check; an in-progress recording's follow takes precedence. - **Code (historical views centre on route bounds, incl. the async server-loaded analysis view — the bit the ticket asked to verify):** - iOS: `RouteAnalysisView.swift:50` passes `fitToRoute: true`, and `TrackerMapView.swift:135` re-fits whenever the point count changes (`if state.fitToRoute, state.routePoints.count != lastFitCount`) — so the fit happens when the async `await load()` finally delivers points, not only on first render. `RouteDetailView.swift:17` likewise. - Android: `RouteDetailScreen.kt:102` fits on `onMapReady`, **and** `:109-113` re-fits from a `LaunchedEffect(r.id, r.points.size)` with the comment "Redraw once loaded (map may already be ready)" — the same async-safe pattern. - **Live:** nothing runtime-observable from this box (native apps). Not migrated: nothing left to do. — Opus 5 Agent

spikerj closed this issue

2026-08-07 13:47:40 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: spikerj/spikersoft-issues#989