[Request]: share_plus refactor and cleanup

[miquelbeltran]

Plugin

share_plus

Use case

Currently, share_plus is a bit messy:

• 4 different methods that do somehow the same (share, shareFiles, shareWithResult, and shareFilesWithResult).
• Sharing URLs, something that iOS and macOS support, is currently broken.

Proposal

The refactor should:

• Unify all four methods into a single one.
• Deprecate the old methods.
• Remove code duplication
• Add a way to share a URL on iOS (not as String, but as NSURL)

[miquelbeltran]

Share files implementation for web to be done in another ticket: #212

[ueman]

Since file io isn't supported on web via dart:io it could make sense to use https://pub.dev/packages/cross_file in order to pass files to the share plugin.

[miquelbeltran]

@ueman note that the web implementation is discussed in #212

edit: oh sorry you already replied there

[ThexXTURBOXx]

I would happily take this issue on as part of Hacktoberfest, if possible and still free :)

[miquelbeltran]

@ThexXTURBOXx details regarding hacktoberfest will be published soon, be sure to follow Majid on Twitter for more info: https://twitter.com/mhadaily ;)

[miquelbeltran]

There's no ticket "reservation". Whoever gets the PR approved gets it.

[ThexXTURBOXx]

Oh okay, I remembered last year when it worked like this. Sorry about that then!

[ThexXTURBOXx]

I have developed a strategy on how to refactor the plugins. However, I still have two questions about this, because I am not sure which solution is desirable:

• What should be the name of the unified method? Normally it would be called share, but this method already exists (as it is not deleted, but deprecated). I thought of shareObject or similar.
• Should the platform interface and the platform-dependent implementations also be unified? I would have said that all share_plus related packages should be refactored, but if desired, I can also modify only the share_plus package and not the other packages.

Details of this are very welcome in order to achieve the desired refactoring.

[ueman]

• What should be the name of the unified method? Normally it would be called share, but this method already exists (as it is not deleted, but deprecated). I thought of shareObject or similar.

You could create a ShareV2 class which would allow you to call the method just share. That would also make deprecation a bit easier, I guess.

[miquelbeltran]

New class ShareV2 or new method shareV2 are both valid options indeed. Adding @Deprecated to the old methods then.

Should the platform interface and the platform-dependent implementations also be unified?

They will have to change as well, but we need to keep the federated plugin architecture, if that's what you mean.

(personally, I'd like to get rid of the federated plugin architecture, but that's out of scope for this ticket)

[ThexXTURBOXx]

Alright, then I have the right picture on what needs to be done. Thank you very much for the detailed clarifications!

[ueman]

I would like to see the new 'share' method to take platform specific configuration objects.
Something like:

// pseudo code
ShareV2.share({
  String? content,
  String? subject,
  File? file,
  AndroidShareOptions? androidOptions,
  IosShareOptions? iosOptions,
}) {
  // implementation
}

The IosShareOptions could then be used to configure the origin for the share dialog on iPadOS for example. The AndroidShareOptions can be used to enable the Rich content previews of Android's share sheet.

That way the method parameters aren't cluttered with parameters and it's also clear which platforms have which options. It's probably also more future-proof.

local_auth does something similar for localizations.

[ghost]

Is this issue fixed already?

[ThexXTURBOXx]

No, not yet. If you want, you can do it :)

[ghost]

Sure! I would love to. Can you help me a bit, like give me a quick rundown since I am a bit (Its not that I don't know the
language) new to Flutter and Dart?

[miquelbeltran]

We won't be doing this at the moment, as we plan a general refactor of the plus plugins architecture.