commit c2f1d0cc70ef6083fd47e055a421fd74f620ea33
author Joshua Trask <joshtrask@google.com> Thu Oct 05 17:16:40 2023 +0000
committer Joshua Trask <joshtrask@google.com> Thu Oct 05 18:34:35 2023 +0000
tree 7fd772af3eaa95e2c561fc3405baab2d527d1c56
parent 989de76169699beee2c92a8ce41bc636896a66b6

"Bottom padding overrides" -> EmptyStateUiHelper

As part of ongoing work to pull low-level empty state responsibilities
out of the pager adapter, this CL generally replicates the change
prototyped in ag/24516421/4..5, in smaller incremental steps to "show
the work." As originally described in that CL:

  "... moves ownership/usage of the 'container bottom padding
override supplier' over to the UI helper; this PagerAdapter dependency
is really only used in empty-state logic, so it can be handed over to
the extracted component *instead of* retaining it as an ivar in the
PagerAdapter."

As presented in this CL, the "incremental steps" per-snapshot are:

 1. Move `getActiveEmptyStateView()` from `ChooserActivity` to
    `MultiProfilePagerAdapter`, and expose it in favor of the broader
    `getEmptyStateView()` method that `ChooserActivity` previously
    used to implement the lower-level logic.

 2. Remove `MultiProfilePagerAdapter.setupContainerPadding()`
    parameters since they're just derived from a combination of a
    single hard-coded (resource) symbol, and a concern that already
    belonged to the pager-adapter (`getActiveEmptyStateView()`).
    Switch tests to using one of our real layouts so that we can find
    an empty-state container with the expected View ID.

    Also update method visibility to show `setupContainerPadding()`
    isn't intended to be overridden in the more-modern "generic pager"
    design, and update Javadoc accordingly.

 3. Inline `ChooserMultiProfilePagerAdapter.setupContainerPadding()`
    as part of its `setEmptyStateBottomOffset()`, since the latter
    method is never called anywhere else (and both concerns already
    belonged to the specialized pager-adapter).

 4. Refactor the internal `setupContainerPadding()` to operate on
    profile descriptors instead of container Views. This is based on
    the observation that both callers of `setupContainerPadding()`
    were passing containers that they had to query from the
    descriptor's empty-state view anyways, and the lookup used the
    same View ID in both cases. This change encapsulates those shared
    concerns at a higher level of abstraction.

 5. Move the implementation logic of `setupContainerPadding()` into
    the descriptor inner-class; given the override-supplier, the rest
    of the operation can be implemented just using the info available
    to the descriptor.

 6. Move ownership of the override-supplier into the descriptor (to be
    shared among all descriptor instances). The outer pager-adapter
    had no remaining need to reference the supplier, and we can easily
    confirm that this results in `setupContainerPadding()` calls for
    each descriptor instance using the same supplier instance they
    would've used before.

 7. Moves implementation logic (including [shared] ownership of the
    override-supplier) from the descriptor down to the empty-state
    helper which now encapsulates the entire `setupContainerPadding()`
    operation with zero args.

    This may require *slightly* more of a leap-of-faith than the other
    "steps," but note the extensive test coverage: the existing
    `MultiProfilePagerAdapterTest` covers this exact functionality
    as integrated into a broader config; parallel unit tests are
    newly-added in `EmptyStateUiHelper`; and even our "broad-scope"
    integration tests exercise empty-state logic to _some_ degree.

 8. Inlines some client usages to simplify scaffolding that we don't
    really need after the earlier refactoring changes.

Bug: 302311217
Test: IntentResolverUnitTests
Change-Id: Icc460ede5b8a0314d5c807dd884e6e2b7044bee9