Game Development Reference
In-Depth Information
The block used in the CCCallBlockN class must take a single parameter of type
CCNode* . The node is the node that's running the CCCallBlockN action. The
block used by CCCallBlockO requires a single parameter of type id . That's the ob-
ject passed as the second parameter to CCCallBlockO . It's easy to miss, unfortu-
nately, because the object parameter follows the block parameter and therefore causes
some syntactical awkwardness because it's either dangling at the end of the block or
floating by itself after what seems to be an empty line.
It's syntactically cleaner and easier to read if you assign the block to a variable and re-
write the CCCallBlockO initialization like this:
void (^callBlock)(id object) = ^void(id object){
CCLOG(@"action with block got called with object %@", object);
[label setString:@"label string changed by block"];
};
CCCallBlockO* blockO2 = [CCCallBlockO actionWithBlock:callBlock
object:background];
Which reminds me: you can assign blocks to variables—and what that looks like. I'm
hoping that maybe now, after a few pages, blocks are starting to click with you. If not,
don't worry. I'll be re-visiting them a couple more times over the course of the topic.
In case you're missing the potentially useful CCCallBlockNO class, whose block
would take both the sending node and a user-supplied object as a parameter, remember
that blocks have access to the local scope. Essentially, you won't even need to use
either CCCallBlockN or CCCallBlockO in most cases because you can just ac-
cess the variables label and background from inside the block without their being
passed as block parameters:
// assuming label and background are already declared & initialized at this point . . .
CCCallBlock* block = [CCCallBlock actionWithBlock:^void(){
CCLOG(@"label: %@ -- background object: %@", label, background);
}];
Writer's block may be a bad thing, but coder's block is nothing but awesome!
Search Nedrilad ::




Custom Search