> Removing some special checks around accessibility drag
> Unifying folder alarm code path for accessible and normal DnD
> Maintaining mDragStartTime inside the dragDriver instead of the callers
> Simplifying some accessibility callbacks
Future cl will create a Accessibility DragDriver and unify it with
other DnD flow
Change-Id: I1919ef218de0174678110f271b450bcb9aaf4a5c
- Add methods to ModelWriter to prepareForUndoDelete, then
enqueueDeleteRunnable, followed by commitDelete or abortDelete.
- Add Snackbar floating view
- Show Undo snackbar when dropping or flinging to delete target; if the
undo action is clicked, we abort the delete, otherwise we commit it.
Bug: 24238108
Change-Id: I9997235e1f8525cbb8b1fa2338099609e7358426
On long pressing, the confirmation activity starts a system
drag-n-drop and focuses the launcher activity. We then drive
the launcher drag controller using the system drag event
Caveats:
> We use a transparent preview for system drag and drop and use
a view inside launcher for actual preview. This gives us better
control over various animations.
> The parameters for drag operation are passed to the Launcher
activity using the intent. Since onNewIntent and onDragEvent
come at different times and are not associated, a random uuid
is used as mime-type to match the drag event with intent params
> If the workspace is locked (eg, loader is running) the drag
operation is simply dropped. Will be imporved in follow up cls
Bug: 33584624
Change-Id: I0bb5b25b690f86b6af31a14e11beb669fcb3a281
> Moving all fling related logic to FlingToDeleteHelper from DragController
> Removing fling related methods from DragSource and DropTarget
> Moving fling animation logic from DeleteDropTarget to FlingAnimation
> Simplifying DropTargetBar to directly look for all valid drop targets.
This makes it easier to add new DropTarget in xml.
Change-Id: I7214d2d30c907ab93c80d92d9f9be6dda2d63354