Skip to content

[webview_flutter] Update to standard platform interface structure #94051

Closed
flutter-team-archive/plugins
#6856

Description

@stuartmorgan-g

The webview plugin was (IIRC) the first plugin to use a platform-interface-like concept, and clearly predates most of what is now standard practice. In particular:

  1. The platform interface doesn't inherit from PlatformInterface
  2. The instance is managed in the app-facing package's class, not the interface package's class, which prevents self-registration
  3. The implementations implement rather than extend it (which would have been prevented if 1 weren't true)

Both 2 and 3 are problematic; 2 because it doesn't really allow for unendorsed implementations, and 3 because we are now in a situation where we essentially can't make any change to the platform interface—adding methods is effectively a breaking change. We can't just fix the implementation packages to extend and then change it, because nothing would prevent older versions of the implementation packages from getting a new version of the interface package and failing (unlikely though that would be).

There are two options:

  1. Do a breaking change to the interface package, and fix it to look like other packages.
  2. Replace the platform interface in a non-breaking way.

It's not clear to me yet whether 2 is possible because the flow is very unusual here, and involves multiple classes, at least on of which is publicly exposed through the app-facing package. (And it's not clear to me yet, not having worked extensively in this plugin, why any of that is true.) My general thought though is that we would define a new, much more standard-looking platform interface within the existing interface package, and then make a default implementation (also in that package) that implements the old interfaces as an adapter. (Because WebviewPlatform is publicly exposed in the app-facing package we'd need a breaking change there to clean that part up, but we're already planning a breaking change at the app-facing level so that's doable.)

/cc @bparrishMines @mvanbeusekom @BeMacized

Activity

  1. mvanbeusekom commented on Nov 26, 2021

    @mvanbeusekom

    This comment is ment as addition to @stuartmorgan's issue and hopefully gives some additional insight.

    The webview_flutter_platform_interface defines multiple classes that need to be implemented (or rather extended) by the platform specific packages to tie everything together. These classes are:

    1. WebViewPlatformController: this class defines the method channel interface and contains all methods that handle the communication between the Dart and the host platform. In the standard situations this class would inherit from the PlatformInterface;
    2. WebViewPlatformCallbacksHandler: this class defines callbacks from the host platform (e.g. onPageFinished which is called when a page is finished loading). This class can be implemented by consumers of the plugin to be informed about the events from the WebView control. The app-facing package wraps this in an internal class and exposes the functionality through callback methods that can be registered with the WebView widget, however the whole WebViewPlatformCallbacksHandler is still publicly exposed and changes are somebody implemented it;
    3. WebViewPlatform: this class is implemented by platform specific packages (i.e. webview_flutter_android and webview_flutter_wkwebview) to provide the correct platform view widget.
  2. added
    P2Important issues not at the top of the work list
    on Nov 28, 2021
  3. added
    P1High-priority issues at the top of the work list
    and removed
    P2Important issues not at the top of the work list
    on Dec 9, 2021
  4. bparrishMines commented on Feb 15, 2022

    @bparrishMines
    Contributor

    Design Doc for the new interface: flutter.dev/go/webview_flutter_4_interface

  5. bparrishMines commented on Sep 22, 2022

    @bparrishMines
    Contributor

    Update

    The platform interface, iOS implementation, and app-facing interface are all completed. The only tasks remaining are the Android implementation and some final improvements that I will list below.

    • Interface method runJavaScriptReturningResult should return an Object since iOS can return nums and bools.
    • Platform specific controller methods in the interface should be moved to their respective platform implmementations. (e.g. enableGestureNavigation for iOS and enableDebugging for Android.) This will also provide us a way to create an example of accessing platform specific features.
    • AutoMediaPlaybackPolicy is missing from the implementations. (This should be in the creation params on iOS and can be in the controller for Android).
    • LoadRequestParams.headers should have a default value.
    • JavaScriptChannelParams should be @immutable.
    • getScrollPosition should return an Offset and not a Point. This is opinionated, but I think Offset is more appropriate for the return value for a WebView. Point is from dart:math while Offset is from dart:ui and is exposed by the Flutter SDK.
    • WebResourceError should include optional isForMainFrame.
      - Change WebViewController -> WebController and WebViewWidget -> WebView? I've been thinking about the comments made in the interface doc and have been considering making this change. It is weird that we include Widget in the widget name. This could be a better alternative. Thoughts on this one @stuartmorgan @mvanbeusekom?
  6. stuartmorgan-g commented on Sep 26, 2022

    @stuartmorgan-g
    ContributorAuthor
    • Change WebViewController -> WebController

    What's the motivation for this one? WebViewController seems more specific and more clearly associated with the webview itself.

  7. bparrishMines commented on Oct 4, 2022

    @bparrishMines
    Contributor

    My thoughts on changing it stemmed from creating and following a consistent pattern. e.g.

    WebController -> WebView
    GoogleMapController -> GoogleMapView
    TabController -> TabBarView.

    Although, I agree that WebViewController is a more accurate name. And I would guess that people prefer accurate naming over consistent naming.

  8. scharfenort commented on Oct 27, 2022

    @scharfenort

    Hi guys,
    do you know, when the new version will be available. I do have a problem with <input type="file"> nothing happened.
    flutter-team-archive/plugins#3225

    Installed webview_pro, but there is an issue with choosing the camera (couldn't find meta data for provider with authority)

    Can you help me? Will this issue here fix my problem? Do you habe a workaround?

  9. bparrishMines commented on Oct 28, 2022

    @bparrishMines
    Contributor

    @scharfenort That issue is being tracked at #27924 and the PR to fix it is blocked by this. We are actively working on this one now, but I can't give you a time frame when it will be finished.

  10. github-actions commented on Mar 4, 2023

    @github-actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.

  11. locked as resolved and limited conversation to collaborators on Mar 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

P1High-priority issues at the top of the work listp: webviewThe WebView pluginpackageflutter/packages repository. See also p: labels.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions