FROM : Jon Hull
DATE : Fri Jul 28 22:54:58 2006
It looks like your problem is not with KVO, but with retain/release
(Memory management). Making sure that you have proper accessors (and
always use them) will go a long way towards fixing your problem.
myAge also needs to be an instance variable of the Person class.
Right now, it is a local variable which is going away when
awakeFromFetch
ends, though it is now being transfered to a class variable before
that for some reason(???). I suggest dumping the class variable and
using an instance variable w/ accessors.
in the Person class:
-(void)setAge:(Age*)newAge
{
if(myAge != newAge){
[myAge autorelease];
myAge = [newAge copy];
}
}
-(Age*)age
{
return myAge;
}
This will also give you KVC/KVO compliance! I suspect that this is
part of why your KVO wasn't working... How is supposed to know the
value has changed if it isn't changed in a KVO compliant way?
It also sounds like you might just want to use a dependent key rather
than KVO in this situation (but I don't know your exact situation).
BTW, you can also use [self setAge:nil] in the dealloc method... you
should never call dealloc directly (it will only lead to headaches).
Thanks,
Jon
On Jul 28, 2006, at 6:13 AM, Arthur C. wrote:
> Finally I have a working solution. It sets up KVO again after
> application restart. It is as follows:
>
> @implementation Person
> NSMutableArray *myAgeArray;
>
> +(void) initialize
> {
> myAgeArray = [[NSMutableArray arrayWithCapacity: 5] retain]; // or
> any number
> }
>
> -(void) awakeFromFetch
> {
> // first, fetch the 'Age' object with index equal to [self index]
> using NSFetchRequest
>
> Age * myAge = [[Age alloc] init];
> myAge = [fetchResults objectAtIndex: 0]; // only one object
> gets fetched
> [myAge index]; // to get rid of the 'fault' state (!)
> [myAgeArray addObject: myAge];
>
> [self addObserver: [myAgeArray lastObject]
> forKeyPath:@"yearofbirth" options: NSKeyValueObservingOptionNew
> context:managedObjectContext];
> }
>
> -(void) dealloc
> {
> [myAgeArray dealloc];
> [super dealloc];
> }
>
> The point is that the fetched 'Age' needs to be retained, or else
> it will get autoreleased and dealloced. The global array takes care
> of that. The solution appears to work OK, but maybe there is a more
> efficient way?
>
> I believe this problem is covered in the KVO programming Guide,
> where it (only) says:
> "Note: The key-value observing
> addObserver:forKeyPath:options:context method does not retain the
> observing object or the observed objects. You need to review your
> application's requirements and manage retain and release for the
> observing, and observed objects."
>
> This looks not particularly enlightening to me, so I will file a
> documentation enhancement request (in particular a piece of sample
> code would do well).
>
>
> Thanks for your time,
>
> Arthur C.
>
> _________________________________________________________________
> Hotmail en Messenger on the move http://www.msn.nl/services
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>
DATE : Fri Jul 28 22:54:58 2006
It looks like your problem is not with KVO, but with retain/release
(Memory management). Making sure that you have proper accessors (and
always use them) will go a long way towards fixing your problem.
myAge also needs to be an instance variable of the Person class.
Right now, it is a local variable which is going away when
awakeFromFetch
ends, though it is now being transfered to a class variable before
that for some reason(???). I suggest dumping the class variable and
using an instance variable w/ accessors.
in the Person class:
-(void)setAge:(Age*)newAge
{
if(myAge != newAge){
[myAge autorelease];
myAge = [newAge copy];
}
}
-(Age*)age
{
return myAge;
}
This will also give you KVC/KVO compliance! I suspect that this is
part of why your KVO wasn't working... How is supposed to know the
value has changed if it isn't changed in a KVO compliant way?
It also sounds like you might just want to use a dependent key rather
than KVO in this situation (but I don't know your exact situation).
BTW, you can also use [self setAge:nil] in the dealloc method... you
should never call dealloc directly (it will only lead to headaches).
Thanks,
Jon
On Jul 28, 2006, at 6:13 AM, Arthur C. wrote:
> Finally I have a working solution. It sets up KVO again after
> application restart. It is as follows:
>
> @implementation Person
> NSMutableArray *myAgeArray;
>
> +(void) initialize
> {
> myAgeArray = [[NSMutableArray arrayWithCapacity: 5] retain]; // or
> any number
> }
>
> -(void) awakeFromFetch
> {
> // first, fetch the 'Age' object with index equal to [self index]
> using NSFetchRequest
>
> Age * myAge = [[Age alloc] init];
> myAge = [fetchResults objectAtIndex: 0]; // only one object
> gets fetched
> [myAge index]; // to get rid of the 'fault' state (!)
> [myAgeArray addObject: myAge];
>
> [self addObserver: [myAgeArray lastObject]
> forKeyPath:@"yearofbirth" options: NSKeyValueObservingOptionNew
> context:managedObjectContext];
> }
>
> -(void) dealloc
> {
> [myAgeArray dealloc];
> [super dealloc];
> }
>
> The point is that the fetched 'Age' needs to be retained, or else
> it will get autoreleased and dealloced. The global array takes care
> of that. The solution appears to work OK, but maybe there is a more
> efficient way?
>
> I believe this problem is covered in the KVO programming Guide,
> where it (only) says:
> "Note: The key-value observing
> addObserver:forKeyPath:options:context method does not retain the
> observing object or the observed objects. You need to review your
> application's requirements and manage retain and release for the
> observing, and observed objects."
>
> This looks not particularly enlightening to me, so I will file a
> documentation enhancement request (in particular a piece of sample
> code would do well).
>
>
> Thanks for your time,
>
> Arthur C.
>
> _________________________________________________________________
> Hotmail en Messenger on the move http://www.msn.nl/services
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Cocoa-dev mailing list (<email_removed>)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/<email_removed>
>
> This email sent to <email_removed>
>
| Related mails | Author | Date |
|---|---|---|
| Arthur C. | Jul 28, 15:13 | |
| mmalc crawford | Jul 28, 16:17 | |
| Jon Hull | Jul 28, 22:54 | |
| Arthur C. | Jul 29, 15:28 | |
| Arthur C. | Aug 1, 19:23 |






Cocoa mail archive

