Question: Why not embrace the usage of read streams?

[Pato05]

Hi! I'm very interested in this package since it's the first time that I'm noticing a file picker which actually exports a stream (via saf_stream on Android) instead of copying the file to a temporary location.
I was wondering, why not drop file_selector entirely, and make it easier to access the read streams on the public APIs, and keep the usage of packages like saf_stream entirely on the backend?

For example, there could be a method file.openRead(), which takes these actions:

• on Android, it makes an internal call to saf_stream and returns this stream
• on iOS and MacOS, it returns a custom stream which:
  • on first read it makes a call to startAccessingSecurityScopedResourceWithURL(uri), and continues streaming the file via File(path).openRead()
  • on close, it makes a call to stopAccessingSecurityScopedResourceWithURL(uri)
• on Web: some inspiration can be taken from file_picker, which seems to make great use of ArrayBuffer to convert the file to a readable stream
• on Windows/Linux: there would be no particular limits from simply using File(path).openRead().

[Pato05]

there could also be a method to convert it to a http.MultipartFile, which would have the sole difference of creating the MultipartFile from a stream on IO platforms, and from the HTML file on Web (which would take off some overhead).

[mgenware]

Thanks for the feedback. Some functionalities (like picking files on windows / linux, or picking save paths) never need to copy files. In these cases, fast_file_picker needs to use file_selector's implementation. If you only need open file pickers on android or ios, you can actually drop both file_selector and fast_file_picker and copy fast_file_picker implementation.

I agree the example looks a bit verbose. So why not adding more packages for a simpler API? The reason is single-responsibility principle, this package is only responsible to show a picker and return OS file paths. It's users' choice to use whatever packages to consume the returned OS paths. There might other packages better than saf_stream. I usually add another wrapper around fast_file_picker and use that wrapper in my project.

Web support is on todo list.

[Pato05]

I usually add another wrapper around fast_file_picker and use that wrapper in my project.

Why don't you make this wrapper public? I think that a decent public API will make this package way more usable rather than something like file_picker.

You could make a package fast_file_picker_internal and wrap that over in this fast_file_picker package so that the user can use the public API with the defaults, and in case they want to change some behaviour, they can either make their own fork, or reimplement the logic entirely.

Anyways, to be clear, I don't pretend you make something like this, it's just an idea for a better file picker, since it would be very unique compared to other packages.

[mgenware]

The problem is there is always friction on each platforms. Let's say we incorporate saf_stream into fast_file_picker. saf_stream supports reading as an array of bytes, or stream, or copying an SAF file to a local file, or a custom stream if you need fine-grained control. There are 4 ways in total, this is only Android. Haven’t looked into web yet. I can support one common way (like reading bytes), users would still need to install saf_stream separately if they need to use other ways. Or I can support all ways, which basically makes this package unnecessarily bloated (imagine reading through 4 APIs on “how to read a file” section). file_selector worked around platform friction by simply copying platform file to a local file which dart can handle.