Facebook open-sources KVOController – simpler key-value observing for iOS | Hacker News Reader

Facebook open-sources KVOController – simpler key-value observing for iOS

github.com

31 pointskimon14 comments

Shameless plug. Here's mine https://github.com/seivan/SHKeyValueObserverBlocks#adding-ob...

Comes with bi- and uni-bindings. I like mine better but I wouldn't have done the auto-removal of observers without Yan Raboviks swizzling magic https://github.com/rabovik/RSSwizzle credits due.

I set a toggle in case you feel that's too dangerous to shut it off - Something I use.

I compared a couple of ways of dealing with that, including writing some of my own and I think Yan does it the best.

When doing my own I had some discussions with James Montgomerie regarding race conditions and dealing with class hierarchies. He had solved with a different way here himself: https://github.com/th-in-gs/THObserversAndBinders

Here's the discussions between us regarding the swizzling magic (that Facebook also does here) https://github.com/th-in-gs/THObserversAndBinders/commit/a4c...

The pull requests leading up to me going with Raboviks library (due to better code and smarter implementation)

Test for infinite loop when deallocating: https://github.com/seivan/SHKeyValueObserverBlocks/pull/5

New test to ensure dealloc of observed objects runs: https://github.com/seivan/SHKeyValueObserverBlocks/pull/2

This is a useful collection of links. One point of note, Facebook's solution doesn't rely on swizzling. Much like THObserversAndBinders, KVOController ties observation to the controller scope.

We use a shared controller instance, that acts as a receptionist for all KVO notifications, as well as a weak reference to the observer, in order to safely allow observer removal on dealloc.

Ah, thanks for correcting me. I didn't have time to go through it yet.

https://github.com/facebook/KVOController#usage

By controller does the readme refer to the KVOController instance? I assume this is a property on the class that uses it, and once the class gets dealloced, its observer also get dealloced? FBKVOController

Hmm... I think this is a much better idea! Much cleaner than what I current got going, but then again we don't offer the same api. Thanks for correcting me!

Correct. Add a strong reference from observer to KVOController instance via a property or instance variable and you've achieved un-observation on observer dealloc :)

This usage pattern is quite common. We'll look into calling this out more explicitly in the readme. Thanks for the feedback!

Looks like it's implemented similarly to MAKVONotificationCenter, except that it doesn't support observation on arrays/array indexes. And why does it need to manually call the shared controller's -observeVFK... when the Initial option is set? That should be called automatically by the KVO machinery. It's a bit concerning.

Also it seems like keeping track of the additional controller objects would be a PITA.

KVOController 1.0.0 supports observing arrays and other ordered relationships, just not values within. I filed https://github.com/facebook/KVOController/issues/5 to track. Features requests are welcome.

Performing the initial callback manually, avoiding the KVO initiated one, was shown to be a performance improvement under certain KVO configurations.

We've updated the readme to include an example tracking the controller object. An instance variable should all that is necessary: https://github.com/facebook/KVOController.

> Performing the initial callback manually, avoiding the KVO initiated one, was shown to be a performance improvement under certain KVO configurations.

Please elaborate. I've been re-implementing KVO, and have not seen this. What configurations?

Also, adding a controller ivar/property is rather invasive, don't you think?

KVO is built-in to iOS, but it has some serious issues. One BIG issue is that you have to register to observe a key in order to de-register from it later. If you never register for the key (because it is dynamic for example), and try to de-register, the app will crash. It's a pretty big issue, and this seems to handle it in a pretty elegant way.

Elegant and elegant, the swizzle (alter it in runtime) the class to remove observers on dealloc (afaik I haven't seen the source yet)

This was the principal motivation behind KVOController. Manually tracking registered observers is tedious and error prone. We hope you give KVOController a try, feedback from the community is welcome.

I remove observers within a @try {} @catch{} block. The exceptions are caught and I can fix where necessary.

I'm looking forward to trying this. KVO is very powerful (I used it extensively in my last app: Well), but it's delicate. Registering/unregistering, making sure you write methods to properly fire KVO events for collections, etc.

At a first glance, this seems like Angular's digest loop. Can someone make a more elaborate comparison for people that know nothing about iOS?

It's basically observing properties on NSObject subclassed classes. It doesn't work properly with UIKit, but most other stuff it works 'fine'. According to some smarter people than myself, the internals of KVO is a giant mess. But that's beyond me.

Reply on news.ycombinator.com