| 558459fe85f56f29a6ed6a4d0adb4a0bd6665884 |
|
14-Oct-2011 |
Joe Fernandez <joefernandez@google.com> |
docs: add developer guide cross-references, Project ACRE, Round 2
Change-Id: I39a534ae3a2a34b4dabc333a09961012ef911d3e
/frameworks/base/core/java/android/view/DragEvent.java
|
| 32736f085b74c4dcc9da61212ccbd6fe2de193a7 |
|
20-Jan-2011 |
Joe Malin <jmalin@google.com> |
sdk doc change: Copy/Paste/Drag/Drop
Change-Id: Ifb9ed554ae1a72ce6badff1c79d95c02f30525e9
/frameworks/base/core/java/android/view/DragEvent.java
|
| 7fb8b565f9cd2ec6a63ff4d8a89f98f68a1a138c |
|
20-Jan-2011 |
Christopher Tate <ctate@google.com> |
Include the local state obj in ACTION_DRAG_STARTED events
Fixes bug 3362502
The underlying cause was that the DragEvent.obtain() variant which
clones an existing event was failing to copy the local state field.
This change also moves the logic for inserting the local state object
into DragEvents about to be dispatched from the Binder incall thread
into the main-thread code sequence. This is to eliminate any potential
SMP memory coherency issues around drag start vs incoming events
needing to refer to the local state object.
Change-Id: I368e8936dbf8a00b7d5cc19c2ef0101bd75b6b2d
/frameworks/base/core/java/android/view/DragEvent.java
|
| f01af7551b3cf8853d3a76412c2745a543063434 |
|
20-Jan-2011 |
Christopher Tate <ctate@google.com> |
Fail more gracefully when window state changes during drags
In particular, if a new window was created out from under the drag,
the drag-move event dispatch logic would wind up blithly assuming
that it would find a valid touch-dispatchable window under the
finger. When this was untrue, it would NPE, but the NPE was caught
and discarded safely by higher-level guard code.
With this change, we now avoid the NPE entirely and report the
spurious condition as part of the debugging log stream.
(Also add the local-state object to DragEvent.toString()'s output.)
Change-Id: Idfa5f45d049e48415ee59c8b0ffb5b0ed4098ce3
/frameworks/base/core/java/android/view/DragEvent.java
|
| 407b4e91fe7627545b8110e683953353236b4543 |
|
01-Dec-2010 |
Christopher Tate <ctate@google.com> |
API CHANGE: drags can now carry an originator-only object payload
When calling startDrag(), the app can now supply an Object to be passed
along in every DragEvent that the app winds up receiving itself. This
object is *not* passed to any other applications; it's strictly app-
local. The purpose is to allow state tracking/management to be done
directly through the drag mechanism rather than requiring out-of-band
code.
An example of the utility here might be TextEdit widgets. A drag that
starts in one TextEdit but ends in a different one should be treated as
a copy/paste operation, where the originating TextEdit is not altered.
However, a drag that starts and ends in the *same* TextEdit is a 'move'
operation within that TextEdit; the text is removed from its original
position and inserted at the drop point. To support this easily, the
drag/drop code in TextEdit can now pass a pointer to the originating
view as the local state object. Then, the drop recipient could tell
whether the drag started within the same TextEdit without needing to
implement any other out-of-band state tracking.
This CL (and its accompanying CLs in a few other packages where the
startDrag() API is being used) adds the new local-state parameter to
the API, but does not actually change the behavior of any existing
clients.
Change-Id: Icba73b2ab4a650b7a94485a19633065b0ef9058c
/frameworks/base/core/java/android/view/DragEvent.java
|
| 855e4c98846a4264b7a27ad68cfa66c12ac0591c |
|
19-Nov-2010 |
Christopher Tate <ctate@google.com> |
Hide DragEvent pool implementation and add docs
Change-Id: Idaead8ab604c69d6dbc1bd5de3afa86e1fae8396
/frameworks/base/core/java/android/view/DragEvent.java
|
| d4533f1469990582e4a2dd0898429093fe2690c0 |
|
20-Oct-2010 |
Chris Tate <ctate@google.com> |
Report drag success/fail in the DRAG_ENDED message
DragEvent.getResult() returns 'true' if the drop was ultimately accepted;
false otherwise. The validity of this datum is only guaranteed when the
DragEvent's action verb is ACTION_DRAG_ENDED.
Also fixes the drag-start timeout handling (though the offending app is
not yet officially declared ANR).
Implements bug 3097807
Change-Id: I6908ac628c72ff7d6193d87060d769a559a78d0e
/frameworks/base/core/java/android/view/DragEvent.java
|
| c02c7af0ec88ec56089a11138d5fcfafcf891c58 |
|
21-Oct-2010 |
Chris Tate <ctate@google.com> |
Fix obtain() when the pool is still empty
Fixes bug 3116798
Change-Id: I187e79892cd2b60173ef4ebef5d2eab56eb5eb42
/frameworks/base/core/java/android/view/DragEvent.java
|
| 2c095f367779ef32130c72849936a2e3013c8492 |
|
04-Oct-2010 |
Christopher Tate <ctate@google.com> |
Refinements to drag/drop
Thumbnail measurement & drawing has been moved out into a delegate
class called View.DragThumbnailBuilder. This consolidates the
thumbnail-related code as well as ensuring that the drag initiator
does not have to know a priori where to place the thumbnail relative
to the touch point *before* the thumbnail measurement step, as was
previously the case.
startDrag() no longer needs to be told where the current touch point
is at the time the drag is launched.
Drag events are now dispatched only to VISIBLE views.
Dispatch shouldn't double-recycle events any more when the target
window is local to the system process.
Change-Id: I49419103765a0cad2e18ddfcdd6dacb94daf1ff1
/frameworks/base/core/java/android/view/DragEvent.java
|
| a53146c5569f8ff5f7eb55e9ad35d23ddacf2add |
|
07-Sep-2010 |
Christopher Tate <ctate@google.com> |
Drag/drop APIs and infrastructure
A View initiates a drag-and-drop operation (hereafter just called a "drag")
by calling its startDrag(ClipData) method. Within the processing of that
call, two callbacks are made into the originating View. The first is to
onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this
callback must respond by calling setDragThumbnailDimension(width, height) to
declare the size of the drag thumbnail image that should be used. Following
this, the View's onDrawDragThumbnail(canvas) method will be invoked to
actually produce the bits of the thumbnail image.
If all goes well, startDrag() will return 'true', and the drag is off and
running. (The other arguments to startDrag() provide reconciliation between
the current finger position and where the thumbnail should be placed on
the screen relative to it.)
Potential receipients of the ClipData behind the drag are notified by a
new dispatch mechanism, roughly parallel to motion event dispatch. The core
routine is the View's onDragEvent(event) callback, with the mechanics of
dispatch itself being routed through dispatchDragEvent(event) -- as in
the case of motion events, the dispatch logic is in ViewGroup, with leaf
View objects not needing to consider the dispatch flow.
Several different event 'actions' are delivered through this dispatch
mechanism:
ACTION_DRAG_STARTED: this event is propagated to every View in every window
(including windows created during the course of a drag). It serves as a
global notification that a drag has started with a payload whose matching
ClipDescription is supplied with the event. A View that is prepared to
consume the data described in this event should return 'true' from their
onDragEvent() method, and ideally will also make some visible on-screen
indication that they are a potential target of the drop.
ACTION_DRAG_ENTERED: this event is sent once when the drag point
enters the View's bounds. It is an opportunity for the View to set up
feedback that they are the one who will see the drop if the finger goes
up now.
ACTION_DRAG_LOCATION: when the drag point is over a given View, that
View will receive a stream of DRAG_LOCATION events, providing an
opportunity for the View to show visual feedback tied to the drag point.
ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point
leaves the View's bounds. The View should undo any visuals meant to
emphasize their being the hovered-over target.
ACTION_DROP: when the drag ends at a given point, the View under that
point is sent this event, with the full ClipData of the payload.
ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global
broadcast that the drag has ended and all Views should return to their
normal visual state. This happens after the DROP event.
Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
/frameworks/base/core/java/android/view/DragEvent.java
|