Android game thread lifecycle implementation

Question

Hello SO,

So I am working on a new basic 2d game for Android and was setting up my usual implementation of a game thread working with a SurfaceView. While typing away, I realized that, while this seems to work, I would really like to know if there is a better way to achieve the same results. Here are the basics of what I do right now (I apologize for the verbosity, I'm trying to compress as much as possible):

GameActivity class

@Override
public void onCreate(final Bundle savedInstanceState)
{
    super.onCreate(savedInstanceState);
    this.setContentView(R.layout.game);

    this.mGameView = (GameView)this.findViewById(R.id.gameview);
}

XML layout

<?xml version="1.0" encoding="utf-8" ?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"&gt;
 <com.package.name.GameView
    android:id="@+id/gameview"
        android:layout_width="fill_parent"
        android:layout_height="fill_parent"
        android:focusable="true"
        android:focusableInTouchMode="true" />
</merge>

GameView

@Override
public void surfaceCreated(final SurfaceHolder holder) { }

@Override
public void surfaceChanged(final SurfaceHolder holder, final int format, 
                            final int width, final int height)
{
    this.mGameThread = new GameThread(this.getContext(), holder, 
                                        width, height);

    this.mGameThread.start(); // starts the game
}

@Override
public void surfaceDestroyed(final SurfaceHolder holder)
{
    // flips volatile flag stopping execution
    // then calls .join()
    this.mGameThread.release(); 
}

GameThread class

@Override
public void run()
{
    // load game state
    while (this.mRunFlag) // volatile loop flag
    {
        // game loop
    }
    // save game state
}

As you can see, basically I depend on the SurfaceHolder's callbacks to manage the game. This works well as orientations change, etc. but without asking, I may never know if this can be achieved in a better way, which I would be anxious to learn if there is. So that's why I'm asking! Any thoughts?

(The reason I'm so curious is because I almost entirely ignore the Activity life-cycle events, and feel this may be a problem...)

Answer 1

It might be better to listen to the activity life cycle events as onSurfaceChanged can get called in times when you don't expect (orientation change, some sort of odd size change, memory on the VRAM gets recycled, and probably other strange ones).

That said, it is true for a game that you probably want to do some resetting of your game if the surface changes. Therefore I recommend using both. Create a method to handle all game stop events and game start events. In onPause and onSurfaceDestroyed call that method (Keep a flag around to make sure you don't double unload your game). In onResume and onSurfaceChanged create your game if it doesn't exist. This will give a bit of a faster startup time since it will allow your thread to initialize itself (but not start the actual game. Basically put it in a ready state) before the renderer is ready. Once the renderer is ready, the game would be able to start at that exact instant.