stream-chat-android
stream-chat-android copied to clipboard
Unread message count disappears on returning to ChannelListFragment
Description
We're using the Stream Chat SDK with ChannelListFragment. The unread message count shows correctly when the fragment is first loaded, and it updates in real-time as expected. However, when the user navigates away from the fragment (e.g., back press or navigating to another screen) and later returns to it, all unread counts are reset to zero — even though there are still unread messages - as I havn't open the channel having unread messages
We are not modifying or customizing ChannelListViewModel directly and are relying on the default behavior of ChannelListFragment.
This seems to suggest that the ViewModel or internal channel query state is not being retained or re-initialized correctly when the fragment is recreated.
- SDK version
- v6.12.0
Acceptance criteria
- Unread message counts persist after navigating away and returning to
ChannelListFragment. - ViewModel retains or re-queries correct channel state upon re-attachment.
Screenshots
Hi @inabdev30 , Can you provide us a video reproducing this behavior using the sample app? Thanks,
@andremion sample app seems working fine, but in my case I am using activity which is then displaying then ChannelListFragment from SDK, here are the details:
- Open then channel list fragment
- In front of each channel I have the unread count - I didn't open any channel
- Go back
- Open the channel list fragment again
- Unread count gone, when tried to read it from global state that's also gives me 0
@andremion we have any update here?
Hi @inabdev30 ,
I can not reproduce it using the 6.15.0 release.
I changed the sample app to use the ChannelListFragment from the SDK, and it seems fine.
class ChannelListFragment : ChannelListFragment() {
override fun createChannelListViewModelFactory(): ChannelListViewModelFactory {
val user = App.instance.userRepository.getUser()
val userId = if (user == SampleUser.None) {
ChatClient.instance().clientState.user.value?.id ?: ""
} else {
user.id
}
return ChannelListViewModelFactory(
filter = Filters.and(
Filters.eq("type", "messaging"),
Filters.`in`("members", listOf(userId)),
Filters.or(Filters.notExists("draft"), Filters.eq("draft", false)),
),
chatEventHandlerFactory = CustomChatEventHandlerFactory(),
)
}
}
https://github.com/user-attachments/assets/cf4c672b-eecd-44a1-9f38-a8ffc0631734
For me, I have also checked the globalState object, and the counter seems to be getting reset, and also the channel unread count just is not there after navigating to any other screen (not opening channel, so mean counter should not get reset)
https://github.com/user-attachments/assets/efb6bff6-abc0-4e84-9024-d4134af7a411
@andremion We have checked the sample app on the iOS side too, and can reproduce the issue
https://github.com/user-attachments/assets/cad1a65c-4376-4b3b-9219-8a59ef598a0e
@andremion Just checking in—any update on this? Appreciate your time!
Hey @inabdev30 , We are investigating internally and will let you know when we conclude. Thanks,
@inabdev30 , Can you please confirm in which version of the SDKs you reproduced it? Thanks,
@andremion Android SDK v6.15.0 iOS SDK 4.69.0
thank you 👍
Hey @nabeelismail30 , Can you try reproducing the issue using the samples from the latest releases? https://github.com/GetStream/stream-chat-android/releases/tag/6.17.0 https://github.com/GetStream/stream-chat-swift/releases/tag/4.79.1 Thanks
@andremion Checked using latest iOS SDK - v4.79.1, issue is presist.
https://github.com/user-attachments/assets/86bf83b3-0098-42aa-9570-47882a1e6fcd
@andremion - Android SDK 6.17.0
https://github.com/user-attachments/assets/e2f408a3-a181-4f44-b558-0ab089e22d34
@nabeelismail30 , thanks for the videos. However, I asked to reproduce using sample apps. Can you please try to reproduce using the sample apps, so we can make sure it's reproducible from our side. Thanks,
@nabeelismail30 , Here is an update on that. It seems the channel unread count is reset when we enter a thread from that same channel. We are discussing this internally to see if that's expected or not. Thanks,
This issue has been automatically closed because there has been no response to our request from the original author. Please don't hesitate to comment on the bug if you have any more information for us - we will reopen it right away! Thanks for your contribution.