android: When opening a notification, "back" should not leave the account's context

[chrisbobbe]

From beta feedback:

Steps to reproduce:

• have at least two servers configured in the app
• use the app on one server, then switch away from it
• receive a notification for the other server
• tap the notification to open zulip
• hit the back button

Expected behavior: the back button should go to rhe next level up on the server that the notification came from. (For instance, if browsing a topic it should go up to the stream, or similar.)

Observed behavior: the back button goes to a view of the other server.

---

If the app is showing UI for Account A and you open a notification for Account B, we push a message-list route for Account B onto the nav stack that's supposed to belong to Account A. This means the "back" button will take you out of Account B's context, which can be confusing.

When we navigate on opening a notification, we should switch to a new nav stack for the notification's account (if different) before pushing the message-list route.

(The iOS counterpart is covered by #1147, for navigating at all when a notification is tapped.)

Implementation

Probably we want to call HomePage.navigate—

  /// Navigate to [HomePage], ensuring that its route is at the root level.
  static void navigate(BuildContext context, {required int accountId}) {
    final navigator = Navigator.of(context);
    navigator.popUntil((route) => route.isFirst);
    unawaited(navigator.pushReplacement(
      HomePage.buildRoute(accountId: accountId)));
  }

—and then push the result of MessageListPage.buildRoute after that.

[lakshya1goel]

Hi, I have started working on this, waiting for related CZO Discussion will raise a PR shortly. Thanks!

[gnprice]

To update the status of this issue: #1240 fixed one case of this. The description says it applies when "opened from background", but thinking again about the code I think it actually applies to a situation I would term differently:

• That PR applies when the app was not running, and starts running because the user opened a notification.
• If the app was already running but in the background, I believe that PR doesn't apply. That would instead go through didPushRouteInformation, which wasn't affected by the PR.
• The third possible case is when the app was already running and was in the foreground. I believe that also goes through didPushRouteInformation.

So I believe the current state is that this issue is resolved for the case where the app wasn't running, but remains open for the case when the app was already running, either in the background or the foreground. @rajveermalviya does that sound right to you?

[rajveermalviya]

Correct, #1240 only addresses the issue when the app was not running, and the user tapped the notification.

I agree that the title of the main (4b2f51e) commit of that PR may've been misleading (though the description tries to explain it correctly), I guess the terminology I was trying to match was FCM's use of "foreground" and "background" for received notifications. But I see it doesn't really make much sense for opening notifications. Sorry for the confusion.

As for the other cases, there was some discussion in the CZO thread linked in the description regarding some potential UX challenges.

[lakshya1goel]

Opened PR #1373 for fixing this issue, PTAL. Thanks!