Calm Current
Inspiration
Calm Current presents paced breathing as a quiet, readable TV experience: a protocol name, current phase, countdown, and progress are visible without requiring a phone. The design favors predictable remote controls and a reduced-motion option over decorative complexity.
What it does
Users choose one of three four-phase protocols: Box breathing (4/4/4/4), Calm breathing (4/2/6/4), or Coast breathing (5/0/7/4), then set a session from 1–30 minutes. The phase labels are Inhale, Hold, Exhale, and Rest. Start resumes a paused session; Restart begins the selected duration from zero; a completed session remains visibly Complete until another start or restart. Pause, protocol navigation, minute adjustment, Reduce motion, and Clear local data are explicit controls. Completed sessions are recorded in local history. The app is wellness support only, not medical advice; users are told to stop if dizzy or uncomfortable and breathe normally.
How we built it
This is a native Android WebView host around an offline HTML/CSS/JavaScript interface. The Java host serves packaged assets and blocks external resources. The domain module owns minute clamping, cycle duration, phase calculation, progress, and history entries; the UI owns timer state, protocol labels, and reduced-motion presentation. High contrast, large text, visible focus rings, and explicit buttons support DPAD/keyboard navigation. No network calls, analytics, external fonts, or runtime frameworks are used.
What we learned
Breathing guidance needs one consistent phase model so timing, labels, and the progress indicator agree. The completed state should remain explicit rather than silently resetting. A reduced-motion setting must change both animation behavior and its label so the user can tell what is active.
Challenges
Lifecycle and Back behavior are safety-relevant to the experience: Escape/Back, the app’s tvpause event, and document hiding pause an active session. Local history is best-effort and remains in the WebView only. The included caption/media material is a desktop local preview, not evidence from a real TV, and the app makes no medical claims.
Verification and next steps
Node domain tests and desktop Chromium flows were executed for protocol cycles, phase selection, progress, minute limits, and session entries. Physical FireOS hardware was not tested. Next steps are real-device checks for D-pad focus, timer lifecycle, reduced motion, persistence, clear data, overscan, legibility, no-internet behavior, and an English FireOS demonstration. This entrant-review draft was AI-assisted and should be reviewed against the implementation before submission.
Log in or sign up for Devpost to join the conversation.