25 lines
1.3 KiB
Markdown
25 lines
1.3 KiB
Markdown
 
|
# ADR 0006 — The Streak is derived; Reminders are rescheduled, not repeating
|
||
|
|
|
||
|
|
Status: Accepted (2026-10-29)
|
||
|
|
|
||
|
|
## Streak
|
||
|
|
|
||
|
|
The Streak, its Freezes and the calendar are computed from scratch from the end times of all complete
|
||
|
|
Sessions (both Modes) every time they are shown (`Streak.compute`). Nothing about the Streak is stored:
|
||
|
|
a Freeze is earned, held and spent deterministically by walking the days from the first Streak Day to
|
||
|
|
today. The Grace Hour is applied while assigning Sessions to Streak Days, in time order, so the rule
|
||
|
|
"counts for yesterday unless yesterday is already done" is stable.
|
||
|
|
|
||
|
|
A few years of daily Sessions is a few thousand rows, which is cheap to walk.
|
||
|
|
|
||
|
|
## Reminders
|
||
|
|
|
||
|
|
Android cannot skip a repeating notification on days that are already done, so instead of repeating
|
||
|
|
alarms the app schedules one-off notifications for the next 14 days and replaces them whenever
|
||
|
|
something changes: on app start, after every saved Session and after a Reminder setting changes. A day
|
||
|
|
that is done gets none. If the app is not opened for two weeks, Reminders stop; that is acceptable for
|
||
|
|
a gentle nudge.
|
||
|
|
|
||
|
|
They use inexact scheduling (`inexactAllowWhileIdle`), which needs no exact-alarm permission but lets
|
||
|
|
Android deliver up to about an hour late. Permission to post notifications is asked for after the
|
||
|
|
first complete Session, or from Settings.
|