> 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
