Why is there no cancel button in Android's progress dialogs?

Question

I\'m facing a head-scratching moment similar to what this person (from Jan 2008) experienced when I realized that there is no cancel button in Android\'s progress dialog or spin

Answer 1

As an Android user, and developer, I can say, in my opinion, and based around my understanding of the platform, that there is a good reason for not having a cancel button by default on the cancel-free progress dialogs.

As a developer, these dialogs can not be cancelled by default, that is, you have to explicitely set them as cancelable.

This makes sense, because their purpose is to alert the user, via the UI thread, that some work is going on elsewhere that is important to the updating of the UI thread, before the user should continue their use of the application.

For example, when fetching a list of data to occupy an empty screen, there is nothing to interact with, and the user needs to be made aware that something is going on, and to expect there to be nothing available to interact with until this process is complete.

However, there may be cases, such as data retrieval from the internet, where the process is "sketchy" and due to connectivity issues, you may not be able to complete the request, and get stuck here.

This as a develop is where you enable the dialog to be cancel-able.

Now as a user, one that clearly understands the UI paradigm of Android, I know that if I want to go back to what I was doing before, or "cancel" the current operation, I should hit the back key.

As a user, it's no different to knowing that in Android, the menu key can often reveal hidden options, some times on a seemingly blank screen with no way to interact.

This is the behaviour a user expects, and the way the platform is designed. You could very well add a cancel button, but from a users perspective that understands their phone, this makes no difference, the back key is clearly the intended choice for this purpose.

Activities and UIs have a flow, you flow through activities and UI "screens" which are "stacked" and the back button essentially "pops" the last thing off the stack to return you to where you were previously. If you see the dialog as another of these activities, you want to pop it from the top of the stack to return to what is underneath, or an activity previous to that.

If a developer has a dialog that can not be cancelled by back, it is either, by design, for which there can, in cases, be very good reason for, or, it is poor development and an oversight on the devloper's part.

Answer 2

not sure about the whole cancel button...i've heard reports of the onCancel() method not firing properly. my solution just consists of making a normal button on the dialog with a call to return whenever the button is pressed.

private void createCancelProgressDialog(String title, String message, String buttonText)
{
    cancelDialog = new ProgressDialog(this);
    cancelDialog.setTitle(title);
    cancelDialog.setMessage(message);
    cancelDialog.setButton(buttonText, new DialogInterface.OnClickListener() 
    {
        public void onClick(DialogInterface dialog, int which) 
        {
            // Use either finish() or return() to either close the activity or just the dialog
            return;
        }
    });
    cancelDialog.show();
}

then just use a simple call method from elsewhere in your activity

createCancelProgressDialog("Loading", "Please wait while activity is loading", "Cancel");

rather simple solution, but it does the trick ;) also just to note that cancelDialog is an activity wipe variable, if you dont need to call it from elsewhere, then you should be able to get away with just limiting the scope of the variable to that method.

Answer 3

The hardware key is the answer here. I'd be careful about generalising the DRY principle to UIs. There are plenty of cases where you need to hammer, hammer, hammer the same point to the user repeatedly via headings, body text, colours and images.

Users dont "read" UIs the way you read a novel. They scan read.

Answer 4

I'm no Android user or developer, but I think the answer given in the linked-to thread is pretty decent: there's a hardware "back" key on all Android devices. Users are supposed to know to press Back to back out of whatever activity they're currently in.

Thus, the UI designers feel it's unnecessary to include a GUI back/cancel button. This could be viewed as the UI application of the DRY principle; if there's already one way of doing something, that's enough.

Answer 5

I can't speak for other apps, but in mine anything that might cause the UI thread to wait is executed in a seperate thread. The most I'll do is show a small progress spinner in the titlebar to let the user know something is going on in the background.