-
-
Notifications
You must be signed in to change notification settings - Fork 676
Closed
Description
Currently we maintain the following data structure in our Android-native code that handles notifications:
/**
* The Zulip messages we're showing as a notification, grouped by conversation.
*
* Each key identifies a conversation; see [buildKeyString].
*
* Each value is the messages in the conversation, in the order we
* received them.
*
* When we start showing a separate notification for each [Identity],
* this type will represent the messages for just one [Identity].
* See also [ConversationMap].
*/
open class ByConversationMap : LinkedHashMap<String, MutableList<MessageFcmMessage>>()
/**
* All Zulip messages we're showing in notifications.
*
* Currently an alias of [ByConversationMap]. When we start showing
* a separate notification for each [Identity], this type will become
* a collection of one [ByConversationMap] per [Identity].
*/
class ConversationMap : ByConversationMap()As those comments foreshadow, we should separate out this data by which account/identity the user received it for. As is, because we don't, we end up showing conversations in different accounts jumbled together in a single summarized notification.
This will then be a building block for #2691.
We might also first use the separated data structure to start showing separate notifications per account within our current style of notification; that'll be worthwhile just if the work consists mostly of refactors we need anyway for #2691.