Re: Who is responsible for removing observers in longer key paths
Re: Who is responsible for removing observers in longer key paths
- Subject: Re: Who is responsible for removing observers in longer key paths
- From: Keary Suska <email@hidden>
- Date: Thu, 01 Mar 2012 13:39:23 -0700
On Mar 1, 2012, at 12:26 PM, Per Bull Holmen wrote:
> In my current project I have a controller object, that the view can
> bind to, with the following key path:
>
> parameterInfo.<parameterName>.<attributeName>
>
> "parameterInfo" is a literal key name, <parameterName> maps to a
> parameter in a plug-in, and must be resolved at run-time.
> <attributeName> is one of several attribute names, such as "minValue",
> "maxValue" etc. There is a value object that represents parameterInfo,
> which is of class PBH_ParameterInfo. Since the information in the tree
> rarely changes, I thought it would be easier to make it immutable, so
> the parameterInfo object will return the same (pointer equal)
> NSDictionary object for each key throughout its entire lifetime. When
> the info in the tree changes, the controller just makes a new
> parameterInfo instance, and replaces the entire tree with [self
> setParameterInfo:newParameterInfo]. What happens then is:
>
> 1) The view correctly updates, meaning it must have received the notification.
> 2) The old parameterInfo object is correctly deallocated.
> 3) I get an error in the console saying the parameterInfo object is
> being deallocated while there are still observers attached.
>
> These observers are clearly registered under-the-hood by NSObject's
> (?) implementation. When the controller object is asked to register an
> observer for the key path parameterInfo.linearGain.maxValue, it goes
> to the next property in the chain (parameterInfo), and registers some
> sort of proxy pbject as an observer for linearGain.maxValue. So my
> question is who is responsible for removing the observation when it is
> no longer needed, and how shall I make it happen The Right Way? The
> old object is being deallocated by NSAutoreleasePool, so all observers
> are already notified that the parameterInfo property has changed.
> Shouldn't NSObject's implementation already know that the observation
> is no longer needed? After all, the old PBH_ParameterInfo instance is
> no longer part of the original key path being observed.
It is the responsibility of the observer to remove observation. The bindings system handles this automatically, but not always on your timetable so you could end up deallocating an object before the observers have updated. How/why I can't tell you, but I have run into this issue myself. I don't recall specific but if memory serves me, you can work around this issue by putting an NSObjectController in the xib whose purpose is to manage the PBH_ParameterInfo object, and change its content when you need to change the object.
HTH,
Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden