[share_plus] Fix types, lower Android minSDK#797
[share_plus] Fix types, lower Android minSDK#797vbuberen merged 4 commits intofluttercommunity:mainfrom
Conversation
|
Not sure how these cases are generally handled, but I would prefer the |
As said - I am pretty new to Android development. If that compiles and works as expected, it is probably the best option we have. The only risk I see there is people unintentionally using |
I understand your concerns. A runtime error is certainly not ideal, although to be fair, How about falling back to the regular non-result based share operations and just returning |
I agree that we should rework the solution with sharing with result. Not sure I can jump right into it (because I am an Android dev for quite some time and might be the right person to take care of it) as I am quite occupied with some activities here in Ukraine due to infamous events, so don't have much time. But let's see how it goes. |
| } | ||
| } | ||
| "shareWithResult" -> { | ||
| expectMapArguments(call) |
There was a problem hiding this comment.
could these *withResults(..) methods extended with check like this?
if(Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP_MR1)
result.notImplemented()
else ...
Then it won't be necessary to bump the minSdkVersion version for Android platform and it could be kept at the level supported in 3.x version of plugin.
There was a problem hiding this comment.
I think so. If anyone can submit a separated PR with a that change, that would be awesome!
That sounds like a good idea, as we already have that status and would not need to break any existing APIs as of version 4.0.1 I might even try to implement that tomorrow PS: I am starting to grasp why Microsoft still supports DOS elements: People seem to hate to upgrade xD We should all adopt the “live at head” mentality abseil has… ^^ |
Thank you for looking into this. Now, if some platform would return |
|
I will fork this fork to base my PR on the better formatted code |
I wouldn't bother yourself with that to depend on this PR, since I don't know for sure as to when it gets a review. If it is just about formatting - auto formatting should work fine for you no matter which IDE you use as the project has an editorconfig file in its root, so code format should be forced according to riles in that file. |
I only use melos format, which seems to not yield the same result as your formatting, but ok, will depend on the main branch then |
|
Just pushed my changes, please try this example project with your low API version devices/emulators: https://github.com/Coronon/share_plus_result_example I also added graceful fallback for other platforms to the normal share experience with |
|
and published |
Description
In this PR I fixed issues with type in
result.error(), which some users reported in #758. Saw that the code wasn't formatted according to oureditorconfigfile, which was added some time ago, so reformatted the code.I didn't like that
share_plusnow has minSDK 23 as it cuts quite a lot of users/devices. I thought we could make it much lower, but it seems that 22 is the minimum possible, becauseIntent.createChooser()withsenderparameter appeared only in SDK 22. So I made required changes to set minSDK to 22 and some additional small fixes.Finally, I saw that in #788 there were changes to min Flutter version, but not all platforms were updated. Fixed it as well, so
share_plusrequires Flutter 1.20 on all platforms now.Related Issues
Closes #758
Partially closes #789
Checklist
Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (
[x]).This will ensure a smooth and quick review process.
pubspec.yamlandCHANGELOG.md.///).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?