Checking If GKScore Instances Have Context Property

Question

For the online mode for my game, I am using the context property of GKScore, and as all devices which support Game Center can update to iOS 5 (which is when the context property was added), I am requiring that the context property is available to play online. However, I am having issues implementing this runtime-check. I was assuming that I could use [GKScore instancesRespondToSelector:@selector(setContext:)] to check its existence, but this returns false on the iOS 5 and 5.1 simulators, as well as for @selector(context). Why on earth is this happening, and what is the cleanest and correct way to perform this check, please?

Answer 1

This looks like a bug in the GK implementation.

Consider the following code...

// Get the C-functions that are really called when the selector message is sent...
typedef BOOL (*XX)(id, SEL, SEL);
XX classImpNSObject = (XX)[NSObject
    methodForSelector:@selector(instancesRespondToSelector:)];
XX classImpGKScore = (XX)[GKScore
    methodForSelector:@selector(instancesRespondToSelector:)];
XX instImpNSObject = (XX)[NSObject
    instanceMethodForSelector:@selector(respondsToSelector:)];
XX instImpGKScore = (XX)[GKScore
    instanceMethodForSelector:@selector(respondsToSelector:)];

// See that the same C function is called for both of these...
NSLog(@"instancesRespondToSelector: %p, %p", classImpNSObject, classImpGKScore);

// But, different functions are called for these...
NSLog(@"respondsToSelector: %p, %p", instImpNSObject, instImpGKScore);

// Invoke to C-Functions for instancesRespondToSelector:
NSLog(@"NSObject instancesRespondToSelector: context: %s",
    classImpNSObject(
        [NSObject class],
        @selector(instancesRespondToSelector:),
        @selector(context))
    ? "YES" : "NO");
NSLog(@"GKScore instancesRespondToSelector: context: %s",
    classImpGKScore(
        [GKScore class],
        @selector(instancesRespondToSelector:),
        @selector(context))
    ? "YES" : "NO");

// Invoke the C functions for respondsToSelector:
GKScore *gkScore = [[GKScore alloc] init];
NSLog(@"NSObject respondsToSelector: context: %s",
    instImpNSObject(
        gkScore,
        @selector(respondsToSelector:),
        @selector(context))
    ? "YES" : "NO");
NSLog(@"GKScore respondsToSelector: context: %s",
    instImpGKScore(
        gkScore,
        @selector(respondsToSelector:),
        @selector(context))
    ? "YES" : "NO");

Basically, we just extracted the C functions that get called when responding to those messages.

As you can see, NSObject and GKScore use the exact same C-function implementation for instancesRespondToSelector:. However, they use different C-function implementations for respondsToSelector:. This means that GKScore overrides respondsToSelector: with its own implementation (but does not override instancesRespondToSelector.

If you send the same GKScore instance to the different C implementations of respondsToSelector: you get different results for some selectors (obviously, or there would not be a reason to provide a subclass implementation).

It looks like they did something funky for a few special properties, and provided an override for respondsToSelector: to handle the special cases, but forgot about making sure instancesRespondToSelector: did the right thing.

If you want to troll through assembly code, set a breakpoint and I'm sure you can see the differences.

I did not do that.

My own personal curiosity will only carry me so far :-)

For you situation, of trying to detect the method implementation in code, I suggest creating a temporary GKScore object to do your tests, cache that result, and free the temporary object.

Answer 2

I can't fully explain this, but an instantiated object of class GKScore will return YES to repondsToSelector(context), even while the class says it won't. If no other solution works, construct a GKScore object just to query it.

---

I wondered if [[GKScore alloc] init] actually returns an object with type other than GKScore. This can happen.

GKScore *instantiatedScore = [[GKScore alloc] init]; // Add autorelease if using manual reference counting.
NSString* className = NSStringFromClass([instantiatedScore class]);
NSLog(@"instantiatedScore class name = %@", className);

But, it doesn't, according to this output:

instantiatedScore class name = GKScore

---

I wondered if the compiler directives in the GKSCore.h header file might affect this. It defines two properties that are only available in iOS 5.0 or greater: context and shouldSetDefaultLeaderboard. Maybe those compiler directives mean that the class can't guarantee it will support those two properties.

Under this hypothesis [GKScore instancesRepondToSelector:@selector(category)] should return YES, but [GKScore instancesRepondToSelector:@selector(shouldSetDefaultLeaderboard)] should return NO.

GKScore *instantiatedScore = [[GKScore alloc] init]; // Add autorelease if using manual reference counting.
NSLog(@"GKScore category = %d", [GKScore instancesRespondToSelector:@selector(category)]);
NSLog(@"instantiatedScore category = %d", [instantiatedScore respondsToSelector:@selector(category)]);

NSLog(@"GKScore context = %d", [GKScore instancesRespondToSelector:@selector(context)]);
NSLog(@"instantiatedScore context = %d", [instantiatedScore respondsToSelector:@selector(context)]);

NSLog(@"GKScore shouldSetDefaultLeaderboard = %d", [GKScore instancesRespondToSelector:@selector(shouldSetDefaultLeaderboard)]);
NSLog(@"instantiatedScore shouldSetDefaultLeaderboard = %d", [instantiatedScore respondsToSelector:@selector(shouldSetDefaultLeaderboard)]);

But, the output is weirder than that:

GKScore category = 0
instantiatedScore category = 1
GKScore context = 0
instantiatedScore context = 1
GKScore shouldSetDefaultLeaderboard = 1
instantiatedScore shouldSetDefaultLeaderboard = 1

Answer 3

If you're specifically looking for the existence of a property, you should use the Objective-C runtime function:

class_getProperty(Class cls, const char *name)

To use it, you will have to import :

#import <objc/runtime.h>

As a tiny test example, here is how you could test for the existence of a particular property:

#import <objc/runtime.h>

//...

objc_property_t realP = class_getProperty([GKScore class], "context");
objc_property_t fakeP = class_getProperty([GKScore class], "fakeContext");


if (realP) {
    NSLog(@"context exists");
}
if (!fakeP) {
    NSLog(@"fakeContext does not exist");
}
// Both statements will log correctly.

As to why GKScore instances do not appear to respond to the correct selector, my thought would be that the context property may be declared @dynamic and thus +instancesRespondToSelector: and -respondsToSelector: would return NO (see this question). Not knowing the internal details, this is all I can suggest, but if you merely want to test the existence of a property, the sample code above will work.

Incidentally, if you don't want an include to the Objective-C runtime floating around, you may want to encapsulate this behaviour in a class or wrap it in a selector rather than just stick it in somewhere verbatim. That's entirely up to you of course.

Answer 4

I have also come across this issue but in my case with GKTurnBasedMatchParticipant. I did a quick dump of the result of sending #instancesRespondToSelector: to each of the properties of this class.

Here's the result:

1   playerID            false
2   lastTurnDate        false
3   status              true
4   matchOutcome        false
5   matchOutcomeString  true
6   isWinner            true
7   invitedBy           false
8   inviteMessage       false
9   internal            true

Notice how many of the properties report that they can't be sent as selectors. However, notice also an additional "internal" property. Now look at the result of querying whether this internal object will respond to the property selectors:

1   playerID            true
2   lastTurnDate        true
3   status              true
4   matchOutcome        true
5   matchOutcomeString  false
6   isWinner            false
7   invitedBy           true
8   inviteMessage       true
9   internal            false

Hence, many of the missing properties are in here. I guess that it's not really safe to make use of a non-documented "internal" feature to get around an apparent Apple bug but it's still interesting to know nonetheless.

EDIT: After another day's mucking around I have found the issue here. These rogue properties are actually set up as forwarding methods to forward to the "internal" object. Being an ObjectiveC noob, I hadn't realized that this is a perfectly acceptable thing to do.

In my case, I'm not just trying to detect if an object responds to a selector but I actually want to invoke it too. Hence the general solution to cope with forwarding is:

(a) To check availability of a response use [instance #respondsToSelector: sel] rather than [[instance class] instanceRespondsToSelector: del].

(b) To invoke a method that may, or may not, be forwarded do this:

NSMethodSignature *signature = [instance methodSignatureForSelector:sel];
if (!signature) {
    // It's possible this is a message forwarding selector, so try this before giving up.
    NSObject *fwd=[instance forwardingTargetForSelector:sel];
    if (fwd && (signature= [fwd methodSignatureForSelector:sel]))
        // Redirect to the forwarding target
        instance=fwd;
    else {
        // ERROR case - selector is really not supported
    }
}

NSInvocation *invocation=[NSInvocation invocationWithMethodSignature:signature];

// Proceed with invocation setup

I hope this is useful to prevent others from wasting as much time as I have on this.