- Understanding Controllers
- Examining the Chapter 4 Project
- Drawing Sprites
- Putting Sprites in Action
- Wrapping Up
This chapter is from the book
This chapter is from the book
This chapter is from the book
Examining the Chapter 4 Project
Open Raiders.xcodeproj in Xcode 4 and look at the files pane to the left. You will notice a lot of new files and what appear to be folders (Figure 4.1).
){kind=link}
Figure 4.1 Files pane
Note
From this point forward, files will be described by their class names, unless otherwise stated. You can assume that all files have an .m and an .h file.
Now, let’s look at the new files in increasing order of complexity.
AbstractSceneController
AbstractSceneController is the abstract class for the scenes. It is a very simple class with only two external methods and one private method.
playScene is implemented by its child classes, and each instance will be particular to that scene, because it includes the rendering code for the scene.
addSprite is used internally to the class and adds a sprite to the list of sprites in the scene. The list of sprites is used in updateScene.
updateScene loops though the list of sprites in the current scene and creates the transformations required to render the sprites. You’ll learn more about updateScene in the “Drawing Sprites” section in this chapter.
GameController
In this project, the GameController class has a property called currentScene of type AbstractSceneController, that holds the active scene; and it has a method called playCurrentScene that calls the playScene method of the currentScene.
You may find something in GameController that you have not seen before. At the top of the .m file is the following:
@interfaceGameController (private) - (void)initScene;@end
This code is called a category in Objective-C. It adds methods to the class without the need to subclass. We could have put initScene in the .h file, but then it would be available to other code using the GameController class. By adding it as a category, it signals that this method is private (internal) to the GameController class and shouldn’t be called from outside the class.
In this specific case, initScene is called when the GameController class is first instantiated, and it assigns the MenuSceneController to the currentScene property, which allows the menu scene to automatically appear when the app is launched.
The other line of code that might catch your eye is the following:
SYNTHESIZE_SINGLETON_FOR_CLASS(GameController);
This code uses a #define macro that is defined in SynthesizeSingleton.h (thanks to Matt Gallagher from www.CocoaWithLove.com). This block of code takes the class name as a parameter and creates the singleton construction code for us. As a result, you don’t have to write the same boilerplate code to create a singleton in every class that needs it. Use this approach in other projects to save a lot of time “reinventing the wheel.”
The last method is updateWorld, in which all of the objects in the “world” update.
ViewController
The biggest change in the code from Chapter 3 is in ViewController. Previously, ViewController was handling all the setup, transformations, and rendering code. In this chapter, we use other classes to handle that code, and the GameController class is used to handle the rendering tasks. A new variable, sharedGameController of type GameController, is a link to the game controller—and if you look in glkView:drawInRect—you’ll see that the code has been replaced with a single call:
[sharedGameController playCurrentScene]
In update, you’ll see a single call to [sharedGameController updateWorld].
This is the power of abstract classes. In the earlier version of the project, methods had a lot of transformation and rendering code. But now the code is abstracted into other classes. In the current project, the current scene will be rendered, which in this case is the Menu scene.
This approach makes reading and maintaining code much easier because each distinct class is responsible for rendering its own scene. It’s therefore easier to go to the appropriate class to understand the flow of the app because you know the code relating to the menu will be in the menu scene.