
Facebook open-sources KVOController – simpler key-value observing for iOS - kimon
https://github.com/facebook/KVOController
======
seivan
Shameless plug. Here's mine
[https://github.com/seivan/SHKeyValueObserverBlocks#adding-
ob...](https://github.com/seivan/SHKeyValueObserverBlocks#adding-observer-on-
an-nsarray-to-keep-track-of-your-data-source)

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](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](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...](https://github.com/th-in-
gs/THObserversAndBinders/commit/a4cff51e0e465427594328be91026bd223718622)

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](https://github.com/seivan/SHKeyValueObserverBlocks/pull/5)

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

~~~
kimon
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.

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

[https://github.com/facebook/KVOController#usage](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!

~~~
kimon
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!

------
icodestuff
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.

~~~
kimon
KVOController 1.0.0 supports observing arrays and other ordered relationships,
just not values within. I filed
[https://github.com/facebook/KVOController/issues/5](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](https://github.com/facebook/KVOController).

~~~
icodestuff
> 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?

------
natasham25
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.

~~~
kimon
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.

------
Greenisus
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.

------
vjeux
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?

~~~
seivan
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.

