3

I've already discovered that you can't override the Home button on an Android phone. It exits the application, it ALWAYS exits the application, and it DOESN'T bother with any sort of namby-pamby confirmation. I suppose I understand Google's reasoning -- but I do think it's a bit short-sighted...

Anyway, (before I learned about the Home button), I set up my app so the user can exit the application through the Options Menu -- using onCreateOptionsMenu() and an XML file, I set up a simple pop-up menu that's displayed when the Menu button is pressed. One of its choices is Exit, and it works fine.

However, it occurred to me that it might be good practice to add a confirmation dialog to the exit process (even if it could also be considered superfluous). So, I created an AlertDialog with the title "Do you want to Exit?" and Yes and No buttons...

The click listeners for the buttons are simple and just set exitConfirm (a boolean) true or false. The code that handles the Exit menu choice then cleans up after my application and executes finish() or not depending on the state of exitConfirm...

Unfortunately, it completely doesn't work... All of the code in onOptionsItemSelected() for the exit case executes and THEN the Dialog is displayed!! I suppose I should've seen that coming. And I suppose if I keep pounding on it, I'll come up with a way accomplish this, but I thought I would ask the community for suggestions - so, does anybody have a suggestion for a way to smoothly exit an Android application in a manner that includes the step of getting confirmation from the user??

Thanks, R.

Davek804
  • 2,804
  • 4
  • 26
  • 55
Rich
  • 4,157
  • 5
  • 33
  • 45
  • 2
    "It exits the application" -- HOME does not immediately "exit" anything, any more than minimizing a window in Windows "exits" anything. "and it DOESN'T bother with any sort of namby-pamby confirmation" -- if your activity is in the foreground, it will be called with `onPause()` and `onStop()`, just as in any other case where another activity takes over the screen. Bear in mind that this also happens when the user takes a phone call, responds to an SMS, has the alarm clock ring, etc. – CommonsWare Dec 07 '10 at 22:49

3 Answers3

6

First of all - this is a terrible practice. Asking for confirmation may be a nice option on a desktop application, but you're writing a mobile application. It's different. Actually, I need to write that in bold:

You are not writing a desktop application.

I recommend: No splash screen. No exit option. Definitely no exit confirmation. Here is an excellent question about it.

For your question: Use setPositiveButton and setNegativeButton to handle buttons.

Community
  • 1
  • 1
EboMike
  • 76,846
  • 14
  • 164
  • 167
  • There's nothing special about desktop apps that says only they should be shutdown gracefully. My app does several desktop-ish things: It communicates over Wifi via TCP and needs to be able to disconnect that connection at the right time -- and NOT disconnect at the wrong time. It accepts user input and changes what going on accordingly, etc. I get that I'm not making a normal Android app, but I don't really see that as my problem. The ultimate answer is, inevitably, "That's the way it is, deal with it," and I get that. But I don't think that's really the best way to do things. – Rich Jan 31 '11 at 15:37
  • This is a smug unhelpful answer. There are plenty of valid cases where you'd be stupid *not* to have exit confirmation. – Cerin Jul 11 '12 at 23:36
  • 1
    @Cerin This isn't a smug, unhelpful answer. It's a correct answer. I think you misunderstood his tone... he wasn't being smug at all, he was just speaking the truth. You shouldn't have an exit button in your Android app. – Alex Lockwood Aug 06 '12 at 21:21
  • You developed a kids app & while playing, kids accidentally pressed back button! what then, as a caution, you need that. – sai Dec 18 '13 at 06:02
4

Short answer:

You should read: When to Include an Exit Button in Android Apps.

Long answer: You can try something like this:

protected Dialog onCreateDialog(int id) {
        Dialog dialog = null;

        switch (id) {
        case MENU_QUIT:
            AlertDialog.Builder builder = new AlertDialog.Builder(this);
            builder.setMessage(getString(R.string.main_screen_quit_text))
                    .setCancelable(false)
                    .setPositiveButton(
                            getString(R.string.main_screen_quit_yes),
                            new DialogInterface.OnClickListener() {
                                public void onClick(DialogInterface dialog,
                                        int id) {

                                    moveTaskToBack(true);
                                }
                            })
                    .setNegativeButton(getString(R.string.main_screen_quit_no),
                            new DialogInterface.OnClickListener() {
                                public void onClick(DialogInterface dialog,
                                        int id) {
                                    dialog.cancel();
                                }
                            });
            AlertDialog alert = builder.create();
            return alert;
        default:
            dialog = null;
        }
        return dialog;
    }
Macarse
  • 91,829
  • 44
  • 175
  • 230
2

Apparently, it's generally considered not to be cool to have an exit button (or menu item, or whatever) in your Android app. Apparently, this is because your application doesn't really exit. It's only minimized out of the way, and presumably, the OS will take care of it eventually.

However, if what you're doing requires some level of clean-up when you're done doing it, this is what I think I know about that:

  1. Pay careful attention to the various Android "Life Cycle Methods", especially what kicks them off. Life cycle methods include onCreate(), onStart(), onResume(), onPause(), and onStop(). There's also onDestroy() -- the complement to onCreate() -- but I don't currently use it.

  2. These methods are called in response to various events (like pressing the Home button), but what was important in my case was that minimizing the application calls onPause() and maximizing it calls onResume(). Hence, I needed to call my set up and tear down methods from those locations, and NOT, for instance, from onCreate() and onDestroy().

  3. There is a function called finish() that I used to use all over my code. Now it's only in the method that's called to handle loss of communication with my external device. I believe the results of calling finish() are exactly the results of pressing the Home button -- so, it's just a way to "press" the Home button in software.

The long-winded conclusion to all this is the Home button absolutely WILL hide your application from the user's view. You cannot trap this key press -- no matter how badly you want to add some sort of, "Are you sure??" functionality. However, the app's been minimized, not closed, and this can either be good or bad. If you've written your start up and shut down code properly (and added it to the proper life cycle methods), you won't blow things up, and your user will be able to easily return to your app once they've learned to long press the Home button to see a list of minimized apps.

With any luck, I suppose, they'll blame their frustration on Google, and not on you...

Alex Lockwood
  • 83,063
  • 39
  • 206
  • 250
Rich
  • 4,157
  • 5
  • 33
  • 45
  • Sure, you can downvote people who disagree with you all you want, but you still don't understand the difference between a desktop app and a mobile app. Your app can be hidden at any time, like an incoming phone call. Do you want a confirmation dialog then? Users of mobile phones switch between apps a lot more, and since there is no virtual memory, a background app can be killed at any time without warning. You should read some of the links in the other answers you got. If you an open TCP connection, you can offer an option to close that, but not kill the app itself. – EboMike Feb 01 '11 at 23:02
  • Isn't that what downvoting is for?? I've read all the links multiple times, and there's just not as much difference between a desktop app and a mobile app as you maintain. As for an incoming phone call, OF COURSE I want a confirmation dialog, when that's what I want. And it is. Quoting you, "A background app can be killed at any time." One assumes it's a decision based on resources, but it seems to me that that would make it even more important to avoid accidental minimization, not less. – Rich Feb 02 '11 at 22:49
  • 2
    `finish()` does not do the same thing as HOME; `finish()` does the same thing as BACK. – CommonsWare Jun 22 '11 at 23:28