2018-11-21 14:12:00 -08:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) 2018 The Android Open Source Project
|
|
|
|
|
*
|
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
|
*
|
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
*
|
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
|
* limitations under the License.
|
|
|
|
|
*/
|
|
|
|
|
package com.android.launcher3.graphics;
|
|
|
|
|
|
|
|
|
|
import static android.view.View.MeasureSpec.EXACTLY;
|
|
|
|
|
import static android.view.View.MeasureSpec.makeMeasureSpec;
|
|
|
|
|
import static android.view.View.VISIBLE;
|
|
|
|
|
|
2019-11-29 21:47:29 -08:00
|
|
|
import static com.android.launcher3.config.FeatureFlags.ENABLE_LAUNCHER_PREVIEW_IN_GRID_PICKER;
|
|
|
|
|
import static com.android.launcher3.model.ModelUtils.filterCurrentWorkspaceItems;
|
2020-05-28 00:59:44 -07:00
|
|
|
import static com.android.launcher3.model.ModelUtils.getMissingHotseatRanks;
|
2019-11-29 21:47:29 -08:00
|
|
|
import static com.android.launcher3.model.ModelUtils.sortWorkspaceItemsSpatially;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import static com.android.launcher3.util.Executors.MODEL_EXECUTOR;
|
2019-11-29 21:47:29 -08:00
|
|
|
|
2018-11-21 14:12:00 -08:00
|
|
|
import android.annotation.TargetApi;
|
|
|
|
|
import android.app.Fragment;
|
2020-02-18 11:52:53 -08:00
|
|
|
import android.appwidget.AppWidgetHostView;
|
2018-11-21 14:12:00 -08:00
|
|
|
import android.content.Context;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import android.content.ContextWrapper;
|
2018-11-21 14:12:00 -08:00
|
|
|
import android.content.Intent;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import android.content.pm.ShortcutInfo;
|
2018-11-21 14:12:00 -08:00
|
|
|
import android.content.res.TypedArray;
|
|
|
|
|
import android.graphics.Color;
|
|
|
|
|
import android.graphics.Rect;
|
|
|
|
|
import android.graphics.drawable.AdaptiveIconDrawable;
|
|
|
|
|
import android.graphics.drawable.ColorDrawable;
|
|
|
|
|
import android.os.Build;
|
|
|
|
|
import android.os.Handler;
|
|
|
|
|
import android.os.Looper;
|
|
|
|
|
import android.os.Process;
|
|
|
|
|
import android.util.AttributeSet;
|
|
|
|
|
import android.util.Log;
|
|
|
|
|
import android.view.ContextThemeWrapper;
|
|
|
|
|
import android.view.LayoutInflater;
|
|
|
|
|
import android.view.View;
|
|
|
|
|
import android.view.ViewGroup;
|
|
|
|
|
import android.widget.TextClock;
|
|
|
|
|
|
|
|
|
|
import com.android.launcher3.BubbleTextView;
|
|
|
|
|
import com.android.launcher3.CellLayout;
|
|
|
|
|
import com.android.launcher3.DeviceProfile;
|
|
|
|
|
import com.android.launcher3.Hotseat;
|
|
|
|
|
import com.android.launcher3.InsettableFrameLayout;
|
|
|
|
|
import com.android.launcher3.InvariantDeviceProfile;
|
2019-11-29 21:47:29 -08:00
|
|
|
import com.android.launcher3.LauncherAppState;
|
|
|
|
|
import com.android.launcher3.LauncherModel;
|
|
|
|
|
import com.android.launcher3.LauncherSettings;
|
2018-11-21 14:12:00 -08:00
|
|
|
import com.android.launcher3.LauncherSettings.Favorites;
|
|
|
|
|
import com.android.launcher3.R;
|
|
|
|
|
import com.android.launcher3.WorkspaceLayoutManager;
|
|
|
|
|
import com.android.launcher3.allapps.SearchUiManager;
|
|
|
|
|
import com.android.launcher3.config.FeatureFlags;
|
2019-12-09 13:42:57 -08:00
|
|
|
import com.android.launcher3.folder.FolderIcon;
|
2018-11-21 14:12:00 -08:00
|
|
|
import com.android.launcher3.icons.BaseIconFactory;
|
|
|
|
|
import com.android.launcher3.icons.BitmapInfo;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import com.android.launcher3.icons.LauncherIcons;
|
2019-11-29 21:47:29 -08:00
|
|
|
import com.android.launcher3.model.AllAppsList;
|
|
|
|
|
import com.android.launcher3.model.BgDataModel;
|
2020-01-05 15:35:29 +05:30
|
|
|
import com.android.launcher3.model.BgDataModel.Callbacks;
|
2019-11-29 21:47:29 -08:00
|
|
|
import com.android.launcher3.model.LoaderResults;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import com.android.launcher3.model.LoaderTask;
|
2020-02-18 11:52:53 -08:00
|
|
|
import com.android.launcher3.model.WidgetItem;
|
|
|
|
|
import com.android.launcher3.model.WidgetsModel;
|
2020-05-28 00:59:44 -07:00
|
|
|
import com.android.launcher3.model.data.AppInfo;
|
2020-04-06 15:11:17 -07:00
|
|
|
import com.android.launcher3.model.data.FolderInfo;
|
|
|
|
|
import com.android.launcher3.model.data.ItemInfo;
|
|
|
|
|
import com.android.launcher3.model.data.LauncherAppWidgetInfo;
|
|
|
|
|
import com.android.launcher3.model.data.WorkspaceItemInfo;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import com.android.launcher3.pm.InstallSessionHelper;
|
|
|
|
|
import com.android.launcher3.pm.UserCache;
|
2020-05-28 00:59:44 -07:00
|
|
|
import com.android.launcher3.uioverrides.PredictedAppIconInflater;
|
2020-02-24 13:50:29 -08:00
|
|
|
import com.android.launcher3.uioverrides.plugins.PluginManagerWrapper;
|
2020-05-28 00:59:44 -07:00
|
|
|
import com.android.launcher3.util.IntArray;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import com.android.launcher3.util.MainThreadInitializedObject;
|
2018-11-21 14:12:00 -08:00
|
|
|
import com.android.launcher3.views.ActivityContext;
|
|
|
|
|
import com.android.launcher3.views.BaseDragLayer;
|
2020-02-24 13:50:29 -08:00
|
|
|
import com.android.launcher3.widget.custom.CustomWidgetManager;
|
2018-11-21 14:12:00 -08:00
|
|
|
|
2019-11-29 21:47:29 -08:00
|
|
|
import java.util.ArrayList;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import java.util.Arrays;
|
|
|
|
|
import java.util.HashMap;
|
|
|
|
|
import java.util.HashSet;
|
|
|
|
|
import java.util.List;
|
|
|
|
|
import java.util.Map;
|
|
|
|
|
import java.util.Set;
|
2019-01-09 17:29:49 -08:00
|
|
|
import java.util.concurrent.Callable;
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
import java.util.concurrent.ConcurrentLinkedQueue;
|
2019-11-29 21:47:29 -08:00
|
|
|
import java.util.concurrent.ExecutionException;
|
|
|
|
|
import java.util.concurrent.Executor;
|
|
|
|
|
import java.util.concurrent.FutureTask;
|
|
|
|
|
import java.util.concurrent.TimeUnit;
|
|
|
|
|
import java.util.concurrent.TimeoutException;
|
2018-11-21 14:12:00 -08:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Utility class for generating the preview of Launcher for a given InvariantDeviceProfile.
|
|
|
|
|
* Steps:
|
|
|
|
|
* 1) Create a dummy icon info with just white icon
|
|
|
|
|
* 2) Inflate a strip down layout definition for Launcher
|
|
|
|
|
* 3) Place appropriate elements like icons and first-page qsb
|
|
|
|
|
* 4) Measure and draw the view on a canvas
|
|
|
|
|
*/
|
|
|
|
|
@TargetApi(Build.VERSION_CODES.O)
|
2020-06-24 12:48:11 -07:00
|
|
|
public class LauncherPreviewRenderer {
|
2018-11-21 14:12:00 -08:00
|
|
|
|
|
|
|
|
private static final String TAG = "LauncherPreviewRenderer";
|
|
|
|
|
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
/**
|
|
|
|
|
* Context used just for preview. It also provides a few objects (e.g. UserCache) just for
|
|
|
|
|
* preview purposes.
|
|
|
|
|
*/
|
|
|
|
|
public static class PreviewContext extends ContextWrapper {
|
|
|
|
|
|
|
|
|
|
private static final Set<MainThreadInitializedObject> WHITELIST = new HashSet<>(
|
|
|
|
|
Arrays.asList(UserCache.INSTANCE, InstallSessionHelper.INSTANCE,
|
2020-02-24 13:50:29 -08:00
|
|
|
LauncherAppState.INSTANCE, InvariantDeviceProfile.INSTANCE,
|
|
|
|
|
CustomWidgetManager.INSTANCE, PluginManagerWrapper.INSTANCE));
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
|
|
|
|
|
private final InvariantDeviceProfile mIdp;
|
|
|
|
|
private final Map<MainThreadInitializedObject, Object> mObjectMap = new HashMap<>();
|
|
|
|
|
private final ConcurrentLinkedQueue<LauncherIconsForPreview> mIconPool =
|
|
|
|
|
new ConcurrentLinkedQueue<>();
|
|
|
|
|
|
|
|
|
|
public PreviewContext(Context base, InvariantDeviceProfile idp) {
|
|
|
|
|
super(base);
|
|
|
|
|
mIdp = idp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public Context getApplicationContext() {
|
|
|
|
|
return this;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-24 13:50:29 -08:00
|
|
|
public void onDestroy() {
|
|
|
|
|
CustomWidgetManager customWidgetManager = (CustomWidgetManager) mObjectMap.get(
|
|
|
|
|
CustomWidgetManager.INSTANCE);
|
|
|
|
|
if (customWidgetManager != null) {
|
|
|
|
|
customWidgetManager.onDestroy();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
/**
|
|
|
|
|
* Find a cached object from mObjectMap if we have already created one. If not, generate
|
|
|
|
|
* an object using the provider.
|
|
|
|
|
*/
|
|
|
|
|
public <T> T getObject(MainThreadInitializedObject<T> mainThreadInitializedObject,
|
|
|
|
|
MainThreadInitializedObject.ObjectProvider<T> provider) {
|
|
|
|
|
if (!WHITELIST.contains(mainThreadInitializedObject)) {
|
|
|
|
|
throw new IllegalStateException("Leaking unknown objects");
|
|
|
|
|
}
|
|
|
|
|
if (mainThreadInitializedObject == LauncherAppState.INSTANCE) {
|
|
|
|
|
throw new IllegalStateException(
|
|
|
|
|
"Should not use MainThreadInitializedObject to initialize this with "
|
|
|
|
|
+ "PreviewContext");
|
|
|
|
|
}
|
|
|
|
|
if (mainThreadInitializedObject == InvariantDeviceProfile.INSTANCE) {
|
|
|
|
|
return (T) mIdp;
|
|
|
|
|
}
|
|
|
|
|
if (mObjectMap.containsKey(mainThreadInitializedObject)) {
|
|
|
|
|
return (T) mObjectMap.get(mainThreadInitializedObject);
|
|
|
|
|
}
|
|
|
|
|
T t = provider.get(this);
|
|
|
|
|
mObjectMap.put(mainThreadInitializedObject, t);
|
|
|
|
|
return t;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public LauncherIcons newLauncherIcons(Context context, boolean shapeDetection) {
|
|
|
|
|
LauncherIconsForPreview launcherIconsForPreview = mIconPool.poll();
|
|
|
|
|
if (launcherIconsForPreview != null) {
|
|
|
|
|
return launcherIconsForPreview;
|
|
|
|
|
}
|
|
|
|
|
return new LauncherIconsForPreview(context, mIdp.fillResIconDpi, mIdp.iconBitmapSize,
|
|
|
|
|
-1 /* poolId */, shapeDetection);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private final class LauncherIconsForPreview extends LauncherIcons {
|
|
|
|
|
|
|
|
|
|
private LauncherIconsForPreview(Context context, int fillResIconDpi, int iconBitmapSize,
|
|
|
|
|
int poolId, boolean shapeDetection) {
|
|
|
|
|
super(context, fillResIconDpi, iconBitmapSize, poolId, shapeDetection);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public void recycle() {
|
|
|
|
|
// Clear any temporary state variables
|
|
|
|
|
clear();
|
|
|
|
|
mIconPool.offer(this);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-21 14:12:00 -08:00
|
|
|
private final Handler mUiHandler;
|
|
|
|
|
private final Context mContext;
|
|
|
|
|
private final InvariantDeviceProfile mIdp;
|
|
|
|
|
private final DeviceProfile mDp;
|
2020-06-24 12:48:11 -07:00
|
|
|
private final boolean mMigrated;
|
2018-11-21 14:12:00 -08:00
|
|
|
private final Rect mInsets;
|
|
|
|
|
|
2019-03-27 16:03:06 -07:00
|
|
|
private final WorkspaceItemInfo mWorkspaceItemInfo;
|
2018-11-21 14:12:00 -08:00
|
|
|
|
2020-06-24 12:48:11 -07:00
|
|
|
public LauncherPreviewRenderer(Context context, InvariantDeviceProfile idp, boolean migrated) {
|
2018-11-21 14:12:00 -08:00
|
|
|
mUiHandler = new Handler(Looper.getMainLooper());
|
|
|
|
|
mContext = context;
|
|
|
|
|
mIdp = idp;
|
|
|
|
|
mDp = idp.portraitProfile.copy(context);
|
2020-06-24 12:48:11 -07:00
|
|
|
mMigrated = migrated;
|
2018-11-21 14:12:00 -08:00
|
|
|
|
|
|
|
|
// TODO: get correct insets once display cutout API is available.
|
|
|
|
|
mInsets = new Rect();
|
|
|
|
|
mInsets.left = mInsets.right = (mDp.widthPx - mDp.availableWidthPx) / 2;
|
|
|
|
|
mInsets.top = mInsets.bottom = (mDp.heightPx - mDp.availableHeightPx) / 2;
|
|
|
|
|
mDp.updateInsets(mInsets);
|
|
|
|
|
|
|
|
|
|
BaseIconFactory iconFactory =
|
|
|
|
|
new BaseIconFactory(context, mIdp.fillResIconDpi, mIdp.iconBitmapSize) { };
|
|
|
|
|
BitmapInfo iconInfo = iconFactory.createBadgedIconBitmap(new AdaptiveIconDrawable(
|
|
|
|
|
new ColorDrawable(Color.WHITE), new ColorDrawable(Color.WHITE)),
|
|
|
|
|
Process.myUserHandle(),
|
|
|
|
|
Build.VERSION.SDK_INT);
|
|
|
|
|
|
2019-03-27 16:03:06 -07:00
|
|
|
mWorkspaceItemInfo = new WorkspaceItemInfo();
|
2019-10-25 13:41:28 -07:00
|
|
|
mWorkspaceItemInfo.bitmap = iconInfo;
|
2019-03-27 16:03:06 -07:00
|
|
|
mWorkspaceItemInfo.intent = new Intent();
|
|
|
|
|
mWorkspaceItemInfo.contentDescription = mWorkspaceItemInfo.title =
|
2018-11-21 14:12:00 -08:00
|
|
|
context.getString(R.string.label_application);
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-06 16:22:50 -08:00
|
|
|
/** Populate preview and render it. */
|
|
|
|
|
public View getRenderedView() {
|
|
|
|
|
MainThreadRenderer renderer = new MainThreadRenderer(mContext);
|
|
|
|
|
renderer.populate();
|
|
|
|
|
return renderer.mRootView;
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-21 14:12:00 -08:00
|
|
|
private class MainThreadRenderer extends ContextThemeWrapper
|
|
|
|
|
implements ActivityContext, WorkspaceLayoutManager, LayoutInflater.Factory2 {
|
|
|
|
|
|
|
|
|
|
private final LayoutInflater mHomeElementInflater;
|
|
|
|
|
private final InsettableFrameLayout mRootView;
|
|
|
|
|
|
|
|
|
|
private final Hotseat mHotseat;
|
|
|
|
|
private final CellLayout mWorkspace;
|
|
|
|
|
|
|
|
|
|
MainThreadRenderer(Context context) {
|
|
|
|
|
super(context, R.style.AppTheme);
|
|
|
|
|
|
|
|
|
|
mHomeElementInflater = LayoutInflater.from(
|
|
|
|
|
new ContextThemeWrapper(this, R.style.HomeScreenElementTheme));
|
|
|
|
|
mHomeElementInflater.setFactory2(this);
|
|
|
|
|
|
|
|
|
|
mRootView = (InsettableFrameLayout) mHomeElementInflater.inflate(
|
|
|
|
|
R.layout.launcher_preview_layout, null, false);
|
|
|
|
|
mRootView.setInsets(mInsets);
|
|
|
|
|
measureView(mRootView, mDp.widthPx, mDp.heightPx);
|
|
|
|
|
|
|
|
|
|
mHotseat = mRootView.findViewById(R.id.hotseat);
|
|
|
|
|
mHotseat.resetLayout(false);
|
|
|
|
|
|
|
|
|
|
mWorkspace = mRootView.findViewById(R.id.workspace);
|
|
|
|
|
mWorkspace.setPadding(mDp.workspacePadding.left + mDp.cellLayoutPaddingLeftRightPx,
|
|
|
|
|
mDp.workspacePadding.top,
|
|
|
|
|
mDp.workspacePadding.right + mDp.cellLayoutPaddingLeftRightPx,
|
|
|
|
|
mDp.workspacePadding.bottom);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public View onCreateView(View parent, String name, Context context, AttributeSet attrs) {
|
|
|
|
|
if ("TextClock".equals(name)) {
|
|
|
|
|
// Workaround for TextClock accessing handler for unregistering ticker.
|
|
|
|
|
return new TextClock(context, attrs) {
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public Handler getHandler() {
|
|
|
|
|
return mUiHandler;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
} else if (!"fragment".equals(name)) {
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
TypedArray ta = context.obtainStyledAttributes(attrs, R.styleable.PreviewFragment);
|
|
|
|
|
FragmentWithPreview f = (FragmentWithPreview) Fragment.instantiate(
|
|
|
|
|
context, ta.getString(R.styleable.PreviewFragment_android_name));
|
|
|
|
|
f.enterPreviewMode(context);
|
|
|
|
|
f.onInit(null);
|
|
|
|
|
|
|
|
|
|
View view = f.onCreateView(LayoutInflater.from(context), (ViewGroup) parent, null);
|
|
|
|
|
view.setId(ta.getInt(R.styleable.PreviewFragment_android_id, View.NO_ID));
|
|
|
|
|
return view;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public View onCreateView(String name, Context context, AttributeSet attrs) {
|
|
|
|
|
return onCreateView(null, name, context, attrs);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public BaseDragLayer getDragLayer() {
|
|
|
|
|
throw new UnsupportedOperationException();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public DeviceProfile getDeviceProfile() {
|
|
|
|
|
return mDp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public Hotseat getHotseat() {
|
|
|
|
|
return mHotseat;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public CellLayout getScreenWithId(int screenId) {
|
|
|
|
|
return mWorkspace;
|
|
|
|
|
}
|
|
|
|
|
|
2019-03-27 16:03:06 -07:00
|
|
|
private void inflateAndAddIcon(WorkspaceItemInfo info) {
|
2018-11-21 14:12:00 -08:00
|
|
|
BubbleTextView icon = (BubbleTextView) mHomeElementInflater.inflate(
|
|
|
|
|
R.layout.app_icon, mWorkspace, false);
|
2019-03-27 16:03:06 -07:00
|
|
|
icon.applyFromWorkspaceItem(info);
|
2018-11-21 14:12:00 -08:00
|
|
|
addInScreenFromBind(icon, info);
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-09 13:42:57 -08:00
|
|
|
private void inflateAndAddFolder(FolderInfo info) {
|
|
|
|
|
FolderIcon folderIcon = FolderIcon.inflateIcon(R.layout.folder_icon, this, mWorkspace,
|
|
|
|
|
info);
|
|
|
|
|
addInScreenFromBind(folderIcon, info);
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-18 11:52:53 -08:00
|
|
|
private void inflateAndAddWidgets(LauncherAppWidgetInfo info, WidgetsModel widgetsModel) {
|
|
|
|
|
WidgetItem widgetItem = widgetsModel.getWidgetProviderInfoByProviderName(
|
|
|
|
|
info.providerName);
|
2020-02-24 13:50:29 -08:00
|
|
|
if (widgetItem == null) {
|
|
|
|
|
return;
|
|
|
|
|
}
|
2020-02-18 11:52:53 -08:00
|
|
|
AppWidgetHostView view = new AppWidgetHostView(mContext);
|
|
|
|
|
view.setAppWidget(-1, widgetItem.widgetInfo);
|
|
|
|
|
view.updateAppWidget(null);
|
|
|
|
|
view.setTag(info);
|
|
|
|
|
addInScreenFromBind(view, info);
|
|
|
|
|
}
|
|
|
|
|
|
2020-05-28 00:59:44 -07:00
|
|
|
private void inflateAndAddPredictedIcon(WorkspaceItemInfo info) {
|
|
|
|
|
View view = PredictedAppIconInflater.inflate(mHomeElementInflater, mWorkspace, info);
|
|
|
|
|
if (view != null) {
|
|
|
|
|
addInScreenFromBind(view, info);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-21 14:12:00 -08:00
|
|
|
private void dispatchVisibilityAggregated(View view, boolean isVisible) {
|
|
|
|
|
// Similar to View.dispatchVisibilityAggregated implementation.
|
|
|
|
|
final boolean thisVisible = view.getVisibility() == VISIBLE;
|
|
|
|
|
if (thisVisible || !isVisible) {
|
|
|
|
|
view.onVisibilityAggregated(isVisible);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (view instanceof ViewGroup) {
|
|
|
|
|
isVisible = thisVisible && isVisible;
|
|
|
|
|
ViewGroup vg = (ViewGroup) view;
|
|
|
|
|
int count = vg.getChildCount();
|
|
|
|
|
|
|
|
|
|
for (int i = 0; i < count; i++) {
|
|
|
|
|
dispatchVisibilityAggregated(vg.getChildAt(i), isVisible);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-06 16:22:50 -08:00
|
|
|
private void populate() {
|
2019-11-29 21:47:29 -08:00
|
|
|
if (ENABLE_LAUNCHER_PREVIEW_IN_GRID_PICKER.get()) {
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
WorkspaceFetcher fetcher;
|
2020-02-24 13:50:29 -08:00
|
|
|
PreviewContext previewContext = null;
|
2020-06-24 12:48:11 -07:00
|
|
|
if (mMigrated) {
|
2020-02-24 13:50:29 -08:00
|
|
|
previewContext = new PreviewContext(mContext, mIdp);
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
LauncherAppState appForPreview = new LauncherAppState(
|
2020-02-24 13:50:29 -08:00
|
|
|
previewContext, null /* iconCacheFileName */);
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
fetcher = new WorkspaceItemsInfoFromPreviewFetcher(appForPreview);
|
|
|
|
|
MODEL_EXECUTOR.execute(fetcher);
|
|
|
|
|
} else {
|
|
|
|
|
fetcher = new WorkspaceItemsInfoFetcher();
|
|
|
|
|
LauncherAppState.getInstance(mContext).getModel().enqueueModelUpdateTask(
|
|
|
|
|
(LauncherModel.ModelUpdateTask) fetcher);
|
|
|
|
|
}
|
|
|
|
|
WorkspaceResult workspaceResult = fetcher.get();
|
2020-02-24 13:50:29 -08:00
|
|
|
if (previewContext != null) {
|
|
|
|
|
previewContext.onDestroy();
|
|
|
|
|
}
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
|
|
|
|
|
if (workspaceResult == null) {
|
2019-11-29 21:47:29 -08:00
|
|
|
return;
|
|
|
|
|
}
|
2018-11-21 14:12:00 -08:00
|
|
|
|
2019-11-29 21:47:29 -08:00
|
|
|
// Separate the items that are on the current screen, and all the other remaining
|
|
|
|
|
// items
|
|
|
|
|
ArrayList<ItemInfo> currentWorkspaceItems = new ArrayList<>();
|
|
|
|
|
ArrayList<ItemInfo> otherWorkspaceItems = new ArrayList<>();
|
2020-02-18 11:52:53 -08:00
|
|
|
ArrayList<LauncherAppWidgetInfo> currentAppWidgets = new ArrayList<>();
|
|
|
|
|
ArrayList<LauncherAppWidgetInfo> otherAppWidgets = new ArrayList<>();
|
|
|
|
|
|
|
|
|
|
filterCurrentWorkspaceItems(0 /* currentScreenId */,
|
|
|
|
|
workspaceResult.mWorkspaceItems, currentWorkspaceItems,
|
|
|
|
|
otherWorkspaceItems);
|
|
|
|
|
filterCurrentWorkspaceItems(0 /* currentScreenId */, workspaceResult.mAppWidgets,
|
|
|
|
|
currentAppWidgets, otherAppWidgets);
|
2019-11-29 21:47:29 -08:00
|
|
|
sortWorkspaceItemsSpatially(mIdp, currentWorkspaceItems);
|
|
|
|
|
|
|
|
|
|
for (ItemInfo itemInfo : currentWorkspaceItems) {
|
|
|
|
|
switch (itemInfo.itemType) {
|
|
|
|
|
case Favorites.ITEM_TYPE_APPLICATION:
|
|
|
|
|
case Favorites.ITEM_TYPE_SHORTCUT:
|
|
|
|
|
case Favorites.ITEM_TYPE_DEEP_SHORTCUT:
|
|
|
|
|
inflateAndAddIcon((WorkspaceItemInfo) itemInfo);
|
|
|
|
|
break;
|
|
|
|
|
case LauncherSettings.Favorites.ITEM_TYPE_FOLDER:
|
2019-12-09 13:42:57 -08:00
|
|
|
inflateAndAddFolder((FolderInfo) itemInfo);
|
2019-11-29 21:47:29 -08:00
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-02-18 11:52:53 -08:00
|
|
|
for (ItemInfo itemInfo : currentAppWidgets) {
|
|
|
|
|
switch (itemInfo.itemType) {
|
|
|
|
|
case Favorites.ITEM_TYPE_APPWIDGET:
|
|
|
|
|
case Favorites.ITEM_TYPE_CUSTOM_APPWIDGET:
|
|
|
|
|
inflateAndAddWidgets((LauncherAppWidgetInfo) itemInfo,
|
|
|
|
|
workspaceResult.mWidgetsModel);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-05-28 00:59:44 -07:00
|
|
|
|
|
|
|
|
IntArray ranks = getMissingHotseatRanks(currentWorkspaceItems,
|
|
|
|
|
mIdp.numHotseatIcons);
|
|
|
|
|
int count = Math.min(ranks.size(), workspaceResult.mCachedPredictedItems.size());
|
|
|
|
|
for (int i = 0; i < count; i++) {
|
|
|
|
|
AppInfo appInfo = workspaceResult.mCachedPredictedItems.get(i);
|
|
|
|
|
int rank = ranks.get(i);
|
|
|
|
|
WorkspaceItemInfo itemInfo = new WorkspaceItemInfo(appInfo);
|
|
|
|
|
itemInfo.container = LauncherSettings.Favorites.CONTAINER_HOTSEAT_PREDICTION;
|
|
|
|
|
itemInfo.rank = rank;
|
|
|
|
|
itemInfo.cellX = mHotseat.getCellXFromOrder(rank);
|
|
|
|
|
itemInfo.cellY = mHotseat.getCellYFromOrder(rank);
|
|
|
|
|
itemInfo.screenId = rank;
|
|
|
|
|
inflateAndAddPredictedIcon(itemInfo);
|
|
|
|
|
}
|
2019-11-29 21:47:29 -08:00
|
|
|
} else {
|
|
|
|
|
// Add hotseat icons
|
|
|
|
|
for (int i = 0; i < mIdp.numHotseatIcons; i++) {
|
|
|
|
|
WorkspaceItemInfo info = new WorkspaceItemInfo(mWorkspaceItemInfo);
|
|
|
|
|
info.container = Favorites.CONTAINER_HOTSEAT;
|
|
|
|
|
info.screenId = i;
|
|
|
|
|
inflateAndAddIcon(info);
|
|
|
|
|
}
|
|
|
|
|
// Add workspace icons
|
|
|
|
|
for (int i = 0; i < mIdp.numColumns; i++) {
|
|
|
|
|
WorkspaceItemInfo info = new WorkspaceItemInfo(mWorkspaceItemInfo);
|
|
|
|
|
info.container = Favorites.CONTAINER_DESKTOP;
|
|
|
|
|
info.screenId = 0;
|
|
|
|
|
info.cellX = i;
|
|
|
|
|
info.cellY = mIdp.numRows - 1;
|
|
|
|
|
inflateAndAddIcon(info);
|
|
|
|
|
}
|
2018-11-21 14:12:00 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Add first page QSB
|
2019-03-15 09:00:05 -07:00
|
|
|
if (FeatureFlags.QSB_ON_FIRST_SCREEN) {
|
2018-11-21 14:12:00 -08:00
|
|
|
View qsb = mHomeElementInflater.inflate(
|
|
|
|
|
R.layout.search_container_workspace, mWorkspace, false);
|
|
|
|
|
CellLayout.LayoutParams lp =
|
|
|
|
|
new CellLayout.LayoutParams(0, 0, mWorkspace.getCountX(), 1);
|
|
|
|
|
lp.canReorder = false;
|
|
|
|
|
mWorkspace.addViewToCellLayout(qsb, 0, R.id.search_container_workspace, lp, true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Setup search view
|
|
|
|
|
SearchUiManager searchUiManager =
|
|
|
|
|
mRootView.findViewById(R.id.search_container_all_apps);
|
|
|
|
|
mRootView.findViewById(R.id.apps_view).setTranslationY(
|
|
|
|
|
mDp.heightPx - searchUiManager.getScrollRangeDelta(mInsets));
|
|
|
|
|
|
|
|
|
|
measureView(mRootView, mDp.widthPx, mDp.heightPx);
|
|
|
|
|
dispatchVisibilityAggregated(mRootView, true);
|
|
|
|
|
measureView(mRootView, mDp.widthPx, mDp.heightPx);
|
|
|
|
|
// Additional measure for views which use auto text size API
|
|
|
|
|
measureView(mRootView, mDp.widthPx, mDp.heightPx);
|
2020-03-06 16:22:50 -08:00
|
|
|
}
|
2018-11-21 14:12:00 -08:00
|
|
|
}
|
|
|
|
|
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
private static void measureView(View view, int width, int height) {
|
|
|
|
|
view.measure(makeMeasureSpec(width, EXACTLY), makeMeasureSpec(height, EXACTLY));
|
|
|
|
|
view.layout(0, 0, width, height);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private static class WorkspaceItemsInfoFetcher implements LauncherModel.ModelUpdateTask,
|
|
|
|
|
WorkspaceFetcher {
|
2019-11-29 21:47:29 -08:00
|
|
|
|
2020-02-18 11:52:53 -08:00
|
|
|
private final FutureTask<WorkspaceResult> mTask = new FutureTask<>(this);
|
2019-11-29 21:47:29 -08:00
|
|
|
|
|
|
|
|
private LauncherAppState mApp;
|
|
|
|
|
private LauncherModel mModel;
|
|
|
|
|
private BgDataModel mBgDataModel;
|
|
|
|
|
private AllAppsList mAllAppsList;
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public void init(LauncherAppState app, LauncherModel model, BgDataModel dataModel,
|
|
|
|
|
AllAppsList allAppsList, Executor uiExecutor) {
|
|
|
|
|
mApp = app;
|
|
|
|
|
mModel = model;
|
|
|
|
|
mBgDataModel = dataModel;
|
|
|
|
|
mAllAppsList = allAppsList;
|
|
|
|
|
}
|
|
|
|
|
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
@Override
|
|
|
|
|
public FutureTask<WorkspaceResult> getTask() {
|
|
|
|
|
return mTask;
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-29 21:47:29 -08:00
|
|
|
@Override
|
|
|
|
|
public void run() {
|
|
|
|
|
mTask.run();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
2020-02-18 11:52:53 -08:00
|
|
|
public WorkspaceResult call() throws Exception {
|
2019-11-29 21:47:29 -08:00
|
|
|
if (!mModel.isModelLoaded()) {
|
|
|
|
|
Log.d(TAG, "Workspace not loaded, loading now");
|
|
|
|
|
mModel.startLoaderForResults(
|
2020-01-05 15:35:29 +05:30
|
|
|
new LoaderResults(mApp, mBgDataModel, mAllAppsList, new Callbacks[0]));
|
2020-02-18 11:52:53 -08:00
|
|
|
return null;
|
2019-11-29 21:47:29 -08:00
|
|
|
}
|
2020-02-18 11:52:53 -08:00
|
|
|
|
|
|
|
|
return new WorkspaceResult(mBgDataModel.workspaceItems, mBgDataModel.appWidgets,
|
2020-05-28 00:59:44 -07:00
|
|
|
mBgDataModel.cachedPredictedItems, mBgDataModel.widgetsModel);
|
2019-11-29 21:47:29 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
private static class WorkspaceItemsInfoFromPreviewFetcher extends LoaderTask implements
|
|
|
|
|
WorkspaceFetcher {
|
|
|
|
|
|
|
|
|
|
private final FutureTask<WorkspaceResult> mTask = new FutureTask<>(this);
|
|
|
|
|
|
|
|
|
|
WorkspaceItemsInfoFromPreviewFetcher(LauncherAppState app) {
|
|
|
|
|
super(app, null, new BgDataModel(), null);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public FutureTask<WorkspaceResult> getTask() {
|
|
|
|
|
return mTask;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public void run() {
|
|
|
|
|
mTask.run();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
@Override
|
|
|
|
|
public WorkspaceResult call() throws Exception {
|
|
|
|
|
List<ShortcutInfo> allShortcuts = new ArrayList<>();
|
|
|
|
|
loadWorkspace(allShortcuts, LauncherSettings.Favorites.PREVIEW_CONTENT_URI);
|
2020-02-24 13:50:29 -08:00
|
|
|
mBgDataModel.widgetsModel.update(mApp, null);
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
return new WorkspaceResult(mBgDataModel.workspaceItems, mBgDataModel.appWidgets,
|
2020-05-28 00:59:44 -07:00
|
|
|
mBgDataModel.cachedPredictedItems, mBgDataModel.widgetsModel);
|
Render user's actual workspace in ThemePicker preview (Part 3)
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
2020-01-12 01:07:59 -08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private interface WorkspaceFetcher extends Runnable, Callable<WorkspaceResult> {
|
|
|
|
|
FutureTask<WorkspaceResult> getTask();
|
|
|
|
|
|
|
|
|
|
default WorkspaceResult get() {
|
|
|
|
|
try {
|
|
|
|
|
return getTask().get(5, TimeUnit.SECONDS);
|
|
|
|
|
} catch (InterruptedException | ExecutionException | TimeoutException e) {
|
|
|
|
|
Log.d(TAG, "Error fetching workspace items info", e);
|
|
|
|
|
return null;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-11-21 14:12:00 -08:00
|
|
|
}
|
2020-02-18 11:52:53 -08:00
|
|
|
|
|
|
|
|
private static class WorkspaceResult {
|
|
|
|
|
private final ArrayList<ItemInfo> mWorkspaceItems;
|
|
|
|
|
private final ArrayList<LauncherAppWidgetInfo> mAppWidgets;
|
2020-05-28 00:59:44 -07:00
|
|
|
private final ArrayList<AppInfo> mCachedPredictedItems;
|
2020-02-18 11:52:53 -08:00
|
|
|
private final WidgetsModel mWidgetsModel;
|
|
|
|
|
|
|
|
|
|
private WorkspaceResult(ArrayList<ItemInfo> workspaceItems,
|
2020-05-28 00:59:44 -07:00
|
|
|
ArrayList<LauncherAppWidgetInfo> appWidgets,
|
|
|
|
|
ArrayList<AppInfo> cachedPredictedItems, WidgetsModel widgetsModel) {
|
2020-02-18 11:52:53 -08:00
|
|
|
mWorkspaceItems = workspaceItems;
|
|
|
|
|
mAppWidgets = appWidgets;
|
2020-05-28 00:59:44 -07:00
|
|
|
mCachedPredictedItems = cachedPredictedItems;
|
2020-02-18 11:52:53 -08:00
|
|
|
mWidgetsModel = widgetsModel;
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-11-21 14:12:00 -08:00
|
|
|
}
|