>FWIW: KVO is explicitly mentioned in the WKWebView documentation. It is a really standard Cocoa pattern and modern APIs are exposing more and more state via KVO. It is not some kind of hack. It is just as official as the Delegate pattern.
I agree that KVO is an official API, and it's definitely not going away. It just has lots of warts and leads to very complex interactions. NSNotificationCenter also has unexpected complexities [1]. You might consider ReactiveCocoa [2] as a common abstraction point, though ReactiveCocoa is something of a global architecture decision that tends to permeate an entire codebase, so think hard about it. [1] http://lapcatsoftware.com/articles/nsnotificationcenter-is-threadsafe-not.html [2] https://github.com/ReactiveCocoa/ReactiveCocoa -Heath Borders [email protected] Twitter: heathborders http://heath-tech.blogspot.com On Thu, Dec 11, 2014 at 3:17 PM, Stefan Arentz <[email protected]> wrote: > > On Dec 11, 2014, at 4:10 PM, Mark Finkle <[email protected]> wrote: > > 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. > > > FWIW: KVO is explicitly mentioned in the WKWebView documentation. It is a > really standard Cocoa pattern and modern APIs are exposing more and more > state via KVO. It is not some kind of hack. It is just as official as the > Delegate pattern. > > 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. > > > So why don’t we decide it on a case by case basis. > > I completely agree that tab management should be done with a well defined > delegate. On the other hand, keeping track of the current displayed URL or > the back button enabled-state seems like a perfect match for KVO. I don’t > think we have to choose one or the other, both have their use cases. > > Sounds fair? > > 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
