Also, you should consider using Apple's CustomHTTPProtocol [1] as a starting point. It is extremely important to use NSURLSession insteand of NSURLConnection when overriding the URL Loading System for requests coming from a UIWebView. The UIWebView and NSURLConnection both limit the number of concurrent connections to a given host. It is possible for them to deadlock waiting for each other to have an open slot in their respective queues. If you override the URL Loading System with NSURLSession, this problem can't happen. I ran into this about a year ago in my app, and spent many emails talking with Apple's helpful Developer Technical Support team trying to figure this out.
Unfortunately, this means that you won't be able to support iOS6, but I assume that since you're talking about WKWebView, that may not be a concern. [1] https://developer.apple.com/library/ios/samplecode/CustomHTTPProtocol/Introduction/Intro.html -Heath Borders [email protected] Twitter: heathborders http://heath-tech.blogspot.com On Mon, Dec 8, 2014 at 2:54 PM, Mark Finkle <[email protected]> wrote: > I wanted to comment on the JIT difference in WKWebView. JS performance > alone is not really a good indicator for a webapp's performance. For now, I > am willing to trade Networking flexibility for a JS speed bump. Some > benchmarks [1] show that the JIT difference does not yield a dramatic > performance improvement. > > [1] > http://developer.telerik.com/featured/why-ios-8s-wkwebview-is-a-big-deal-for-hybrid-development/ > > > > > ------------------------------ > > I think a lot of our "platform" direction (DNT, Tracking Protection, Mixed > Content Blocking, SafeBrowsing) depend on accessing the URL Loading System. > > As Heath mentions, we will need to consider it for HTTP Auth and cert > features too. > > Let's start with UIWebView and see how things evolve. > > > ------------------------------ > > Background: we have two choices for embedding a web view in an iOS > application: UIWebView, which has been there since the early days, and now > with iOS8, the new WKWebView. The UIWebView is what for example Chrome and > pretty much every other third-party app uses while WKWebView is what Safari > (and newer third party apps) uses. > > The UIWebView is very minimal but it gets the job done. Basically you can > ask it to load content, handle navigation and execute JavaScript when a > page has loaded. But, no JIT. So about 3x slower than WKWebView. > > The WKWebView is new with iOS8 and exposes a much richer API. It has for > example wonderful gesture support so you can swipe left just like in Mobile > Safari. It also supports user scripts much better, which would allow us to > introduce HTML5 APIs that WebKit does not know about. And it runs Nitro at > full speed. > > It seems obvious to use the new WKWebView but there is a big limitation: > it is impossible to intercept the URL Loading System. I found this out when > I was trying to add support for a custom header (DNT) in a little > experiment. > > > https://github.com/st3fan/WebKitExperiments/blob/master/DoNotTrack/BasicBrowser/ViewController.swift#L6 > > How this works is as follows: by providing a custom NSURLProtocol class it > is relatively trivial to intercept URL loading. In my example I simply > build on top of the built-in NSURLConnection and the only custom thing I do > there is to add a DNT header for outgoing requests. This same mechanism can > also be used to inspect and modify requests for things like Mixed Content > detection and would probably be part of Tracking Protection. > > Now the sad news. Unfortunately this only works on UIWebView. I see that > my `CustomURLProtocol.canInitWithRequest()` is being called, but other than > that nothing happens. I assume this is because the WKWebView executes > network and content in a remote process. Which is good for security and > performance, but closes the door to customizations like this. > > So, it seems we have to make a choice between slower UIWebView or a less > optimal WKWebView. > > Note that there is not a good product definition just yet, but because so > many of our better features depend on access to networking, I can only > assume this will be a problem in the long run. > > I’ve been staring at this for a while now and I don’t really see a good > workaround. I’d love to hear some suggestions or questions. > > S. > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > > > > > _______________________________________________ > mobile-firefox-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/mobile-firefox-dev > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
