A few thoughts: 1. I agree with others that we should embrace WKWebView. I have learned to avoid premature abstractions. Unless you have a use for the abstraction, it ends up just cluttering up the code until you get around to removing it. 2. I think Notifications and KVO each has it's strengths and weaknesses. My initial thoughts are that KVO seems nice for an outer object to "watch" an aggregated (compostion) object: Like Browser holding a WKWebView as a member. I guess I am more comfortable with well defined delegates, protocols or notifications for "cross-object" communication. If we decide to start with KVO, I think we should use it sparingly and explicitly. Let's avoid an explosion of KVO hookups and lose control over the code flow. 3. I agree with Wes in that we should create some "single responsibility" objects and not allow code duplication to creep into the code. Wes' examples of Browser/Tab management are good ones. Objects should not need to recreate how to determine the selected tab. We also don't want lots of objects watching via KVO just to cache the selected tab for use when a situation arises.
Finkle ----- Original Message ----- > 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
