Skip to content
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

notifications: Open to unreads from summary notification. #5472

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

rachelhyman
Copy link

Adds an intent to the summary notification. When the summary
notification is clicked in the collapsed state, the app will open and
reset itself to the unreads screen. It will also switch to the
appropriate account if needed.

Because the intent flags (Intent.FLAG_ACTIVITY_NEW_TASK
and Intent.FLAG_ACTIVITY_CLEAR_TOP) apply to both the normal
notification and the summary one (and are prefaced with explanatory
comments), I moved them to a variable before where both notifications
are created.

This was manually tested for the following cases, with both the app
already being on the correct account and being on a different account:

  • App open in background on non-unreads screen
  • App open in background on unreads screen
  • App not open in background

I also made sure that tapping on a notification in the expanded state
still routes the user to the correct screen.

Fixes #5242.

Adds an intent to the summary notification. When the summary
notification is clicked in the collapsed state, the app will open and
reset itself to the unreads screen. It will also switch to the
appropriate account if needed.

Because the intent flags (Intent.FLAG_ACTIVITY_NEW_TASK
and Intent.FLAG_ACTIVITY_CLEAR_TOP) apply to both the normal
notification and the summary one (and are prefaced with explanatory
comments), I moved them to a variable before where both notifications
are created.

This was manually tested for the following cases, with both the app
already being on the correct account and being on a different account:
- App open in background on non-unreads screen
- App open in background on unreads screen
- App not open in background

I also made sure that tapping on a notification in the expanded state
still routes the user to the correct screen.

Fixes zulip#5242.
Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @rachelhyman!

In my testing, this doesn't actually result in navigating to the account in question, or navigating to the unreads screen, when the user opens the summary notification. It opens the app or brings it to the foreground, but then the app remains on the account that was previously active, and on the screen it'd been on if it was already running.

This is a little bit subtle to test manually, even though it's a quite common situation in normal use: you have to send the user notification-causing messages in two different conversations (e.g., a 1:1 PM and also a PM to some group.) If the test messages you send are all in the same conversation, then they all get shown in a single notification, and then the summary notification doesn't get involved. Perhaps that's what happened in your testing.

One good way to test your test procedure is to try it on the unmodified app, without the new setContentIntent call you added, and make sure that it correctly fails there.

I've added a comment below pointing at the other bit of existing code for the individual notifications that will need a counterpart for the summary notification. That supplies some information to the JS side of the app; and then for where that information gets consumed, see src/notification/notifOpen.js.

// all the activities on top of the target one.
Intent.FLAG_ACTIVITY_NEW_TASK or Intent.FLAG_ACTIVITY_CLEAR_TOP
)
.setFlags(intentFlags)
.putExtra(EXTRA_NOTIFICATION_DATA, bundleOf(*fcmMessage.dataForOpen())),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's the line in the existing code where we supply the data that the JS side of the app relies on in order to know where it should navigate to when opening the notification.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Depending on the outcome of the below, I take it we would want a dataForSummaryOpen that only includes the realm_uri and user_id?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, that sounds good.

@rachelhyman
Copy link
Author

Hi @gnprice, thanks for testing it on your end. Hm....I took a screen recording of what I'm seeing on my end with the new code:
https://user-images.githubusercontent.com/5513682/186184671-223a468f-456b-4b68-98b5-333595db4a6a.mp4
This shows me on a particular conversation, backgrounding the app, then clicking on the summary notification which takes me to the home screen. Is the notification I click on actually the summary notification? Or is it something else?

I did notice that when I have existing notifications that are all from one conversation (like PMs from one person), and then receive a new notification from a different conversation, it takes a minute for them all to "collect" under the summary one. They appear in separate groups at first, and then after a time or two of swiping down to show the notifications screen, they show up as all under the summary notification like I expect.

@gnprice
Copy link
Member

gnprice commented Aug 24, 2022

Interesting, thanks for the video.

I believe what's happening there is that the app is getting started again from scratch, with the side effect of resetting the navigation to the unreads/inbox screen. One detail that points to that is the "Connecting…" banner showing up at the top -- that's something that happens when the app starts up, but doesn't have another reason to appear in connection with opening a notification.

That demonstration also doesn't appear to involve switching between different accounts. I think this version of the code fundamentally can't accomplish that, because there's no information it attaches to the summary notification that would make it possible for the JS side of the code to know it should switch to a particular account.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Click on notification should expand it
2 participants