Two builds at once were two lines inside one notification; they are now
two notifications in one group, each with its own title and its own bar,
which is what the shade is for -- and what lets a component that
finishes take its own row down while its sibling carries on. Rows are
keyed by a tag (<key>/<component>) rather than an id, so an update
replaces the row it is about and two components cannot collide, and
`drawn` is the path out for one whose work is over.
A foreground service needs one notification that outlives every row, so
the service's own is the row itself while one thing is running and the
group's summary once there are more. Measured on API 36: a group of one
is collapsed to its header, which is the line of text with the bar left
out of it -- so grouping a single row would cost it the progress it had.
Verified on the emulator through all four states: one row with its
count, two grouped rows with a bar each, the fast one finishing and
leaving the other as a single row again, and everything gone when the
last build lands.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Everything this app asks for is minutes of the build machine's time
followed by a download, and all of it runs in the list screen's own
coroutines -- so with the app in the background the process is an
ordinary cached one, and Android is free to take it away halfway
through a build. A foreground service is the only way to say otherwise,
and its notification is both what that costs and what it is for: the
work is visible from the shade while it runs, and one tap comes back to
the card that started it.
The work itself stays where it is. WorkNoticeService runs nothing --
it collects a list of what is happening and reposts one notification,
stopping as soon as the list is empty -- and that list is *derived* by
workItems from the same projectStates/componentStates the cards are
drawn from, so there is nothing to forget to post and nothing to forget
to take back. The words are shared rather than written twice:
componentWorkLine and buildLine are now read by the card's own bars and
by the notification alike.
Measured on API 36 rather than assumed: the collapsed row drops the
content text the moment there is a progress bar, so one thing running
puts both the component and what is happening to it in the title
("Test Tablet / tablet: building 14/30"); several get a line each in
the expanded view and an indeterminate bar, there being no honest
single number for two builds at once. With the app at the home screen
the process sits at fg-service-act rather than cached, and the builds
it started landed while it was there.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
iris-aiandClaude Opus 5