Schedule reminders with WorkManager and no exact alarms #25

New Issue

Closed

opened 2026-08-18 15:06:56 -05:00 by null · 0 comments

null commented

2026-08-18 15:06:56 -05:00

Owner

§31: use WorkManager for persistent, inexact reminder work, and do not request exact-alarm permissions — a period reminder does not need alarm-clock precision, and asking for that permission is Play scrutiny bought for nothing.

What to build in a new core/notifications module:

a worker that wakes at the user's reminder time, reads the current forecast, and decides whether anything is due
scheduling that survives process death and reboot
rescheduling whenever the forecast changes. §31 lists it explicitly, and it is the requirement most likely to be missed: a "Not yet" moves the forecast, so a reminder scheduled against the old one is now wrong. The engine already re-conditions; the reminders have to follow.

The worker must not do the arithmetic itself. CycleStatusRules and the forecast already decide what state the user is in, and a second copy of that logic inside a worker is the classic way for a notification to contradict the screen it deep-links to.

Also from §31: request notification permission at an appropriate moment, not blindly on first launch. Onboarding deliberately does not ask; the right moment is when the user enables a reminder.

Verify: ./gradlew :core:notifications:test covers "is anything due today" for each cycle state; scheduling is inexact (no SCHEDULE_EXACT_ALARM in the merged manifest); and a forecast change cancels and re-enqueues the work.

§31: use WorkManager for persistent, inexact reminder work, and **do not request exact-alarm permissions** — a period reminder does not need alarm-clock precision, and asking for that permission is Play scrutiny bought for nothing. What to build in a new `core/notifications` module: - a worker that wakes at the user's reminder time, reads the current forecast, and decides whether anything is due - scheduling that survives process death and reboot - **rescheduling whenever the forecast changes.** §31 lists it explicitly, and it is the requirement most likely to be missed: a "Not yet" moves the forecast, so a reminder scheduled against the old one is now wrong. The engine already re-conditions; the reminders have to follow. The worker must not do the arithmetic itself. `CycleStatusRules` and the forecast already decide what state the user is in, and a second copy of that logic inside a worker is the classic way for a notification to contradict the screen it deep-links to. Also from §31: request notification permission at an appropriate moment, not blindly on first launch. Onboarding deliberately does not ask; the right moment is when the user enables a reminder. Verify: `./gradlew :core:notifications:test` covers "is anything due today" for each cycle state; scheduling is inexact (no `SCHEDULE_EXACT_ALARM` in the merged manifest); and a forecast change cancels and re-enqueues the work.