Repository navigation
[Request]: share_plus refactor and cleanup #1099
Description
Activity
Share files implementation for web to be done in another ticket: #212
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.
Reacted by Miguel Beltran1 remaining item
I would happily take this issue on as part of Hacktoberfest, if possible and still free :)
@ThexXTURBOXx details regarding hacktoberfest will be published soon, be sure to follow Majid on Twitter for more info: https://twitter.com/mhadaily ;)
There's no ticket "reservation". Whoever gets the PR approved gets it.
Oh okay, I remembered last year when it worked like this. Sorry about that then!
Reacted by Miguel BeltranI 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 ofshareObjector similar. - Should the platform interface and the platform-dependent implementations also be unified? I would have said that all
share_plusrelated packages should be refactored, but if desired, I can also modify only theshare_pluspackage and not the other packages.
Details of this are very welcome in order to achieve the desired refactoring.
- What should be the name of the unified method? Normally it would be called
- 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 ofshareObjector similar.
You could create a
ShareV2class which would allow you to call the method justshare. That would also make deprecation a bit easier, I guess.Reacted by Miguel Beltran- What should be the name of the unified method? Normally it would be called
New class
ShareV2or new methodshareV2are both valid options indeed. Adding@Deprecatedto 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)
Alright, then I have the right picture on what needs to be done. Thank you very much for the detailed clarifications!
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
IosShareOptionscould then be used to configure the origin for the share dialog on iPadOS for example. TheAndroidShareOptionscan be used to enable theRich content previewsof 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.
Reacted by Miguel Beltran, Maxim Kalistratov, Nico Mexis and LXNo, not yet. If you want, you can do it :)
We won't be doing this at the moment, as we plan a general refactor of the plus plugins architecture.
- locked as resolved and limited conversation to collaborators
on Jan 22, 2025
Plugin
share_plus
Use case
Currently, share_plus is a bit messy:
share,shareFiles,shareWithResult, andshareFilesWithResult).Proposal
The refactor should: