Been wanting to try out https://github.com/apache/cordova-plugin-wkwebview-engine, but needs to use cordova-ios 4 alpha (whcih I assume I can’t just place in my local meteor build?). I also noticed Crosswalk iOs has recently come out, but the meteor crosswalk package only leverages it for android. Wouldn’t really know where to begin to try to make it work with ios.
Would be interested to hear if anyone has got it working, could really do with that performance increase in my app.
I’m currently working on rewriting the Meteor Cordova file serving and hot code push plugin. One of the goals is to align it with Cordova iOS 4.0, which should be out soon. These changes will finally allow us to properly support WKWebView. Just a little more patience!
Crosswalk iOS isn’t really an option because it doesn’t have a Cordova plugin yet (and it doesn’t bundle Chromium like the Android version, so it isn’t clear what the benefits are over the regular WKWebView support).
Well, the news I can give you is that I currently have WKWebView running with Cordova iOS 4.0 and our new plugin There is still some work to be done, so I’m hoping to release a preview sometime next month. That also depends on the state of Cordova iOS 4.0, which isn’t out yet and has some issues that need to be resolved first.
Hi @martijnwalraven - That really is fantastic news. Having the ability to use WKWebView for iOS and Crosswalk for Android, along with the re-written HCP, is going to completely change the landscape. I’m currently using WKWebView in a production app in the app store and the performance increase I got by using it was the difference between usable and unusable.
Images/fonts stored in your public/ folder should work up if you’re using the WKWebview build.
You have to set up access rules in your mobile-config.js:
// This is the relevant rule that will allow images/fonts access from your application
App.accessRule(’*’);
// These will set the orientation/and status bar to the same as the default for UIWebView
App.setPreference(‘AllowInlineMediaPlayback’, true);
App.setPreference(‘Orientation’, ‘landscape’);
App.setPreference(‘StatusBarOverlaysWebView’, true);
Also I set my Content-Security-Policy in my header as follows:
cdvfile no longer works with WKWebView however.
If you’re maybe trying to display images from cdvfile:// or file:/// urls you can’t use the cdvfile urls like in UIWebView on iOS.
For this you have to use the httpd module, and set up a local server that proxies to the directory you want to serve content from.
METEOR CORDOVA DEBUG loading filepath: /var/mobile/Containers/Data/Application/2B3163B7-050C-4DFD-A881-8C40C32BF927/Library/NoCloud/meteor/f5f36961d11669d2bae797ca6d590e7d51a87985/search-logo.png for path: /search-logo.png
Do you have a simple example application that exhibits this behavior? I’d be happy to look at it and try to figure out the difference and why my application behaves differently.
I dont have simple example. I’ll try to make one.
But there is one strange thing: if i run app like this:
meteor run ios --port 3001 --mobile-server http://localhost:3001
it works, and loads all images fine.
And if i build app
meteor build out --server https://myserver.ltd:443
and then open project with XCode and build there, images not loading.
Here is a simple test: https://github.com/scsirdx/wkwebview_test
If you run app using meteor run ios, you will see custom background. But if you build app using meteor build out --server http://localhost, and then open project from XCode and build there, you will not see custom background, and will got that strange message in debug console.
Okay, so I took a look at this, and definitely there seems to be an issue proxying items from public after the first load of the application.
It has something to do with setting the httpd module to proxy from the cordova.file.applicationDirectory, rather than from cordova.file.dataDirectory.
meteor_cordova_loader.js checks if there are any new versions, then does an autoupdate and sets window.location to point at the proxy. If there are no new versions, it calls ‘fallback’ that points at the scripts in the cordova.file.applicationDirectory path.
Clearly it’s not desirable to have the user not see any images on the first load of the application until it has received an autoupdate. I think I actually noticed this in my own application, but it autoupdated so quickly I thought it was a red herring and had just gone away.
I’ll look around to see if there is a way I can correct this.
In the meantime, can you get your bundled application on the same network as the server, let it autoupdate, and check if you can see images then?
I can see in your demo app the gridded 3-box background.
The problem is that my cordova application is totally different than main application, so no autoupdates, only files that bundled within. It all working fine without WKWedView, even with crosswalk (android).
I updated to 1.5 as well. When I run the project via emulator using XCode, any images or custom fonts are not displayed. When I run it on an actual device using XCode, I don’t even see HTML displayed on the screen. All the files are loaded though and templates rendered, but the app just shows splash screen and then background of the app and nothing else.
!
There is still some work to be done, so I’m hoping to release a preview sometime next month. That also depends on the state of Cordova iOS 4.0, which isn’t out yet and has some issues that need to be resolved first.