Menus & Popovers - Learn SpriteBuilder for iOS Game Development - page 181

header A. The compiler gets all confused and spits out unknown type name errors
when you have a circular import.
You still have to #import the corresponding class' header file in the GameMenuLay-
er.m implementation file, which was done in Listing 6-1 . But being able to move the
#import from the header (interface) file to the implementation file is the best strategy to
prevent circular imports.
Note For @property , the storage identifiers are written without the leading
underscores. Hence, it is weak for properties and __weak for ivars. I've also
frequently seen developers use the assign storage identifiers, perhaps because
they were following outdated tutorials. The assign keyword for ARC-enabled
apps is the same as unsafe_unretained , which will not retain the referen-
ce nor set it to nil when it deallocates, leaving a dangling pointer and a potential
EXC_BAD_ACCESS crash. For ARC-enabled apps, you should almost exclus-
ively use weak storage identifiers or no (defaults to strong ) storage identifi-
ers for properties and ivars.
Now you only need to assign self to the gameScene property in didLoadFromCCB
in GameScene.m as seen in Listing 6-4 .
Listing 6-4 . Assigning self to the GameMenuLayer's gameScene property
-(void) didLoadFromCCB
{
_gameMenuLayer.gameScene = self;
// remaining code omitted...
}
Caution The didLoadFromCCB method runs in reverse hierarchical order.
This means a child's didLoadFromCCB will always run before the
didLoadFromCCB of its parent. In this case, _gameMenuLayer is a child
of the GameScene node. This means that the _gameMenuLay-
er.gameScene property is assigned after GameMenuLayer 's
didLoadFromCCB method runs. Code in GameMenuLayer that requires a