share_plus - Give back result of user action

[kristijorgji]

I will propose below a feature for the plugin https://pub.dev/packages/share_plus

Request is: Give back some enum of user action after share screen is shown. Currently we have this signature, which returns void

  static Future<void> share(
    String text, {
    String? subject,
    Rect? sharePositionOrigin,
  })

In many use cases as I will describe in the other section, will be very useful to know what user did in the share screen.

Use case

1. Tracking. We need to know if user shared the text/file/etc =, or just closed the dialog(view) without doing nothing. This enabled a lot of opportunities, like A/B testing, trying to improve ui (explanation text) for what user is about to share and so on.
2. Follow up logic. Based on whether user shared or not, app might want to follow up with different code paths. Example: thank you for sharing, you received 10 super app points.

Proposal

The functions will return instead of Future Future

  static Future<Result> share(
    String text, {
    String? subject,
    Rect? sharePositionOrigin,
  })

//where Result can be something like

enum ShareResult {
  shared,
  closed,
  // maybe something else here no idea currently i see big need for binary did share or not  
}

[Coronon]

@Coronon and yes I did alter the code a bit to better test my use case of sharing a link but I`m also using async/await:

                onPressed: () async {

                  final result = await Share.shareWithResult(

                    'https://github.com',

                  );

                  setState(() {

                    status = result.status.name;

                    raw = result.raw;

                  });

                },

That seems like it should work - let me fix the FLAG thing really quick and then see again? :) ~5-10min probably

[Coronon]

Just added the FLAG_IMMUTABLE - sorry for taking so long, had to fight with my build environment quite a bit ^^

This little flag, which is required from V31+ requires us to up our minSdkVersion once more from 21(2014)->23(2015).

[appinteractive]

still have that message:

E[/flutter]() ( 5535): Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles., null, java.lang.IllegalArgumentException: com.example.example: Targeting S+ (version 31 and above) requires that one of FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.
E[/flutter]() ( 5535): Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if some functionality depends on the PendingIntent being mutable, e.g. if it needs to be used with inline replies or bubbles.
E[/flutter]() ( 5535):  at android.app.PendingIntent.checkFlags(PendingIntent.java:375)
E[/flutter]() ( 5535):  at android.app.PendingIntent.getBroadcastAsUser(PendingIntent.java:645)
E[/flutter]() ( 5535):  at android.app.PendingIntent.getBroadcast(PendingIntent.java:632)
E[/flutter]() ( 5535):  at dev.fluttercommunity.plus.share.Share.share(Share.kt:57)
E[/flutter]() ( 5535):  at dev.fluttercommunity.plus.share.MethodCallHandler.onMethodCall(MethodCallHandler.kt:44)
E[/flutter]() ( 5535):  at io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler.onMessage(MethodChannel.java:262)
E[/flutter]() ( 5535):  at io.flutter.embedding.engine.dart.DartMessenger.invokeHandler(DartMessenger.java:296)
E[/flutter]() ( 5535):  at io.flutter.embedding.engine.dart.DartMessenger.lambda$dispatchMessageToQueue$0$DartMessenger(DartMessenger.java:320)
E[/flutter]() ( 5535):  at io.flutter.embedding.engine.dart.-$$Lambda$DartMessenger$TsixYUB5E6FpKhMtCSQVHKE89gQ.run(Unknown Source:12)
E[/flutter]() ( 5535):  at android.os.Handler.handleCallback(Handler.java:938)
E[/flutter]() ( 5535):  at android.os.Handler.dispatchMessage(Handler.java:99)
E[/flutter]() ( 5535):  at android.os.Looper.loopOnce(Looper.java:201)
E[/flutter]() ( 5535):  at android.os.Looper.loop(Looper.java:288)
E[/flutter]() ( 5535):  at android.app.ActivityThread.main(ActivityThread.java:7839)
E[/flutter]() ( 5535):  at java.lang.reflect.Method.invoke(Native Method)
E[/flutter]() ( 5535):  at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
E[/flutter]() ( 5535):  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
E[/flutter]() ( 5535): )
E[/flutter]() ( 5535): #0      StandardMethodCodec.decodeEnvelope
package:flutter/…/services/message_codecs.dart:607
E[/flutter]() ( 5535): #1      MethodChannel._invokeMethod
package:flutter/…/services/platform_channel.dart:177
E[/flutter]() ( 5535): <asynchronous suspension>
E[/flutter]() ( 5535): #2      MethodChannelShare.shareWithResult
package:share_plus_platform_interface/method_channel/method_channel_share.dart:95
E[/flutter]() ( 5535): <asynchronous suspension>
E[/flutter]() ( 5535): #3      _HomePageState.build.<anonymous closure>
package:example/main.dart:50
E[/flutter]() ( 5535): <asynchronous suspension>
E[/flutter]() ( 5535):

[Coronon]

Did you flutter clean before testing the new changes to ensure it pulls the newest version? That was one of my bigges issues when I was trying to test the new flag.

[appinteractive]

Thanks! The message is gone but when tapping I get:

D[/EGL_emulation]()( 6044): app_time_stats: avg=257.37ms min=14.94ms max=6758.12ms count=28
E[/flutter]() ( 6044): [ERROR:flutter[/lib/ui/ui_dart_state.cc]()(209)] Unhandled Exception: PlatformException(prior share-sheet did not call back, did you await it? Maybe use non-result variant, null, null, null)
E[/flutter]() ( 6044): #0      StandardMethodCodec.decodeEnvelope
package:flutter/…/services/message_codecs.dart:607
E[/flutter]() ( 6044): #1      MethodChannel._invokeMethod
package:flutter/…/services/platform_channel.dart:177
E[/flutter]() ( 6044): <asynchronous suspension>
E[/flutter]() ( 6044): #2      MethodChannelShare.shareFilesWithResult
package:share_plus_platform_interface/method_channel/method_channel_share.dart:129
E[/flutter]() ( 6044): <asynchronous suspension>
E[/flutter]() ( 6044): #3      HomePage.build.<anonymous closure>
package:example/main.dart:47
E[/flutter]() ( 6044): <asynchronous suspension>
E[/flutter]() ( 6044):

All my changes are on another branch, so it's exactly your latest code.

[Coronon]

That is super weird… Could you tell me the exact emulator you use, so I can have a deeper look this evening. I am very sorry this doesn’t work for you - all my tests did not raise any issues :/

[Coronon]

I just checked my version with a Pixel4 API v31 emulator, and it works like a charm. Did you flutter clean + update the minSdkVersion to 23 & clean gradle caches? The error you are experiencing seems pretty much impossible with my example code - that's why I am asking. Maybe hit me up on Discord Coronon#5077 so we can resolve this together.

What the error means: The "prior share-sheet did not call back..." indicates that the callback handler was assigned a new callback before the prior one was executed -> Some WithResult method was called before another WithResult call completed, which can happen if you don't await subsequent calls. Here, we only call once, so the only way this happens (that I can imagine) is if your emulator somehow registers more than 1 click on the button, therefore executing onPressed multiple times -> calling shareFilesWithResult multiple times -> error. Perhaps add some print in onPressed to test this theory? This should normally not be possible because the shareFilesWithResult will raise the share-sheet / you dont spam the button.

EDIT: I was just able to reproduce the issue when spamming the 'Share' button -> you should add some multi click protection in production.

[appinteractive]

But that happens on ALL my simulators. So did I increase the minSDK from 21 to 23 on your branch (which is still 21) but with no luck. flutter clean does not bring any difference. So did I upgrade my android studio with no effect.

Only difference could be that I'm on an ARM machine (Apple M1) !?

The callback does run just once!

Is there another step needed beside flutter clean && flutter pub get?

[Coronon]

Ok... I just tried the exact same settings here: (I did a git reset --hard & flutter clean right before)

https://user-images.githubusercontent.com/33808743/158076687-ddbfa6cc-8af4-46f2-9d4e-66edf9186e3e.mp4

Did you make sure that you have the latest version from git? You said I was still using minSdkVersion 21, which indicates you did not pull the latest version. git pull in the example project should fix that, as I just added the ref to all git dependencies, so you don't have to ensure that it uses the latest _https://github.com/Coronon/plus_plugins_ commit.

[appinteractive]

Hey @Coronon it works 🥳 sorry for that hickups, I did the pull part but somehow it was not enough 🙄 Huge thanks to you for your work! 🤝

Just one questions that is remotely related, but do you know why safari is not shown as an option when sharing a link? Is there another property needed for that kind of sharing? Use case is when trying to share a deep link from an app (which has a microsite with preview).

Thanks again!

[appinteractive]

And regarding the results, shareWithResult.raw does only output the chosen option on iOS correct? Android does not return anything here as fare as I can tell. Just to be sure what the expected/possible behavior is.

[Coronon]

Hey @Coronon it works 🥳 sorry for that hickups, I did the pull part but somehow it was not enough 🙄 Huge thanks to you for your work! 🤝

Just one questions that is remotely related, but do you know why safari is not shown as an option when sharing a link? Is there another property needed for that kind of sharing? Use case is when trying to share a deep link from an app (which has a microsite with preview).

Thanks again!

Glad it finally works for you 🚀

I have not tested that scenario but can have a look into it. The raw property is pretty much all we can get our hands on I am afraid…

[Coronon]

And regarding the results, shareWithResult.raw does only output the chosen option on iOS correct? Android does not return anything here as fare as I can tell. Just to be sure what the expected/possible behavior is.

No, all implementations should return something in raw. The status should not be success otherwise. The kind of string IOS, Android and Mac oX return is very different though! But you should be able to get the selected action on Android. What app are you trying specifically? Can you try the std Messages (SMS) app?

[appinteractive]

I do not need any special app, I just might be interested in tracking the user behavior here.

On Android, I do not get any raw date, even if success is true. Unfortunately, I can't complete any of the actions because I only have the simulator and a dummy phone which can't send SMS.

So does the copy command on iOS get a success but not on android (which can be caught in code if needed and the raw data is present)

I do have a strange behavior with mail where I can't get back to the app without closing it, but that's Android being confusing?

https://user-images.githubusercontent.com/432828/158237103-7f135be0-550e-404e-9e41-55c5be990290.mp4

On iOS everything works like expected beside some apps reporting success when dismissing (like telegram) but I guess that's their implementation.

[alexrainman]

When this will be merged in the main branch and released in the official plugin?

[Coronon]

I do not need any special app, I just might be interested in tracking the user behavior here.

On Android, I do not get any raw date, even if success is true. Unfortunately, I can't complete any of the actions because I only have the simulator and a dummy phone which can't send SMS.

So does the copy command on iOS get a success but not on android (which can be caught in code if needed and the raw data is present)

I do have a strange behavior with mail where I can't get back to the app without closing it, but that's Android being confusing? share.mp4

On iOS everything works like expected beside some apps reporting success when dismissing (like telegram) but I guess that's their implementation.

You are absolutely right!!! The FLAG_IMMUTABLE prevents the selected action from editing the PendingIntent, causing us to always receive the string 'null'. We would need to use FLAG_MUTABLE, but here comes the problem: That flag is only available v31+ -> We would need to raise our minSdkVersion to 31... Luckily, there is a way to avoid these shenanigans by checking the API version at runtime and specifying appropriate flags. (I did not know about that before discovering this catch 22 -> Second time programming for android ever...) We could in theory now support minSdkVersion 21 again, but 23 sounds reasonable to me, considering that's 2015...

This should be fixed now - just git pull in the example again ;)

[miquelbeltran]

When this will be merged in the main branch and released in the official plugin?

soon :tm:

[miquelbeltran]

share_plus 4.0.0 has been published!

Thanks a lot to @Coronon and everyone else who helped to test.

[mustafa-707]

@miquelbeltran , Thanks a lot for publishing the feature ,

all good , but there's something that's need some updates , which is the share_plus_platform_interface is 2.0.0 and the feature is returning ShareResult object that's need share_plus_platform_interface is 2.1.0 i fixed it internally and it works now good

also its need after this update to make the android min sdk to 23 , it's not possible to do it under 21 (the min. for most plugins)

[appinteractive]

Could not build it on android and now when trying to use 4.0.0 in my real project I get (yes I did flutter clean) following:

Launching lib[/main.dart]() on sdk gphone64 arm64 in debug mode...
lib/main.dart:1
[/opt/homebrew/Caskroom/flutter/2.10.3/flutter/.pub-cache/hosted/pub.dartlang.org/share_plus-4.0.0/lib/share_plus.dart:96:17](): Error: Type 'ShareResult' not found.
  static Future<ShareResult> shareWithResult(
                ^^^^^^^^^^^
[/opt/homebrew/Caskroom/flutter/2.10.3/flutter/.pub-cache/hosted/pub.dartlang.org/share_plus-4.0.0/lib/share_plus.dart:120:17](): Error: Type 'ShareResult' not found.
  static Future<ShareResult> shareFilesWithResult(

                ^^^^^^^^^^^
[/opt/homebrew/Caskroom/flutter/2.10.3/flutter/.pub-cache/hosted/pub.dartlang.org/share_plus-4.0.0/lib/share_plus.dart:102:22](): Error: The method 'shareWithResult' isn't defined for the class 'SharePlatform'.
- 'SharePlatform' is from 'package:share_plus_platform_interface[/share_plus_platform_interface.dart]()' ('[/opt/homebrew/Caskroom/flutter/2.10.3/flutter/.pub-cache/hosted/pub.dartlang.org/share_plus_platform_interface-2.0.1/lib/share_plus_platform_interface.dart]()').
package:share_plus_platform_interface/share_plus_platform_interface.dart:1
Try correcting the name to the name of an existing method, or defining a method named 'shareWithResult'.
    return _platform.shareWithResult(
                     ^^^^^^^^^^^^^^^
[/opt/homebrew/Caskroom/flutter/2.10.3/flutter/.pub-cache/hosted/pub.dartlang.org/share_plus-4.0.0/lib/share_plus.dart:129:22](): Error: The method 'shareFilesWithResult' isn't defined for the class 'SharePlatform'.
- 'SharePlatform' is from 'package:share_plus_platform_interface[/share_plus_platform_interface.dart]()' ('[/opt/homebrew/Caskroom/flutter/2.10.3/flutter/.pub-cache/hosted/pub.dartlang.org/share_plus_platform_interface-2.0.1/lib/share_plus_platform_interface.dart]()').
package:share_plus_platform_interface/share_plus_platform_interface.dart:1

Try correcting the name to the name of an existing method, or defining a method named 'shareFilesWithResult'.
    return _platform.shareFilesWithResult(
                     ^^^^^^^^^^^^^^^^^^^^

FAILURE: Build failed with an exception.

Did I miss something?

[mustafa-707]

@appinteractive yes , I faced the same issue but i did fix it locally by going to the plugin folder and changed the share_plus_platform_interface is 2.0.0 to share_plus_platform_interface is 2.1.0 in the yaml

also make sure that's android min sdk is 23 in the plugin , so it's need match or be under your project min. sdk

[skela]

Same here, ShareResult not found, with complaints about method shareWithResult on class SharePlatform not being defined.

Launching lib/main_verbose.dart on sdk gphone x86 64 in debug mode...
: Error: Type 'ShareResult' not found.
  static Future<ShareResult> shareWithResult(
                ^^^^^^^^^^^
: Error: Type 'ShareResult' not found.
  static Future<ShareResult> shareFilesWithResult(
                ^^^^^^^^^^^

: Error: The method 'shareWithResult' isn't defined for the class 'SharePlatform'.
- 'SharePlatform' is from 'package:share_plus_platform_interface/share_plus_platform_interface.dart' ('../../../../.pub-cache/hosted/pub.dartlang.org/share_plus_platform_interface-2.0.1/lib/share_plus_platform_interface.dart').
Try correcting the name to the name of an existing method, or defining a method named 'shareWithResult'.
    return _platform.shareWithResult(
                     ^^^^^^^^^^^^^^^
: Error: The method 'shareFilesWithResult' isn't defined for the class 'SharePlatform'.

- 'SharePlatform' is from 'package:share_plus_platform_interface/share_plus_platform_interface.dart' ('../../../../.pub-cache/hosted/pub.dartlang.org/share_plus_platform_interface-2.0.1/lib/share_plus_platform_interface.dart').
Try correcting the name to the name of an existing method, or defining a method named 'shareFilesWithResult'.
    return _platform.shareFilesWithResult(
                     ^^^^^^^^^^^^^^^^^^^^

FAILURE: Build failed with an exception.

* Where:
Script '/home/skela/files/sdks/flutter/packages/flutter_tools/gradle/flutter.gradle' line: 1102
* What went wrong:
Execution failed for task ':app:compileFlutterBuildDebug'.
> Process 'command '/home/skela/files/sdks/flutter/bin/flutter'' finished with non-zero exit value 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org

BUILD FAILED in 33s
Exception: Gradle task assembleDebug failed with exit code 1
Exited (sigterm)

[miquelbeltran]

hmm, the internal dependency in the pubspec.yaml was not updated, so the plugin is still using 2.0.0 instead of 2.1.0 internally. You should be able to fix this with a flutter pub upgrade so the pubspec.lock will point to 2.1.0.

[Coronon]

True - because ^2.0.0 means: from 2.0.0->3.0.0(exclusive)

[Coronon]

@miquelbeltran , Thanks a lot for publishing the feature ,

all good , but there's something that's need some updates , which is the share_plus_platform_interface is 2.0.0 and the feature is returning ShareResult object that's need share_plus_platform_interface is 2.1.0 i fixed it internally and it works now good

also its need after this update to make the android min sdk to 23 , it's not possible to do it under 21 (the min. for most plugins)

We could actually roll back to 21 as pointed out earlier

[miquelbeltran]

I am publishing a hotfix now.

True - because ^2.0.0 means: from 2.0.0->3.0.0(exclusive)

No really. It is because the pubspec.yaml was still referencing the 2.0.0 instead of 2.1.0, so when updating to 4.0.0 of share_plus the project was still using platform internace 2.0.0 instead of being forced to 2.1.0.

Since there was been breaking changes, I am bumping all federated share_plus plugins to 3.0.0 to avoid mistakes

[Coronon]

I am publishing a hotfix now.

True - because ^2.0.0 means: from 2.0.0->3.0.0(exclusive)

No really. It is because the pubspec.yaml was still referencing the 2.0.0 instead of 2.1.0, so when updating to 4.0.0 of share_plus the project was still using platform internace 2.0.0 instead of being forced to 2.1.0.

Since there was been breaking changes, I am bumping all federated share_plus plugins to 3.0.0 to avoid mistakes

I think we just misunderstood each other ^^ But thanks for forcing the update :)

[miquelbeltran]

4.0.1 has been published, let me know if you still face errors. A flutter pub upgrade should help as well.

[appinteractive]

Works like a charm, thank you guys! I'm very thankful for your work, a thousand 💯 thanks 🙌

[ekuleshov]

As I described in issue #789 this change drops support for a lot of old Android devices still being used and this Android minSdk bump is above Flutter's own min supported Android API version. Given that share_plus in its roots one of the platform's core plugins, it should match with the Android versions currently supported by Flutter core.

A better approach would be to gracefully ignore feature not supported on some older devices. It is already separate shareWithResult() that provides feedback.

The shareWithResult() method only implemented on Android, iOS and macos and it should be simple enough to further restrict this only method by Android version rather than increasing Android API level for entire plugin.

[Coronon]

First of all, we are talking about API version 22 now (2015), which is now 7 years old - most people probably posses much more current devices.

While Flutter supports minSdkVersion version 19, it probably doesn't run all that smooth on them anyway (assumption) and you have to drop support at some point. We have a feature that a lot of people requested for a long time, and you can still depend on an older version of share_plus if you need to support legacy systems.

I think that the needs of the many out way the needs of the few in this case.

PS: Thank you, @vbuberen, for the PR to decrease minSdkVersionto 22 :)

[vbuberen]

I think that the needs of the many out way the needs of the few in this case.

While I am strongly with you here that even Plus plugins should move forward to at least 21 already (as it is really time even for Flutter to move forward as we have quite a lot of better APIs available, so we would simplify the code for plugins, like network_info), we would still cut not few, but quite a lot of devices with minSDK version 22.

Here is the screenshot from Android Studio project creation wizard which helps you pick the min supported Android version for your project:

2.7% seems like not much, but if you consider that it is 2.7% from 2.5 billion devices it feels like we are cutting a big amount of users.

I feel till Flutter team pushes minimum supported version to 21 we will see lots of angry devs demanding us to support APIs 16-19 even though they might not have such users of their apps at all.

[ekuleshov]

First of all, we are talking about API version 22 now (2015), which is now 7 years old - most people probably posses much more current devices.

Regardless how old is the Android APIs are, in the end it is about being able to run the Flutter-based app on devices that users have, without forcing them to update their hardware.

While Flutter supports minSdkVersion version 19, it probably doesn't run all that smooth on them anyway (assumption) and you have to drop support at some point.

I'm not playing with assumptions here, but on my actual user base and devices they are using. I understand it is much easier for plugin developers to drop the old APIs, but the app developers have to take care and support their users. It is unfortunate when plugin developers forgetting that.

We have a feature that a lot of people requested for a long time, and you can still depend on an older version of share_plus if you need to support legacy systems.

The problem with the old version is that sticking one plugin to an old version quickly forces you to also stick many other to the old versions, which quickly turns into dependency hell. We just went through all of that when migrating everything to null safety.

I think that the needs of the many out way the needs of the few in this case.

I wonder what data this statement is based on? I've been using the share plugin for several years before this change and didn't need to know if data was shared or canceled. Meaning this new feature is not an essential one.

Hence my request to not break the existing use of the plugin and add this new feature as a separate API only supported on newer devices, which you can easily do in Android code using Build.VERSION.SDK_INT > Build.VERSION_CODES.L check, which is a common approach in native Android development to accommodate to platform API specifics and it is not considered cumbersome.

[ekuleshov]

Here is the screenshot from Android Studio project creation wizard which helps you pick the min supported Android version for your project:

2.7% seems like not much, but if you consider that it is 2.7% from 2.5 billion devices it feels like we are cutting a big amount of users.

I feel till Flutter team pushes minimum supported version to 21 we will see lots of angry devs demanding us to support APIs 16-19 even though they might not have such users of their apps at all.

The problem with these numbers in Android studio, they are too broad general and don't take into account device categories (phone vs tablets) or even the app categories. Distribution for real apps can be well off those numbers.

Without going into specifics, the app is one of those that users are buying tablets to run just this one app on them. For them buying these tablets is a big investment and they don't want to do that investment over and over again every few years just because Android or iOS APIs became dated. The tablets are keep going, even the nearly 10 years old 1st gen iPad Minis (these still supported by Flutter, at least of mid of this year).

Here are the number of users of my app from the 2021 (ones that came online at least once, but there are more offline users). The numbers with API <=21 add up to ~1500 users out of 44K-ish total (~3.5%). For comparison, there are about 4.5K more have non-upgradeable Android tablets with API 22.

The 1.5K end users don't seem a lot in the grand scheme of things, but those users will have to get new hardware in order to keep using the app, which will make them very very very unhappy users.

Also the Flutter core is yet to decide if they are going to bump the Android min API level. Also not stated in the roadmap.

[ekuleshov]

The newly introduced shareWithResult() method is only implemented on Android, iOS and macos and it should be simple enough to further restrict only this method by Android API version rather than increasing Android API level for entire share_plus plugin.

So, just check Build.VERSION.SDK_INT > Build.VERSION_CODES.L or whichever version is required for this new functionality.

PS: btw, an alternative approach to support use cases described in the initial feature request could have been some kind of optional call back on the share(..) methods with events like canceled, shared, etc. Then in case functionality is not available on a given platform the callback just wouldn't get called.

[vbuberen]

The newly introduced shareWithResult() method is only implemented on Android, iOS and macos and it should be simple enough to further restrict only this method by Android API version rather than increasing Android API level for entire share_plus plugin.

So, just check Build.VERSION.SDK_INT > Build.VERSION_CODES.L or whichever version is required for this new functionality.

Your PRs are also welcome with your vision/solution as it is an open source project.

[alexrainman]

I don't see a point of supporting a 9 years old OS with only 0.8% of market share. The chance of your app reaching those devices is basically close to none.

[vbuberen]

By the way, while testing lowering minSDK to 22 today I saw that newly introduced callback don't give us a 100% guarantee that user actually shared something as I can select any app (like default Messages) and close it without actually sending any message and I would still get success result by share_plus. I feel like it makes the merged solution not valid for the 1 use case described by the original issue author:

Tracking. We need to know if user shared the text/file/etc =, or just closed the dialog(view) without doing nothing. This enabled a lot of opportunities, like A/B testing, trying to improve ui (explanation text) for what user is about to share and so on.

[ekuleshov]

Your PRs are also welcome with your vision/solution as it is an open source project.

Normally that is what I would do. But the whole plus_plugins monorepo with this Melos thing is beyond my comprehension. Tried to get it all configured several times and had to give up.

PS: isn't it ironic that new functionality is not completely working for the cost of supported devices

[ekuleshov]

I don't see a point of supporting a 9 years old OS with only 0.8% of market share. The chance of your app reaching those devices is basically close to none.

How about close to 1500 chances where my real app actually reached those devices?

But then again, fundamentally all the *_plus plugins are the common platform support plugins and they should stay at least somewhat close to the currently supported Flutter's platforms.

[vbuberen]

I don't see a point of supporting a 9 years old OS with only 0.8% of market share. The chance of your app reaching those devices is basically close to none.

I suggest to move such comments and discussion back into #789 It was me, who initially suggested @ekuleshov to move here to share his concerns, but the discussion here turns from discussion of share_plus feature to versions support and I feel like mentioned issue will be a better place for that.

[Coronon]

By the way, while testing lowering minSDK to 22 today I saw that newly introduced callback don't give us a 100% guarantee that user actually shared something as I can select any app (like default Messages) and close it without actually sending any message and I would still get success result by share_plus. I feel like it makes the merged solution not valid for the 1 use case described by the original issue author:

Tracking. We need to know if user shared the text/file/etc =, or just closed the dialog(view) without doing nothing. This enabled a lot of opportunities, like A/B testing, trying to improve ui (explanation text) for what user is about to share and so on.

Yes, that is true and I have stated that multiple times and included it in the documentation. That is a limitation by android (at least I couldn’t find another way) and we simply have to accept it or dont get a result at all. While IOS also supports an actual share result, applications are free to return whatever they want (I belive Telegram always returns the same? Someone stated that in one of the comments in this issue I think), so we decided that we go for the best thing we got on each platform.

[Coronon]

PS: isn't it ironic that new functionality is not completely working for the cost of supported devices

I understand it is much easier for plugin developers to drop the old APIs, but the app developers have to take care and support their users. It is unfortunate when plugin developers forgetting that.

I can’t help to feel that you think you are entitled to support. I contributed to this project because I saw people that really wanted this feature and considered it possible for me to implement. Now you come along and seemingly blame me. If you want that version check: please implement it yourself. You don’t even need melos to work on share_plus. I always like receiving constructive criticism because I can learn from it and improve - but yours doesn’t feel all that constructive anymore I am afraid.

Please submit a PR so everybody can be happy.

[ekuleshov]

I can’t help to feel that you think you are entitled to support.

Not at all. It is unfortunate it came across this way. The issue I've been trying to explain is about introducing a new feature and API at the cost of dropping large chunk of existing functionality on devices generally supported by the Flutter platform. I guess no one else sees that important.

As for Melos, the contribution guide does not provide alternative setup options. I'd appreciate any guidelines on not using it, e.g. on this issue https://github.com/fluttercommunity/plus_plugins/issues/724

[ekuleshov]

Yes, that is true and I have stated that multiple times and included it in the documentation. That is a limitation by android (at least I couldn’t find another way) and we simply have to accept it or dont get a result at all.

Could documentation further extended to state these limitations on android platform? The current shareWithResult method doc, quoted below, doesn't seem clear about Android or iOS not always returning the accurate result. It may need to state that result is provided on the best effort as platform allows it.

  /// Behaves exactly like [share] while providing feedback on how the user
  /// interacted with the share-sheet. Until the returned future is completed,
  /// any other call to any share method that returns a result _might_ result in
  /// a [PlatformException] (on Android).
  ///
  /// Because IOS, Android and macOS provide different feedback on share-sheet interaction,
  /// a result on IOS will be more specific than on Android or macOS. While IOS can detect if
  /// the user actually completed his selected action or aborted it midway, Android and macOS
  /// only record if the user selected an action or outright dismissed the share-sheet.
  ///
  /// **Currently only implemented on IOS, Android and macOS.**

[mbalmer]

Is getting a result from an intent possible or not? Looking at the code, it seems not...

[michalss]

is this implemented pls ?

[Coronon]

is this implemented pls ?

Could you please make your question a bit more specific? The general ShareResult functionality has been implemented for quite some time now :)

Please consult the documentation on:

• shareWithResult
• shareXFiles

[michalss]

is this implemented pls ?

Could you please make your question a bit more specific? The general ShareResult functionality has been implemented for quite some time now :)

Please consult the documentation on:

• shareWithResult
• shareXFiles

Sorry ment this https://github.com/fluttercommunity/plus_plugins/issues/2039

[Laraib0000]

Does anyone know accurate solution? Didn't find any solution.