Game Development Reference
NSLog(@"Local player NOT logged in!");
However, this example will always report that the player isn't logged in. Why? Well,
the execution path is such that the authenticateWithCompletionHandler
will take your block as a parameter and store it while it sends a request to the server
and waits for the response to come back. However, the execution continues right away
after the authenticateWithCompletionHandler method, and that's where
the success variable decides which log statement to print. The problem is, the suc-
cess variable is still set to NO because the block hasn't been executed yet.
Several milliseconds later, the server responds to the authentication, and that triggers
the completion handler—the block object—to be run. If it returns without error, the
success variable is set to YES . But alas, your logging code has already been run, so
the assignment has no effect.
Note that this isn't a problem of block objects in general; some methods immediately,
or even repeatedly, run a block right away before returning back to you. But in the case
of almost all Game Kit methods, the block objects are used exclusively as pieces of
code that will be run whenever the Game Center server has responded to a particular
request. In other words, the block objects used by Game Kit are run asynchronously
after an unspecified delay (and possibly not at all if the connection is interrupted).
Receiving the Local Player's Friend List
When the local player signs in or out, the onLocalPlayerAuthentica-
tionChanged method is received and forwarded to the delegate. The delegate in
these examples is the TileMapLayer class, which implements this method to ask for
GKLocalPlayer* localPlayer = GKLocalPlayer.localPlayer;