Skip navigation.
 
mlKVO - Observing self from self
FROM : Daniel Jalkut
DATE : Sat Jul 01 17:43:04 2006

I'm using KVO to observe a keypath relative to "self." For example, 
I'm observing "myTree.apples" from an object with a keyed object 
"myTree."

This is very convenient because it means I don't have to carefully 
manage the addObserver/removeObserver status as "myTree" changes. 
But I've noticed that KVO, in an attempt to protect me from "bad 
stuff" actually limits my ability to use this technique.

In the object's "dealloc" method, it removes observation of itself. 
This should have the effect of cleaning everything up, right? But 
apparently KVO interferes much earlier - detecting my impending 
dealloc and warning me about the fact that there is still an observer:

> An instance 0x38f6a0 of class CueSpecifier is being deallocated 
> while key value observers are still registered with it.  Break on 
> _NSKVODeallocateLog to start debugging.


What's worse, is it apparently then removes the observer for me, so 
that when my responsible "self cleanup" occurs moments later, I see 
this in the console:

> Exception ignored while releasing an object in an autorelease pool: 
> [<CueSpecifier 0x38f6a0> removeObserver:<CueSpecifier 0x38f6a0> 
> forKeyPath:@"cueHandler.parameterMenuItems"] was sent to an object 
> that has no observers.


I guess this is tricky because KVO's watch-dogging is happening at 
the sneaky isa-swizzling level.

What are my options? Does anybody have a clean solution for observing 
self keypaths from self? I could figure out some way to manually 
remove observation before being dealloc'd, but at that point the 
convenience factor pretty much disappears.

Daniel

Related mailsAuthorDate
mlKVO - Observing self from self Daniel Jalkut Jul 1, 17:43
mlRe: KVO - Observing self from self Joakim Danielson Jul 2, 11:25
mlRe: KVO - Observing self from self Daniel Jalkut Jul 3, 02:06