Restore notifications when app starts #1509

felixwiemuth · 2022-09-17T13:30:52Z

Overview

This pull request makes notifications from habit reminders survive reboots, app updates and force-closing by recreating them on app startup. After reboot and app update, notifications reappear without having to start the app manually, after a force-close, they reappear after starting the app manually. In all of these cases, notifications were previously gone and not recreated.

When notifications that had been shown before are recreated, they are shown silently, to not give the impression that they just became due. As before, notifications display the original reminder time - that is, when a notification is recreated, it doesn't display as "now", but shows the relative time since the reminder was due.

This implements #172.

Implementation

Technically, this is implemented in the following way:

Active notifications are persisted whenever they are changed, and reloaded from persistent storage whenever the NotificationTray class is instantiated.
- Persistence is achieved through serializing the map with NotificationData objects (which now also includes a flag whether the notification has been shown already) to SharedPreferences, whenever this map is changed.
- With persistency, it becomes more important to also remove no more active notifications from the map of active notifications, as they otherwise would be restored, but not reshown, and thus accumulate.
Whenever the app is created, HabitsApplication calls NotificationTray.reshowAll() which results in all active notifications being reshown. This also happens after reboot (because of receiving the BOOT_COMPLETED intent) and after app upgrade (because of receiving the MY_PACKAGE_REPLACED intent).
Previously, ReminderReceiver initiated a rescheduling directly; this was and is still not necessary, as it was and is initiated in HabitsApplication.

Testing

Manually tested successfully the following on a Pixel 4a (Android 13) to check whether it works as intended, including some previous behaviour:

Force stop app while notification showing, it shows again silently when opening app again
Force stop app before notification becomes due
- Start app again before notification becomes due, it shows normally when due
- Do not start app: notifications are not shown when due (this should be expected, as alarms are cancelled by force-stopping)
  - However, notifications due (but not shown previously) should be shown when eventually starting the app, but currently don't - this problem already exists in the current release version (2.1.0).
Force stop app after having marked habit as done in notification, it does not show again when starting app
Reboot while notification showing, it shows again silently about 2min after login (this is normal, it can be delayed a bit depending on when Android sends the reboot intent to the app)
Reboot before notification is due (while it is not showing), login after it is due: does not show - this problem also exists in release version 2.1.0, as above for the force-stop case
Updating app: active notifications show up silently after installing the update without manually starting the app
Changing reminder time while notification is showing: notification stays, but renews with sound etc. at the new due time
- The same with rebooting (or force-stopping) before it becomes due and it becoming due before logging in (or starting the app, respectively): shows silently with old due time (NOTE: I would say this is not optimal but acceptable; I guess this is due to the same reason that new notifications are not shown when they became due while the app was not running, see above)
  - The same but with logging in / receiving boot intent before it becomes due: it first shows silently with old due time and then renews with sound at the new due time
When a notification is still active from the previous day, it gets replaced by the new one from the current day when it becomes due

The action is already performed via HabitsApplication.onCreate. It is sufficient that there is a boot receiver.

- Persist the map of active notifications on every change and reload it on application startup. - Reshow all active notifications on application startup using the original reminder due time.

So that notifications are also restored after app upgrade

It is not necessary to keep this field as in the map of active notifications (and its persisted form) this field is always `true`.

felixwiemuth · 2022-09-18T08:35:36Z

Note that I changed the implementation so that notifications are first added to the active map when the ShowNotificationTask is executed, and not when this task is created and scheduled to execute. I guess that this is fine and it is very unlikely that the app stops before the task is run?

This also means that we actually don't have to persist the shown field of NotificationData, as all notifications added to the active map have been shown (or are just about to be shown). I am currently testing this variant (it is a small change) and I think this will be preferable, except anyone sees an advantage of the current version.

hiqua · 2022-09-18T13:26:12Z

Thanks a lot! Any way to have automated tests for this?

felixwiemuth · 2022-09-18T14:23:56Z

Any way to have automated tests for this?

I looked into the existing unit tests but didn't find anything related, e.g. some stubbing/test setup that would allow to test whether persistence works correctly.

Regarding instrumented tests, I am not sure how straight-forward it is to test the relevant situations (reboot, force-stop, update). What could be useful is to test whether after starting the app, previously serialized active notifications are shown (however, one has to make sure that they actually should be shown, there are some conditions). At best the serialized notifications are created through the UI as well (schedule habit reminder so that it becomes due). But I am not enough into instrumented tests to say how easy this is.

felixwiemuth · 2022-09-18T16:03:07Z

I have now also tested that a notification from the previous day gets replaced by the new one from the current day when it is due (in the slightly updated version without persisting shown though).

felixwiemuth · 2022-09-19T19:21:13Z

I now also pushed the small update with removing the unnecessary shown field from NotificationData. I executed all manual test from above again and they still seem to pass in the same way. However, I updated, corrected and extended the test list a bit, see in bold for some undesirable behaviour.

I think what should be fixed is that reminders becoming due while the device is off are not eventually shown when the device or even the app is started. This exists, as noted, already in the current release version 2.1.0.

If you agree that this should be fixed, I would take a look.

iSoron

Hi @felixwiemuth, thank you for the pull request. I tried it out, and it seems to work well. Please see some comments below.

Regarding testing, I suggest not testing any uhabits-android classes at this time, but I think it's important to write tests for all changes in uhabits-core. For example, we could:

Store notifications to preferences then immediately retrieve them and check that the retrieved version equals the original one.
Create a NotificationTray with a mock Preferences, and ensure that the correct calls to preferences.setActiveNotifications are made. Also ensure that set/remove/get operations behave as expected.

iSoron · 2022-09-25T01:11:16Z

uhabits-android/src/main/java/org/isoron/uhabits/receivers/ReminderReceiver.kt

                Intent.ACTION_BOOT_COMPLETED -> {
                    Log.d("ReminderReceiver", "onBootCompleted")
-                    reminderController.onBootCompleted()
+                    // NOTE: Some activity is executed after boot through HabitsApplication, so receiving ACTION_BOOT_COMPLETED is essential.
                }


Could you clarify why do we still need this block? We would still receive ACTION_BOOT_COMPLETED, even if we remove the block.

The block is not needed (and I can see the intent is also logged above); What I deemed important is that somewhere it is noted that it is important that the ACTION_BOOT_COMPLETED intent is received.

Actually, as for both ACTION_BOOT_COMPLETED and MY_PACKAGE_REPLACED the only thing we need is that the application is started (and all the code from ReminderReceiver is not needed), I would suggest that both should be received by a common dummy receiver (as currently with UpdateReceiver), which we could call StartAppReceiver or similar. Then it is clear that these intents are solely received to let the app start.

iSoron · 2022-09-25T01:15:19Z

uhabits-android/src/main/java/org/isoron/uhabits/receivers/UpdateReceiver.kt

+class UpdateReceiver : BroadcastReceiver() {
+
+    override fun onReceive(context: Context, intent: Intent) {
+        // Dummy receiver, relevant code is executed through HabitsApplication.
+        Log.d("UpdateReceiver", "Update receiver called.")
+    }
+}


Why do we need a new (empty) receiver? Could we add MY_PACKAGE_REPLACED to the list of intent filters of ReminderReceiver instead?

See comment above.

iSoron · 2022-09-25T01:21:59Z

uhabits-core/src/jvmMain/java/org/isoron/uhabits/core/ui/NotificationTray.kt

        for ((habit, data) in active.entries) {
-            taskRunner.execute(ShowNotificationTask(habit, data))
+            taskRunner.execute(ShowNotificationTask(habit, data, true))


For boolean arguments, it's best to add the argument name (shown = true)

iSoron · 2022-09-25T01:23:08Z

uhabits-core/src/jvmMain/java/org/isoron/uhabits/core/ui/NotificationTray.kt

+    private inner class ShowNotificationTask(
+        private val habit: Habit,
+        private val data: NotificationData,
+        private val shown: Boolean


silent is a bit more clear to me. Changing it would also make it consistent with the other class.

Agree, done.

iSoron · 2022-09-25T01:27:39Z

uhabits-core/src/jvmMain/java/org/isoron/uhabits/core/preferences/Preferences.kt

+        return if (serialized == "") {
+            HashMap()
+        } else {
+            val activeById = Json.decodeFromString(MapSerializer(Long.serializer(), NotificationTray.NotificationData.serializer()), serialized)


What happens if the decoding fails? Does the app fail to boot? I think this could happen if: (i) user receives some notifications; (ii) we update NotificationData with some new/renamed fields; (iii) user installs updates and restarts the app. The new version of the app would not be able to read serialized data from the old version.

I suggest adding a try/catch block here, and returning HashMap() if the operation fails.

Yes currently there would be an uncaught exception if decoding fails, and the app would crash on startup. That is of course bad, even though unlikely. Returning an empty map in case it cannot be deserialized is fine, as (as far as I can see) no other functionality depends on all active notifications being available in the map.

What we could do is show a notification that notifications could not be restored and the user should make sure to look at the habits manually, but regarding that it is a corner case it's probably not worth it.

Btw., decoding will not fail if fields not present in the encoded string have default values in the Kotlin class.

iSoron · 2022-09-25T01:39:01Z

I think what should be fixed is that reminders becoming due while the device is off are not eventually shown when the device or even the app is started. This exists, as noted, already in the current release version 2.1.0.

This would be a nice feature, but it could also be a separate PR.

In case serialized notifications cannot be deserialized, continue with an empty map of active notifications

felixwiemuth · 2022-09-25T13:11:37Z

I think what should be fixed is that reminders becoming due while the device is off are not eventually shown when the device or even the app is started. This exists, as noted, already in the current release version 2.1.0.

This would be a nice feature, but it could also be a separate PR.

I agree that this should be a separate PR (or issue for now). I have also a few other related things where I'd open a new issue for.

felixwiemuth · 2022-09-26T11:28:40Z

Regarding testing, I suggest not testing any uhabits-android classes at this time, but I think it's important to write tests for all changes in uhabits-core. For example, we could:
1. Store notifications to preferences then immediately retrieve them and check that the retrieved version equals the original one.

I'm currently looking into adding a test to PreferencesTest but am looking for some help with map comparison (see https://stackoverflow.com/questions/73852632/test-equality-of-collections-with-custom-matcher).

2. Create a NotificationTray with a mock Preferences, and ensure that the correct calls to `preferences.setActiveNotifications` are made. Also ensure that `set/remove/get` operations behave as expected.

I started writing a test with a MockPreferences : Preferences(DummyStorage()) class which simply retains the map passed to it via setActiveNotifications. For this I need to make the set and get operations open, so that they can be overridden with the mock functionality.
Then we can test the public methods show and cancel of NotificationTray, and potentially the four special cases where habits should be removed from the active list during execution of ShowNotificationTask.

felixwiemuth

I have now added the described tests in their current state. They check most of what we discussed. See the comments for further info.

felixwiemuth · 2022-10-02T10:03:24Z

uhabits-core/src/jvmTest/java/org/isoron/uhabits/core/ui/NotificationTrayTest.kt

+        notificationTray.show(habit, timestamp, reminderTime)
+
+        // Verify that the active notifications include exactly the one shown reminder
+        // TODO are we guaranteed that task has executed?


As a ShowNotificationTask is executed by a task runner, I am not sure whether this might be asynchronous and we should for example add a delay here to increase the likelihood that it has executed? Or are tasks (at least for these tests) run in the same thread, which would make tests safer?

felixwiemuth · 2022-10-02T10:05:21Z

uhabits-core/src/jvmTest/java/org/isoron/uhabits/core/ui/NotificationTrayTest.kt

+        notificationTray.cancel(habit)
+        assertThat(preferences.getActiveNotifications(habitList).size, equalTo(0))
+
+        // TODO test cases where reminders should be removed (e.g. reshowAll)


Here we could add tests whether the remaining methods which touch the active notifications map remove entries in the correct situations. It is a little work to setup all the special cases, I can't promise right now when I'll be able to do that.

felixwiemuth · 2022-10-02T10:08:56Z

uhabits-core/src/jvmTest/java/org/isoron/uhabits/core/preferences/PreferencesTest.kt

+        assertThat(a.keys, equalTo(b.keys))
+        a.forEach { e -> assertThat(b[e.key], equalTo(e.value)) }


This is a manual workaround for the missing matcher/library function I was looking for.

hiqua · 2023-08-10T22:48:05Z

@iSoron if the state of the PR seems ok I can try to rebase it, let me know. AFAICT from reading the comments, all the concerns were addressed.

felixwiemuth added 6 commits September 17, 2022 14:50

Remove habits from active list when should not be shown

33100df

Remove redundant rescheduling after reboot

0d1d8a9

The action is already performed via HabitsApplication.onCreate. It is sufficient that there is a boot receiver.

Add dependency and plugin: kotlinx-serialization-json

794289b

Persist notifications

09c46f5

- Persist the map of active notifications on every change and reload it on application startup. - Reshow all active notifications on application startup using the original reminder due time.

Show previously shown notifications silently

857e21a

Add app update broadcast receiver

68f2639

So that notifications are also restored after app upgrade

felixwiemuth marked this pull request as ready for review September 17, 2022 15:49

Remove shown field from NotificationData

4174359

It is not necessary to keep this field as in the map of active notifications (and its persisted form) this field is always `true`.

iSoron requested changes Sep 25, 2022

View reviewed changes

felixwiemuth added 2 commits September 25, 2022 10:10

Catch serialization exception

f1c104a

In case serialized notifications cannot be deserialized, continue with an empty map of active notifications

Better name: NotificationData.silent

015c0d1

Add tests for active notifications persistence

1540427

felixwiemuth commented Oct 2, 2022

View reviewed changes

felixwiemuth added 2 commits October 2, 2022 12:14

Make NotificationData data class

e65357b

Fix code style

ee0663e

hiqua requested a review from iSoron November 25, 2022 16:33

hiqua assigned iSoron Aug 10, 2023

felixwiemuth mentioned this pull request Aug 11, 2023

Reminder not shown when device was off or app force-closed at due time #1808

Open

2 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Restore notifications when app starts #1509

Restore notifications when app starts #1509

felixwiemuth commented Sep 17, 2022 •

edited

Loading

felixwiemuth commented Sep 18, 2022

hiqua commented Sep 18, 2022

felixwiemuth commented Sep 18, 2022

felixwiemuth commented Sep 18, 2022

felixwiemuth commented Sep 19, 2022

iSoron left a comment

iSoron Sep 25, 2022

felixwiemuth Sep 25, 2022

iSoron Sep 25, 2022

felixwiemuth Sep 25, 2022

iSoron Sep 25, 2022

felixwiemuth Sep 25, 2022

iSoron Sep 25, 2022

felixwiemuth Sep 25, 2022

iSoron Sep 25, 2022

felixwiemuth Sep 25, 2022

iSoron commented Sep 25, 2022

felixwiemuth commented Sep 25, 2022

felixwiemuth commented Sep 26, 2022

felixwiemuth left a comment

felixwiemuth Oct 2, 2022

felixwiemuth Oct 2, 2022

felixwiemuth Oct 2, 2022

hiqua commented Aug 10, 2023

		assertThat(a.keys, equalTo(b.keys))
		a.forEach { e -> assertThat(b[e.key], equalTo(e.value)) }

Restore notifications when app starts #1509

Are you sure you want to change the base?

Restore notifications when app starts #1509

Conversation

felixwiemuth commented Sep 17, 2022 • edited Loading

Overview

Implementation

Testing

felixwiemuth commented Sep 18, 2022

hiqua commented Sep 18, 2022

felixwiemuth commented Sep 18, 2022

felixwiemuth commented Sep 18, 2022

felixwiemuth commented Sep 19, 2022

iSoron left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

iSoron commented Sep 25, 2022

felixwiemuth commented Sep 25, 2022

felixwiemuth commented Sep 26, 2022

felixwiemuth left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hiqua commented Aug 10, 2023

felixwiemuth commented Sep 17, 2022 •

edited

Loading