Feature Request: File pickers on UIKit and Android

[Ravbug]

The new SDL FileDialog API is amazing. I would love to see file choosers on non-desktop platforms, because it would greatly assist users in importing and exporting save data from games, among other things.

UWP has the FileOpenPicker and FolderPicker documented here: https://learn.microsoft.com/en-us/windows/uwp/files/quickstart-using-file-and-folder-pickers. They give sample code in C# but the C++ equivalent is probably very similar. As far as I am aware, this is also supported on UWP for Xbox.

UIKit has the UIDocumentPickerViewController, documented here: https://developer.apple.com/documentation/uikit/uidocumentpickerviewcontroller. It's available on iOS and visionOS. You can choose folders by passing kUTTypeFolder into the documentTypes parameter of the UIDocumentPickerViewController constructor.

Android has ACTION_OPEN_DOCUMENT and ACTION_OPEN_DOCUMENT_TREE which prompt the system to display a DocumentsProvider and return the chosen items as content:/// URLs. It's documented here: https://developer.android.com/reference/android/content/Intent#ACTION_OPEN_DOCUMENT. It may require JNI interop to invoke.

[slouken]

Sounds great, feel free to post a PR implementing one or more of those. :)

[Semphriss]

Posting the original idea I had here:

I planned to add a function similar to the existing file dialogs, but instead of treating with path strings, it would treat with SDL_IOStreams, which should be compatible with pretty much any conception of importing/exporting data. It would fallback on ordinary file dialogs on desktop platforms.

I wanted to investigate into the various platforms (at least iOS/Android, but also console and Emscripten) to understand how they work before developing the interface, but I haven't yet finished my research. If somebody else is working on it, please let me know so that I don't duplicate the work.

[MikuAuahDark]

I have an idea for Android and may try to get my hands on it next week.

Since Android returns content:// URI as opposed to regular file path, I propose one of these function:

• int SDL_AndroidContentURIToFileDescriptor(conost char *uri, const char *mode); function that converts the content:// URI to integer file descriptor (so you can pass it to fdopen); or
• SDL_IOStream *SDL_AndroidOpenContentURI(const char *uri, const char *mode);.

With this method, the filelist can be kept as const char* without breaking current API. Note that the mode is either "r" (for reading/open file dialog) or "w" (for writing/save file dialog) or both. Feel free to discuss which one is better.

So how would be 3rd-party apps retrieve the filename? It's not possible to deduce the filename from content:// URI string alone but Android has an API that gives you the filename along with the content:// URI. The idea then is to put the filename in the query string to it. So, content://something/somefile?SDL_filename=filename.txt&SDL_mtime=1234567890. I'm not sure if Android will ignore the query string completely or we have to clear it before passing it to Android ContentResolver or if this method of putting the filename work at all.

If there are things that you want to know or want me to know, feel free to tell me.

[icculus]

(Removed UWP from title since WinRT support is gone in SDL3.)

[crudelios]

I'm in the process of trying to implement the "open folder" dialog on SDL but I have a question: on Android, when selecting the folder, you may request permission to have automatic folder access on subsequent runs of the application, without needing to show the "open folder" dialog again in order to access the files.

How should that be handled by SDL? I see three options:

• Always add the permission - useful but out of the developer's control
• Never add the permission - personally, I'd avoid this
• Create a new hint like SDL_HINT_ANDROID_ALLOW_PERSISTENT_FOLDER_ACCESS - my preferred solution
• A new File Dialog property - this would also work well but it feels like overkill just for android

Any suggestions would be welcome!