Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I just wrote a simple Android app that uses SurfaceHolder.Callback interface to communicate the state of the SurfaceView. In the Callback.surfaceDestroyed() method i just informed the rendering thread to terminate and returned, like so:

    public void surfaceDestroyed(SurfaceHolder holder) {
    renderingThread.requestStop();  
    }

I did this because in the Android documentation SurfaceHolder.lockCanvas() it states that a null will be returned when the surface is not available. And also that the SurfaceHolder holds a lock internally until SufraceHolder.unloackCanvasAndPost() is called, which prevents calls to SurfaceHolder.Callback methods.

So to me it seems that it's not necessary to wait for the rendering thread to finish. However all examples I've seen wait for the thread to finish, usually something like:

    public void surfaceDestroyed(SurfaceHolder holder) {
       boolean retry = true;
       rederingThread.setRunning(false);
       while (retry) {
          try {
            thread.join();
            retry = false;
          } catch (InterruptedException e) {
        }
     }
  }

Is this really necessary? My application runs without problems.

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

One reason to follow what most of the examples do is because just because the current implementations allow for this usage, it doesn't mean future implementations will. It's better to code defensively and to what the API is documented to do rather than what a particular implementation does.

In this case, you already have working code that's been implemented the correct way. Just toss it in your code and then you don't have to worry about it again.

share|improve this answer
add comment

I believe for the most part it is just good practice. Imagine if it was a thread that did a lot of heavy IO. If you simply killed the thread, you could potentially cause data corruption if it was in the middle of writing to disk. Now for a rendering thread, I'm not sure what the consequences would be. Memory leaks? It really just depends on what all is happening in your rendering thread.

share|improve this answer
add comment

I'm not sure that your code needs to wait the end of renderingThread but it is a generic approach or a Best Practise.

I use renderingThread.requestStop() too without problems.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.