An Android Game Development Framework - Beginning Android Games - page 232

public Input getInput() {
return input;
}
public FileIO getFileIO() {
return fileIO;
}
public Graphics getGraphics() {
return graphics;
}
public Audio getAudio() {
return audio;
}
The getInput() , getFileIO() , getGraphics() , and getAudio() methods need no explanation.
We simply return the respective instances to the caller. Later, the caller will always be one of the
Screen implementations of our game.
public void setScreen(Screen screen) {
if (screen == null )
throw new IllegalArgumentException("Screen must not be null");
this .screen.pause();
this .screen.dispose();
screen.resume();
screen.update(0);
this .screen=screen;
}
At first, the setScreen() method we inherit from the Game interface looks simple. We start with
some traditional null-checking, since we can't allow a null Screen . Next, we tell the current
Screen to pause and dispose of itself so that it can make room for the new Screen . The new
Screen is asked to resume itself and update itself once with a delta time of zero. Finally, we set
the Screen member to the new Screen .
Let's think about who will call this method and when. When we designed Mr. Nom, we identified
all the transitions between various Screen instances. We'll usually call the
AndroidGame.setScreen() method in the update() method of one of these Screen instances.
For example, let's assume we have a main menu Screen where we check to see if the Play
button is pressed in the update() method. If that is the case, we will transition to the next Screen
by calling the AndroidGame.setScreen() method from within the MainMenu.update() method with
a brand-new instance of that next Screen . The MainMenu screen will regain control after the call
to AndroidGame.setScreen() , and should immediately return to the caller as it is no longer the
active Screen . In this case, the caller is the AndroidFastRenderView in the main loop thread. If
you check the portion of the main loop responsible for updating and rendering the active Screen ,
you'll see that the update() method will be called on the MainMenu class, but the present()
method will be called on the new current Screen . This would be problematic, as we defined the
Screen interface in a way that guarantees that the resume() and update() methods will be called