Skip to content

refactor(reminders): split up AlarmManagerService#21271

Open
ericli3690 wants to merge 2 commits into
ankidroid:mainfrom
ericli3690:ericli3690-alarm-management
Open

refactor(reminders): split up AlarmManagerService#21271
ericli3690 wants to merge 2 commits into
ankidroid:mainfrom
ericli3690:ericli3690-alarm-management

Conversation

@ericli3690

@ericli3690 ericli3690 commented Jun 15, 2026

Copy link
Copy Markdown
Member

Note

Assisted-by: Claude Sonnet 4.6 (class splitting and unit test splitting grunt work)

Purpose / Description

AlarmManagerService has acquired three responsibilities:

  • It is a BroadcastReceiver because it listens to snooze intents
  • It has the core functionality for scheduling review reminder notifications
  • It is supposed to be the centralized point for handling AlarmManager in AnkiDroid

This is too much responsibility for one file. This PR breaks it up into SnoozeService, ReviewReminderAlarmManager, and AlarmManagement respectively for the three responsibilities above.

Additionally, I found a lot of inconsistent logic scattered throughout the codebase for dealing with AlarmManager. I've centralized it all in AlarmManagement.

In the past, I found that AlarmManagerService, and specifically its logic relating to snoozing, were the hardest parts of the review reminders code to understand. I hope to improve on this through this PR and an incoming documentation PR.

Fixes

Approach

Simple split up.

How Has This Been Tested?

  • normal notifications: work
  • normally snoozing a reminder: the snoozed notification should appear
  • snoozing a reminder and then deleting it: the snoozed notification should not appear
  • opening app during window when notification should fire: notification should immediately fire
  • opening app again after notification has fired: notification should not immediately fire again
  • unit tests
  • tested on a physical Samsung S23, API 36

Learning

  • In my opinion, "...Service" as a name should be reserved for BroadcastReceivers. Hence, the naming of "ReviewReminderAlarmManager".
  • I considered naming the centralized point for handling AlarmManager "AlarmManagerManager"... but that felt a bit too silly, hence "AlarmManagement".

Checklist

  • You have a descriptive commit message with a short title (first line, max 50 chars).
  • You have commented your code, particularly in hard-to-understand areas
  • You have performed a self-review of your own code

@ericli3690 ericli3690 self-assigned this Jun 15, 2026
@ericli3690 ericli3690 added the Blocked by dependency Currently blocked by some other dependent / related change label Jun 15, 2026
@ericli3690 ericli3690 force-pushed the ericli3690-alarm-management branch from bcf19b4 to 0f9917a Compare July 5, 2026 06:08
@ericli3690 ericli3690 marked this pull request as ready for review July 5, 2026 06:43
For some reason, my past self thought it was a good idea to pass around ReviewReminders as a Parcelable extra within an intent. This violates the single-source-of-truth nature of the stored review reminders, as when a notification tries to fire, it passes in a ReviewReminder that might be stale and has been updated on disk since the intent was created. There's no bugs caused by this, as editing review reminders via the UI deletes all pending intents and recreates them, but it's still bad design. I've refactored both the notification path and the snooze path to only pass around review reminder IDs in intent extras and to refer to the database when actually retrieving review reminder details.
AlarmManagerService has acquired three responsibilities:

1. It is a BroadcastReceiver because it listens to snooze intents
2. It has the core functionality for scheduling review reminder notifications
3. It is supposed to be the centralized point for handling AlarmManager in AnkiDroid

This is too much responsibility for one file. This commit breaks it up into SnoozeService, ReviewReminderAlarmManager, and AlarmManagement respectively for the three responsibilities above.

Additionally, I found a lot of inconsistent logic scattered throughout the codebase for dealing with AlarmManager. I've centralized it all in AlarmManagement.

In the past, I found that AlarmManagerService, and specifically its logic relating to snoozing, were the hardest parts of the review reminders code to understand. I hope to improve on this through this change and an incoming documentation PR.

Assisted-by: Claude Sonnet 4.6 (class splitting and unit test splitting grunt work)
@ericli3690 ericli3690 force-pushed the ericli3690-alarm-management branch from 0f9917a to db8a17b Compare July 5, 2026 07:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Blocked by dependency Currently blocked by some other dependent / related change Needs Review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant