Commit Graph

2 Commits

Author SHA1 Message Date
Tracy Zhou
be13d109b7 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-02-21 15:49:00 -08:00
Tracy Zhou
7df93d28d4 Setup infrastructure (multi-db support) for the new grid migration algorithm
We'll have a db for each grid option and a db for back up / restore.

TODO(pinyaoting): support back up / restore using the new infrastructure, particularly calls to GridBackupTable should use different DBs when the feature flag (NEW_GRID_MIGRATION_ALGORITHM) is on.

Bug: 144052802
Test: N/A

Change-Id: I644a3e70148bd78204a747a337446a3c038f616f
2020-02-05 19:55:05 -08:00