[Story] Threaded push notifications
Description
Description
- As a user
- When I receive a push notification belonging to a specific thread and check it in the notifications center
- Then I want it to be in a separate group from the room, where all other notifications of the same thread are present.
- And when I tap on it, I want the app to directly bring me to the thread, and focus the message.
Acceptance criteria
- The threaded notification is clearly identified and labelled as such
- The threaded notification should be rendered in the notification center in a group where all other threaded notifications belonging to the same thread root
- Tapping on the notification should open the room, the thread it belongs and focus the event
Dependencies
- None
Out of scope
Questions
- [ ] How should we label a threaded notification? Considering that we also have a different way to render mention/replies and that there is a difference between how group and DMs are rendered (at least on iOS for the latter)
We had a chat with @amshakal and we decided to simplify the behaviour of tapping a notification a bit, so instead of focusing on the event, we will just open the thread without doing any focus. Same for a normal non threaded message, it should just simply open the room without focussing the event.
@mxandreas Since you proposed the focus event solution, it turned out to be a bit slower on iOS during my tests (about 1-2 seconds slower) do you think this easier solution would be better? It will definitely fix the slowdown since we won't force the timeline to focus.
We had a chat today and we decided to also focus the event when tapping a notification (regardless if is a thread or not).
Small remark: when the root event and a thread reply will be displayed in notification there will be no direct link between them:
I do not see how to easily improve this so this is probably acceptable!
To clean this up: after trying this, we concluded that the current performance of opening the specific message (thread or main timeline) from notification may be too slow in some cases - so we keep the current behaviour of opening just the latest of room/thread. Correct? cc @Velin92 @manuroe
It is a bit more complicated than that. We are less impacted by this slowness on Android. The Android app is able to cache data in background when receiving a push. So, when the user taps on a notification, EXA can directly open the timeline (main or thread) on the message of the notifcation.
EXI cannot cache data. If we want to open the timeline on the message of the notification, it creates most of time long spinners
We decided to have a different behavior:
- EXA opens main and threaded timelines on the message of the notification and highlights it.
- EXI opens main and threaded timelines at the bottom.
Once possible EXI will behave like EXA. For now, EXI can have the same behavior but only via the developer settings ("Focus event on notification tap") I updated the acceptance criteria.
Thanks @Velin92 and @jmartinesp for the implementations.
I only found this minor issue on EXI: https://github.com/element-hq/element-x-ios/issues/4745.
Tested it again. The bug mentionned above does not exist anymore.
We can close this story 🥳 .