3
votes

So, to do much of anything useful with leaderboard data, one must first fetch an array of GKScores from GKLeaderboard and then fetch the corresponding GKPlayers for each score.

Once you have that, you might want to have a dictionary mapping the players to scores or the scores to players or playerIDs to score values or some such. And it'd be nice to set up such a dictionary using +[NSDictionary dictionaryWithObjects:forKeys:] since we already have arrays.

The question is: are these arrays guaranteed to be in the same order? i.e. is it safe to do the following:

GKLeaderboard *leaderboard = [[GKLeaderboard alloc] init];
[leaderboard loadScoresWithCompletionHandler:^(NSArray *scores, NSError *error) {
    NSArray *playerIDs = [scores valueForKey:@"playerID"];
    [GKPlayer loadPlayersForIdentifiers:playerIDs withCompletionHandler:^(NSArray *players, NSError *error) {
        self.scores = [NSDictionary dictionaryWithObjects:scores forKeys:players];
    }];
}];

(Error handling and ARC safety ommitted for brevity.)

I know [scores valueForKey:@"playerID"] will get me an array of playerIDs in the same order as the scores -- that's what valueForKey: on an array is supposed to do. But does the completion handler from loadPlayers guarantee that the array of fetched player scores will be in the same order as the input? I've created a few sandbox accounts and done a few tests, and it appears that the sort order always matches, but that's no guarantee.

The documentation doesn't say anything either way. (It does say the array may contain partial results in the case of an error, in which case it obviously won't map to the input, but what about the no-error case?) It's pretty simple to sort both arrays on playerID, of course, but it'd be a shame to have to spend time sorting an array if it'll always be already sorted.

1

1 Answers

0
votes

I would guess that it is equal from the method name BUT it is not guaranteed and an implementation detail. I would not rely on it I guess.

I would call sort again.. right now (as they are already sorted) that would result in the best case runtime of the sort algorithm... so. o(n). You would be sage than in any case :)