Add NotifListBuilder to new notif pipeline
Adds the NotifListBuilder, the second half of the new notification
pipeline. The NLB is responsible for building the "notif list", the list
of notifications that are currently visible to the user. This differs
from the current list that is generated by the NEM/NotificationData in a
couple ways:
- It's grouped. Children have already been collected into their parent
groups. This means that the notif list now contains only "top-level
entries" -- i.e. either notification groups or notifications that aren't
part of a group.
- It's completely filtered. Previously, we did some filtering in
NEM/NotificationData and some filtering in ViewHierarchyManager. Now,
all filtering should take place in NotifListBuilder.
In order to build the final list, the NLB executes four distinct stages
of its pipeline:
1. Filtering: Notifications that shouldn't be shown right now are
excluded.
2. Grouping: Notifications that are part of a group are clumped
together into a single object (GroupEntry).
3. Group transform: Groups are optionally transformed by splitting
them apart or promoting single entries to top-level.
4. Section assignment & sorting: top-level entries are divided into
major "sections" (e.g. silent notifications vs. people
notifications vs. ...) and then the contents of each section are
sorted (as well as the contents of each group).
The NLB tries to avoid having any "business" logic in its own
implementation of the pipeline. Instead, parties that want to
participate in building the notif list can register "pluggables" that
can take part in stages 1, 2, and 4. These are:
* NotifFilter (stage 1): A pluggable for filtering out notifs from
the final notif list.
* NotifPromoter (stage 3): A pluggable for "promoting" a child
notification out of its enclosing group and up to top-level.
* SectionsProvider (stage 4): A pluggable for determining the
overall section that an entry belongs to.
* NotifComparator (stage 4): A pluggable for sorting notifications
within sections.
Whenever something about a pluggable changes so that it would like to
give a different answer than the one it gave previously, it should call
invalidate() on itself. This will trigger a new run of the pipeline.
In order to represent a list of top-level entries that might be either
single notifications or groups, this CL introduces a new object
hierarchy:
- ListEntry (superclass)
- NotificationEntry (subclass, pre-existing)
- GroupEntry (subclass, new)
Thus, the output of the NLB is a List<ListEntry>. Consumers will need to
do instanceof checks on each entry to discover if it is a
NotificationEntry or a GroupEntry. We could have just allowed
NotificationEntry to have children and skipped the need for GroupEntry,
but it's usually important to force code to think about whether it needs
to examine just the summary or also the children. Some code just cares
about the summary but some really should look at the children as well,
and it's too easy to forget to think about groups if everything is a
NotificationEntry.
Test: atest
Change-Id: I86ffe97611b0cc9792b6c96f3196061b170f56b7
30 files changed
