What is the problem or limitation you are having?
iOS and Android don't currently implement file dialogs like OpenFileDialog, SaveFileDialog and SelectFolderDialog.
Describe the solution you'd like
It should be possible to select, open and save file content on iOS and Android.
Describe alternatives you've considered
No real option; this is a missing feature that is required for parity.
Additional context
The complication to implementing file dialogs on mobile platforms is that the concept of a "File" is more abstract than it is on desktop platforms. Desktop platforms expose a clear POSIX interface, and a "file" is a pointer to an object on disk. While mobile platforms have a POSIX file interface, the "files" that users are more likely to interact with are "cloud resources", and as a result, the APIs for the mobile equivalent of "file" dialogs are tied to platform abstractions.
On Android, this manifests as dialogs that return a ContentURI, which then need asynchronous Java calls to retrieve data from that URI. This approach is needed even for content that is "on device", such as files on an SD card attached to the device - essentially any content that isn't in the app bundle.
A previous attempt at file dialogs on Android was attempted with #1158. That code works (or worked at the time); but the API exposed for "files" isn't consistent with desktop platforms - you don't use a Path object referencing a file on disk; you get an object that needs other "getData" calls. That's fine for Android-specific use, but isn't appropriate for a Toga cross-platform API.
This need to support cloud storage is, to an extent, true of desktop platforms as well - a laptop can open a file from iCloud, Dropbox etc. Having an easy way to treat Cloud files as local files would be useful in a desktop context as well.
Historically, the thought has been that we need a cross-platform, high level async "File-like object" API - something that presents that API of "Path" object, which can be opened, read, written etc. That File-like object API would also provide an asynchronous API for reading and writing (See #1171). This API would provide implementations for local file access, cloud access on different file services, etc. The synchronous version of the API may involve streaming content to a local file that is in the app bundle, so that POSIX APIs can be used on that content.
We would then modify the existing file dialogs on desktop to return the "local file" versions of those APIs, and implement Android/iOS versions that implement file access using those platforms file/content selection dialogs.
An alternative approach would be to have a separate set of dialogs for "cloud content", encourage those to be used when appropriate, and only implement the Cloud Content APIs on mobile platforms.
What is the problem or limitation you are having?
iOS and Android don't currently implement file dialogs like OpenFileDialog, SaveFileDialog and SelectFolderDialog.
Describe the solution you'd like
It should be possible to select, open and save file content on iOS and Android.
Describe alternatives you've considered
No real option; this is a missing feature that is required for parity.
Additional context
The complication to implementing file dialogs on mobile platforms is that the concept of a "File" is more abstract than it is on desktop platforms. Desktop platforms expose a clear POSIX interface, and a "file" is a pointer to an object on disk. While mobile platforms have a POSIX file interface, the "files" that users are more likely to interact with are "cloud resources", and as a result, the APIs for the mobile equivalent of "file" dialogs are tied to platform abstractions.
On Android, this manifests as dialogs that return a ContentURI, which then need asynchronous Java calls to retrieve data from that URI. This approach is needed even for content that is "on device", such as files on an SD card attached to the device - essentially any content that isn't in the app bundle.
A previous attempt at file dialogs on Android was attempted with #1158. That code works (or worked at the time); but the API exposed for "files" isn't consistent with desktop platforms - you don't use a Path object referencing a file on disk; you get an object that needs other "getData" calls. That's fine for Android-specific use, but isn't appropriate for a Toga cross-platform API.
This need to support cloud storage is, to an extent, true of desktop platforms as well - a laptop can open a file from iCloud, Dropbox etc. Having an easy way to treat Cloud files as local files would be useful in a desktop context as well.
Historically, the thought has been that we need a cross-platform, high level async "File-like object" API - something that presents that API of "Path" object, which can be opened, read, written etc. That File-like object API would also provide an asynchronous API for reading and writing (See #1171). This API would provide implementations for local file access, cloud access on different file services, etc. The synchronous version of the API may involve streaming content to a local file that is in the app bundle, so that POSIX APIs can be used on that content.
We would then modify the existing file dialogs on desktop to return the "local file" versions of those APIs, and implement Android/iOS versions that implement file access using those platforms file/content selection dialogs.
An alternative approach would be to have a separate set of dialogs for "cloud content", encourage those to be used when appropriate, and only implement the Cloud Content APIs on mobile platforms.