fix: resolve Updates screen's UI issues
Description
Fixed Updates screen's UI issues with list rendering, Update All button's behaviour along with improved code organization.
Technical details
The Updates screen had two classes of problems:
- The screen did too much work for the wrong kind of event.
- A full list render path was being reused for small status changes.
- That caused repeated list refresh work, repeated scroll-to-top behavior, and unnecessary button recomputation.
Update Allwas not driven by a clean, reliable source of truth.- Button state was recalculated from many different call sites.
- It used synchronous
WorkManager.get()calls on the main thread. - It listened to all WorkManager jobs, not only update/install work relevant to this screen.
- It mixed UI timing, repository state, and background work state in a way that made edge cases easy to break.
The goal of the refactor was to separate those concerns and make Update All derive from a smaller, clearer set of inputs.
flowchart TD
A[updatesList emission] --> B[renderStructuralUpdates]
B --> C[sort + submit list]
C --> D[loading/content/empty UI]
D --> E[recompute Update All]
D --> F[optional scroll to top]
G[downloadList emission] --> H[apply status overlay to displayedUpdates]
H --> I[submit lightweight row state]
I --> E
J[relevant WorkManager emissions only] --> EAt a high level, the screen now has three different input streams:
- Structural update list data
updatesViewModel.updatesList- This answers: which apps belong in the list?
- Per-app status overlay data
mainActivityViewModel.downloadList- This answers: for the apps already on screen, which ones are queued/downloading/installing?
- Background work state
- relevant
WorkManagerobservations only - This answers: is there still active update/install work that should block
Update All?
- relevant
Combined, they are the source of truth for the updates list.
Tests
Issues
https://gitlab.e.foundation/e/os/backlog/-/work_items/4235
10 commandments of code review
Edited by Fahim M. Choudhury