Closes #4

Added a boolean flag to allow non-allowed items to be dropped if at least one item in the dropping session was allowed Fixed a potential bug where files such as PDF would be categorized as DropDataType.pdf even if only DropDataType.file was allowed Fixed a bug where documents (.numbers) dropped from iCloud would not be accepted Refactor code to be more readable

Problem: It is possible to drop items that have not been allowed as long as one item in the drop session is allowed

Proposed solution: In the handle drop method, check the item if it conforms to an allowed type identifier or file extension. Code from the can drop method should be pulled into private functions so it can be reused (if possible).

I've run into the issue while testing that some filetypes can't be dropped from iCloud in the Files app, specifically apk. It works fine using Dropbox. This may not be limited to just apk files, I suspect its something related to iOS' Uniform Type Identifier system.

I'm not entirely sure of the reason, but theres two issues I've found related to iCloud. If DropDataType.file is enabled, apks cannot be dropped from iCloud unless "apk" is added to allowed file extensions. A second issue is that even when "apk" is added to the file extensions and it looks like it should accept, it does not load the file if dragged from iCloud.

In the first gif, you can see that the apk cannot be uploaded if it is on the iCloud drive, while it can if it is stored locally.

This second gif shows that other files work fine through iCloud

Add DropDataType.file to allow dropping any file Support restricting what types of DropDataType and file extensions can be dropped

NativeDropView(
  allowedDropDataTypes: const <DropDataType>[
    DropDataType.image,
  ],
  allowedDropFileExtensions: const <String>[
    'epub',
    'apk',
  ],
  ...

Dropping is allowed when the dropping session contains an item that conforms to one of the allowedDropDataTypes OR when the file extension is included in allowedDropFileExtensions

I see that you've made some commits since I started working which has caused some conflicts. Let me know if you need me to resolve them.

This issue will track android support's overall development. Individual features may get split into its own issue. Research on APIs and their implementation should also be posted here.

API

Android 7+

Android Drag and Drop API: https://developer.android.com/guide/topics/ui/drag-drop#DragPermissionsMultiWindow Multi-Window guide: https://developer.android.com/guide/topics/large-screens/multi-window-support Multi-Window/Multi-Instance: https://developer.samsung.com/galaxy-z/multi-window.html DropHelper (min API level 24), simplified drag and drop: https://developer.android.com/guide/topics/ui/drag-drop#drophelper_for_simplified_drag_and_drop

Galaxy Fold, Z Fold2, or Z Fold3: https://developer.samsung.com/codelab/galaxy-z/multi-window-drag-drop.html Emulator: https://developer.samsung.com/galaxy-z/testing.html

Surface Duo: https://docs.microsoft.com/en-us/dual-screen/android/sample-code/drag-drop?tabs=java Emulator: https://docs.microsoft.com/en-us/dual-screen/android/emulator/surface-duo-download Java SDK Examples: https://github.com/microsoft/surface-duo-sdk-samples App Examples: https://github.com/microsoft/surface-duo-app-samples

Permissions

The following permissions are required for drag and drop in different scenarios: (info from here)

For public files, to use the media library MediaProvier, permissions for reading and writing external storage are required.

The FileProvider is used to share private app data. Use the per-URI permission mechanism for authorization. The source app can set Intent.FLAG_GRANT_READ_URI_PERMISSION or Intent.FLAG_GRANT_WRITE_URI_PERMISSION to grant the read or write permission to the Intent data or the URI specified in ClipData.

Features

• [x] NativeDropView (Drop Items Into App)
• [ ] NativeDragView (Drag Items Outside App)
• [x] Allowed Data Types
• [x] Allowed File Extensions
• [x] Item Types
  • [x] text
  • [x] urls (Patterns.WEB_URL.matcher(url).matches())
  • [x] images
  • [x] videos
  • [x] audio
  • [x] pdfs
  • [x] files
• [x] Change parameters during runtime

Other possible features

• [ ] Callback to update UI according to result of drag events. This is all conceptual, implementation has not been decided yet but the idea is that the UI should be able to react to drag events.
  • [ ] ACTION_DRAG_STARTED: Drag started. Includes can/cannot accept, x/y location, and description of drag contents.
  • [ ] ACTION_DRAG_ENTERED: Drag entered NativeDropView's bounds. Includes can/cannot accept, and description of drag contents.
  • [ ] ACTION_DRAG_LOCATION: Drag is in NativeDropView's bounds and not in a child view that can accept. Includes x/y location.
  • [ ] ACTION_DRAG_EXITED: Drag moved out of NativeDropView's bounds or into a child view that can accept. Includes description of drag contents.
  • [ ] ACTION_DROP: Dragged contents dropped on NativeDropView and can accept and not in a child view that can accept the drop. Includes x/y location, and description of drag contents.
  • [ ] ACTION_DRAG_ENDED: Drag and drop session concluded. Includes if data was received and the x/y location of the drop in the view.
• [ ] DraggableText (Tap and hold to drag entire text)
• [ ] DraggableSelectableText (Tap and hold to select text, then tap and hold on selected text to drag)
• [ ] DraggableImage

This fixes a bug where some files, specifically apk, could not be dropped even when DropDataType.file was allowed. A workaround was to add that file's file extension, but now that is no longer needed.

This issue was discussed in #2