Flutter_file_picker: Clarify intended usage with web platform

Created on 13 Aug 2020  路  11Comments  路  Source: miguelpruivo/flutter_file_picker

After reading through a few issues, including https://github.com/miguelpruivo/flutter_file_picker/issues/292 and https://github.com/miguelpruivo/flutter_file_picker/issues/229, and the readme, I'm still not quite sure how flutter_web_picker is intended to be used.

The readme looks very similar to the standard flutter plugin, and suggests that adding file_picker_web to the pubspec should be enough to enable the web platform (this is how, for example, image_picker works). Unfortunately, this isn't quite set up to work.

This is blocked by:

  • The use of MethodChannelFilePicker here. I thought this would be a fairly straightforward fix, but even if we fix the parameters on the FilePickerPlatform interface, we still end up with the issue:
  • Web.FilePicker.getFiles(...) returns a List of files, while FilePicker.getFiles (the delegating class) expects either a String or a Map.

So, since the flutter plugin architecture doesn't seem to be working here, is the preferred usage to conditionally import the correct package?

Something like
`import 'package:file_picker/file_picker.dart' if(dart.library.js) 'package:file_picker_web/file_picker_web.dart'

If that's the case, then

  • It would be helpful to export FileType from the file_picker_web package, otherwise the user will have to import file_picker_platform_interface as well if the user wants to use the type parameter
  • The general file_picker repo might be able to get rid of the complexity of the PluginPlatformInterface, since it isn't used.

Thanks again for your work on this!

suggestion wip

Most helpful comment

I will probably work on this during my vacation time which is scheduled for the next week, so you might expect some news. 馃帀

All 11 comments

Hi! The idea behind this is exactly that, to have to use only the file picker web alone without any other dependency. If this is not happening, then there could be an issue with it that should be addressed.

Initially I wanted to have only one package and stub all the files accordingly to web/io. However, having common class names on both (File) makes it impossible because you need to effectively return one of those types, that鈥檚 where the interface comes in play to solve all of this.

I鈥檓 sorry that I haven鈥檛 had enough time lately to work on this but let me know if you come up with a fix and I鈥檒l be happy to implement/review it.

Do you have any suggestions @wreppun?

@miguelpruivo You should consider using a wrapper for returning files like other file picker plugins are doing. That way, stubbing would work fine. Check this out. Thought it might help.

@BirjuVachhani thank you, I'll take a look as soon as I have the time.

I will probably work on this during my vacation time which is scheduled for the next week, so you might expect some news. 馃帀

FYI: I'm already working on this along with #234, expect a release this week. 馃帀

After that, a single plugin (file_picker) should be the only required dependency that will work transversally on all platforms.

@miguelpruivo That's great. Looking forward to trying it out.

Update: I鈥檝e had success on its implementation and it鈥檚 only missing iOS refactor to include the new changes. I鈥檓 expecting to do so by tomorrow with 2.0.0 release that will include breaking changes (for better) and only file_picker will be required.

From there on, instead of paths and multiple methods, it will be simplified and a FilePickerResult will be returned that contains helper getters with relevant data and a List<PlatformFile> with the picked files which include detailed data such as name, bytes, path, uri, etc.

Also, on Android it will _always_ create a cached copy of the picked file (just like iOS does) to prevent misleading picks and ensure that everything can actually be picked.

I鈥檒l write a migration guide anyway when deploying. Expect the file_picker_interface and file_picker_web to be deprecated after that.

Thanks!

This sounds wonderful. Does this also work for Android's scoped storage?

@BirjuVachhani yes, that鈥檚 also one of the focuses.

Update is now live with 2.0.0 please, see the changelog for details of what have changed.

All platforms are now unified with file_picker and this should be the only required dependency.

Let me know if you find any issue!

Thank you!

Was this page helpful?
0 / 5 - 0 ratings