views:

2850

answers:

2

I've been working with AsyncTasks in Android and I am dealing with a strange issue.

Take a simple example, an Activity with one AsyncTask. The task on the background does not do anything spectacular, it just sleeps for 8 seconds.

At the end of the AsyncTask in the onPostExecute() method I am just setting a button visibility status to View.VISIBLE, only to verify my results.

Now, this works great until the user decides to change his phones orientation while the AsyncTask is working (within the 8 second sleep window).

I understand the Android activity life cycle and I know the activity gets destroyed and recreated.

This is where the problem comes in. The AsyncTask is referring to a button and apparently holds a reference to the context that started the AsyncTask in the first place.

I would expect, that this old context (since the user caused an orientation change) to either become null and the AsyncTask to throw an NPE for the reference to the button it is trying to make visible.

Instead, no NPE is thrown, the asynctask thinks that the button reference is not null, sets it to visible. The result? Nothing is happening on the screen!

I have tackled this by keeping and updating the context reference into the AsyncTask. This is cumbersome and prone to leaks.

Here's the code:

    public class Main extends Activity {

        private Button mButton = null;
        private Button mTestButton = null;

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

            mButton = (Button) findViewById(R.id.btnStart);
            mButton.setOnClickListener(new OnClickListener () {
                @Override
                public void onClick(View v) {
                    new taskDoSomething().execute(0l);
                }
            });
            mTestButton = (Button) findViewById(R.id.btnTest);   
        }

        private class taskDoSomething extends AsyncTask<Long, Integer, Integer> 
        {
            @Override
            protected Integer doInBackground(Long... params) {
                Log.i("LOGGER", "Starting...");
                try {
                    Thread.sleep(8000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                return 0;
            }

            @Override
            protected void onPostExecute(Integer result) {
                Log.i("LOGGER", "...Done");
                mTestButton.setVisibility(View.VISIBLE);
            }
        }
}

Try executing and while the AsyncTask is working change your phones orientation.

A: 

This is the type of thing that leads me to always prevent my Activity from being destroyed/recreated on orientation change.

To do so add this to your <Activity> tag in your manifest file:

android:configChanges="orientation|keyboardHidden" 

And override onConfigurationChanged in your Activity class:

@Override
public void onConfigurationChanged(final Configuration newConfig)
{
    // Ignore orientation change to keep activity from restarting
    super.onConfigurationChanged(newConfig);
}
mbaird
Your approach works but do you have good counter-arguments to this approach? Why is it by default that the OS destroys and recreates the activity then? In other words what do I "lose" by doing what you propose?Btw, it worked as expected though.Thanks for the reply.
dnkoutso
As far as I know, the main thing you would lose would be the ability to have different Activity layouts for landscape and portrait mode. There may be other things that you would "lose" but I don't know what they are.
mbaird
+3  A: 

AsyncTask is not designed to be reused once an Activity has been torn down and restarted. The internal Handler object becomes stale, just like you stated. In the Shelves example by Romain Guy, he simple cancels any currently running AsyncTask's and then restarts new ones post-orientation change.

It is possible to hand off your Thread to the new Activity, but it adds a lot of plumbing. There is no generally agreed on way to do this, but you can read about my method here : http://foo.jasonhudgins.com/2010/03/simple-progressbar-tutorial.html