❓ LocalNotify is not used anymore (is that ok?)

[JGreenlee]

By my count, there is only one Angular service rewrite left that doesn't already have an open PR (yay! 🎉), and we are not even sure that we need it!

@jiji14 was going to begin on LocalNotify but could not find any instance of the service being invoked. I tried also, and found that LocalNotify is injected by SplashCtrl, which has not been in use since the onboarding changes.
As a result, LocalNotify is still initialized on master but not on service_rewrite_2023.

Since these changes, we have not noticed any regressions regarding local notifications, so this might be completely fine. When a permission is revoked, we still get prompted to open the app and the UX of doing so is smooth, so the permissions notifications have not seen regressions at least.

But I want to make sure there are no regressions in the 'reminders' before saying it's ok to let go of LocalNotify.

[JGreenlee]

Verdict:

'Reminders', and all other local notifications, are working fine even though LocalNotify is not in use anymore.

LocalNotify was needed when certain notifications had launch a specific route in the app. Before the migration, we only needed to do this for the 'fix permissions' notification - app status used to be only accessible from the Profile tab, so the notification needed to launch directly to there.
Now, the app status / permissions popup is app-wide and appears iff needed. We don't have to trigger a specific route for the user to get to it so opening to the (default) Label tab is fine.

The 'reminders' notifications also only need to open to the (default) Label tab, so they're fine.

---

Later, it's likely that we will want to re-implement routed notifications. But since we do the routing with React now, the implementation will be vastly different. Thus, there is little reason to keep the old LocalNotify code laying around.

[shankari]

@JGreenlee

'Reminders', and all other local notifications, are working fine even though LocalNotify is not in use anymore.

Did we actually test against 'Reminders'? If so, please document here.
We will likely use 'Reminders' extensively in a few upcoming projects, but they are not enabled in open access and most of the staging environments, so I don't want to rely solely on "we haven't noticed any regressions".

[JGreenlee]

I tested it in the devapp by spinning up a new OPcode on the 'timeuse' configuration, changing the 'reminder time' to a few minutes from the current time and minimizing the app. A notification came at the specified time, and when clicked, it launched the app.

To test it on staging, we need new OPcodes or we need to make the reminder scheme last for more than ~1 week

[shankari]

Interesting. I think we can also test by uninstalling, editing your opcode's profile to remove the reminder scheme and then reinstalling. That will keep the data but set the notifications, right?

[JGreenlee]

After the reminder settings were cleared for my opcode, I tested again by adjusting the 'reminder time' and waiting for a notification to arrive. It came as expected and was functional. I did not need to uninstall and reinstall.

Just to be sure, I will keep monitoring through Friday to see that the notifications keep coming according to the scheme.

---

I did notice one other issue, though: the list of "upcoming notifications" in the developer zone is not in order. It should be sorted by time (soonest first)

Maybe this is something @sebastianbarry can address while working on e-mission/e-mission-phone#1092

[sebastianbarry]

Fixed notifications scheduled out of order in e-mission/e-mission-phone@0ee468a

[JGreenlee]

Just to be sure, I will keep monitoring through Friday to see that the notifications keep coming according to the scheme.

The reminders ran their course on my test phone according to the scheme, with the last one on Friday. I think we are good here.