| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Samples should compile with 1.5
Change-Id: I029ae9ded4237fd9d4d2d1dbf2c7c537afbbf36b
|
| |
|
|
|
|
|
| |
This is to show off and test the handling of views that become
visible after the primary ACTION_DRAG_STARTED broadcast happens.
Change-Id: I8bb575c2e055a9d60fc6ed8bc77457dec13a80b4
|
| |
|
|
|
|
|
|
|
| |
startDrag() that crosses application boundaries will remain @hide until we get
more of the surrounding behaviors nailed down.
Drag-and-drop demo updated to only show app-local drag operations pro tem.
Change-Id: I9cdcd132c1aae45bc472e70293b7187b4cba9bca
|
|
|
Drag/drop among four big dots on screen. Drags to a dot will have
the identity of the originating dot put into a text field below the dots.
In all cases, a text field to the right of the dots reports whether the
drag ended in a successful drop.
Attempting to start a drag from a dot reading "Drag ANR" should ANR and
be cleaned up properly.
Attempting to drop onto a dot reading "Drop ANR" should similarly ANR
and be cleaned up properly.
Drags from a dot labelled "Local" are restricted to targets within
the app's own window -- they are not draggable to the system "shirt
pocket" drop target, etc.
A drop onto the same dot that it originated from will append text to
that effect to the message that notes the dropped payload. This
uses the "local state" convenience mechanism in startDrag() and
DragEvent.getLocalState().
Change-Id: Ic5cd6a29186a84c91d3dc4187e83e7bcf530ba2f
|