The between-set break never finished once the phone's screen was off. Three independent causes (worked through on-device on 2026-09-12; left uncommitted awaiting the go-ahead, committed here as-is plus one pin bump): 1. The countdown was not wall-clock: `_breakRemaining--` on a Timer.periodic, which Android throttles and Doze suspends in a backgrounded isolate, so the counter stalled and _onBreakFinished() never fired. Now a BreakClock deadline on the wall clock. 2. An expired break was silently dropped on restore (`if (remaining > 0)` only) — now cued and logged. 3. No notification infrastructure at all: no package, no POST_NOTIFICATIONS / FOREGROUND_SERVICE / WAKE_LOCK. Now: flutter_foreground_task runs the countdown in a service isolate that survives BACK and the screen lock; flutter_local_notifications shows an ongoing "Workout A · break m:ss / Next: …" notification with −1 rep / Done actions and a "Break over" alert on its own channel (raw break_end sound, vibration). Button presses go through a persisted BreakIntent queue the screen drains on resume, so a press with the app killed is not lost. Finish and Reset stop the service; a startup reaper handles the crash case. Verified on the phone with the screen off and locked: service alive and ticking while Dozing, both notifications on the lock screen, channel importance 5 with the break_end sound. Not verifiable from adb (receiver is RECEIVER_NOT_EXPORTED): an actual action-button tap, and a true recents swipe — see stronglift_replacement/TODO-workout-app-v2.md. Also fixed en route: the break-end sound had never played in any widget test (AssetSource needs path_provider, which nothing faked, and the failure was swallowed by catchError); the queue's prune wrote back a stale list. This commit additionally: - takes the freshness gate's bump flutter_local_notifications 22.3.1; - restores web/package.json to HEAD (the tree held a stale pre-bump copy); - gives scripts/check_flutter_coverage.sh a FLUTTER_TEST_CONCURRENCY knob: the default one-isolate-per-core run peaks over 4 GiB and is OOM-killed under the resource cap. Default behaviour unchanged. Gate: flutter analyze clean, 511 tests, 3187/3187 lines (100%), pre-commit green. Not re-installed on the phone for the 22.3.1 pin: no device attached at commit time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01C7vgacLhb4WJjxuVj2QLEP
4.0 KiB
This is a continouation from design.md file with what is left to be done and what new ideas came to me since the last time arranged in order of importance
Crucial (max 1 feature): If user starts workout and later either exit the app completely or clicks the arrow in upper left the workout gets reset completely, all progress is lost this is very bad once user starts workout only by tapping finish and confirming that they INDEED finished workout should end it OR if user clicks and confirms RESET button, NOTHING ELSE DONE (verified 2026-08-09): StorageService.saveActiveSession persists after every tap and resumes on the same set/rep; the back arrow is gone (automaticallyImplyLeading: false) and Finish/Reset both confirm. Mirrored to /sdcard so even an uninstall resumes.
High (max 2 features): adds breaks between REPS (3 minutes if REP succeeded (as in all reps were done) and 5 minutes if it failed) <-- currently app ads breaks between SETS which wrong STILL OPEN (2026-08-09): breaks are still per-SET, and suppressed on the last set of an exercise. Needs a decision — "break between reps" would mean pausing mid-set, which is unusual; confirm intent before building. After break time (after REPS) is over app should play a sound and vibrate the phone and generally point the user attention towards the app DONE (verified 2026-09-12, on-device, screen off and locked): break end plays assets/sounds/break_end.mp3 and vibrates 800ms, AND the OS rings the break_end_v1 channel from res/raw. The old "only while foregrounded" caveat is gone: a flutter_foreground_task service holds a wake lock and owns the deadline, and the countdown is now derived from a stored end time instead of a tick counter that stalled whenever Android throttled the isolate.
Mid (max 3 features): change warmup exercises weight from 2/3 to 3/4 of target weight DONE, but shipped as 4/5 rather than 3/4 — 4/5 confirmed intended (2026-08-09). Warmups should be a selectable circles in a separate screen, optional but still interactive and after doing them give the user a 3 minute break ALSO The app should change between workout A and B AUTOMATICALLY, no user interaction if last workout done was "A" the next one should be "B" and then "A" and so on...
Low (max 4 features): If set is finished user cannot modify reps on this set for some reason -> this is a bug user should ALWAYS be able to modify ANY reps in ANY exercise shows history of workouts and a graph for showing progress The app should be capable of working in the background without any problem and display status notifications allowing user to click on "done rep" from the status bar DONE (2026-09-12): a foreground service runs for the whole workout and shows an ongoing notification — "Workout A · break 1:47" / "Next: Dumbbell Lunge — set 2/5 / 12 reps @ 10 kg" — with three action buttons: ✓ Done (records the set at full target reps), − 1 rep (decrements the set recorded last, which also stretches a 3-min rest to 5), Skip break. Presses go into a durable SharedPreferences queue and are applied through the same _tapCircle/_skipBreak the on-screen buttons use, so a press made while the app is dead still lands on the next launch. Verified on-device with the screen off and locked; the button PRESSES themselves still want a human tap to confirm end-to-end (the plugin's receiver is NOT_EXPORTED, so adb cannot fire them). automatically decreases weight if user had a break from using the app <-- not sure if implemented (maybe implemented but did not have a change to check it add fallback manual setting of weights by user)
Technical Requirements: App should work on rooted and unrooted phones with minimum android version of at least 12 Full test coverage (100%) (but first check the functionality and if the functionality fully works and is approved by user THEN start writing ANY tests at all please) I connected an unrooted phone with adb on to the pc use it for testing
REMOVE ME AFTER FINISH