>I think we can catch that with code reviews. But if we have a bad feeling about using ‘raw’ KVO code then we can probably create a higher level wrapper to abstract away boilerplate code.
That totally makes sense. I just wanted to make sure you had all the facts. Good luck! -Heath Borders [email protected] Twitter: heathborders http://heath-tech.blogspot.com On Thu, Dec 11, 2014 at 2:05 PM, Stefan Arentz <[email protected]> wrote: > > > On Dec 11, 2014, at 2:53 PM, Heath Borders <[email protected]> > wrote: > > > > I agree with using WKWebView as a first-class citizen, however, I > suggest you implement callbacks with a custom delegate that wraps KVO > instead of injecting KVO code everywhere. > > Yes but that means that we go from ‘here is a progress bar that you just > have to tell about the webview it is showing progress for’ to ‘here is a > progress bar that can only work if a third object is going to listen to the > progress change events from the webview and relay them to the actual > progress bar’. I don’t think that is a bad design but it does add a lot of > overhead that is not needed when you use KVO to directly listen to state > change events of dependent objects. > > > KVO is very easy to get wrong. > > I think we can catch that with code reviews. But if we have a bad feeling > about using ‘raw’ KVO code then we can probably create a higher level > wrapper to abstract away boilerplate code. > > S. > >
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
