Reputation: 23540
In NSCoder, you can call encodeObject:
and encodeObject:forkey:
. And this for many data types. What is the difference beetween those calls? How to use them? Why isn't there a encodeDataObject:forkey:
or encodePropertyList:forKey:
?
Upvotes: 3
Views: 1629
Reputation: 104065
Most of the time you just call the encodeSomething:forKey:
method and supply a key that you later use to get the value back from a decoder:
- (void) encodeWithCoder: (NSCoder*) coder
{
[coder encodeObject:someProperty forKey:@"someProperty"];
}
- (id) initWithCoder: (NSCoder*) decoder
{
self = [super init];
if (self) {
[self setSomeProperty:[decoder decodeObjectForKey:@"someProperty"]];
}
return self;
}
The unkeyed version of the call is older, I guess that serialization used to work differently back before 10.2.
There isn’t a separate encodeDataObject:
call since NSData
conforms to NSCoding
, so that you can encode it using regular encodeObject:
. The same applies to property lists – a property list is just a dictionary, and a dictionary is a regular object that can be encoded using encodeObject:
.
What maybe got you confused is the number of specialized methods for encoding primitive types like BOOL
or NSUInteger
. These have to do with the type system. When encoding and decoding objects, the interface can use the id
type and it works regardless of the particular object type:
// can pass NSObject*, NSData*, any object
- (void) encodeObject: (id) anObject {…}
- (id) decodeObject {…}
There is no such general, “wildcard” type for primitive types, therefore the number of specialized getters and setters:
- (void) encodeBool: (BOOL) flag {…}
- (BOOL) decodeBool {…}
Theoretically you could use void*
and cast, but that’s clumsy and the encoding interface wouldn’t know the size of the object to encode anyway.
Upvotes: 3