Re: KVO and Core data
Re: KVO and Core data
- Subject: Re: KVO and Core data
- From: Gideon King <email@hidden>
- Date: Tue, 10 Aug 2010 03:03:05 +1000
It's a graphical application, and when things change in the back end, I often need to move things around on the screen, so need to invalidate the drawing rect at the old location, perhaps remove some bezier paths, and then need to set it to need display at the new location. I was just thinking that it may be handy for situations like this where I may have a whole lot of different things that could happen in the back end, which all lead to the same action required at the front end (though I will probably still need to use something like a notification queue and coalescing to make sure that I only do the expensive calculations once for a bunch of related changes in the back end.
Gideon
On 10/08/2010, at 2:38 AM, Dave Fernandes wrote:
>
> On 2010-08-09, at 11:13 AM, Gideon King wrote:
>
>> Dave's idea of using + (NSSet*)keyPathsForValuesAffecting<Key> may help in some situations, but I don't think it's practical for all, especially where I'm using KVO for my front end to observe changes in the back end and react, where I sometimes need to know the before and after values. I'd have to think about that some more...
>
> Actually, it's particularly effective for keeping the UI updated and works with bindings. You provide an accessor method for your attribute and when called, the method first checks toOne's attributes that it depends on and then updates itself to be consistent before returning the new value. However, if you want the 'before' value, you will need your own caching/messaging in there somewhere. How is this information used?
>
> Dave
_______________________________________________
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