Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?
Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?
- Subject: Re: KVO Question: How to programmatically determine if one object is observing another on a keyPath and context?
- From: Richard Somers <email@hidden>
- Date: Mon, 10 Sep 2012 11:22:48 -0600
On Sep 10, 2012, at 5:59 AM, Motti Shneor wrote:
> Although I don't need such heavy-weapons, and I don't at all deal with programmatic bindings here, I'd still like (if possible) to learn some more about the implementation of your internal tools. I didn't yet have a chance to work with swizzling, and maybe its time I started.
>
> My case is not of complexity, but of performance. If I simply observe all the time, and then filter what I need, penalty would be too much. I get huge amount of observation-calls (every refresh of my core-data context) and I need to inspect lots
Method swizzling lets your replacement method make use of the original method, almost like subclassing. In my case it let me add a form of bindings introspection. For example, what objects currently have active bindings and what are those bindings. I have found that the tools available for debugging bindings to be almost non-existant. (None of the malloc diagnostics tools help and for some reason adding -NSBindingDebugLogLevel 1 has never helped.)
Given that bindings are just a relatively thin veneer on Key Value Observing perhaps there is some similarity here.
One of the problems I faced was that when an edit was underway certain objects with active bindings would cause an avalanche of KVO notifications resulting in a substantial performance penalty. One of the things I did to help alleviate the situation was to programmatically remove and recreate the binding for objects that did not directly participate in the edit.
I guess this does seem like a lot of work but then again most people would likely say that writing glue code is a lot of work.
--Richard
_______________________________________________
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