The widget picker design is currently not optimized for large screen form factor devices.
We resolve that by adding a two pane widget picker like that of the design in go/widget-picker-2023.
Bug: 256684299
Test: Make sure to be on a tablet in landscape mode.
1.Turn on flag LARGE_SCREEN_WIDGET_PICKER.
2. Press and hold on an empty spot in workspace until the popup menu appears.
3. Click widgets.
4. Notice the new two pane layout
Change-Id: Ia3ea17dc320f72f9bc5dea52399ff51d9161602b
> Updating the LayoutManager's scroll calculation instead of a separate
implementation to better support recyclerView's calculations
> Caching the view sizes during layout to avoid view-inflation for
unknown types
> Fixing scrollbar jump during scroll when widget list is expanded
> Fixing scrollbar never reaching end when onboarding card is displayed
in work tab
Bug: 240343082
Test: Verified on device that new views are not inflated
Change-Id: Ied11ccf65b053691c5c126c4bf8de306ec24786d
This was overriding the previously bound RecyclerView if multiple
were attached simultaneously. Instead, the appropriate container
(All Apps / Widgets) should bind the active RecyclerView whenever
it changes, with the onAttach serving as a fallback to ensure
the scrollbar has an initial RV to avoid NPEs.
Fix: 234591523
Bug: 235476489
Test: Manually checked All Apps from Launcher and Taskbar, as well
as Widget bottom sheet. Also ran relevant Tapl tests.
Change-Id: I06e27d2f66f9778087711a566817b6806ec7218b
Also using itemType instead of item object for widget size cache
Bug: 234008165
Test: Verified on device
Change-Id: Ia4b4a00a11627c0c454e4a699570e8ab1667a390
Bug: 206905515
Test: Manually verified b/230648542 did not resurface. Tested
on phone and tablet with and without work profile.
Change-Id: If724f635286b9dff2c64255f9ece3568a5cb4ea9
This reverts commit 6729f0b950.
Reason for revert: This change caused b/230648542.
Please see https://b.corp.google.com/issues/230648542#comment5 for the video after reverting this change.
Bug: 206905515
Bug: 230648542
Change-Id: I85f063c56cad137c05b810204244bba7e8f94ee7
This will help enable transitions between A-Z apps lists and
search results because both can be seen simultaneously and
manipulated independently.
Some high level items of the refactor:
- SearchRecyclerView is added; logic that populated the main
(personal) tab with search results was simply redirected to
this RV instead.
- BaseAllAppsContainerView added isSearching() method. Returns
false, and ActivityAllAppsContainerView overrides (as search
is handled there).
- Renamed BaseRecyclerView to FastScrollRecyclerView to better
describe what it does. SearchRecyclerView extends this, but
returns false for supportsFastScrolling().
- AlphabeticalAppsList#mAllAppsStore is now optional, so the
Search RV doesn't need to store/listen to apps. Note this
doesn't affect the predicted app row which is still updated
if one of the predicted apps is uninstalled (I tested this).
Future work:
- Determine why dispatchRestoreInstanceState is not called for
BaseAllAppsContainerView. Save is called, e.g. on rotation.
Effect of restore not called: rotating while searching goes
back to A-Z list.
- Keep suggested apps in Header while searching. Currently they
are rendered in the SearchRV above search results, as before.
- Potentially extract Personal/Work tabs to move independently of
header.
- AlphabeticalAppsList is a misleading name because it can also
contains search results. However, things are pretty intertwined
between that and BaseAllAppsAdapter (effectively a circular
dependency), so I figured cleaning all that up was out of the
immediate scope of this refactor, which is mainly meant to
unblock transition work.
Bug: 206905515
Test: Manually checked for regressions, ran tests.
Change-Id: I4d3757c8a8f9b774956ca6be541dd4fcdad1de13