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

Note For our first game, Mr. Nom, we will use a target resolution of 320×480 pixels. The
AndroidGame class has these values hard-coded. If you want to use a different target resolution,
modify AndroidGame accordingly!
We also calculate the scaleX and scaleY values that the SingleTouchHandler and the
MultiTouchHandler classes will use to transform the touch event coordinates in our
fixed-coordinate system.
Next, we instantiate the AndroidFastRenderView , AndroidGraphics , AndroidAudio ,
AndroidInput , and AndroidFileIO with the necessary constructor arguments. Finally, we call the
getStartScreen() method, which our game will implement, and set the AndroidFastRenderView
as the content view of the Activity . Of course, all the previously instantiated helper classes will
do some more work in the background. For example, the AndroidInput class tells the selected
touch handler to communicate with the AndroidFastRenderView .
@Override
public void onResume() {
super .onResume();
wakeLock.acquire();
screen.resume();
renderView.resume();
}
Next is the onResume() method of the Activity class, which we override. As usual, the first thing
we do is call the superclass method. Next, we acquire the WakeLock and make sure the current
Screen is informed that the game, and thereby the activity, has been resumed. Finally, we tell the
AndroidFastRenderView to resume the rendering thread, which will also kick off our game's main
loop, where we tell the current Screen to update and present itself in each iteration.
@Override
public void onPause() {
super .onPause();
wakeLock.release();
renderView.pause();
screen.pause();
if (isFinishing())
screen.dispose();
}
First, the onPause() method calls the superclass method again. Next, it releases the WakeLock
and makes sure that the rendering thread is terminated. If we don't terminate the thread before
calling the current Screen 's onPause() method, we may run into concurrency issues since the
UI thread and the main loop thread will both access the Screen at the same time. Once we are
sure the main loop thread is no longer alive, we tell the current Screen that it should pause itself.
In case the Activity is going to be destroyed, we also inform the Screen so that it can do any
necessary cleanup work.