Widget is loaded only when the user enters the overview mode and we keep
the list updated as long as the user is in the overview mode. Once the user
leaves the overview mode, we stop responding to widget updates
Bug: 26077457
Change-Id: I9e4904b8f1300bfe0d77e2bc5f59aa6963fad8d1
There are 3 classes coordinating the gesture: PinchToOverviewListener,
PinchThresholdManager, and PinchAnimationManager.
- PTOL listens for the pinch gesture on DragLayer.
- When a pinch is detected, the PTOL keeps track of the interpolated
progress and passes it along to both the PTM and PAM.
- The PTM uses the progress to determine whether a new threshold has
been passed, and tells the PAM to animate it if so.
- The PAM uses the progress to animate things like workspace scale
throughout the pinch.
- If the pinch ends early, the PTOL uses the last passed threshold to
determine whether to animate to workspace or overview, and tells
PAM to perform the animation at the same velocity as the pinch.
Bug: 24414635
Change-Id: I9e53706c705f8b2982409bf7c223d8d0e9618bf0
-> Refactored the preview background rendering to be much more self-contained.
This cleans up a lot of code in the CellLayout, and keeps the logic in the
right place.
-> We switch to software rendering for performance and compatibility reasons.
-> Removed all assets.
-> FolderIcon accept animation includes animation of the clipped region.
-> 1:1 hand-off of drawing of the FolderIcon background between the FolderIcon
and the CellLayout. Unfortunately, CellLayout rendering is still required
to work around clipping issues (due to use of software layer). We also
need this to support folder creation feedback.
Change-Id: Ib8f7fa6359dfedff8145f38dd50ba03849ca0d51
> Sending unboundX to the overlay which is the total untranslated X and not just deltaX from last frame
> Handling overlay callback and translating workspace accordingly
Change-Id: I3bd8d9efac738e9ce131758f0e5ff1b9c1d6a8fc
-> Created com.android.launcher3.folder package to house most folder-related files
(aside from the FolderInfo) which is more related to the model than the UI.
Change-Id: I767063e1e4c775c01a799a3bede30cd94ac48ade
- No page indicators in spring-loaded mode
- Don’t move workspace up as high
- Scale workspace at 90% instead of 80% on phones
- Increase speed of workspace -> spring-loaded -> workspace
- Widgets were being scaled down twice when dragging from widget picker
- Don't scale up icons when dragging (scaling other stuff down is enough)
- Make scrim less dark and panels more transparent
- Thin white border around page instead of highlight when hovering
Change-Id: I963e91c20d4c0340480d165e0f3b8064783c0cb2
- Added side hints back
- Only scale down icons if spring-loaded
- Only show App Info drop target if spring-loaded
Change-Id: I4b0dddccbe0e80b7ceb6b7266fc527f757744148
Because going to overview mode scales down the workspace, it was
thinking the touch was moving even though your finger was still. If
the "movement" was large enough, it was treated as a scroll, causing
jank. This was especially prevalent on tablets due to their size.
Bug: 25779718
Change-Id: Idb7833e0087bd24ca840f6afc451bf221f6bc047
The problem was due to a race condition between removing a prebound
widget view from the drag layer and adding the same view to the
workspace upon dropping it; if you let go of the widget immediately
after picking it up, the latter happened before the former.
Specifically, the flow was: long-click a widget --> drop --> remove
the view from the drag layer if it's not null (it is, so nothing
happens) --> the view is finally bound/inflated and added to the drag
layer --> add the view to the workspace --> already has a parent.
There are actually 2 problems here: one is that the bind/inflate is
asynchronous, and can therefore happen after dropping the widget view
being inflated, and the other is that the view is added to the
workspace even though the transition has barely started (we usually
ignore drops if the transition is less than half complete). It turns
out that this second problem was also due to a race condition, this
time between dropping a widget or app onto the workspace and calling
LauncherStateTransitionAnimation.dispatchOnLauncherTransitionStart().
If the drop happened before the dispatch, as in the case of the
crash, then the drop was accepted because the transition progress was
still 1.0 from the previous transition.
I fixed the first problem by removing the drag layer widget view
in Launcher where it is potentially used instead of Workspace. And I
fixed the second problem by setting mTransitionProgress to 0 in
Workspace.onLauncherTransitionPrepare().
I also added some debugging logs.
Bug: 23896857
Change-Id: I66944e6d3f23b70dea15f7fb01af0763a1bfcbda
Using itemId instead of generating a new id for each item. This is because
if the process gets killed, View.generateId will get reset but we will still
receive the generated item id map in onRestoreInstance. This will cause
conflicts with newly generated item ids.
We wrap all the generated homescreen views inside a single sparse array. This
ensures that we do not cause any conflict with dynamically generated views in
other parts of the UI.
Bug: 16840760
Change-Id: I6fe69c2e1dd463402f51222715fae31b9d4dd240
Before, the resize frame was created as soon as a widget was dropped,
but this caused it to be in the wrong spot after the spring loaded
mode exited. Instead, we should wait until the workspace is back to
normal before creating the resize frame.
Bug: 24192073
Change-Id: I8d87febcc4ec7e3c44d50135184c3a837d7cd960
Sunny Goyal
Tony Wickham
Adam Cohen
Winson