fix(share_plus): fallback for shareXFiles() to use download on web

[ekuleshov]

Description

Adds fallback to use download files on web when Navigator.share() failed

Related Issues

• Fix [Bug]: share_plus Share.shareXFiles() is not working on web #1643

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I titled the PR using Conventional Commits.
• I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
• All existing and new tests are passing.
• The analyzer (flutter analyze) does not report any problems on my PR.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

• Yes, this is a breaking change (please indicate that with a ! in the title as explained in Conventional Commits).
• No, this is not a breaking change.

[miquelbeltran]

Thanks for the PR! I will check it in the following days. Meanwhile, there are formatting errors in packages/share_plus/share_plus/example/lib/main.dart and packages/share_plus/share_plus/lib/src/share_plus_web.dart.

[miquelbeltran]

Taking a look at it now. So I think it's a good start, but I think that if we want to follow the idea that it should always fallback to download, then on any point of failure should fall back to downloading and not just the NotAllowedError. That would mean that, for example, the call to throw Exception('Navigator.canShare() is unavailable'); on line 207 should also be replaced by a call to _download(), also on 211, etc.

[ekuleshov]

Taking a look at it now. So I think it's a good start, but I think that if we want to follow the idea that it should always fallback to download, then on any point of failure should fall back to downloading and not just the NotAllowedError. That would mean that, for example, the call to throw Exception('Navigator.canShare() is unavailable'); on line 207 should also be replaced by a call to _download(), also on 211, etc.

Makes sense. I'll update.

Also, the API docs says that shareXFiles() method "May throw PlatformException or FormatException from MethodChannel", but the web implementation throws plain Exception. Should I change it to use the PlatformException instead?

I also wonder if there should be a flag on the shareXFiles() method to enable/disable this fallback?
Perhaps that could be done as part of #3307 (comment)

[miquelbeltran]

Also, the API docs says that shareXFiles() method "May throw PlatformException or FormatException from MethodChannel", but the web implementation throws plain Exception. Should I change it to use the PlatformException instead?

I think Exception is fine, instead the documentation should be updated once this feature is ready.

I also wonder if there should be a flag on the shareXFiles() method to enable/disable this fallback? Perhaps that could be done as part of #3307 (comment)

I was thinking that as well. Maybe is a very dirty hack, but even a static variable with a flag to enable/disable the download fallback could be an option. And then refactor properly in #3307

[ekuleshov]

I also wonder if there should be a flag on the shareXFiles() method to enable/disable this fallback? Perhaps that could be done as part of #3307 (comment)

I was thinking that as well. Maybe is a very dirty hack, but even a static variable with a flag to enable/disable the download fallback could be an option. And then refactor properly in #3307

Updated.

On a side note. The XFile.saveTo(path) on the web also makes a file download with the HTMLAnchorElement. The "path" parameter is ignored and XFile.name is used for downloaded files, which won't allow for fileNameOverrides.

[miquelbeltran]

I've made some changes to the PR:

• Moved the downloadFallbackEnabled to the Share class so it is accessible
• Updated the README
• Added trailing comas to the methods
• Wrapped the example "share from assets" in a try/catch
• Added the downloadFallbackEnabled to the example so it can be tested

Let me know what you think

[ekuleshov]

Looks good.

PS: those trailing comas are going away when dart_style is bumped to 3.0.0. Hopefully you could increase line length from 80 to 120 at that time...

[miquelbeltran]

I'll go ahead and merge, if there are any other necessary changes they can go in a new PR

PS: those trailing comas are going away when dart_style is bumped to 3.0.0. Hopefully you could increase line length from 80 to 120 at that time...

Interesting.. now taking a look at dart-lang/dart_style#1253