-
Notifications
You must be signed in to change notification settings - Fork 9.7k
[webview_flutter_wkwebview] Start work on new ios implementation #4626
[webview_flutter_wkwebview] Start work on new ios implementation #4626
Conversation
| break; | ||
| } | ||
|
|
||
| if (_isGreaterOrEqualVersion(await systemVersion, '10.0')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative to having this version check logic would be to only support mediaTypesRequiringUserActionForPlayback and handle calling the other methods with platform code. However, I wanted to try a solution of handling version conflicts in Dart. A future feature may require a more complex solution than a 1 liner like this one.
| /// cannot change those settings dynamically later. | ||
| class WebViewConfiguration { | ||
| /// Indicates whether HTML5 videos play inline or use the native full-screen controller. | ||
| set allowsInlineMediaPlayback(bool allow) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| /// | ||
| /// Use [AudiovisualMediaType.none] to indicate that no user gestures are | ||
| /// required to begin playing media. | ||
| set mediaTypesRequiringUserActionForPlayback( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packages/webview_flutter/webview_flutter_wkwebview/CHANGELOG.md
Outdated
Show resolved
Hide resolved
| /// Deprecated for iOS >= 10.0. | ||
| /// | ||
| /// Passing false indicates the videos can play automatically. | ||
| @Deprecated( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this code going to be entirely internal to the package? We shouldn't deprecate our internal wrappers when we know we'll be using them.
| throw UnimplementedError(); | ||
| } | ||
|
|
||
| /// Deprecated for iOS >= 9.0. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's all we support now, so this is dead code. We just never cleaned up the implementation after changing the min version (I guess we missed it in the scrub).
| /// app’s interface. For example, if your UI includes forward and back buttons, | ||
| /// connect those buttons to the [goBack] and [goForward] methods of your web | ||
| /// view to trigger the corresponding web navigation. Use the [canGoBack] and | ||
| /// [canGoForward] fields to determine when to enable or disable your buttons. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should not be duplicating docs wholesale from Apple code.
I would much prefer we say something like:
"Wraps WKWebView. See insert-link-here for documentation".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was back and forth about to what extent we should document these classes. I think this is a good pattern moving forward. I think this would also pair well with testing that links are up to date. I created an issue for it: flutter/flutter#96974
|
|
||
| /// The system version of the iOS device. | ||
| /// | ||
| /// If null, this value is retrieved asynchronously. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This documentation seems confusing; AFAICT is is describing what clients of this code might do, not anything this class does.
| /// If null, this value is retrieved asynchronously. | ||
| final FutureOr<String>? systemVersion; | ||
|
|
||
| /// The handler for constructing [web_kit.WebView]s. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's for creating webviews, isn't it a Factory rather than a Proxy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On Android, this class is also used to call static methods. So there is a possibility that it could be used for more than constructing WebViews. I updated the documentation.
| pluginClass: FLTWebViewFlutterPlugin | ||
|
|
||
| dependencies: | ||
| device_info_plus: ^3.1.1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I definitely don't want to do this. We should build the specific functionality we need into the plugin.
| return _parseVersion(first).compareTo(_parseVersion(second)) >= 0; | ||
| } | ||
|
|
||
| Version _parseVersion(String versionStr) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub_semver is overkill here; you're already writing manual parsing code anyway, and the set of things it needs to support is smaller than pub_semver (there's no iOS 10.0.7+3-dev for instance). You can eliminate the dependency and just parse to a three-element array then compare in a loop.
| if (requiresUserAction) web_kit.AudiovisualMediaType.all, | ||
| if (!requiresUserAction) web_kit.AudiovisualMediaType.none | ||
| }; | ||
| } else if (_isGreaterOrEqualVersion(await systemVersion, '9.0')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is always true, so should just be the else.
|
@stuartmorgan This is ready for another review. I decided to remove the logic for checking the version since it can be easily handled with platform code: https://github.com/flutter/plugins/blob/main/packages/webview_flutter/webview_flutter_wkwebview/ios/Classes/FlutterWebView.m#L568 |
stuartmorgan-g
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this took forever to re-review :( LGTM with some small nits.
| /// | ||
| /// Wraps | ||
| /// [WKWebView](https://developer.apple.com/documentation/webkit/wkwebview?language=objc). | ||
| class WebView { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should actually keep the WK prefix on these? It's not standard Dart, but it would make it very clear that these are just mirroring the corresponding ObjC class.
I could go either way on it, but I thought it was worth raising.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this idea. I added WK to all the webkit classes.
| import 'web_kit/web_kit.dart' as web_kit; | ||
|
|
||
| /// A [Widget] that displays a [web_kit.WebView]. | ||
| class WebViewCupertinoWidget extends StatefulWidget { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably not call this Cupertino since we'll likely add macOS support to this package at some point, and in Flutter terminology Cupertino is specifically iOS. WKWebViewWidget? Although that could be confusing, especially if we put WK on the other classes. How about WebViewWebKitWidget?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used Cupertino because it is used as the name of the WebViewPlatform implementation, but I think we should also update that with the new plugin interface. What are your thoughts on WebKitWebViewWidget? I was also, coincidently, updating the Android implementation to AndroidWebKitWebViewWidget.
This also made me consider that this plugin is called webview_flutter_wkwebview, but the Apple library is called WebKit and WKWebView is only a class in the library. However, the Android library could technically be called WebKit too, so I could understand why are plugin naming scheme wouldn't be consistent.
But all in all, I was considering
| Platform | Platform Implementation Prefix | Library File Name |
|---|---|---|
| iOS/MacOS | WebKit... | web_kit.dart |
| Android | AndroidWebKit... | android_web_kit.dart |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like WKWebView because it's less ambiguous; webkit doesn't really say much if you don't know its intended to be a library name. UIWebView was also WebKit-based, for instance. While WKWebView is only one class, it's the core class, with all the others being supporting classes.
packages/webview_flutter/webview_flutter_wkwebview/lib/src/webview_cupertino_widget.dart
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| /// An implementation of [WebViewPlatformController] with the WebKit api. | ||
| class WebViewCupertinoPlatformController extends WebViewPlatformController { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same name change here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
conversation continued in #4626 (comment)
Start of iOS side of: flutter/flutter#93732
Starts the Dart side of the platform specific implemention for iOS. Created
WebViewCupertinoWidgetand added support forWebSettings.allowsInlineMediaPlaybackandAutoMediaPlaybackPolicy. This currently has no effect on the working iOS implementation.The branch that contained all the changes for Dart came out to about
9300lines of code. This is the first PR to add all the api piece by piece.No version change:
This is only the initial commit to flutter/flutter#93732 and doesn't make any changes to the current implementation.
No CHANGELOG change: Incremental unused code doesn't need to be noted in the CHANGELOG.
Pre-launch Checklist
dart format.)[shared_preferences]pubspec.yamlwith an appropriate new version according to the pub versioning philosophy, or this PR is exempt from version changes.CHANGELOG.mdto add a description of the change, following repository CHANGELOG style.///).If you need help, consider asking for advice on the #hackers-new channel on Discord.