Rework url_launcher API

[stuartmorgan-g]

The url_launcher API has been added to piecemeal over time, and at this point is kind of a mess. Major issues:

• People pass invalid URLs since it takes a String rather than a Uri; what happens to them is highly platform-specific.
• There are separate iOS-specific and Android-specific options for whether to use an in-app web view or launch the browser:
  • It's likely that people will want the same behavior most of the time, making them awkward to use.
  • The default behavior for the two is different, and in fact the iOS flag has three modes, not two, since it has special handling of null, making it extremely confusing.
  • This doesn't scale to other platforms (all desktop platforms could have in-app pop-up windows or overlay views, for instance)
• There's handling of iOS overlay brightness, which when it was added had to be done in the native plugin implementation code, but has since moved entirely into Dart, so doesn't need to be in the plugin at all since someone could easily write that wrapper themselves.

I think it's time to do a breaking change to the plugin that completely overhauls the API. My current proposal is https://github.com/stuartmorgan/plugins/blob/url-launcher-uri/packages/url_launcher/url_launcher/lib/url_launcher.dart, but I'll gather feedback and potentially iterated before moving forward. (Once I've settled on an API I'll do a change to the platform interface and the implementations first, so it's not shoehorning the new API into the old platform interface API.)

[ditman]

A couple of things:

• The change you proposed looks perfectly backwards compatible to me, so no need to do a breaking change at all, people will migrate to the new methods.
• When in web, many of the parameters don't make sense, and are especially confusing to users (for example: headers). Is this a good opportunity to have different APIs depending on the platform (THAT would be a really breaking change! :P)

[stuartmorgan-g]

My hope was that moving the in-app-specific settings into their own class world make it clearer that they are all only applicable to one specific mode.

We certainly could instead split the modes into a couple of methods. The main reason I didn't is that default uses both on some platforms. But it would make it very clear that only in-app accepts those parameters.

[ditman]

But it would make it very clear that only in-app accepts those parameters.

@stuartmorgan we've been discussing for a while having/allowing different APIs per platform, and I thought this was an example small enough to put it to the test.

(Admittedly the plugin is used by many people, and it might cause more breakage than good!)

[stuartmorgan-g]

It would be interesting to see what an API designed just for web looks like to see what overlap there is.

[ditman]

It would be interesting to see what an API desgined just for web looks like.

I think the web version of this would be to expand on the Link widget, so people get normal links, and then window.open, which is probably the "programmatic" way of opening new tabs (and popups), which the current version of the plugin doesn't treat differently (I guess it'd be similar to opening in a webview: new tab, in the browser: popup window? but that idiom from mobile doesn't translate to web too well in any case.)

One last comment, can: class WebConfiguration become class WebViewConfiguration? That way there's no confusion between Web (as a platform) and WebView (as the native API that lets you "turn off Javascript", but only on native!)

[ditman]

@Gene-Dana if you take a look at google sign in, that's how it's implemented (opens a popup with window.open, does things, and checks when the popup closes, either with a successful auth, or because the user canceled).

However, the google sign in flow is written with javascript; the url_launcher for web doesn't have that much control over the window that is being opened, nor returns a reference to it so it can be closed later.

[Gene-Dana]

@ditman I greatly appreciate your response and definitely these are things that I just learned !

This tutorial just helped me understand how to do exactly this!
https://itnext.io/flutter-web-twitch-oauth2-authentication-flow-implementation-77d239c72be5

@stuartmorgan The url_launcher implements the same dart:html package as this tutorial and with this package it handles redirecting. Would adding this functionality be within the scope of reworking the url_launcher api?

[stuartmorgan-g]

@Gene-Dana Sorry, I don't understand what you're asking. I don't see how that link relates to this issue at all.