Re: CoreData - re-faulting object and removing self-observers results in messages being sent to zombie
Re: CoreData - re-faulting object and removing self-observers results in messages being sent to zombie
- Subject: Re: CoreData - re-faulting object and removing self-observers results in messages being sent to zombie
- From: Frank Illenberger <email@hidden>
- Date: Wed, 3 Aug 2005 23:31:46 +0200
Jim and Bill,
I agree that there definitely has to be a better generic solution for
formulating change dependencies in CoreData.
These are the lessons I learned until now for the cases where
setKeys:triggerChangeNotificationForDependentKey: and handling your
caches in transient attributes does not suffice:
1. willChangeValueForKey/didChangeValueForKey are only called when
there is actually some object obeserving the key. This is an
optimization new to Tiger. In Panther, these methods were called even
when there was no one observing. So this is not a good place to hook in.
3. Self-observing: Is is a bit expensive because of the load of
notifications that are sent around, but it is working. So if I have a
lot of hooks that should signal a change in another object, I set up
a transient attribute - a NSDate - and set this to the current date
from all the places that should signal the change. Then I set up a
self-observer on that date to limit the number of observations. This
works even with undoes.
4. Removing the self-observers before deallocating: The trick that
worked for me is to hook into the release method and remove the
observer before dealloc gets called:
- (void)release
{
if([self retainCount]==1)
[self removeObserver:... ]
[super release];
}
But I agree: There should be easier ways to to this. One solution
would be to extend the existing setKeys:
setKeys:triggerChangeNotificationForDependentKey: method to accept
key paths:
setKeys: setKeys:triggerChangeNotificationForDependentKeyPath:
This would be based on the change notifications but it would be of
great use.
Cheers
Frank
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden