notif: Ignore notifications for logged out accounts

[tomlin7]

Fixes: #1264

Changes

• Ignores notifications received for accounts that were logged out while the app was offline
• Removes notifications (if there exist) of the user when the user logs out

[gnprice]

Thanks @tomlin7 for the contribution! Before we can review this, it will need a test — see the repo's README file.

[chrisbobbe]

Thanks! Comments below from a brief review.

[chrisbobbe]

Our tests for logOutAccount should check that the notifications are removed.

[chrisbobbe]

Also, what's the effect when this runs on iOS? Does it error or do nothing?

[chrisbobbe]

Also let's have this be unawaited, like unregisterToken above; we still want to do the removeAccount, as soon as possible, if this fails or takes a long time for some reason.

[tomlin7]

@chrisbobbe The tests are passing, I can't test on iOS atm since I'm on Android :)

[chrisbobbe]

Yeah; I see this output in the console when I log out on iOS:

[ERROR:flutter/runtime/dart_vm_initializer.cc(40)] Unhandled Exception: PlatformException(channel-error, Unable to establish connection on channel: "dev.flutter.pigeon.zulip.AndroidNotificationHostApi.getActiveNotifications"., null, null)
#0      AndroidNotificationHostApi.getActiveNotifications (package:zulip/host/android_notifications.g.dart:721:7)
<asynchronous suspension>
#1      NotificationDisplayManager.removeNotificationsForAccount (package:zulip/notifications/display.dart:531:33)
<asynchronous suspension>

I'll start a CZO discussion on what to do for iOS here. Edit: here: https://chat.zulip.org/#narrow/channel/243-mobile-team/topic/NotificationDisplayManager.20Android-only/near/2099143

[chrisbobbe]

Following that discussion, yeah, we will need to put the new call inside an Android platform conditional.

Then as an optional, independent improvement, you could add a commit that does this:

Could be helpful to put asserts at the top of [NotificationDisplayManager's] public methods, checking the target platform is indeed Android — because that's basically an assumption the implementation is making

[chrisbobbe]

We have other code for computing a group key; let's be sure to use shared code for that, so the implementations stay in sync.

[tomlin7]

@chrisbobbe but the current implementation of _groupKey() takes a subtype of FcmMessageWithIdentity and I don't have sufficient data at this point. What should be done?

[chrisbobbe]

I see two options:

1. Change _groupKey to take a realm URL and user ID instead of an FcmMessageWithIdentity.
2. Keep _groupKey's signature but add a separate helper that takes a realm URL and user ID; have _groupKey and this new function call that new helper.

Option 1 is less code; let's try that for now, and perhaps Greg will have thoughts in his review.

[tomlin7]

@chrisbobbe I noticed _personKey does exactly what I needed here, and it works fine. What do you think about using it instead?

[chrisbobbe]

Hmm, I'd appreciate @gnprice's thoughts on that question.

[chrisbobbe]

I found some 🙂—https://chat.zulip.org/#narrow/channel/516-mobile-dev-help/topic/Removing.20notifications.20for.20logged.20out.20account/near/2088813 :

As a matter of code organization, we'll want to keep centralized in one place the details of how the group key is formatted — the fact that it's the realm URL, then user ID, and separated by |. That's currently in this method:

  static String _groupKey(FcmMessageWithIdentity data) {
    // The realm URL can't contain a `|`, because `|` is not a URL code point:
    //   https://url.spec.whatwg.org/#url-code-points
    return "${data.realmUrl}|${data.userId}";
  }

So you'll want to refactor that a bit so that it can be used by this code path as well as the existing code paths that use it.

I read that as suggesting my option (1) above.

[chrisbobbe]

I believe the two questions above that were open now have answers:

• notif: Ignore notifications for logged out accounts #1349 (comment)
• notif: Ignore notifications for logged out accounts #1349 (comment)

So you should be able to proceed, incorporating those.