Undefined result when opening managed dialog in AsyncTask when in background

Question

I have a problem that causes me some problems when a user (or another app, like the phone-application) pushes my application to the background.

My application does following:

1. A User can enter some information that is supposed to be pushed to a server.
2. When the user clicks "Send" i open a managed ProgressDialog and start an AsyncTask that performs the server communication.
3. When server communication is complete the AsyncTask reports back to my Activity where i perform a dismissDialog().
4. Directly after dismissDialog(), I will show another managed dialog using showDialog() that will inform the user about whether the submission was ok or if it failed.

This all works perfectly without any issues; however, when a call happens to come while the AsyncTask is running I get (seemingly random) one of these results:

1. The activity holding the managed dialog is dismissed completely and the previous view from the stack is presented when I come back.
2. The activity holding the managed dialog is still on screen, but it is grayed out without showing a dialog. The only way to fix this is to rotate the phone at which point it shows the "Submission sent"-dialog exactly the way it should and everything is ok after that.

All this happens without any warning messages so I get absolutely no clues as to why Android is behaving this way.

I know a way around this and that is to cancel the AsyncTask (so no dialogs are shown at the end). However, in this very use-case the requirements are that the app has to try to complete the server transaction so that there is as little confusion as possible (i.e. the user wondering if it was really sent or not).

Has anybody else had this issue and knows a way around?

Answer 1

I see recommendations to hold a reference to the asynch task in onRetainNonConfigurationInstance

What to do with AsyncTask in onPause()?

Or implement a bus:

https://github.com/commonsguy/cwac-bus/tree

EDIT: The complexity of your challenge is two fold:

1) saving and restoring state of your app on a kill such as when there is an incoming phone call

https://sites.google.com/site/jalcomputing/home/mac-osx-android-programming-tutorial/saving-instance-state

2) somehow continuing the asyncTask on kill instead of canceling it onPause

https://sites.google.com/site/jalcomputing/home/mac-osx-android-programming-tutorial/asynch

Both of these are significant challenges alone, and trying to fix both at the same time would give me a headache. In fact, I am getting a headache just thinking on it :) One clue is that you say the dialog returns on orientation change. This MAY be due to the fact that using the standard architecture for dialogs, the OS handles saving and restoring the state of dialogs for you on orientation change.

[EDIT] See CommonsWare

@Override
public Object onRetainNonConfigurationInstance() {
    task.detach();
    return(task);
}

and

@Override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.main);      
    bar=(ProgressBar)findViewById(R.id.progress);   
    task=(RotationAwareTask)getLastNonConfigurationInstance();  
    if (task==null) {
        task=new RotationAwareTask(this);
        task.execute();
    }
    else {
        task.attach(this);
        updateProgress(task.getProgress());
        if (task.getProgress()>=100) {
            markAsDone();
        }
    }
}

where task is an instance of

static class RotationAwareTask extends AsyncTask<Void, Void, Void> {

I see no reason why this would not work for all types of soft kills, but on a hard kill, well, you get killed. Dead is dead :)

Answer 2

Without looking at your code it is slightly difficult to say what the problem is. However, here is something you could use to help get around the problem. You can override the onPause() method of your Activity.

This is taken directly from the Android Acitivy javadoc:

onPause() is where you deal with the user leaving your activity. Most importantly, any changes made by the user should at this point be committed (usually to the ContentProvider holding the data)