Main Scene and Game State - Learn SpriteBuilder for iOS Game Development - page 235

meter to the selector is simply ignored if the selector is declared to take no para-
meters, as in this case. But because there is now a timer involved, and despite
the delay being 0, the selector may not necessarily be performed before the cur-
rent frame gets rendered. So this may introduce an additional delay of a single
frame before the selector runs—though that won't be a problem when dismiss-
ing a popover.
What's left now is to implement the same shouldClose method in a CCB's custom
class that is an ancestor of CloseButton.ccb . In this case, we needn't go very far, the Set-
tingsLayer should handle it. Move over to SettingsLayer.m to implement the method
in Listing 7-7 in its implementation.
Listing 7-7 . The shouldClose selector is forwarded to the SettingsLayer instance
-(void) shouldClose
{
[self removeFromParent];
[_mainMenuButtons show];
}
So why not just remove aParent directly in the CloseButton 's shouldClose
method? (See Listing 7-6 .)
Note Separation of concerns is one of the most fundamental programming
principles. The close button should notify and leave the implementation to the
affected class, rather than assuming that “close” means removeFromParent
and nothing else—and not even giving the removed node a chance to know
what is being done to it. That would be rude! For more information on separa-
tion of concerns, see http://en.wikipedia.org/wiki/Separa-
tion_of_concerns .
In the same light, just as the _mainMenuButtons.visible state could have been set
from within the SettingsLayer method in Listing 7-7 , it's best to let the
MainMenuButtons class handle it in the way it sees fit. Therefore, add the method de-
claration of Listing 7-8 to MainMenuButtons.h .