Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fetch messages in background #4475

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Fetch messages in background #4475

wants to merge 4 commits into from

Conversation

rapterjet2004
Copy link
Contributor

@rapterjet2004 rapterjet2004 commented Nov 22, 2024 •
edited
Loading

Fetches messages and saves them when refreshing the conversation list. Only refreshes what is needed, to save battery.

🏁 Checklist

  • ⛑️ Tests (unit and/or integration) are included or not needed
  • 🔖 Capability is checked or not needed
  • 🔙 Backport requests are created or not needed: /backport to stable-xx.x
  • 📅 Milestone is set
  • 🌸 PR title is meaningful (if it should be in the changelog: is it meaningful to users?)

@rapterjet2004 rapterjet2004 self-assigned this Nov 22, 2024
@rapterjet2004 rapterjet2004 marked this pull request as ready for review November 25, 2024 15:18
@rapterjet2004 rapterjet2004 requested a review from mahibi November 25, 2024 15:50
@mahibi
Copy link
Collaborator

mahibi commented Nov 26, 2024

not to be merged for 20.1.0, might review only afterwards

mahibi
mahibi requested changes Dec 3, 2024
View reviewed changes
Copy link
Collaborator

@mahibi mahibi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

something is wrong with the chatBlocks, they don't get merged correctly (i guess because "lastKnown" in the fieldMap is not set up correctly). In the UI this leads to the fact that the newest loaded message is shown first, and then the older messages appear. With correctly merged chatBlocks this should not happen.

There is a high danger to introduce serious bugs when something is wrong with the chatBlocks, so i might be quite nitpicky with this PR ;)

app/src/main/java/com/nextcloud/talk/conversationlist/ConversationsListActivity.kt Outdated
@@ -446,6 +449,34 @@ class ConversationsListActivity :
updateFilterConversationButtonColor()
}

private fun List<ConversationModel>.refreshMessages() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As we already have a ConversationListViewModel we should use this, so as the code is just about data handling it should not be in the Activity.

@mahibi mahibi added this to the 21.0.0 milestone Dec 3, 2024
@mahibi mahibi force-pushed the issue-4381-fetch-messages-in-background branch 2 times, most recently from 9bf582b to 7dfc82c Compare December 3, 2024 11:40
@mahibi
Copy link
Collaborator

mahibi commented Dec 3, 2024

fyi @rapterjet2004 i rebased on master...

@rapterjet2004 rapterjet2004 force-pushed the issue-4381-fetch-messages-in-background branch from 7dfc82c to 9b756d4 Compare December 10, 2024 17:16
@rapterjet2004 rapterjet2004 requested a review from mahibi December 12, 2024 15:21
@mahibi mahibi force-pushed the issue-4381-fetch-messages-in-background branch from 6ed9910 to 096c0aa Compare January 20, 2025 12:51
mahibi
mahibi requested changes Jan 20, 2025
View reviewed changes
app/src/main/java/com/nextcloud/talk/conversationlist/viewmodels/ConversationsListViewModel.kt

private suspend fun updateRoomMessage(model: ConversationModel, limit: Int, credentials: String, baseUrl: String) {
val urlForChatting = ApiUtils.getUrlForChat(1, baseUrl, model.token) // FIXME v1?
chatRepository.setData(model, credentials, urlForChatting)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't have a better idea yet,
but using the same chatRepository and only setData etc in a loop feels risky.

Some question that come to my mind:
Is the way we use dependency injection fine with this loop approach?
Is async / synchronized handling correct?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dependency Injection is a bit confusing, as even though the provider is annotated as a @singleton, it's not an actual Singleton. Each time we inject, we create a separate instance.

Async handling should be fine, the suspend function runs in ViewModelScope, so it shouldn't be attached the activity lifecycle.

app/src/main/java/com/nextcloud/talk/chat/data/network/OfflineFirstChatRepository.kt Outdated Show resolved Hide resolved
@rapterjet2004 rapterjet2004 requested a review from mahibi January 21, 2025 17:51
@github-actions GitHub Actions
Copy link
Contributor

APK file: https://www.kaminsky.me/nc-dev/android-artifacts/4475-talk.apk

qrcode

To test this change/fix you can simply download above APK file and install and test it in parallel to your existing Nextcloud Talk app.

@mahibi
Copy link
Collaborator

mahibi commented Jan 22, 2025

will do some testing tomorrow, then it should be fine to merge

@rapterjet2004 @mahibi
WIP
a7574e1 
Signed-off-by: rapterjet2004 <juliuslinus1@gmail.com>

Got it loading on refresh

Signed-off-by: rapterjet2004 <juliuslinus1@gmail.com>

linter

Signed-off-by: rapterjet2004 <juliuslinus1@gmail.com>
@rapterjet2004 @mahibi
Fixed bugs w/ lastKnown and async work and refactored
5e5bf06 
Signed-off-by: rapterjet2004 <juliuslinus1@gmail.com>
@rapterjet2004 @mahibi
linter
a58b0b2 
Signed-off-by: rapterjet2004 <juliuslinus1@gmail.com>
@rapterjet2004 @mahibi
Some fixes
3cba747 
Signed-off-by: rapterjet2004 <juliuslinus1@gmail.com>
@mahibi mahibi force-pushed the issue-4381-fetch-messages-in-background branch from 48dc925 to 3cba747 Compare January 23, 2025 13:07
@mahibi
Copy link
Collaborator

mahibi commented Jan 23, 2025

sorry Julius i won't merge this PR.

There were just too many things wrong when i tested (messages that i expected to be there were missing / Messages were loaded from when conversation was created / ...)

Also the calculation with the previous/current/result lists doesn't make sense to me.
Why is only the difference to the last state counted? If the unread messages are missing, we want to have them all.

Tbh i would like to close the PR for now and we should have a fresh look at it later.

mahibi
mahibi requested changes Jan 23, 2025
View reviewed changes
Copy link
Collaborator

@mahibi mahibi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see comment in pr

@mahibi mahibi removed this from the 21.0.0 milestone Jan 23, 2025
@github-actions GitHub Actions
Copy link
Contributor

Codacy

Lint

TypemasterPR
Warnings104104
Errors3636

SpotBugs

CategoryBaseNew
Bad practice66
Correctness222222
Dodgy code7171
Internationalization33
Malicious code vulnerability33
Performance44
Security11
Total310310

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mahibi mahibi mahibi requested changes

Requested changes must be addressed to merge this pull request.

Assignees

@rapterjet2004 rapterjet2004

Labels
don't merge
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

Fetch messages in background when unread messages are detected in conversation list
2 participants
@rapterjet2004 @mahibi