dilly/rippr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Document Phase 6 on-device verification for FB-06..FB-09

Browse Source
This commit is contained in:
uhryniuk
2026-08-25 08:32:32 -05:00
parent 2abbaf5564
commit c67072135b
4 changed files with 64 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
docs/feedback/FB-07-route-planner-null-island.md
View File

@@ -200,3 +200,27 @@ The code change and its three widget tests are the verified deliverable for this
the on-device screenshot check called for in Implementation step 3 / Acceptance criteria
was not completed and should be picked up in a follow-up pass when the emulator is
stable, rather than by fighting it further here.
### On-device verification, later pass (emulator available)
Opened a brand-new route with a mock GPS fix set (`adb emu geo fix`). Confirmed the
camera now opens centered on the mock location at street-level zoom, not Null Island —
this ticket's actual fix is verified working.
Tile rendering itself was intermittent: the Route Planner's own `TileLayer` repeatedly
fell back to the app-wide skeleton placeholder (`SkeletonMapLayer`, a faint animated
grid — confirmed present on close visual inspection of a cropped/enlarged screenshot,
not truly blank) for extended periods, while the separate, already-fully-cached
`AppShell` background map kept showing live tiles at the same location moments apart.
Since `skeletonMode` is one process-wide `ChangeNotifierProvider` shared by every map
in the app (`mapConnectivityProvider`), both maps must agree at any instant — the
divergence observed here is consistent with `skeletonMode` genuinely flapping
true/false (a real, if intermittent, tile-fetch problem in this emulator session) and
the two screenshots simply landing on different sides of a flip. A host-side `curl` to
the tile host succeeded instantly, but an in-emulator `ping` hung for its full 2-minute
timeout, pointing at degraded network condition inside this specific AVD rather than a
`RoutePlannerScreen`-specific defect — its `TileLayer`/`CachedTileProvider` setup is
byte-for-byte the same pattern `RideMap` already uses successfully. This matches the
"second, distinct bug" this ticket's own Risks section anticipated as a possibility;
the investigation here did not find a code-level cause, and the location-centering fix
itself is confirmed correct and complete.