Alex DamianiContact
All selected work
03 / 03Android · Reliability · Local-first product

Android Recurring Reminders

A reminder app looks simple until time zones, month ends, process death, permissions, simultaneous schedules, backup recovery, and lock-screen privacy all become part of correctness.

RoleProduct owner and developer
StatusPersonal application
SourcePrivate source
Kotlin · Jetpack Compose · Room · AlarmManager · Hilt · Flow · Glance · Macrobenchmark

The challenge

Complexity lives in the failure paths

The product needed to remain useful without accounts or an application server, preserve user data across routine failure modes, and be honest about the limits Android places on exact delivery.

System design

Boundaries before components

Architecture map
01
Compose interfaceViewModels + FlowRoom database
02
Room schedulesAlarm reconciliationAndroid AlarmManager
03
Alarm receiverNotification actionsCompletion + reschedule
04
Versioned exportSystem document pickerOptional Drive backup
Conceptual flow. Detail is intentionally scoped to public system boundaries.

Product surface

Real interface, real operating states

Recurring Reminders home screen showing reminder cards and navigation
Home view with reminder state and quick actions.
Agenda screen grouping upcoming reminders by date
Date-focused agenda for upcoming occurrences.
Calendar screen showing scheduled reminders
Calendar view with remembered layout preferences.
Settings screen for reminder delivery and backup controls
Delivery health, permissions, backup, and display controls.

Key decisions

Tradeoffs made explicit

01

Local-first by default

Reminder content and schedules live in Room. The app has no account, analytics service, telemetry pipeline, or network-backed application database.

02

Reconcile instead of assuming

Boot, permission, edit, and restore paths rebuild or verify scheduled alarms. Delivery health tools expose problems rather than silently masking them.

03

Treat recurrence as domain logic

Weekday rules, interval schedules, month-end clamping, daylight-saving transitions, simultaneous occurrences, and completion tokens are tested as explicit behavior.

Evidence & validation

What can be inspected

  • The app supports one-time and repeating schedules, multiple schedules per reminder, agenda and calendar views, tags, checklists, templates, attachments, and a home-screen widget.
  • CI runs lint, JVM tests, debug and instrumentation builds, the performance module, and a minified release bundle.
  • A managed-device matrix covers phone, tablet, and foldable profiles; UI tests include accessibility labels and 200% font scale.

Outcomes

  • Produces a complete daily-use product while keeping user data under explicit device-level control.
  • Turns Android delivery constraints into visible health checks, recovery actions, and documented limitations.

Honest limits

  • Source is private; this page presents product behavior and architecture rather than inviting a code audit.
  • Exact delivery remains best effort when Android revokes access, the app is force-stopped, or the device is powered off.

Continue exploring

Back to the full body of work

View all projects