MKPlacemark and NSCoder in iOS 4 vs iOS 5

Question

In iOS 4, MKPlacemark does not conform to NSCoding.

In iOS 5, MKPlacemark conforms to NSCoding by way of CLPlacemark.

I'm not sure if I can use -initWithCoordinate:addressDictionary: with my own keys/values (outside of Address Book) and get away with it, but what I'm really curious about is NSCoding.

In particular, let's say I've subclassed MKPlacemark. If I want to support NSCoding, I'd want to call up to the superclass, so long as it conforms.

What's interesting is that -conformsToProtocol: returns YES on iOS 5 and iOS 4!

On iOS 4, even if I check to see if the superclass responds to -encodeWithCoder: (I prefer to check the protocol, but whatevs), no matter. "Oh, did I say we conform and respond to that selector? Oh! Yeah. No." (Ka-blammo.)

I'd prefer not to check OS versions here but, if I'm going to get back YES in both cases ... (shudder).

Answer 1

I think the best thing to do, for now anyway, is something along these lines:

- (id)initWithCoder:(NSCoder *)aDecoder {
    if ([super conformsToProtocol:@protocol(NSCoding)] &&
        [super isKindOfClass:[CLPlacemark class]]) {
        [super initWithCoder:aDecoder];
    } else {
        // Homegrown MKPlacemark (ostensibly iOS 4.x) initWithCoder
    }
    // Subclass-specific initWithCoder
}

- (void)encodeWithCoder:(NSCoder *)aCoder {
    if ([super conformsToProtocol:@protocol(NSCoding)] && 
        [super isKindOfClass:[CLPlacemark class]]) {
        [super encodeWithCoder:aCoder];
    } else {
        // Homegrown MKPlacemark (ostensibly iOS 4.x) encodeWithCoder
    }
    // Subclass-specific encodeWithCoder
}

I suppose it's redundant, since CLPlacemark handles NSCoding, but I can't shake wanting to check the protocol vs. the class. Let's hear it for dichotomy!