Are UI recommendations or guidelines somewhere. I am looking for the recommendation from Google but unfortunately I can't find it.
I want to see something like "...do not use exit button in your Applications until you really need it...".
I'm sure that the exit button in android app is not good idea, in general at least. But I want to prove this idea to customers and designers.
I need links with explanations.
This video will help your customers to understand: https://www.youtube.com/watch?v=631T7B8HOv4
Basically, the back button is an exit button. So, there is already an exit button!
Show it to your customer and ask him if he wants to look stupid with duplicate button that takes precious space on a small screen.
His app will never look professional.
General Design Guidelines:
http://developer.android.com/design/get-started/principles.html
Best Practices for User Experience & UI:
http://developer.android.com/training/best-ux.html
Providing Proper Back Navigation(Something you were looking for):
http://developer.android.com/training/implementing-navigation/temporal.html
we used back button as Exit button. Generally on Back button, as per clients req we used to show the default dialog to user, "Do you want to exit app ? ".
Generally clients needs this confirmation because if we press back the app is directly exit from app. so just for confirmation to user clients want this exit dialog be there.
No exit button is iOS philosophy, not android. I suggest you stick with device's back button rather than a UI button to exit your app while asking for confirmation via dialog box or a Toast.
Related
I'd like to have an options menu that includes a logout option to exit the entire app, but none of the logout(), exit(), finish() methods I've tried to incorporate do more than just exit the present activity to show the previous one.
I didn't see anything addressing this on the SOF site, so maybe I'm not approaching a logout in the best way. Optimally, it would also prompt a "Are you sure you want to exit the app" message and flush out particular SQLite data- but I'll worry about that after I get the logout part running.
Any insight?
It's a bad practise to kill the app in your application. However if you really need to do this here is a good solution:
https://stackoverflow.com/a/44208360/6683139
So my question is fairly simple, but I cannot find a solution of the entire idea. Running Android App in background should be achievable with Background Service . However, I am not sure how to make "wake up" the service by a specific button press combination.
DUMMY EXAMPLE:
// My app is installed and launched on the device and is running in background since it got installed
void onCorrectButtonCombinationPressed(){
startActivity(someIntent);
}
How to achieve the above scenario ?
Thanks for suggestions and I apologize if there is something silly that I missed out, because to me it sounds easy to do, but I am struggling to figure it out..
That depends on what you mean by a "specific button press combination"
If you want to detect clicks or button presses from your own activity, then handle it within its respective view through standard event handlers.
if you want to detect clicks or button presses from OTHER activities, give up! There is no means by which you can achieve this through (standard) methods. If you root your device you'll have more power to do something like this, but I did some deep research and found no other ways. The reason for this is because imagine how easy it would be to steal information from activities if you could intercept events being sent to it.
I asked a question the other day that may give you further information.
I have been an Android user for more than 3 years already and I am used to enter into a screen (Activity), change some settings and press back. The changes are saved automatically.
Now I am devoping an app and I wanted to use the Discard | Done buttons in the ActionBar. This Activity is a settings Activity so the user changes some stuff and then presses Done. However now I am confused because what should I do if the users presses Back? Should I also save the setting or should I discard them?
To my mind, keep the "discard" button only, and save the setting when the back button is pressed.
For me, the system-back button should offer the same functionality as the DISCARD button. The DONE button shouldn't be disregarded - it's still common (in apps for mobile or desktop-based) to confirm an action, or actively save/send information in a form.
Removing the DONE button as Sporniket suggests means there are two negative interactions (both equating to a cancel) and no confirmation to the user of a save action - for me, I'd be wondering what to do to save the information I'd inputted/changed.
Using system-back as the default save action is counter-intuitive; the system-back button navigates backwards through the activity stack - it's associated with an "exit" by common users, not save.
If you do decide to continue with your implementation (DISCARD only), then ensure you have some visual feedback which allows the user to know that the information has been saved and to help train them (reassure them) that in your app, system-back will save your changes. This could be achieved by using a Crouton when the user presses back, which displays a message telling the user that the data has been saved.
-- Edit:
I should add that my above recommendations are appropriate where the DISCARD/DONE pattern is appropriate. You mentioned in your question that you're used to changing settings, and pressing back, having it save your changes automatically, and I would suppose that these are areas which are predominantly toggles, rather than content that's being edited.
Roman Nurik's post here offers more guidelines, and even mentions a way in which system-back saves information by default. In this instance, he describes having the DONE replace the up affordance, and to hide the DISCARD button in the overflow menu, citing the use-case where the user is unlikely to want to discard information. (IMHO, I disagree with him - I think that if there's a visible DONE or Save action, then system-back should discard, for the reasons stated above. That said, at least it's some guidance for the pattern with usage guidelines from one of the proponents of the pattern.)
Overall, I think it's something that could be better answered if you gave more context about the information the user will be editing in this screen.
I am building an app that requires the user to login to get access to their information. Within the app there are four branches all accessible via menu options. When the user logs in he is placed on the first screen of one of the branches.
I programmed the app so that when the user BACKs to the first screen of any branch, the activity stack is flushed and pressing back again exits the app.
The question: What is the best practice for exiting?
Should pressing back a second time log the user out and return to the login screen.
Or should pressing back log the user out and return the user to the android home screen?
I have seen both ways of doing it and not sure what criteria I should look at to make the proper usability decision.
To clarify the flow:
[Android Home Screen] -> [App Login Screen] -> [Internal App Branch]
I usually capture the Back button, give the user a Toast notification like "Press Back button again to exit". I capture the System.currentTimeMillis and compare subsequent presses for a threshold of 2 seconds or something close to that. I've seen a couple apps do that and it seems pretty intuitive to me.
If the home screen does not require authentication then I would prefer this method. This is a highly subjective question, though. I'm sure there are other people who would disagree with me and say they prefer the log in screen. That's why it's pretty subjective :)
Can someone point me in the right direction to have an Android Application reopen itself to the forefront after a user has pressed the home key? It should be able to be linked to some kind of countdown (which I already have setup, and runs when pushed to background).
I just can't find the function to force this action
*And yes, this is what the user will want, don't worry, I know this doesn't sound user friendly (forcing open) but in this case the user wants it.
Thanks
I needed the exact same thing before -> an app being displayed upon an event but I was sure I read on the Android developers site that this can't be done and that's what notifications are used for, although starting a new activity does bring an app to front. I found this link however to a NEW_TASK_LAUNCH flag with startactivity that might solve your problem -
http://developer.android.com/guide/appendix/faq/framework.html#4