[url_launcher] Url launcher platform interface null safety #3142

mvanbeusekom · 2020-10-12T16:44:07Z

Description

Migration of "url_launcher_platform_interface" to null safety.

Note: I had to pin the "plugin_platform_interface" package to the git repo since version 1.1.0-nullsafety is not yet released (see companion PR #3115). I have decorated the line with a # TODO (mvanbeusekom): comment. Please let me know if I should solve this in a different way.

Related Issues

flutter/flutter#66395

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.

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 a breaking change in CHANGELOG.md and increment major revision).
No, this is not a breaking change.

cyanglaz · 2020-10-12T20:46:05Z

packages/url_launcher/url_launcher_platform_interface/lib/method_channel_url_launcher.dart

@@ -14,7 +13,7 @@ const MethodChannel _channel = MethodChannel('plugins.flutter.io/url_launcher');
 /// An implementation of [UrlLauncherPlatform] that uses method channels.
 class MethodChannelUrlLauncher extends UrlLauncherPlatform {
  @override
-  Future<bool> canLaunch(String url) {
+  Future<bool?> canLaunch(String url) {


Returning a nullabe bool seems odd. Should it just be bool?

I also felt the same, but since the documentation of the invokeMethod explicitly mentioned the return value could be null I decided for allowing null.

I could of course check for null on the Dart side and return false if this is the case. Would this be the preferred solution? Enforcing non-null using the ! operator also doesn't feel correct since we have no real control on what's happening on the native side (or even inside the method channel logic).

I think it is fair to do a check in invokeMethod and return false if the return value is null.

However, if we do that, it might counts as a breaking change. @blasten Just wanted to make sure, we are going to introduce a major bump regardless of a public api breaking change or not, right?

I have updated the code to match the above. The canLaunch and launch methods now return false if the value from the native side is null. I have also included additional unit test to test for these cases.

For now I left the version number as is until @blasten had a change to have a look at the situation.

Thanks! Yeah, I have confirmed with @blasten offline, all the NNBD migrations are going to be a major bump, so making breaking changes in public API (like this one) is harmless.

Does this mean this PR can be approved?

all the NNBD migrations are going to be a major bump, so making breaking changes in public API (like this one) is harmless

This is the general guidance, and the default option. There are cases where doing a major bump is less desired.

I think we reached a general consensus that we can leave the major bump, so I will leave it as is (see also feedback from Amir on CHANGELOG.md)

blasten · 2020-10-13T21:10:36Z

packages/url_launcher/url_launcher_platform_interface/CHANGELOG.md

@@ -1,3 +1,7 @@
+## 2.0.0-nullsafety


@amirh do you have any comment on this version bump?

I think that for the null safety migration as we expect all platform implementations to get the same bump in close proximity it is reasonable to do a major bump on the platform interface.

blasten · 2020-10-13T22:09:39Z

...ages/url_launcher/url_launcher_platform_interface/test/method_channel_url_launcher_test.dart

+
+      if (methodCall.method == 'canLaunch') {
+        if (methodCall.arguments['url'] == 'http://example.com/null') {
+          return null;
+        }
+      }
+
+      if (methodCall.method == 'launch') {
+        if (methodCall.arguments['url'] == 'http://example.com/null') {
+          return null;
+        }
+      }
    });


nit: what about moving this code to the specific test where it's being used, or the setUp function in the worst case? This way the test doesn't leak state, and it doesn't need log.clear(); in the tearDown.

The problem is that setting the mock method channel (using setMockMethodCallHandler) has a global impact (this is how it is handled inside the MethodChannel class). So if I am to update in the specific test it will affect all tests that are run after (or during, since tests can run in parallel) the specific test. Or am I missing something here?

For now I removed the above logic, as it turns out the method channel will automatically return null if no return statement is specified, which is exactly the behavior needed by the tests. I did however added a return null; statement to make the logic explicit instead of implicitly relying on the behavior of the implementation of the MethodChannel class.

blasten · 2020-10-13T22:14:48Z

packages/url_launcher/url_launcher_platform_interface/pubspec.yaml

-  plugin_platform_interface: ^1.0.1
+  # TODO (mvanbeusekom): use pub.dev once 1.10.0-nullsafety released.
+  plugin_platform_interface:
+    git: 


It looks like this would need to be a local path dependency: https://api.cirrus-ci.com/v1/task/4983717032624128/logs/main.log

I have updated the code to use a local path dependency which has the same result unfortunately (https://api.cirrus-ci.com/v1/task/6308195557703680/logs/main.log).

We can only solve this be publishing the null safety version of the "plugin_platform_interface" package (or of course updating the publishable CI step, which is highly undesirable in my opinion).

I see. I think we can skip this test for now. Feel free to revert it back to a git dependency. I think we will need that for some testing in the Flutter framework repo.

Thanks, I have reverted back to the git dependency just to be sure.

blasten · 2020-10-14T02:10:56Z

@mvanbeusekom The analysis is failing due to an issue in the branch, but it was fixed by #3150. Therefore, you would also need to rebase, and add the analysis_options.yaml file as well as whitelist in incremental_build.sh similar to that PR.

BREAKING CHANGE: this will introduce null safety and thus updates the signature of several methods.

blasten · 2020-10-14T21:48:30Z

It's missing the file: packages/url_launcher/url_launcher_platform_interface/analysis_options.yaml:

include: ../../../analysis_options.yaml
analyzer:
  enable-experiment:
    - non-nullable

Otherwise, LGTM. The presubmits will be red until url_launcher is migrated.

blasten

LGTM

mvanbeusekom · 2020-10-15T08:23:55Z

include: ../../../analysis_options.yaml
analyzer:
  enable-experiment:
    - non-nullable

Indeed this file was supposed to be there and got removed locally when rebasing (my mistake), I just added the file again. Thanks for pointing it out.

mvanbeusekom requested review from amirh, bkonyi, bparrishMines, cyanglaz, dnfield, iskakaushik, LHLL, matthew-carroll, mehmetf and mklim as code owners October 12, 2020 16:44

google-cla bot added the cla: yes label Oct 12, 2020

mvanbeusekom changed the title ~~Url launcher platform interface null safety~~ [url_launcher] Url launcher platform interface null safety Oct 12, 2020

mvanbeusekom force-pushed the url_launcher_platform_interface_null_safety branch from 93ff574 to b7072f7 Compare October 12, 2020 19:42

cyanglaz reviewed Oct 12, 2020

View reviewed changes

mvanbeusekom mentioned this pull request Oct 13, 2020

[url_launcher] migrate url_launcher package to null safety #3148

Merged

13 tasks

blasten reviewed Oct 13, 2020

View reviewed changes

mvanbeusekom added 4 commits October 14, 2020 08:35

Migrate to null safety

4597be4

BREAKING CHANGE: this will introduce null safety and thus updates the signature of several methods.

Remove unused import of meta package

b351ed1

canLaunch and launch should return false if value is null

18a8d57

Processed feedback on PR 3142

6e84ec9

mvanbeusekom force-pushed the url_launcher_platform_interface_null_safety branch from 68a2dea to 6e84ec9 Compare October 14, 2020 07:07

blasten approved these changes Oct 14, 2020

View reviewed changes

Add missing analysis options

4555b55

Depend on plugin_platform_interface from GIT

bce0612

blasten merged commit ab36fed into flutter:nnbd Oct 15, 2020

mvanbeusekom deleted the url_launcher_platform_interface_null_safety branch November 2, 2020 09:33

[url_launcher] Url launcher platform interface null safety #3142

[url_launcher] Url launcher platform interface null safety #3142

Uh oh!

Conversation

mvanbeusekom commented Oct 12, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issues

Checklist

Breaking Change

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mvanbeusekom Oct 13, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

blasten commented Oct 14, 2020

Uh oh!

blasten commented Oct 14, 2020

Uh oh!

blasten left a comment

Choose a reason for hiding this comment

Uh oh!

mvanbeusekom commented Oct 15, 2020

Uh oh!

Uh oh!

mvanbeusekom commented Oct 12, 2020 •

edited

Loading

mvanbeusekom Oct 13, 2020 •

edited

Loading