Temporary PKJS watchPosition() speed feed #13
Labels
No labels
area:companion
area:docs
area:shared
area:tooling
area:watchapp
blocker
kind:chore
kind:feature
kind:spike
kind:test
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Blocks
Depends on
#21 Retire the PKJS feed behind a fallback flag
robert/PedalPebble
#7 shared/message_keys.json plus C and Kotlin codegen
robert/PedalPebble
Reference
robert/PedalPebble#13
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Give the watchapp real speed immediately, so it is genuinely useful before any Android work exists.
Acceptance criteria
navigator.geolocation.watchPosition()withenableHighAccuracy: true,maximumAge: 0Files
watchapp/src/pkjs/index.jsNotes
This is scaffolding, replaced by the companion app in Phase 2 and kept only behind a fallback flag.
Closed by PR #110 (merged). Plain-ES5 PKJS speed feed using watchPosition() with enableHighAccuracy/maximumAge:0/a real 15s timeout, both error and success paths handled (all three W3C PositionError codes send the SPEED_MMS sentinel rather than a stale/fake value). SPEED_MMS/AVG_SPEED_MMS/DISTANCE_M come from PROTOCOL.md section 2.2, hand-copied into package.json's messageKeys since tools/gen_message_keys.py (#7) has no JS output target yet -- flagged as a real, undetected second copy of those three integers, and extending the generator to a JS target is a reasonable follow-up. Deliberately does NOT port SpeedPipeline/StopDetector's real machinery (GPS-quality gating, wraparound, dwell/hysteresis) -- reuses only the 0.8 m/s stopped-speed number, not the class, since this file is scaffolding #21 will delete. Fallback flag: localStorage['pkjsSpeedFeedEnabled'], default enabled since Phase 1 has no other speed source yet.
Real end-to-end verification, a first for a PKJS feature in this repo: pebble build clean on all three platforms, then a live emery emulator run confirmed watchPosition() getting a genuine fix through pypkjs's actual IP-geolocation path, the resulting AppMessage arriving at the watch's C inbox handler, and the ack returning to PKJS -- via pebble logs, not just compiled. Honestly unverified: multi-fix accumulation (pypkjs's watchPosition() fires its success callback only once, an emulator limitation) and the error/timeout path (network never failed in this sandbox) -- both verified by reading the logic instead, stated as such rather than claimed.