There was a discussion yesterday on IRC about abstracting/hiding WKWebView. I
would like to make a counter argument here and suggest we embrace the the
WKWebView APIs fully and not try to hide its existence.
Currently we have wrapped WKWebView in a Browser object. The Browser has
functions like canGoBack() and goBack(). I think this is redundant because
these map 1:1 to the WKWebView.
This adds a layer of complexity that we don’t need. Instead I would like to be
able to freely access the WKWebView and for example use Key-Value Observing to
update user interface elements (and internal logic) when the WKWebView’s state
has changed.
A good example of the power of directly talking to the WKWebView combined with
KVO is this:
https://gist.github.com/st3fan/df6e470f177044a41436#file-gistfile1-swift-L123
Here we have a LocationTextField that only needs to know what WKWebView it is
currently connected to. It then starts observing for URL changes and security
changes and updates its UI accordingly. The URL is now always up to date and
when the page has secure content, the location field turns green. Look how
little code this is. This is the Cocoa way of doing things. If we abstract away
the WKWebView then we are basically going to reinvent all of this by
introducing delegates and extra infrastructure code to do what the framework is
already giving us.
The same mechanism can be used for progress tracking, keeping back/forward
button state correct, showing a title, acting on page loads and a bunch more
things.
I think we should realize that WKWebView is the way forward on iOS. UIWebView
will likely be deprecated by iOS9 (which is summer next year) and Gecko will
never happen on this platform because the App Store forbids it. So lets use
WKWebView as a first class object and take advantage of the things it gives us.
What do you think?
S.
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
