element-hq
Notifications aren't set as Conversation
Steps to reproduce
- Receive a notification
- See it as random notification instead of Conversation
Here's a screenshot displaying difference notification between old Element and Element X :
Outcome
What did you expect?
To have enriched notifications labeled and grouped in Android 13 as a conversation notification and have quick options as "Mark as read" or "Quick Reply"
What happened instead?
Normal blank notification (see screenshot above)
Possible cause
I didn't see any issue about this, so I'm guessing it can be because of my phone configuration. I'm using a de-googled smartphone running MicroG instead of Google Play Service :shrug:
Your phone model
Poco F3
Operating system version
Android 13
Application version and app store
Element X 0.2.3
Homeserver
matrix-org/synapse:v1.93.0
Will you send logs?
No
Are you willing to provide a PR?
No
On a quick glance, notification logic seems to be lifted from the old app -- so all that's fine.
What's missing are shortcuts (the links to specific rooms that pop up when you long press an app icon on the home screen, or that show at the top of a share sheet). Android won't put a notification in the conversations section if it's not associated with a shortcut.
Once those are created, conversation features should work fine. Here's how shortcut creation was handled in the old app.
@dkter I checked the code and yes it seems weird that it's missing enriched and well classified notifications... Do you have the same issue as me ?
Yep, I have the same issue, it's not because of your configuration @RoiArthurB.
I started taking a look at what would be required to implement shortcut publishing in this app, but may not have time to finish it anytime soon.
This is the main thing that's stopping me from using Element X instead of Element.
Seems like this might have been resolved with https://github.com/element-hq/element-x-android/pull/3916 ?
Seems like this might have been resolved with #3916 ?
I can see that this PR adds actions to notifications, but I don't see any reference to the conversation API, which would enable one to exclude certain chats from "Do not Disturb"-Mode and assign different notification sounds, among other things. Will have to test tho as I have no clue about android development.
I can see that this PR adds actions to notifications, but I don't see any reference to the conversation API, which would enable one to exclude certain chats from "Do not Disturb"-Mode and assign different notification sounds, among other things. Will have to test tho as I have no clue about android development.
There is no "conversation API". There is an initiative from the Android team to integrate conversation better with the OS. See https://developer.android.com/develop/ui/views/notifications/conversations for more information.
In my opinion the feature as it's explained here is implemented in #3916. I'd say it's appropriate to create a new issue, if you think implementing any other conversation-related API is beneficial.
In my opinion the feature as it's explained here is implemented in #3916. I'd say it's appropriate to create a new issue, if you think implementing any other conversation-related API is beneficial.
Since #2992 discussed the features I am describing and was closed as a duplicate of this issue, I'd disagree.
Since #2992 discussed the features I am describing and was closed as a duplicate of this issue, I'd disagree.
So based on the link I've shared, I believe it's fair to say that based purely on the description of this issue that it has been implemented. Nowhere in this issue or its discussion before @codesalatdev commented was the "conversation API" ever mentioned. Conversation in this context refers to how the notification pops up. This is further clarified by screenshot provided, which unambiguously clarifies the precise difference in behavior. If there was an intention for more APIs to be implemented it has not been properly communicated. At least, that is my interpretation of the issue. And it's the interpretation I considered when I decided to subscribe to this issue. As far as I'm concerned all behavior I'm interested in has been implemented so I'm fine with the issue being closed. I believe it's fair to say that the literal objective interpretation of the issue takes precedence over any external actions, including labeling an issue as duplicate. I don't believe any circumstantial arguments matter if the issue itself is already unambiguous in this regard. And while I see how the usage of conversation can create confusion, reading the issue thoroughly doesn't leave much room for ambiguity.
Concerning #2992 specifically, I have 2 concerns with this. The first is that the determination of it being a duplicate hasn't been contested. I didn't know about what conversations really were until it was mentioned that the conversation API wasn't implemented. It's not the responsibility of maintainers to make sure issues are correctly communicated. This includes the determination of something being a duplicate. It's the responsibility of the author, or any other person interested in the feature, to clarify any misunderstandings. The second is that the issue isn't clearly communicating its precise intent. Unlike this issue, it doesn't specify any behavior, instead specifying an implementation. Given the ambiguity of "conversation", relating to multiple behaviors, this is especially difficult to deal with in this context. Also, it mentions things like "lay groundwork for", which doesn't precisely explain what the extend of that implementation should be.
I have to disagree on the semantics. OP said: “To have enriched notifications labeled and grouped in Android 13 as a conversation notification and have quick options as "Mark as read" or "Quick Reply"”
While the latest release now supports the requested quick options, the notification is not labeled as a Conversation notification, doesn’t have the features (bubbles, shortcuts, granular controls for notifications from each room etc) that Android provides for Conversations, and isn’t separated from other notifications like Conversation notifications are, and like the old Element app does.
I have to disagree on the semantics. OP said: “To have enriched notifications labeled and grouped in Android 13 as a conversation notification and have quick options as "Mark as read" or "Quick Reply"”
While the latest release now supports the requested quick options, the notification is not labeled as a Conversation notification, doesn’t have the features (bubbles, shortcuts, granular controls for notifications from each room etc) that Android provides for Conversations, and isn’t separated from other notifications like Conversation notifications are, and like the old Element app does.
I can definitely see where you're coming from. And I don't strictly disagree with your framing. I think it's completely reasonable to interpret the framing as including more features, and I think it's completely reasonable to interpret the framing as being just about quick replies. The point is that quick replies are clarified by the screenshots, whereas the other features are not. This could be because the original author believed that other features were implied, or perhaps there was the understanding of a single unified "conversation API". When in reality conversations relates to multiple APIs that may be implemented partially or incrementally.
My point stands regardless of interpretation. Let's assume the interpretation that the issue has not yet been implemented. Framed like this, I'm going to argue that this issue is too big. It describes on implementation of many features. Best practice is to write issues based on expected behavior, not implementation.
While semantics are important, they are secondary to the overall usefulness of the issue. And in this case, I believe that writing more issues will yield more utility, regardless of how the issue is interpreted.
I think #4441 is an issue more specific to the conversation api that doesn't suffer from different possible interpretations.
Another reason this functionality is important is for users who need to send and receive messages through Android Auto when driving. The old Element has this functionality, and you can have incoming messages read to you and you can dictate responses. However, this does not work with Element X. Because of this missing feature, I still run the old Element on my phone so I can still communicate while driving. It would be great if this was implemented.
Another reason this functionality is important is for users who need to send and receive messages through Android Auto when driving. The old Element has this functionality, and you can have incoming messages read to you and you can dictate responses. However, this does not work with Element X. Because of this missing feature, I still run the old Element on my phone so I can still communicate while driving. It would be great if this was implemented.
It's not that simple. The conversations API is not related to AA functionality. AA requires something else.
While I value both, they are different beasts.
I did the implementation for element quite some time ago. Should I have a look into it also on ElementX or is there already an implementation?
I did the implementation for element quite some time ago. Should I have a look into it also on ElementX or is there already an implementation?
I don't think that there is one, Conversation API will be nice to have 😀
