While this looks nice, I think we've found in Fennec and desktop that eventually a whole lot of players want to know things like "Selected tab", "Closed tab", "Progress started", etc. The location bar would also have to listen to different tabs as we switch (or check on every message if this is a selected tab or not). I would rather we do this sort of messaging through a real message-bus this time. NotificationCenter seems well suited to that AFAICT.
- Wes ----- Original Message ----- From: "Stefan Arentz" <[email protected]> To: [email protected] Sent: Thursday, December 11, 2014 9:53:02 AM Subject: On abstracting away WKWebView 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 _______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
