flutter_inappwebview
flutter_inappwebview copied to clipboard
pichillilorenzo
Support for Flutter Desktop
Environment
Flutter version: newest Plugin version: newest Android version: - iOS version: - Xcode version: - Device information: Windows / Linux / MacOS Desktop
Description
What you'd like to happen: I would like to have this to be compatible with the Flutter Desktop version. Most important for me would be the Flutter Desktop for Windows.
For macOS, it should be easy, as WKWebView is the same as iOS.
For Linux, I think we can use something like this: https://webkitgtk.org/.
For Windows, we can use Microsoft Edge WebView2 (https://docs.microsoft.com/en-us/microsoft-edge/webview2/).
Hey guys whats the progress here with desktop targets? Where can I follow the progress, if there isnt much work left to do I want to hire someone to finish the job.
To follow Flutter PlatformView API availability for Desktop, see:
- MacOS: https://github.com/flutter/flutter/issues/41722
- Linux: https://github.com/flutter/flutter/issues/41724
- Windows: https://github.com/flutter/flutter/issues/31713
The only thing I can do now, probably, is to implement only the InAppBrowser class (so, no Flutter widget integrated to the flutter widgets tree at the moment!) for these platforms.
For Linux and Windows platforms, it is also more difficult because I need to write native C++ code, so probably it will take more time (especially because I have zero experience with C++).
I think that MacOS will be the first platform to be supported because it should be the easiest one, using the same code of iOS
Here is an update:
Starting from plugin version 5.4.0, there will be a lot of deprecation that will help me to initialize the work for Desktop Support. It means that every event/class/method/property/etc. that starts with the "android" or "ios" keyword will be renamed without that keyword unless for specific reasons.
For example, events such as androidShouldInterceptRequest and iosOnNavigationResponse will be renamed to shouldInterceptRequest and onNavigationResponse (or something like this). So, androidShouldInterceptRequest, iosOnNavigationResponse, etc... will not be deleted, just deprecated respect to the new counterpart.
It doesn't mean that the particular event/class/method/property/etc. will be supported by all platforms. The list of platforms supported of an API will be documented on the specific Docs of it.
Also, consider to support this project making a donation: https://inappwebview.dev/donate/
This plugin is absolutely amazing! I would love to port my app which uses WebView to desktop. @pichillilorenzo Therefore I am curious if desktop support can only be achieved once the flutter team adds PlatformView support to flutter on MacOS, Windows and Linux? All of them are tagged with "P4" and will sadly take a long time to be implemented...
While researching about WebView and desktop platforms in Flutter I found a package which makes a WebView available for windows. @pichillilorenzo Maybe this can be used for this package on windows?
The desktop_webview plugin supports all 3 desktop platforms. Can that effort help inapp_webview?
It would be fine for inapp_webview to initially offer limited support only and open a separate window on desktop platforms. But it would be great if Flutter applications would only need one API, not two (inapp_webview on mobile and desktop_webview_window on desktop). One of the biggest pluses of Flutter is that it allows a single code base that works everywhere and offers good performance and good native bindings.
I'd rather use a desktop capable inapp_webview, as that produces support for SFSafariViewController on iOS. desktop_webview only does WKWebview, which is a bit of a second class citizen in the kingdom of Apple. uche WebRTC uche.
Hello
Is there any news about a plugin update with Linux platform support?
I can't find any webview plugins that work on Linux. I had read that from version 5.4.0 some actions would be initiated that would lead to a start of support towards the desktop.
Do you know anything about it? A roadmap of when it will also be supported by Linux? Around I find plugins that work for Windows, for macOS, for the web, except for Linux, which the only one is dekstop_webview_window but it's not good because it opens in a new window and I need it integrated into the app.
Thanks
It'd be great to support macos & windows.
Yeah, I think so. This will take flutter to the next level.
@pichillilorenzo recently I found the webview_cef package. Maybe until platform views are ready this could be a great alternative?
@CaptainDario I'm currently working on the macOS implementation (without platform views but using a separate Window such as the plugin you mentioned).
It should be available with 6.0.0-beta.3 soon.
The desktop_webview plugin supports all 3 desktop platforms. Can that effort help inapp_webview?
I guess you mean this package that opens a separate window. But the plugin I mentioned does not open a separate window (if i am not mistaken), it uses chromium embedded framework to render as a normal flutter widget.
Ah wow, I didn't notice it. Also, just checked platform view support for macOS and it seems it is already available in a certain way. I will try it
Ah wow, I didn't notice it. Also, just checked platform view support for macOS and it seems it is already available in a certain way. I will try it
Windows also already has some progress on the platform view problem.
Version 6.0.0-beta.3 with MacOS support is released now!
Unfortunately, I tried the current platform view implementation for MacOS but it still not working, so we need to wait for the Flutter team to fix it.
The current MacOS WebView implementations are the InAppBrowser and HeadlessWebView classes!
Check Setup MacOS
@pichillilorenzo that is great news! We are very happy to see the macOS support. I have already tried it and it works great. The way it opens in a separate window is fine for us. Are you also planning to add support for windows soon? Thanks in advance for you response.
@jaroslawdabrowski unfortunately, there is no plan to add support for Windows and Linux soon. They require C/C++ knowledge, which I don't have. There is a proposal for Windows to make C# usable for Flutter plugins that will help a lot:
- https://github.com/flutter/flutter/issues/64958
So, until then, there is no plan for Windows.
The Windows WebView2 component has been integrated into Flutter in a couple of repos, including this one. This utilizes off screen rendering via the Windows 10 API's to allow a non-windowed "in_app_webview" style integration.
I have had a quick go at integrating it into this library and it worked straight away so I think Windows integration is very achievable. Pull from my fork here and run 'flutter build windows --verbose' for a build in the 'example\build\windows\runner\Release' folder or 'flutter run -d windows '.
There is an outstanding issue with High DPI screens and I haven't considered licensing but it looks like a merging of the controllers used in each library would be possible. Only a proof of concept and I won't be able to take it much further due to time constraints. Please check licensing and give due consideration to the author if anyone takes it further
The Windows WebView2 component has been integrated into Flutter in a couple of repos, including https://github.com/jnschulze/flutter-webview-windows. This utilizes off screen rendering via the Windows 10 API's to allow a non-windowed "in_app_webview" style integration.
I have had a quick go at integrating it into this library and it worked straight away so I think Windows integration is very achievable. Pull from my fork at https://github.com/stevehayles/flutter_inappwebview and run 'flutter build windows --verbose' for a build in the 'example\build\windows\runner\Release' folder or 'flutter run -d windows '.
There is an outstanding issue with High DPI screens and I haven't considered licensing but it looks like a merging of the controllers used in each library would be possible. Only a proof of concept and I won't be able to take it much further due to time constraints. Please check licensing and give due consideration to the author if anyone takes it further
Very good news. I'm looking forward to it!
@stevehayles the problem is not that I can't develop the plugin for Windows or Linux. The problem is that they require C/C++ knowledge, which I don't have! Using C/C++ will be too much work for me. It's not straightforward. Also, plugin maintenance for these platforms will be a lot harder for me. At least, for Windows, I will wait for C# support, so that should be easier.
@pichillilorenzo I was just pointing anyone that was interested to my working solution which has the Windows WebView2 component integrated into your library. Pretty much all of the C++ code won't need touching and the build chain and plugin integration is also fairly complete. Having tested it, I have decided it's not the right solution for my particular use case but it's hard to search through the numerous forks these projects end up with and I figured it might be a good starting solution for someone.
Don't hold your breath on C# support in Flutter, that will be a very controversial inclusion....!
@stevehayles unfortunately, the integration you made isn't a valid integration for the plugin because it isn't using the official InAppWebViewController class or other classes of the flutter_inappwebview plugin.
It seems to be just a copy and paste of the Windows code of the other flutter plugin, so it's not the right way to do it.
All the integrations should use the main classes, such as InAppBrowser, HeadlesswebView, etc... (as I have done for the macOS platform), otherwise, it doesn't make any sense because it won't be a cross-platform plugin.
What do you mean by "controversial inclusion"?
What I mean is that C# is more suitable for me because it's more like Java, so it's easier to develop and maintain the plugin code for me.