commit 702b0bcb8cde313c97cdd461e6c96b8075cf0b6d
author Joshua Trask <joshtrask@google.com> Mon Dec 04 17:56:09 2023 +0000
committer Joshua Trask <joshtrask@google.com> Mon Dec 04 17:56:09 2023 +0000
tree 57c6a5a5410ec09e34d7740afa7621432aace27f
parent acbd4647f757cf4d651a15cb72df2acb5ea59a68

Chooser pager-adapter: override generic rebuildTab

(This is the "miscellaneous" change from go/chooser-ntab-refactoring /
"snapshot 19" from ag/25335069). TLDR: we want to burn down external
references to having an "inactive" tab, and this is one "low-hanging
fruit" case where we really didn't need to distinguish active/inactive
status in the first place.

As originally noted in ag/25335069, this is essentially a no-op change;
there may appear to be a discrepancy compared to the legacy
`rebuildInactiveTab()` with regards to the old `getItemCount() != 1`
condition, but the distinction is vacuous since the only caller of
`rebuildInactiveTab()` (`ResolverActivity.configureContentView()`)
already verifies `shouldShowTabs()` as a precondition to the rebuild,
which implies `getItemCount() > 1`.

FWIW this CL *does* invert the "nesting" of the two different trace
mechanisms. In the original implementation, the chooser override's
"app target loading section" would begin prior to the call up to
the super `MultiProfilePagerAdapter.rebuild{Active,Inactive}Tab()`,
"outside" of the tracing that starts in those methods; now the
subclass trace section is moved "inside," to `rebuildTab()`, where
the superclass tracing has already started. IMO this distinction
should be negligible.

It's hard to test this kind of "structure-only" change in isolation,
especially when we expect more upcoming changes to redefine the APIs
that we're taking care to preserve here (namely via other anticipated
changes from ag/25335069, if nothing else in the "v2 restructuring").
For the sake of being thorough I did confirm that we have *some*
meaningful test coverage that exercises this rebuild flow, as I was
able to induce test failures (in `IntentResolver-tests-activity`) by
by deliberately omitting the superclass call in the override
`ChooserMultiProfilePagerAdapter.rebuildTab()`. Otherwise, I believe
the equivalence should be clear from code-reading.

Bug: 310211468
Test: `IntentResolver-tests-{unit,activity,integration}`. See note ^
Change-Id: I938984e5f2fade24d1f4c58cf0d99e60e4932e3d