Skip to content
This repository has been archived by the owner on Feb 22, 2023. It is now read-only.

Add web url launcher #2119

Merged
merged 5 commits into from Oct 2, 2019
Merged

Add web url launcher #2119

merged 5 commits into from Oct 2, 2019

Conversation

harryterkelsen
Copy link
Contributor

Description

Adds the url_launcher_web plugin, the Web platform implementation of url_launcher.

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.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (flutter analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • The title of the PR starts with the name of the plugin surrounded by square brackets, e.g. [shared_preferences]
  • I updated pubspec.yaml with an appropriate new version according to the pub versioning philosophy.
  • I updated CHANGELOG.md to add a description of the change.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

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.

Copy link
Contributor

@amirh amirh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

overall looks good.

One minor detail - but one that we should decide on one and will probably affect all platform implementations for all plugins: url_launcher_<platform> or <platform>_url_launcher ? my tendency is to go with the former as that what we already used for fuchsia webview, and in the http://flutter.dev/go/federated-plugins which was reviewed by multiple people and no one commented on the naming...
I also feel like people the name should emphasize that this is a implementation more than that this is for the url_launcher plugin (especially once it get endorsed we don't expect people to find this plugin in pub and use it...)

Again it's a minor detail and I wouldn't spend the time discussing it normally, but once we publish there's no way back and as we'll probably want to be consistent across all plugins/platforms this is going to set the naming convention for all of them...

test('cannot launch "tel" URLs', () {
expect(canLaunch('tel:5551234567'), completion(isFalse));
});
});
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a way to test launch ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would require a lot of extra code. Rather than running the test using flutter test --platform chrome we would have to spin up our own instance of Chrome, somehow build the JS getting the Flutter Web SDK from somewhere, call launch, and determine that a new tab was opened with the correct API.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added some basic tests for launch

@stuartmorgan
Copy link
Contributor

url_launcher_<platform> or <platform>_url_launcher ? my tendency is to go with the former as that what we already used for fuchsia webview,

I think you mean the latter?

(especially once it get endorsed we don't expect people to find this plugin in pub and use it...)

Except that the doc explicitly describes cases (API extension) where people will directly use the implementation package; in that case, having foo_plugin and foo_plugin_bar in their pubspec.yaml is clearer than bar_foo_plugin.

But in the directory structure we picked having the platform first is probably nicer in terms of navigating the repository, so I think both have relatively small pros and cons, and either is fine with me.

@stuartmorgan
Copy link
Contributor

The web implementation package doesn't include the dummy iOS and Android files, so adding this to a project that targets iOS and/or Android will break them. Do you want to add the workaround, or are we just waiting for the real fixes to the Flutter plugin tooling on that?

@amirh
Copy link
Contributor

amirh commented Sep 30, 2019

url_launcher_<platform> or <platform>_url_launcher ? my tendency is to go with the former as that what we already used for fuchsia webview,

I think you mean the latter?

Oops, yes the latter.

@harryterkelsen
Copy link
Contributor Author

I have a slight preference for url_launcher_<platform> because "Web_____" may lead to confusion (for example, a plugin name starting with "view" or "assembly"), but I'm okay either way

@harryterkelsen
Copy link
Contributor Author

FYI, I changed the incremental_build.sh script to not ignore plugin folders without a pubspec.yaml (since this would also cause us to ignore all federated plugins).

Add url_launcher_web package

Test plugins even if they don't have a pubspec in the top-level folder

Bump up the pubspec version for new homepage URL

Add dummy podspec file for iOS

Remove unused import

Format test

Update check_publish.sh script
@harryterkelsen
Copy link
Contributor Author

I updated the PR so the tests run, and the publish check works properly, PTAL

@amirh
Copy link
Contributor

amirh commented Oct 1, 2019

I have a slight preference for url_launcher_<platform> because "Web_____" may lead to confusion (for example, a plugin name starting with "view" or "assembly"), but I'm okay either way

Ok, lets keep the current name.

Copy link
Contributor

@amirh amirh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few comments on the CI scripts, I think that change probably worth a separate PR though.

script/common.sh Outdated
CHANGED_PACKAGES="${CHANGED_PACKAGES},$package"
CHANGED_PACKAGE_LIST=("${CHANGED_PACKAGE_LIST[@]}" "$package")
fi
CHANGED_PACKAGES="${CHANGED_PACKAGES},$package"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like the pubspec.yaml logic was introduced to prevent a deleted package to be running on CI, maybe we can just check that the directory exists instead?

cc @gspencergoog who originally introduce this logic.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed this to check if the directory exists

@@ -12,8 +12,8 @@ source "$SCRIPT_DIR/common.sh"

function check_publish() {
local failures=()
for package_name in "$@"; do
local dir="$REPO_DIR/packages/$package_name"
for dir in $(pub global run flutter_plugin_tools list --plugins="$1"); do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems wrong to only look at the first argument (prior to this change it would check the packages for all arguments)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was because previously, check_publish was called with the dereferenced CHANGED_PACKAGE_LIST array, which passed the array items as separate arguments. Now there is only one argument, the packages list in a comma-separated list.

Copy link
Contributor

@amirh amirh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@harryterkelsen harryterkelsen merged commit 1d5301d into flutter:master Oct 2, 2019
stuartmorgan added a commit to stuartmorgan/plugins that referenced this pull request Oct 14, 2019
Follows the structure established in flutter#2119 to add a federated macOS
implementation of the url_launcher plugin.

Fixes macOS portion of flutter/flutter#41721
mormih pushed a commit to mormih/plugins that referenced this pull request Nov 17, 2019
* Move url_launcher to url_launcher/url_launcher

Add url_launcher_web package

Test plugins even if they don't have a pubspec in the top-level folder

Bump up the pubspec version for new homepage URL

Add dummy podspec file for iOS

Remove unused import

Format test

Update check_publish.sh script

* UPdate check_publish for federated plugins.

* Follow correct semver when bumping version

* Add some tests for `launch`

* Check if directory exists for CI
sungmin-park pushed a commit to sungmin-park/flutter-plugins that referenced this pull request Dec 17, 2019
* Move url_launcher to url_launcher/url_launcher

Add url_launcher_web package

Test plugins even if they don't have a pubspec in the top-level folder

Bump up the pubspec version for new homepage URL

Add dummy podspec file for iOS

Remove unused import

Format test

Update check_publish.sh script

* UPdate check_publish for federated plugins.

* Follow correct semver when bumping version

* Add some tests for `launch`

* Check if directory exists for CI
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
4 participants