[TIMOB-17723] iOS8: Provide support for the WKWebView as Titanium's WebView in iOS
GitHub Issue | n/a |
---|---|
Type | Improvement |
Priority | Medium |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2016-12-25T13:37:19.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Backlog |
Components | iOS |
Labels | TCSupport, hyperloop-examples, ios8 |
Reporter | Mauro Parra-Miranda |
Assignee | Hans Knöchel |
Created | 2014-09-18T06:59:47.000+0000 |
Updated | 2018-08-06T17:49:36.000+0000 |
Please note some outstanding bugs with the current implementation. Are we comfortable with those? http://www.sencha.com/blog/apple-shows-love-for-html5-with-ios-8
As long as loading a local HTML file doesn't work we shouldn't use it.
Here is the OpenRadar bug for loading local files: http://www.openradar.me/radar?id=5839348817723392 It's unclear if that's just a temporary problem or a security stance.
It looks like local html can work just fine: http://atmarkplant.com/ios-wkwebview/ I have not ran the code in the above mentioned article. I'd suggest making this a separate module for now. This is useful for hybrid developers now (even if it only loads remote html), but like Fokke said, I wouldn't replace the implementation of Ti.UI.createWebView just yet.
There is a workaround to this issue which is demonstrable in the following sample project: https://github.com/shazron/WKWebViewFIleUrlTest The workaround is to copy the web content to a temporary directory inside the app sandbox and to give the WKWebView a URL to it there.
Is this planned for 4.X ?
We would consider it if the workarounds are acceptable. Thoughts from others?
I'm checking out how they did it on a plugin for Cordova... It seems they had to spawn a local web server to serve the local html files... it seems pretty unacceptable to me in terms of performance. All radar files on this bug are still open since iOS 8 release. They already fixed it on WebKit but Apple haven't replicated it to iOS yet... perhaps on iOS 9 ?! http://openradar.appspot.com/20160687 http://www.openradar.me/18039024
Was support for WKWebview ever included in a TiSDK? There is an issue with JQuery in iOS 9 https://github.com/jquery/jquery-mobile/issues/8254 which appears to be resolved by using the WKWebView. Thanks, Travis
Not completely fixed. WKWebView still requires a few improvements and features to deliver what Ti Webview can do. Links here for further reference when we revisit this ticket: https://github.com/ShingoFukuyama/WKWebViewTips http://stackoverflow.com/questions/26501172/launching-phone-email-map-links-in-wkwebview
Would it be an idea to implement Crosswalk instead? https://crosswalk-project.org
Crosswalk is an interesting idea. While I like the capabilities it brings to the table. I am not a big fan of the additional bloat it would bring. https://crosswalk-project.org/documentation/about/faq.html bq. How big is the Crosswalk Project runtime, and how will it affect my application's size? {quote} To give a rough idea, the HTML/JS/CSS for one of the project's sample applications takes up 24Kb of disk space. Once this application is packaged with its own Crosswalk 10 (x86 Android) runtime, the apk file size is ~20Mb. Installed, the application takes ~58Mb of disk space. {quote} This could fly as a ti.plugin that could be optionally included, but I wouldn't want this as a default.
[~sophrinix] agree
Any progress on this issue? I think iOS9 supports loading from a file:/// url. Cordova has implemented it last year: https://issues.apache.org/jira/browse/CB-9567 Could we at least have an option to use it? A lot of us don't need the few features that aren't properly supported.
Example of iOS WKWebView implementation in Alloy using Hyperloop and Ti SDK 5.4 added to the [Hyperloop Examples](https://github.com/appcelerator/hyperloop-examples) repo
Thanks for that but Hyperloop is no good to most developers since we don't have access to it.
We are not resolving the ticket as fixed with Hyperloop. This ticket is still in our backlog and we will address this when resources and time permits us. We want to maintain parity cross platform as much as possible for Titanium SDK, and because I think there's quite a few API from UIWebView that just can't be implemented in WKWebView, and vice versa (probably why Apple still supports both instead of replacing one with another), we may have to do a platform-exclusive implementation. So we will try our best to do this after working on other critical tickets. PRs are very welcomed for Ti.UI.iOS.WKWebView :)
Yep let's be honest the ticket has been up for 2 years now, this is never going to be added by Appc. Looks like if we want it, we have to build it ourselves.
[~bearus] You can see the obvious reasons why it has not been implemented, yet. Summary for you: - Parity with UIWebView - Parity with Android & Windows - Minimum version iOS 8 (+ fallback behavior for iOS < 8) Replacing a whole API is not just replacing some classes (unfortunately \:-).
But WKWebView is now encouraged for a couple years and this should be important to implement too. It is a pretty basic native functionality. Fallback pre-iOS 8 shouldn't be hard either, it is already there. Loop modules just did an implementation: http://loopmodules.com/downloads/ti-webview/
I will jump on the pile and say I have been waiting desperately for WKWebview as well. For us hybrid app developers it just seems like a no-bainer. Theres no reason it need to have any Android parity or replace the current web view, just sit along side web view as Apple has intended it for now. Ti.UI.iOS.WKWebView as has been mentioned. Appcelerator by its very design/existence is for us ppl that don't exactly know or understand native iOS development so we are here, so please give us the tools to make our apps really powerful and hide the fact that they are not exactly native apps. WKWebview with its speed lets us do this Humble request of course
Spent some hours on this and made a Proof Of Concept for constructing a
Ti.UI.iOS.WebView
: https://github.com/hansemannn/titanium_mobile/commit/961b259d5278190993bebc8645d6a66e1e8817f5 It basically supports local and remote URL's, blob data and HTML strings, it has basic support for all load-specific events. *app.js*:*remote_test.html* (thanks to [~kosso]!)
So if anyone wants to use or improve this, go ahead. But we won't give official support for this for now, so please do not comment on the usage in this ticket. It's more a functional template for those who really need to use this instead of the
Ti.UI.WebView
.Nice one Hans! Just found this after spending all day looking at this [https://github.com/kaga/Titanium-Module-WKWebview] module. It would be great to add the ability to use
postMessage
to communicate to an app from remote HTML. (evalJS is local only) I have also made some progress in adding the remote postMessage ability to an Android webView too, using an android module which I had a go at making.Just a follow-up to this. I've tried (badly) to create PoC iOS and Android modules to cater for a (kind of)
postMessage
ability from remote HTML. I've tried to use a lot of Hans' WKWebView code here to try and get things working. The modules *do* work (kinda) but could do with plenty of improvement. (Especially since I do not consider myself a *proper* Objective-C or Java developer ;) ) https://github.com/kosso/titanium-postmessage-webviewI think to do a real replacement for the current webview it would be important to do the the Ti.App.fireEvent support that is currently supported for communication between titanium and webview
Hey guys, quick update on my above PoC: * It now supports webview-app-communication (currently only from the webView to the app, not the other way around - PR's welcome) * Support for common navigation flows (
goBack
,goForward
,reload
,loading
,canGoBack
,canGoForward
) * JS evaluation e.g.* New
progress
event for real-team progress * Other supported API's: Picture-inPicture, 3D-Touch, custom user agent, airplay playback, inline playback, certificates, incremental rendering Happy christmas!Resolving this ticket as fixed. The module now covers all use-cases we know from the
Ti.UI.WebView
and many more (see above). For event handling, use thepostMessage
method for context-based communication from the webview -> app andevalJS
for app -> webview. Parity withTi.App
events are limited by the native API and won't be supported in this API. Just like theTi.SafariDialog
, this module will stay independent to achieve a more flexible development process apart from our SDK releases. Please feel free to contribute to the project!Cleaning up older fixed issues. If this issue should not have been closed as fixed, please reopen.