Should android up action save state of current activity? - android

The use of the Home / back button is well documented within the android docs here and here, however it does not state if the expected usage will "save changes" to the state of the current activity.
My specific situation is a user is presented with a data entry form (list of equations) that can be manipulated (and possibly have the data messed up by applying crazy maths) so i want the user to be able to leave "without saving changes".
It is unclear if this is the expected action of the home button, or if it is expected to allow users to return to the activity as they left it.
Clarification would be grand.

My expectation is that the user is prompted when pressing Up, informing the user that her information will be lost. When she confirms, loose the information, when she cancels stay on the Activity.
Edit: Better to only show the prompt when there was any editing done. Otherwise it might be just annoying to the user.

The HOME/BACK buttons are means provided to the user to navigate in an App. The BACK button normally acts as a means to navigate user to the parent of the current screen (Activity) or to the last screen in the chronological order.
HOME button is a quick way to suspend whatever the user is currently doing and come back to it later. So when the user next comes back to the app again, he can start from where he left. Android framework by default will retain the APP or UI state (mostly), so you have to hardly do anything if you want to stick to the default behaviour. But it really depends on the nature of the App. There are apps, which will trim down to the app main screen next time when the user launches (But these are very few).
Also note, that it is really upto the system how long it is going to retain the app's state in the background. Sometimes it gives to memory pressure and user has to start from scratch next time when he launches the app.
hope I answered your question

Related

Activity Lifecycle. When application already opened (Collapsed) is closing and starting again on icon click?

Can you please explain to me why my activity which is currently (onStop) is go to OnDestroy event and restarting again after clicking on the app icon in the interface.
Because of that i have problem with user data saving. I'm using event OnDestroy to ask user if he want to save the data. Because of my misunderstanding when i collapse the app and click to it again i am waiting to my activity to have all the data in it but instead i see saving dialog from the previous activity whiсh goes to onDestroy event.
Other apps don't act like this.
What should i check?
Your description is not very clear, so my answer may not help you.
Research the app life cycle here: https://developer.android.com/guide/components/activities/activity-lifecycle.html
Your app will enter onStop is before onDestroy. This can happen if user activates another app. (So the user may no longer see any prompts that you display e.g. To ask to save or not.) Android may choose to destroy your app based on its rules after that point, even if the user clicks on the app icon to start it again.
Perhaps you can test what happens if the user switches back to the app (not clicking the icon), but use the "Recent apps" button and select it.

Discard | Done pattern how to correctly implement in conjunction with the Back button?

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.

Why does my app open more iterations

When I open my app for the first time, it launches the splash screen, then goes to a home page.
Usually when I reopen the app (by pressing the app icon) I am directed to the home page properly. However, sometimes I get the splash screen again.
This wouldn't be a problem (because it means I'm reopening the app) but when I press the back button from the home page, I see the last iteration of my app (still open and running).
So what is going on?
Thank you
Try adding launchMode="singleInstance" to your android <activity> manifest.
http://developer.android.com/guide/topics/manifest/activity-element.html#lmode
Generally the default behavior of android apps makes sense. If you have multiple activities you generally expect that pressing the back button will move you back to the previous state. It is possible to have multiple versions of the same activity in your activity stack and negating this would not be expected. If I filled out a form twice then pressed back to the first form I wouldn't expect it to contain my second form's data, for instance. But for specific types of applications this does not make sense. There are multiple ways to handle this so you need to be aware of what you app will be doing and what the expectations for your app will be.

Should app logout to logging screen or home 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 :)

Are the 4 Android buttons standard? Ex. back button, menu button

Are the physical buttons that Android phones come with standard? Specifically the back, menu, home, and search button? In my applications I assume everyone has a back button so I don't bother putting in a "soft" button to go back to a previous screen.
For some reason I can't find any official documentation on this.
Looking at http://www.androphones.com/2010-android-phones.php it appears that all of the phones have at least the back, menu and home button.
Should I just assume all phones have a back button or do I have to always code one in my apps?
The CDD describes what is required to be compatible:
http://source.android.com/compatibility/index.html
(See "Current CDD" on the left)
In this case:
7.2.3. Navigation keys
The Home, Menu and Back functions are essential to the Android
navigation paradigm. Device implementations MUST make these functions
available to the user at all times when running applications. These
functions MAY be implemented via dedicated physical buttons (such as
mechanical or capacitive touch buttons), or MAY be implemented using
dedicated software keys, gestures, touch panel, etc.Android 4.1
supports both implementations
I haven't been able to find any definitive answer one way or another. However, the documentation assumes there will always be a Back key that the OS responds to:
As the user moves from activity to activity, across applications, the Android system keeps a linear navigation history of activities the user has visited. This is the activity stack, also known as the back stack. In general, when a user starts a new activity, it is added to the activity stack, so that pressing BACK displays the previous activity on the stack. However, the user cannot use the BACK key to go back further than the last visit to Home. The adding of an activity to the current stack happens whether or not that activity begins a new task (as long as that task was started without going Home), so going back can let the user go back to activities in previous tasks. The user can get to tasks earlier than the most recent Home by selecting its root activity from the application launcher, a shortcut, or the "Recent tasks" screen.
Activities are the only things that can be added to the activity stack — views, windows, menus, and dialogs cannot. That is, when designing the navigation, if you have screen A and you want the user to be able go to a subsequent screen B and then use the BACK key to go back to screen A, then the screen A needs to be implemented as an activity. The one exception to this rule is if your application takes control of the BACK key and manages the navigation itself.
From http://developer.android.com/guide/practices/ui_guidelines/activity_task_design.html
Based on that, I would say it is safe to assume that there will always be a physical Back key.
If you are developing specifically for the android the back button is standard.
The only other thing you could do is within the menu add a 'back' option, but it is redundant at best.
Amazon Fire phone do not have a back key.
On Android platform it is generally wrong to assume that, standard defined by an entity will work everywhere. It is usually depend on device manufacturer.
if your app rely on some specific device feature, make sure that you check and recheck, if that specific feature exist on device. Some time just putting information on AndroidManifest is not enough.

Categories

Resources