Basically this removes the inner class MainThreadRenderer, which
was only created and used for its populate() method in the parent's
getRenderedView() method. All methods and members of that subclass
are merged into the parent LauncherPreviewRenderer class, and
getRenderedView() simply inlines the previous populate() code.
Other smaller changes:
- Extracted out shouldShowQsb() and shouldShowRealLauncherPreview()
- Disables search view and its children to prevent interaction
Change-Id: I7d0cce73efbe022c16661a0ad66eefe5cb285641
Predictions are loaded and managed by Launcher model and follow
the model lifecycle. They are then bound to the callback which
handles the UI
Bug: 160748731
Change-Id: I4a3ea0698d80fafe94afb4ce66ffa7f4a6a91c68
After breaking down the time we spend in rendering preview under a different grid setting, I found out that we spend a huge amount of time loading the workspace. It takes a long time in non preview case (launcher workspace init), so to optimize we should try to cut down things that are not necessary for preview. Widget model loading (widget and shortcut updates) takes half of the time, and can be optimized with minimal risks / code changes.
Bug: 160662425
Test: Manual
Change-Id: I89029d0ddf6e2517077a0ba3fbbcfdcd60b268d9
Also remove USE_SURFACE_VIEW_FOR_PREVIEW flag
Fixes: 159755324
Test: manual
Change-Id: I6517c34911e217a69063226b01e4583194902f9c
(cherry picked from commit 633a4bdf57)
The focus of ag/10346770 is around the actual algorithm, while in the meantime our preview logic has changed during the code review of ag/10100264.
GridSizeMigrationTaskV2 addresses both cases, the difference being preview passes in constructed IDP while actual migration uses IDP from the current Context.
When doing actual migration, we call METHOD_UPDATE_CURRENT_OPEN_HELPER to update the current db helper and copy the favorites table from the previous db into the current db in favorites_tmp table. Then we do migration from there.
When calculating preview, I added METHOD_PREP_FOR_PREVIEW in this change to copy the favorites table from the intended grid setting to the current grid setting in favorites_preview table. Then we calculate migration from the current favorites table to favorites_preview table and save into favorites_preview table.
Bug: 144052802
Fixes: 144052839
Test: Manual
Change-Id: I64a8b61a4e0bf8399c0ae1af4ef9d2bde0f1ee2f
Didn't test out widgets in Part 5. So in this change,
- Added some widget classes to the PreviewContext WHITELIST
- Manually update widget model after loading workspace since we do not attach widget listeners to the LauncherAppModel for preview.
Change-Id: I0a555b2319b2e91432dbd58289ddb66aca1384df
go/grid-migration-preview
With this change, we can see actual grid migration in wallpaper preview.
The approach here: we use a tmp table (favorites_preview) here specifically for this preview (to write off the migration results), and load from this tmp table workspace items if migration is necessary and successful. Otherwise, we load from the current workspace.
UPDATED: this change should be completely compatible with the new multi-db grid migration algorithm. Here is why
1. In LauncherPreviewRender#renderScreenShot, I added a check to decide which grid migration preview method we should call. Once v2 preview method is implemented, it should be integrated with other parts of this change perfectly (the reason will be mentioned below).
2. While we have multiple DBs, mOpenHelper in LauncherProvider always points to the current db we are using. Queries using CONTENT_URI is routed to whatever DB mOpenHelper points to, so it works perfectly to directly operate on CONTENT_URI even when we use multi-db underneath the hood.
3. With 1 and 2 mentioned, I believe in order for this preview change to support multi-db, we only need to implement the V2 grid migration algorithm. Because most of what we are doing in this change is wrapped in GridSizeMigrationTask, it's perfectly safeguarded.
Bug: 144052839
Change-Id: Ie6d6048d77326f96546c8a180a7cd8f15b47e4c4
This change takes care of rendering widgets using widget provider's layout info.
Test: manual
Bug: 144052839
Change-Id: I7002d8bf653513cdd317736d550a47f61f0ee474
With this change, we can also render folders in preview. It's built on top of part 1.
Test: Go to grid options, choose a different grid option, and see user's workspace rendered in the preview
Bug: 144052839
Change-Id: Iaf6d8af6b909ece4147ea250d95dec3d2c0019d3
This change takes care of icon rendering. Further work still needs to be done for folders and widgets.
Test: Go to grid options, choose a different grid option, and see user's workspace rendered in the preview
Bug: 144052839
Change-Id: I696153dec1d1f08c5ac82d0c75be5740325c0fc4
This will allow subclassing BitmapInfo to support custom icon/dynamic
icons which can be loaded on the background thread instead of going
through IconFactory which runs on UiThread
Change-Id: Ieced6e91330bdff1b505826d097a8df711dfe967
Creating a utility class which generates a launcher preview
for a provided InvariantDeviceProfile
Bug: 118758696
Change-Id: I0aebeb6eed37f72edd1cc305e58eece305aae3ff
