feat: meeting occurrences pagination [WPB-20268]#5061
Conversation
…rences-pagination # Conflicts: # app/src/main/kotlin/com/wire/android/mapper/ConversationMapper.kt
…rences-pagination
…rences-pagination
Codecov Report❌ Patch coverage is ❌ Your patch check has failed because the patch coverage (30.00%) is below the target coverage (80.00%). You can increase the patch coverage or adjust the target coverage. Additional details and impacted files@@ Coverage Diff @@
## develop #5061 +/- ##
===========================================
- Coverage 49.41% 49.40% -0.02%
===========================================
Files 657 656 -1
Lines 23912 23918 +6
Branches 3728 3730 +2
===========================================
Hits 11816 11816
- Misses 10969 10973 +4
- Partials 1127 1129 +2
... and 2 files with indirect coverage changes Continue to review full report in Codecov by Harness.
🚀 New features to boost your workflow:
|
…rences-pagination
…rences-pagination # Conflicts: # kalium
|
@saleniuk looks like you are rolling back kalium to a previous commitish. This means that the PR's target branch (develop) is using a newer version of Kalium, and the changes in this PR will rollback Kalium to an older version.
Is this intentional? |
…rences-pagination # Conflicts: # kalium
|
@saleniuk looks like you are rolling back kalium to a previous commitish. This means that the PR's target branch (develop) is using a newer version of Kalium, and the changes in this PR will rollback Kalium to an older version.
Is this intentional? |
| * This use case observes and returns a flow of paginated meeting occurrences for the UI layer. | ||
| * TODO: MeetingsTabItem.PAST is not yet implemented, so it will return the same data as MeetingsTabItem.NEXT for now. | ||
| */ | ||
| class GetPaginatedFlowOfMeetingsUseCase @Inject constructor( |
There was a problem hiding this comment.
Can we have this use case in kalium side ?
There was a problem hiding this comment.
We do have use case in kalium, it's called GetPaginatedMeetingOccurrencesUseCase and it returns Flow of PagingData, and we usually have another one in android code to setup PagingConfig and other parameters. It follows our usual logic of having use case in android code which is responsible for setting up such things like start offset, filters, search query, depending on the current UI. We do have similar use cases for conversations, messages or assets and similarly here we will have different tabs ("past" and "next") and depending on that we need to setup the pager properly in android code or even use a different one for each tab (that can be true for past meetings), so we need to have some place where it's determined and kalium doesn't need to know how we group this data in UI.
There was a problem hiding this comment.
@ohassine I will merge this PR with this use case, if you think that this should be changed then let me know, we can then discuss it on collective and/or create a proper refactor ticket for that to update all these paging use cases
4 participants
https://wearezeta.atlassian.net/browse/WPB-20268
PR Submission Checklist for internal contributors
The PR Title
SQPIT-764The PR Description
What's new in this PR?
Showing paginated meeting occurrences, fetched, stored and generated in kalium. Also, observing single meeting occurrence to be used on bottom sheet menu. It now uses real meetings data, some models and mappers had to be adjusted. Updated load-more to the simplified version according to current specs (load 20 items in each page, no "show more" button). Adjusted repeating frequencies to only use the ones that are supported.
Dependencies (Optional)
Needs releases with:
Testing
Test Coverage (Optional)
How to Test
You need to have an account that has some meetings already created and use dev debug version.
Attachments (Optional)
Screen_recording_20260716_130522.mp4
PR Post Submission Checklist for internal contributors (Optional)
PR Post Merge Checklist for internal contributors
References
feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764.