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.
Related
I want to know what are the pro and cons when you try to open a new activity with android and destroy the previous one straight away by calling finish.
People think that is a bad idea because Android can take care of the activity and drop them when there is too much memory used, but what about if I get inside that activity once and probably the user will never come back? Is this a bad option?
Also by finishing the activity, the history with the back button is "clear", so it wont get back to that activity ( only if your user flow needed to go back I think you should not call finish ).
And in terms of memory, is better to kill the activity with finish or leave android to have this activity in the background for who knows for how long time?
I feel like, that you kind of help the system to GC the activity that you closed and make sure that the user wont need to tap the back button 100 times before getting out of the application.
So what do you think? Better call Finish or not
I want to know what are the pro and cons when you try to open a new activity with android and destroy the previous one straight away by calling finish.
Either you want the user to return to the previous activity via the BACK button, or you do not.
If you want the user to return to the previous activity via BACK, do not call finish()
If you do not want the user to return to the previous activity via BACK, there are a multitude of options, depending upon where you do want the user to go when the user presses BACK
People think that is a bad idea because Android can take care of the activity and drop them when there is too much memory used
No, Android does not do this.
is better to kill the activity with finish or leave android to have this activity in the background for who knows for how long time?
It is "better" to have the activity implement onTrimMemory() and reduce its memory footprint as needed. Do not harm the user expectations of the BACK button.
that you kind of help the system to GC the activity that you closed and make sure that the user wont need to tap the back button 100 times before getting out of the application
Few users will "tap the back button 100 times". They will press HOME, or bring up the overview screen (a.k.a., recent-tasks list), or navigate to another app by other means.
Now, that being said, there will be times when you want to clear the task (back stack), again with an eye towards providing a logical flow for the user. For example, in an email app:
The user launches the app, and a fresh task is created, with the user going to the app's launcher activity, which shows the messages in the user's inbox (A)
The user taps on a "search" action bar item, bringing up a search activity, where they can search by various criteria (B)
The user fills in search criteria and clicks the "Go!" button, which does the search and shows matching email messages (C)
The user taps on an email message, bringing up an email-viewing activity (D)
The user taps a "delete" action bar item, which should delete the message and return the user... somewhere
If you believe that the user should return to the search results (C), you could call finish() in D. If, however, you believe that the user should return to the inbox (A), you would call startActivity() on A with appropriate flags (e.g., Intent.FLAG_ACTIVITY_CLEAR_TASK), to clear out the back stack and return the user to A.
In sum: do NOT call finish() to deal with heap space; implement onTrimMemory() instead. However, if navigation calls for finish(), then use it.
I am having a specific problem in my android app. I have 2 activities and the flow is from
Activity 1 to Activity 2.
I press back button from Activity 2 and then it goes to activity 1. This is great. But in some devices if I stay too long on activity 2(Like for days, I check it once in a while ) , and when I press back button it doesn't go back. So I guess history is cleared by android os for getting more memory.
I know that I can manually override onBackPressed() and achieve the functionality, but I need a perfect solution for this. so it will be like
If the history is all right let android handle back, If history is disturbed then I should be able to handle it.
IS there any way to check any issue with history?
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?
I couldn't find it in the docs, is there a module, or some other way to catch events from the android back button? If not it would be a nice and probably quick module to add.
No: the back button just pops you one item back in the history stack. You do something like change the hash fragment to track navigation through your app (frameworks like Backbone.js can do this for you automatically).
The reason we've taken that approach is there's no hardware back button on iOS so we're wary of setting people up to rely on it in their app, only for the app to be fundamentally broken on that platform: we're aiming for consistency of completeness at the moment.
Update: due to popular demand, we've added support for controlling the back button behaviour on Android: http://docs.trigger.io/en/v1.4/modules/event.html#backpressed-addlistener - note backPressed.preventDefault too.
The event handler is passed a function which, when invoked, closes the app, so you could have code like:
forge.event.backPressed.addListener(function (close) {
if (atHomeScreen) {
close();
}
}
I'm ware of androids life cycle and that it's not needed to add a "exit" button in the application.
But still, this back button stuff isn't really working out well.
You maybe know this issue from the default SMS-App that android comes with: you open it when you get a new message and exit it using the menu button or something else.
After like 20 times doing this, you then decide to exit the app using the back button, what happens? you have to go back though 20 views. every time you press back you return to the "all messages (by sender)" listview and when you press back there again you return to the message opend 20-1 (message 19). again you press back and return to the listview and again you press back and end up at message 18. till, after40 times pressing back, you finally exit the messanger app.
same happens when for example you got a action bar with a "home" icon which opens the main screen of your app. the user picks a action and the new activity starts. than the user clicks the home button and returns to the main screen. when pressing the back button - no matter if you call finish() in the onButtonBack listener or not, you the user would expect the app to exit, but in fact the app returns to the previous activity which is wrong.
such cycleing may happen for various reasons, thats why - even thought i'm aware of the supposed to be lifecycle of android - i wan't to EXIT (& destroy) the app when pressing back within a defined activity.
calling finish() dosn't help. if there's a previous activity it will re-open it. calling system.exit(0) isn't nice to do.
so: whats the right way to prevent such back-press-cycles and/or exit a application (WITH destruction)?
for better illustration of what i want to achieve: consider A, B, C being activities. a arrow (-->) illustrations a new intent call from the activity leftside of the arrow, rightside of the arrow represents the activity that is called. ex.: A --> B means activity A starts activity B. now here's what i want:
1) A --> B --> C pressBack:--> B pressBack:-->A pressBack:--> Exit
2) A --> B pressBack: --> A pressBack: --> Exit
3) A --> B --> A pressBack:--> Exit
as you see, back works as always, BUT when in activity A it exits the application.
the behaviour i got now is 1) and 2) as above but
3) A --> B --> A pressBack:--> A pressBack: --> Exit
keep in mind, i've already overwritten the onBackPressed listener of activity A with a finish() call. even calling system.exit(0) dosnt work. however, even if it would: its not what i want, i want the REAL way to do it android style - i cant imagine system.exit(0) is best practise.
Well this is the default behavior.
If you have another approach, just implement it.
One approach to deal with this is to use the android:launchMode="singleInstance" for activities that can be launched in a singleton manner (only one activity can exist)
For example, if the SMS page in the SMS app was a singleTop, it would have needed only one back press to remove all the SMS pages. It is a matter of choice
Another more aggressive way would be to finish Activities when you start another activity. Of course, such decision would risk making the app less friendly (android users are not accustomed to this behavior). Nevertheless, if this is used only where it may be considered acceptable then it might be acceptable.
A very acceptable place to do this would be a login screen: Once login is successfull, you start another activity (probably designed for logged in users) and finish the login activity.
Enjoy Finally, in my personal opinion, you can add an Exit button. Users will find it nice.
Check my post: Adding an Exit button to Android Application