tree 9303d9a8c652a51c588ac40c37940a21ea2119a1
parent b3ba57700e6cb779d34cebb48af77d614f402281
author Ned Burns <pixel@google.com> 1571363724 -0400
committer Ned Burns <pixel@google.com> 1573758338 -0500

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