tree 45997e637d12416ef74f1768022b20128b582b47
parent 4723328ceece47d182a25dd0752154a6c4054c2d
author Ned Burns <pixel@google.com> 1584144338 -0400
committer Ned Burns <pixel@google.com> 1584393166 -0400

Change NotifCollection to use an event queue

Whenever some change needs to be applied to the NotifCollection (adding
a notification, a lifetime expiring, etc), we'd ideally like to first
make any appropriate changes to our internal state and only after all
changes have been made emit events to any listeners. This ensure that we
never emit an event while our internal state is in some inconsistent or
half-transitioned form.

Previously, we sidestepped this problem by carefully arranging
the order of our internal method calls so that things tended to work
out, but with the introduction of a new collection event,
onRankingApplied(), that is no longer a viable approach.

Now, whenever we need to emit a change event to listeners, we first push
that event to an event queue (mEventQueue). Only once the entire
mutation has been applied to our state do we then emit any events that
have built up in the queue (dispatchEventsAndRebuildList()).

In this CL:
- Move to event queue system for emitting events
- Add new event, onRankingApplied()
- Rearrange how and in what order applyRanking() is called. It is now
always called after the main mutation event. This means, for example,
that the order of events for adding a new notification is (initEntry,
addEntry, applyRanking).
- Clean up some minor test nits

Bug: 112656837
Test: atest SystemUITests
Change-Id: If1b69c19b3303718443dfe91fcde3e03113eea8c