Since the item hasn't yet been removed until the deferred drag
starts, adding it again will throw an exception (the view
already has a parent).
Bug: 30769920
Change-Id: Icb95aaa64e6e3c5dc105bbf3e54460b529d02033
- Instead of creating our own drag view within the container, and
handling logic to determine when to start a real drag, we start
the drag immediately and just defer onDragStart().
- To determine when the deferred drag should start, we add a
DeferDragCondition to DragOptions. The default DeferDragCondition
never defers a drag, but is overridden for apps with shortcuts
to defer until the icon is dragged a given distance.
- Because the drag is handled in DragController, including checking
when to start the deferred drag, DeepShortcutsContainer no longer
needs to handle touch events and ShortcutsContainerListener has
been removed.
This change has several immediate benefits:
- The code is much cleaner, because it allows touch handling to be
done by the DragController through the normal drag flow, without
recreating logic in ShortcutsContainerListener/DeepShortcutContainer.
- The janky second haptic feedback has been removed (now it vibrates
when you long press, like everywhere else, but not again when the
shortcuts close after dragging a distance).
- Drops are animated, instead of just popping the icon back into place.
Bug: 30769920
Bug: 30465972
Bug: 31533078
Change-Id: I679b412b72fbf6c3895d76963311eb5010c8e8db
> Removing logic to have multiple widgets in resize mode
> Making ResizeFrame a touch controller, so that it fits well with
other touch interaction in drag layer
> Chaning the method names in touch controller, so that it do not
overlaps with the default View methods
Change-Id: I85d4dbdfc82d078781adbce137dfaaea59c9c83d
Using center vertical alogn with a fixed height, overrides
the custom drawable padding and divides the available space
proportionally between padding and drawable padding
Change-Id: I4523543ab3007ef40eac69d878d2afbca13b483a
Now both AllAppsContainerView and WidgetsContainerView will be
dismissed when the background is clicked.
Bug: 27130340
Change-Id: Ie8446e4b8908742ddc8a227fe71ea56ec11c2457
(This change is in the onShortcutsChanged() callback.)
- Remove all workspace icons that correspond to shortcuts that
are now unpinned
- Remove all workspace icons that have the same package and
user handle as passed in onShortcutsChanged(), if they aren't
included in the list of shortcuts that is also passed.
These cases will happen for static and dynamic shortcuts,
respectively, when an app's data is cleared.
Bug: 30316501
Change-Id: I50db6567cb318d087012ab5d8208e765b81c6f99
Animate open:
- Stagger-fade shortcuts as they open
- Become fully opaque before fully open, at which point the
arrow animates in (scale). This way there is no overlap of
a translucent shortcut over an opaque arrow.
Animate close:
- Stagger-fade shortcuts as they close
- Delay fade until arrow animation is finished, to ensure
there is no overlapping of translucent and opaque.
This is much less visually jarring when quickly dragging
and dropping apps with shortcuts.
Bug: 31533078
Change-Id: I8673ee64e92414c718233ea89b70362187e53696
In ag/1460444 we used TransformingTouchDelegate to extend the
touch target for the widgets list. Now both WidgetsContainerView
and AllAppsContainerView will use the same TransformingTouchDelegate logic
to extend the touch target for their respective lists.
This is part of a larger refactor where in a follow up CL, we will
handle the logic for dismissing WCV and AACV when touching outside
of its content in BaseContainerView. (currently broken in WCV).
Change-Id: I7fddb456bba34a6533f8824da0481d308a8b715e
bug#1: if long press from page indicator region, you can pull up all apps
even though the workspace is in overview state.
bug#2: all apps should not intercept touch not only in overview mode
but also in any modal state.
Change-Id: I91c0a181f037f6c2465a983825da3a2da7e2920f
Regression occurred in ag/1315317.
In that change, Launcher#enterSpringLoadedDragMode() was moved from
the end of startDrag() to the end of onDragStart(). This changed the
sequence of events from:
beginDragShared() --> DragController#startDrag() --> onDragStart -->
dropTarget.onDragOver() --> Launcher#enterSpringLoadedDragMode()
to:
beginDragShared() --> DragController#startDrag() --> onDragStart -->
Launcher#enterSpringLoadedDragMode() --> onDragOver()
Basically, the key difference is that onDragOver() is called after
enterSpringLoadedDragMode(). This matters, because onDragOver()
returns early if Workspace#transitionStateShouldAllowDrop() returns
false, which it does during the spring loaded transition. This meant
that onDragOver() didn't update the layout to be Hotseat, and thus
the current workspace page was used as default, since that is what
was set in onDragEnter(). To fix it, I've copied the logic in
onDragOver() that checks to see if the drag is over the hotseat first
to a new method that onDragEnter() now calls as well.
Bug: 31245181
Change-Id: Ie758921b25fc96516a09c32bdc9706da941522df
Tony
Tony
Jonathan Miranda
Sunny Goyal
Hyunyoung Song
Bill Yi
TreeHugger Robot
Shankhoneer Chakrovarty