tags:

views:

49

answers:

1

When it comes to threads and orientation changes, it seems the normal thing to do is something like this:

public class Bwent extends Activity {
    private static Bwent instance;

    @Override
    public void onCreate(Bundle icicle) {
        super.onCreate(icicle);

        instance = this;
    }

    //...

That way, if you're making a network request with a thread, and someone changes the orientation of the phone, the thread will know to use the new Activity.

However, is it possible that the thread could finish during the time Android is destroying the old Activity and creating a new one?

Is there a moment in the process where the thread still might be pointing to the wrong Activity, or a partially destroyed activity?

It seems like there shouldn't be, but even using a Handler created in the main thread, I'm having intermittent issues with a thread trying to update an object that no longer exists. It's rare, but it does happen.

+1  A: 

When it comes to threads and orientation changes, it seems the normal thing to do is something like this:

It is a thing to do. I am not certain whether or not it is the "normal" thing to do. I am dubious that it is the best thing to do.

However, is it possible that the thread could finish during the time Android is destroying the old Activity and creating a new one?

Yes. There is nothing in your code preventing it.

Is there a moment in the process where the thread still might be pointing to the wrong Activity, or a partially destroyed activity?

Yes. There is nothing in your code preventing it.

Instead, try the pattern that I illustrate here. Use an AsyncTask, implemented as a static inner class or a public class. Have it be the one that knows about the Activity. Have it only use the Activity in doPostExecute() (or possibly onPublishProgress()). From the way AsyncTask and Handler work, our understanding is that the AsyncTask will always have an Activity in those on-the-main-thread methods.

Some of this stuff was discussed recently.

CommonsWare
This is basically exactly what I'm doing. However, it seems that there's still a chance the AsyncTask could have a reference to an Activity that's currently being destroyed when it returns (doPostExecute).
synic
@synic: Streets of Boston and I haven't run into it yet. And, if that's true, there is nothing you can do about it, other than to have your activity avoid the destroy/recreate cycle.
CommonsWare
Streets of Boston?
synic
@synic: He was one of the posters on the thread I linked to in my original answer.
CommonsWare
I actually haven't had any problems with this method myself. I only know it happens because I put in a library that emails me stack traces when there's a crash (it's currently released as beta software), and I get a few emails a day on it. I've tried and tried to reproduce it on my own, but I just can't.
synic
@synic: Check to see if the object exists, and if it doesn't, do a `postDelayed()` on your `Handler` to execute your logic after, say, 200ms.
CommonsWare