Race condition between filtering and refreshing apps

[akariv]

Long time user, I've noticed that sometimes, when quickly returning to the launcher, opening the drawer and starting to filter the apps, the app list resets to the full, unfiltered list ignoring the filter completely.

Steps to reproduce:

• (After using another app for a long time)
• Return to the launcher
• Immediately open the app drawer
• Start typing to filter the list
• After typing 3 letters, the list is filtered
• Then the list is re-populated with the original, full, app list.

After reading the code, my guess as to why this happens is that when using another app for a long time, the launcher needs to be re-created in Android, which, in turn, triggers a re-fetch of the system's App List.
However, if the user already started filtering before the results of this fetch arrive, they will override the apps in the adapter and disregard the current filter.

Solution proposal - probably around this area:

Olauncher/app/src/main/java/app/olauncher/ui/AppDrawerFragment.kt

Line 177 in 3411bc2

it?.let { adapter.setAppList(it.toMutableList()) }

After setting the apps list in the adapter, re-apply the filter so that the new filtered list remains in sync with the query string.

[KeunyoungSong]

Hi @tanujnotes. Thanks for the app.
Looking at the reference, it looks like it was an enhancement while fixing another issue and added logic to do the filter after the submitList. But considering that the filter function does the submitList internally, isn't this unnecessary redundancy? Couldn't we do either filter or get a new list based on the presence of a query, and wouldn't updating the list with values that aren't being filtered at any point have the potential to cause flicker? Would love to hear your thoughts. I guess we could also think about managing the query in an adapter.

P.S. Is there any way to reproduce this memory related issue?