Archiving and encoding objects help

[JR2760]

Hello,
I'm trying to archive and save an instance of a (custom) object:

-(void) saveProfile{
ProfileObj *profile = [[ProfileObj alloc] init];
profile = Player[0];

NSMutableData *data = [[NSMutableData alloc] init];
NSKeyedArchiver *archiver = [[NSKeyedArchiver alloc] initForWritingWithMutableData:data];
[archiver encodeObject:profile forKey:kDatakey];
[archiver finishEncoding];
[data writeToFile:[self pathOfFile] atomically:YES];
[profile release];
[archiver release];
[data release];
}

for debugging purposes my ProfileObj currently only has one NSString variable that is being saved, and the code runs fine while that NSString is nil (currently loaded from Player[0]) but when the string has data the app crashes at [archiver encodeObject:profile forKey:kDatakey]; and i cannot figure out why or how to fix it. This is my first time ever trying to save data and any help would be greatly appreciated!


#pragma mark NSCoding
-(void) encodeWithCoder:(NSCoder *)encoder {
[encoder endodeObject:Name forKey: kNameKey];
}
-(id) initWithCoder:(NSCoder *)decoder {
if (self = [super init]){
self.Name = [decoder decodeObjectForKey:kNameKey];
}
return self;
}
#pragma mark -
#pragma mark NSCopying
-(id)copyWithZone:(NSZone *)zone{
ProfileObj *copy = [[[self class] allocWithZone: zone] init];
copy.Name = [[self.Name copyWithZone:zone] autorelease];
return copy;
}

This is some code within ProfileObj.h, the one string i'm trying to save is called Name.

[smasher]

Is the .Name property declared as (nonatomic,retain) ? If it's not set to retain then the string will probably get dealloc'd before you go to use it. Do you always use the .Name property when changing the Name variable?

[JR2760]

thanks for replying

Yes the .Name is declared as (nonatomic, retain) . Currently i do always use .Name to change the variable. Would adding setter and getter methods fix my problem?

the part that's throwing me off is it crashes at [archiver encodeObject:profile forKey:kDatakey] only when .Name contains data.

[JR2760]

I further narrowed down the error, commenting out the [encoder encodeObject:Name forKey: kNameKey]; line inside the encodeWithCoder: method results in no data saved while leaving it results in a crash regardless if .Name has a value or not.

any clue what i'm doing wrong?

[Duncan C]

Originally Posted by JR2760

I further narrowed down the error, commenting out the [encoder encodeObject:Name forKey: kNameKey]; line inside the encodeWithCoder: method results in no data saved while leaving it results in a crash regardless if .Name has a value or not.

any clue what i'm doing wrong?

Sounds like the value of Name is bad at the time of encoding. Put a breakpoint at that line in your code and look at the Name instance variable. I'm guessing that you are assigning it without using property syntax, so it's not invoking the (retain) setter, and is getting released.

if you ever have code like this:

Name = [NSString stringWithFormat: @"blah blah blah %d", somevar];

Then Name won't be retained, and you will probably crash at some future date when you try to reference it.

self.Name = [NSString stringWithFormat: @"blah blah blah %d", somevar];

would invoke the setter, and thus the new value assigned to Name would be retained.

[JR2760]

thanks for the help,

I used a breakpoint and .Name DOES contain data at the time of encoding, but right after checking that i saw a typo, I put endodeObject: instead of encodeObject: , after fixing that everything works fine. God i feel silly

thanks for the help

[Duncan C]

Originally Posted by JR2760

thanks for the help,

I used a breakpoint and .Name DOES contain data at the time of encoding, but right after checking that i saw a typo, I put endodeObject: instead of encodeObject, after fixing that everything works fine. God i feel silly

thanks for the help

Oops.

You really, really have to check for warnings when you compile. I daresay you got a warning when you first compiled it. The really bad thing about warnings is that they only show up the first time you compile. If you don't check them the first time, the warning isn't repeated until you change the file in which it occurs.


Duncan