You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support for saving files at selected location on Android and iOS in the file_selector plugin #168318
Currently the file_selector plugin declares saving files at selected location on Android and iOS as unsupported (or not implemented). It would be great if if this functionality worked on all platforms.
Proposal
The current cross_file API allows to specify either the path or the data for files.
When path is provided we can toss a temp file and send the path over the plugin channel and then use corresponding platform API on Android and iOS to select file location for saving. That should also allow to send through very large files on mobile platforms and that use case is not well supported in the ecosystem.
I can try to put together a PR if this proposed feature makes sense.
Reacted by existedinnettw, SMAGGHE Clément and Leo D.
@darshankawar after reviewing these issues neither of them describe or exactly targeting the scenario I'd like to address.
These issues are discussing supporting some native UI for selecting a file path (or a folder) for saving a file and current API returns a path to that location.
Unfortunately on mobile platform that path is not enough for saving a file. For example, on Android the file/document API returns a content://... url backed up by available content provides and there is native Android API to save/read a stream to/from that content url. And native framework handles all appropriate permissions.
Perhaps either a new API method (e.g. saveFile) needs to be added to the file_selector plugin, or XFile parameter added to getSaveLocation(). Then XFile would contain either data or a path to file that needs to be saved. Then plugin can show a platform-specific UI to select file location and name and then would save XFile content there using native API.
Unfortunately on mobile platform that path is not enough for saving a file. For example, on Android the file/document API returns a content://... url backed up by available content provides and there is native Android API to save/read a stream to/from that content url.
Could you link to the specific APIs you are proposing wrapping, to make it clear how this would map to underlying system functionality?
(If the only way to implement file saving is with a different API, we should probably updating the existing issues accordingly, rather than having two versions of the request, one of which is not implementable.)
Activity
darshankawar commentedon May 6, 2025
@ekuleshov
I think there's already respective open issues for the use case, please check if they resemble yours or not:
#113441
#111583
ekuleshov commentedon May 6, 2025
@darshankawar after reviewing these issues neither of them describe or exactly targeting the scenario I'd like to address.
These issues are discussing supporting some native UI for selecting a file path (or a folder) for saving a file and current API returns a path to that location.
Unfortunately on mobile platform that path is not enough for saving a file. For example, on Android the file/document API returns a
content://...url backed up by available content provides and there is native Android API to save/read a stream to/from that content url. And native framework handles all appropriate permissions.Perhaps either a new API method (e.g.
saveFile) needs to be added to thefile_selectorplugin, orXFileparameter added togetSaveLocation(). ThenXFilewould contain either data or a path to file that needs to be saved. Then plugin can show a platform-specific UI to select file location and name and then would saveXFilecontent there using native API.darshankawar commentedon May 7, 2025
Thanks for the feedback.
stuartmorgan-g commentedon May 13, 2025
Could you link to the specific APIs you are proposing wrapping, to make it clear how this would map to underlying system functionality?
(If the only way to implement file saving is with a different API, we should probably updating the existing issues accordingly, rather than having two versions of the request, one of which is not implementable.)
stuartmorgan-g commentedon Jun 3, 2025
(Triaging for now, but we should re-evaluate later whether this should be a duplicate.)