Refactoring search for correctness and efficiency and clarity

[rapterjet2004]

• fixes fetch open conversations only when searching #5629

The getOpenConversations API endpoint was being called every time the user gets a list of rooms, which was very inefficient, considering how often that occurs. This PR, moves that functionality to the querying logic, while also refactoring the querying logic for clarity and correctness.

Now every time you search, it launches a Coroutine that gets the open conversations/users with structured concurrency, and processes their data in a thread safe way, before retrieving the messages async and adding them to the adapter when ready.

🚧 TODO

• Figure out why users appear when tapping the search bar initially
• Clicking load more doesn't remove the refresh indicator
• Test this out with filtering button

🏁 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?)

[github-actions]

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



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

[github-actions]

Codacy

Lint

Type	master	PR
Warnings	99	99
Errors	0	0

SpotBugs

Category	Base	New
Bad practice	6	6
Correctness	10	10
Dodgy code	54	54
Internationalization	3	3
Malicious code vulnerability	3	3
Performance	4	4
Security	1	1
Total	81	81

[mahibi]

I approve as it solves the issue. 👍

But we should solve that in a different way in a follow up PR:

A better solution (but not for this PR) will be to move the fetching into the viewModel and there we should make use of combine to combine different data sources.
This should be done in general throughout the app and not only for this scenario.
Using async + awaitAll is not necessary then and also mutex handling is not needed.

So in the viewModel there should be code like:

viewModelScope.launch {
    combine(
        repository.fetchUsersFlow(filter),
        repository.fetchOpenConversationsFlow(filter)
    ) { users, conversations ->
        users + conversations
    }.collect { combined ->
        _searchResults.value = combined
    }
}

So in general, move more logic to view model while keeping the UI "dumb". The UI should only get the ready to use data for displaying..
We should make use of combine in many places which will also reduce boilerplate and complex code as we use too many flows that emit to the UI's.
Using combine will avoid to have too many flows.
Having too many flows makes code hard to read and it's hard to keep track where something is catched and what happens.