commit 6cf3e38519ef4704b14e8ac3f94ea651fa309f68
author Joshua Trask <joshtrask@google.com> Tue Dec 19 22:36:59 2023 +0000
committer Joshua Trask <joshtrask@google.com> Fri Jan 05 18:06:59 2024 +0000
tree b34c2b20724181bf57f0b360796b4ce81fde2ba1
parent af6a22081dca5b68e99af1cd6127bae660651565

Generalize pager-adapter to support "many" tabs

(as in "0-1-many": if we have to support "multiple" then we shouldn't
hard-code limitations on the number that we *do* support.)

These changes are as prototyped in ag/25335069 and described in
go/chooser-ntab-refactoring, in particular replicating the changes of
"snapshot 34" through "snapshot 36." See below for a "by-snapshot"
breakdown of the incremental changes composed in this CL.

Snapshot 1: build pager-adapters from requests that include enough
details about the pages for us to be able to implement
`setupProfileTabs()` from our own records, without requiring the
caller to provide per-tab data. This change stops short of actually
changing the implementation of `setupProfileTabs()` and mostly just
establishes the bookkeeping / new convention for configuration.

Snapshot 2: implement `MultiProfilePagerAdapter.setupProfileTabs()` to
build tabs from its own records.

Snapshot 3: look up the page number for the "default profile" page,
instead of assuming it's equal to the profile ID (since that may not
be true in the "n-tab" case).

Bug: 310211468
Test: `IntentResolver-tests-{activity,unit}`, `ResolverActivityTest`
Change-Id: I3f8b9f9e53ff7a0740d1accd3a50b08e7c01bb55