-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
feat(reminders): request notification permissions #19167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
7965ebb
d2b572a
7e66987
07702c3
b76a246
9530089
fa06e76
cadc706
9732ace
21a3a3e
43507ec
0b541e0
5cba550
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -266,6 +266,15 @@ open class PrefsRepository( | |
|
|
||
| //endregion | ||
|
|
||
| /** | ||
| * Whether the sync process has requested notification permissions before. | ||
| * We only want to request notification permissions for the sync feature if the dialog has never been shown | ||
| * for this reason before. | ||
| * | ||
| * @see reminderNotifsRequestShown | ||
| */ | ||
| var syncNotifsRequestShown by booleanPref(R.string.sync_notifs_request_shown_key, defaultValue = false) | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Given -
Then -
Uncertainty -
Action -
Or alternatively we can just note this possibility in the code, and ignore it. The failure case is after an app restore on to a new device, we will not request optional permissions. As long as there is a nice header on reminder edit dialog (as I mentioned separately) warning the user that notifications can't be shown, users should clue in
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good point. I like your proposed solution of noting and ignoring this though, as I've now implemented the little notification box in ScheduleReminders if notifications are disabled, irrespective of whatever Prefs are set. I've added some docs to Prefs to document this decision! For curiosity's sake, I checked whether Google app data backup applies to AnkiDroid, and I think it does? Looking through the manifest and https://developer.android.com/identity/data/autobackup, it seems that it's enabled for everything in AnkiDroid's storage directory, though it turns off after collecting 25MB, which some collections may exceed in size, so whether what it collects is actually useful is a different story entirely. |
||
|
|
||
| // ************************************** Review Reminders ********************************** // | ||
|
|
||
| /** | ||
|
|
@@ -278,6 +287,48 @@ open class PrefsRepository( | |
| */ | ||
| var reviewReminderNextFreeId by intPref(R.string.review_reminders_next_free_id, defaultValue = 0) | ||
|
|
||
| /** | ||
| * Whether the review reminder feature has requested notification permissions before. | ||
| * We only want to request notification permissions for the review reminder feature if the dialog has never been | ||
| * shown for this reason before. | ||
| * | ||
| * @see syncNotifsRequestShown | ||
| */ | ||
| var reminderNotifsRequestShown by booleanPref(R.string.reminder_notifs_request_shown_key, defaultValue = false) | ||
|
|
||
| // *************************************** Permissions ************************************** // | ||
|
|
||
| // Flags for whether the system UI dialog for requesting certain permissions has been shown before. | ||
| // If the user has viewed the dialog at least once, we should check if they pressed "don't ask again" | ||
| // or pressed "deny" repeatedly (via [androidx.core.app.ActivityCompat.shouldShowRequestPermissionRationale]). | ||
| // This is because trying to show the system dialog again after the user has indicated they don't want to see it | ||
| // is likely tracked by Play Console statistics and may lead to lower Play Store discoverability. | ||
| // | ||
| // @see com.ichi2.anki.ui.windows.permissions.PermissionsFragment.requestPermissionThroughDialogOrSettings | ||
| // @see com.ichi2.utils.Permissions.isUserOpenToPermission | ||
|
|
||
| /** | ||
| * Whether the system UI dialog for requesting notification permissions has been shown before. | ||
| * | ||
| * Flags like [reminderNotifsRequestShown] etc. are not enough because those flags check if | ||
| * the BottomSheet dialog explaining the need for notification permissions has been shown before, | ||
| * whereas this flag checks if the system dialog has been shown before. | ||
| * | ||
| * If the user restores their data from a backup or migrates to a new device, this flag may be true | ||
| * when in reality notification permissions have not been requested for the device. This is most prominently | ||
| * an issue for the review reminders feature, so to ensure the user is able to receive review reminder notifications after | ||
| * a data restore / migration, a Snackbar noting that notification permissions are missing will be shown | ||
| * on the [com.ichi2.anki.reviewreminders.ScheduleReminders] fragment if notification permissions are not granted. | ||
| * | ||
| * @see com.ichi2.anki.reviewreminders.ScheduleReminders.checkForNotificationPermissions | ||
| */ | ||
| var notificationsPermissionRequested by booleanPref(R.string.notifications_permission_requested_key, false) | ||
|
|
||
| /** | ||
| * Whether the system UI dialog for requesting audio recording permissions has been shown before. | ||
| */ | ||
| var recordAudioPermissionRequested by booleanPref(R.string.record_audio_permission_requested_key, false) | ||
|
|
||
| // **************************************** Reviewer **************************************** // | ||
|
|
||
| val ignoreDisplayCutout by booleanPref(R.string.ignore_display_cutout_key, false) | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.