I want to disable back button from closing the app.
How can i disable back button?
You can override the onBackPressed() method and determine what happens in that method. Like this:
#Override
public void onBackPressed() {
// do nothing because you don't want them to leave when it's pressed
}
Just add that method to your activity class and you're good to go.
However, this is bad app design. What you would most likely want to do is make a dialog pop up that asks them if they are sure they want to leave. You would add the dialog code inside that method so that when the back button is pressed, the dialog pops up.
Generally, that's not a good idea. Users hate to feel "trapped" in your app.
Many users are able to start apps "on top of" other apps. When they hit "back" they may expect your app to stop, and the app they were in previously to appear. This is different from "home" where they expect all apps to go to the background.
Users familiar and comfortable with this functionality will not like it if you change "back" - although you may give them options like "press back again to exit" as some apps do. It depends on your particular situation.
So if you are in need of it, here is a good reference:
Android - How To Override the "Back" button so it doesn't Finish() my Activity?
Related
I have an app that consists of two activities: the "main" activity (M) and the "settings" activity (S). S can only be launched from M. The purpose of S is to modify settings which affect M. S has a "done" button that finishes the activity and goes back to M (through M's onActivityResult method, with an Intent that contains the new settings for M to apply).
My problem is: if I go back from S to M using the hardware "back" button (instead of S's "done" button) the system brings M to the top without any knowledge of the modified settings. Can this behaviour be modified? Ideally I would like to alter the behaviour of the hardware "back" button when S is on top, so that it cause S to finish (that way M would get the new settings).
If that's not possible, and more generally: what would you do you to have the settings applied on a "back" button pressing?
You can simply override onBackPressed()
#Override
public void onBackPressed()
{
// check if settings have been changed
super.onBackPressed();
}
Since this is a "closing action" do the super call after you have done your other work.
Following up on comments left on blackbelt's answer (now deleted comments) you may want to consider, if you haven't already, asking the user if they are sure they want to exit without saving in case they went into settings and decided not to change anything. What if they press the back button because they decided not to save the changes? You may already have something in place for this like a cancel button.
you have to override the onBackPressed from Activity and manage the same logic from the done button
You can also introduce a new java class to your package with static fields holding your settings.
Write to them as user changes settings & read from them as soon as in Activity's OnResume() method or later as needed.
You can achieve what you want by overriding onbackpressed method
#Override
public void onBackPressed() {
Intent intent = new Intent();
//get your settings from your views
intent.putExtra("setting1","on");
intent.putExtra("setting2","off");
setResult(RESULT_OK);
finish();
}
The answers above will do what you want, however:
Have you looked into using the built in android SharedPreferences? That way changes to the settings (made in S) will be stored to the device and then you can tell activity M to look at the settings and update appropriately in the onResume method. Plus the settings will be saved forever and it doesn't matter what happens to S.
How to complete the application when pressed buttons Home and Back? Provided that in my memory holds many pictures.
When pressed on the Back button - application restarts... When pressed on the Home button - quit application, but when it restart - does not start Splashstsreen.
Hard to see without code but it sounds like your activity is resuming rather then starting from scratch (as it should behave). It sounds like it's behaving correctly in that case. If you insist in wanting your application to truly quit after the back button is clicked perhaps you can override onBackPressed() then have your Activity call its finish() method.
I don't think it's good programming practice to fiddle and interfering with the activities lifecycle. It's the OS responsibility to manage the lifecycle, including pause and finish activities.
Instead you should use other methods to handle your problem with not showing splash screen, these methods are onResume and maybe also onStart(). Also you should get familiar with the activity lifecycle(link submitted by #ss1271).
Press Home will let the activity to enter onPause(). however, if you insist to quit the application when press HOME, which is obviously not a good practise, you can do like this:
Override onPause() and onBackPressed()
add finish(); to these methods.
I am sure by adding finish(); to onBackPressed() will quit the app when Back button pressed, but I haven't tried on Home.
Please refer to Activity Lifecycle for more info.
if a user tapped the home button and open the app after that, how to not allow back? eg don't allow users to go back to screens that they seen before tapping the home button. It should be treated as a new session
This sounds like a bad idea, as it blatantly goes against the Android task/navigation guidelines.
The user expects to be able to back out to the previous screen after resuming a task... and preventing it will potentially piss off a lot of users.
Please, please, please read these documents before you risk destroying the user experience.
App structure
Navigation
Tasks and back stack
The home button cannot be overridden nore should it, if you dont want the user to go back to the activity they left when the home button was clicked then on the on pause of the activity just pop the backstack to where you want to be.
see this answer
If you want to end your Activity once it is no longer visible then finish your activity in your Activities call to onStop().
#Override
protected void onStop() {
super.onStop();
this.finish();
}
This will finish your Activity with no chance of onRestart() being called. Be careful with this method because users expect to resume the app instead of having to start over, but there are cases where this would be the accepted protocol. See more on Navigation and the Activity LifeCycle.
Edit:
Also see the question Android-Quittings an application - is that frowned upon? specifically this answer.
I have an app in which the user logs in from a main activity, and then can browse through a heirarchy of entities using listviews. So, the Activity stack would look something like this:
A -> B -> B -> B -> ...
where the number of B's is proportional to how deep you are in the tree of entities.
Frequently, I find myself pressing backbackbackbackback to get to the root (the first 'B'), but one too many presses and I log myself out, or even leave the app. I'm considering overriding the back button so that, when pressed from the root B, it will pop up a dialog essentially saying "Log out? (Y/N)", thus blocking a string of back-presses from completely exiting the app.
I've noticed a sort of sensitivity regarding overriding the back button, though, and - while it makes sense to me - I want to know if this is considered a good use of the back button.
So:
Would this be considered an appropriate/conventional override of the back button?
Is there a better/more conventional way to accomplish this without overriding?
Also, so this question might be more generally useful in the future, are there any guidelines for what is acceptable/unacceptable when overriding the back button?
I would find this use acceptable; I've seen a number of apps that ask for a confirm before exit - if the user wants to exit an app, they usually will press the Home button and let Android handle the finish() if and when it's needed.
I know I've accidentally exited an app by pressing back too many times :(
Dotmister's comment about Handcent is spot on - the back button should feel natural to the user; your use seems to adhere to this, in that a user will cycle back through activities as expected for the most part. As he said though, give it a try and test it.
Coincidentally, I have a similar flow in my app, but I've included a button for the root activity.
No it is not normal to overide the back button because the user ecxpects the back button to function as a... ?? back button.
On the other side if it is really that annoying using the back button in the normal way, than a compremise? will always be better. But make sure the user still has the idea he 'controls' the device according his rules, do not make him look for yours. (dutch way of making a point, sorry).
The only way to find out is getting some people to try your application and see if it's annoying or not.
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.
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.
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;
}
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:
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.
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().
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...