Watchapp skeleton: window stack, view switching, button handling #8
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
#10 HRM integration with sample-period lifecycle
robert/PedalPebble
#11 Ride state machine: idle / running / paused / stopped
robert/PedalPebble
#42 view_map polyline renderer
robert/PedalPebble
#45 Backlight policy for night riding
robert/PedalPebble
#60 Page carousel navigation with long-press jumps
robert/PedalPebble
Reference
robert/PedalPebble#8
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
Set up the app shell that the three views plug into.
Acceptance criteria
main.chandles app lifecycle and owns the AppMessage inboxapp_message_open(app_message_inbox_size_maximum(), app_message_outbox_size_maximum())heap_bytes_free()logged at each view transitionemery, and degrades to a usable layout onbasalt(144x168)Files
watchapp/src/c/main.cwatchapp/src/c/view_ride.cwatchapp/src/c/view_nav.cwatchapp/src/c/view_map.cNotes
Max-size AppMessage buffers cost roughly 16 KB of heap - measure before assuming it fits.
Update — 2026-08-31: view stack becomes a page carousel
The three-view stack is replaced by a flat page ring — data pages, navigation and map all as pages of
the same carousel. Button handling moved to its own issue; see
docs/DESIGN.mdsection 5.This issue keeps app lifecycle, the AppMessage inbox,
heap_bytes_free()logging at page transitions,and the
basaltdegradation check.Closed by PR #83 (merged): main.c app lifecycle, AppMessage inbox opened at max buffer size, and a minimal page_view.c placeholder (Select cycles the three #58 default pages, heap logged at each transition) so the heap-logging criterion has something to transition between — full carousel behaviour (Up/Down, skip-empty-page, long-press jumps) stays #60's job, not built here. Verified live in the emulator on all three targets (screenshots, real button presses), not just compiled.\n\nWorth flagging for whoever picks up #59/#60/#62 next: measured AppMessage-open heap cost is a flat 16500 bytes on every platform (8200 inbox + 8200 outbox + ~100 bookkeeping) since inbox/outbox size maximum() is platform-independent here. On
basaltthat leaves 44952 bytes free out of 61452 before opening (a ~27% cut, not the ~73% the PR description misstated) — still the tightest of the three targets by a wide margin, and every future feature (map polylines, sensor buffers, more AppMessage decoding) draws from that same shrunken basalt pool. Not blocking this issue, but a real number worth checking against DESIGN.md/REQUIREMENTS.md's basalt heap assumptions before #59/#62's round/template work leans on it.