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.
Related
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
Background
Let's take the next sceneraio:
the user uses an app X which has multiple activities (like the gmail app).
after navigating the app X a bit, he goes to your app.
in your app, you need to start this X app using an intent, to go to a specific activity within it.
now the user goes to this specific activity on the app X.
the user presses the back button, hoping to go back to your app instead of staying on the app X.
another similar scenario:
the user navigates on your app between activities.
your app went to the background (using the home button, for example).
your app shows a notification that once clicked, it will open a specific activity of your app.
the user clicks on the notification and goes to the specific activity of your app.
the user presses the back button, hoping to return to the app that was shown before clicking on the notification, instead of going to the previous activity on your app that was shown the last time it left it.
It seems that the last step on both scenarios isn't the default behavior.
This is why I've searched what is the best combination of flags for this purpose.
The problem
It seems that the only flag that can achieve the behavior i've described is Intent.FLAG_ACTIVITY_MULTIPLE_TASK (together with Intent.FLAG_ACTIVITY_NEW_TASK).
According to the android API, however, this flag isn't recommended for normal use:
Do not use this flag unless you are implementing your own top-level
application launcher.
...
Because the default system does not include
graphical task management, you should not use this flag unless you
provide some way for a user to return back to the tasks you have
launched.
This information seems as confusing as the rest of the descriptions about intents.
There are other intents flags that I've seen, like Intent.FLAG_ACTIVITY_CLEAR_TASK that achieve a similar result, but they have weird behaviors and/or they use high API
The question
Is it safe to use this flag? Are there any good alternatives to it?
What is the danger of using this flag and what is the meaning of the description on the API of using it?
In your first scenario, if your app needs to start an activity of another app, it can just start this activity within the same task as your application. There is no reason to use any special Intent flags for this (you don't need FLAG_ACTIVITY_NEW_TASK or FLAG_ACTIVITY_MULTIPLE_TASK). In step 5 of your scenario, the user will return to your application (because BACK just takes him to the previous activity in the current task). This is the standard, default behaviour.
In your second scenario, my first response is "that isn't the standard behaviour". That means that users probably won't expect to be able to go back to the task that they were doing prior to clicking on the notification. However, if you really want to implement this, then I would suggest that you create a special Activity that is launched from the notification and this special Activity should have a different taskAffinity than the rest of the Activities in your application. In this case, when the special Activity is launched from the notification, it will not bring your application's task to the foreground. It will just create a new task containing just the special Activity. When the special Activity is showing, the user can press the BACK key and this will return him to the task that he was working on prior to clicking on your notification.
In general you should NOT use FLAG_ACTIVITY_MULTIPLE_TASK. The main reason is that if you have several tasks containing your application (or parts of it), it is pretty much impossible for the user to return to a specific one. There is no way to provide different launch icons or different application names (for the different tasks)(, so that the user will see multiple tasks in the "recent tasks" list, but will not be able to tell which one is which. You will have a hard time cleaning up what you are doing and you will just make more problems than you can deal with. There are about a million side effects of using this flag and for general applicaitons there is just no need to do it.
My app is designed to run as a single instance and the Back button does not allow you to exit the app and return to the Start screen because it is used internally to navigate a hierarchy of screens where each screen can be an activity.
However, an external app can launch one of the app's internal activities. When the user is done with whatever the activity is designed for, the user's intuitive action is to hit the Back button to return back to the calling client. But because I prevent the Back button from exiting, the user cannot return.
I can add code to override this when the code detects that the activity is being launched by a client. The problem however is that if the app closes to return, the user might return to the app from where they left off. But since I closed the app to return to the calling client, the user cannot return back to the app as it was last opened. My app needs to remain as a single instance, so the activity that gets launched cannot be created more than once. Any suggestions on how to return back to the calling client but also keep the app running if it was running when the calling client used one of its activities?
In general, you can programmatically control the back navigation trail. Take a look at
TaskStackBuilder and the documentation for handling notifications Responding to Notifications. It seems that what you're trying to do is control the so-called "back stack". If you use TaskStackBuilder, the behavior will match the platform version you're on.
In pre 3.0 platforms, the Back button went all the way through the back stack to the first task the user did since the phone was turned on. Post 3.0, back does not traverse task boundaries; to get to other tasks, the user clicks the "Recent Items" icon. There's also the "up" icon in an app to navigate to the "beginning" of a task within an app. TaskStackBuilder will "do the right thing" for all versions.
In the current platform version, not allowing Back to exit your app is OK, because Back should only go to the first Activity in the current task. In versions previous to 3.0, not allowing Back to exit the app is more problematic, and I personally wouldn't do it that way, but it's up to you.
What happens when the user clicks Back after an Intent starts your app should be clear from the documentation I've cited. Basically, what you want to do is go back to the previous task.
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.
We're trying to provide an application to the mentally and physically handicapped daughter of my neighbor that let's her use an Android tablet as a Talker, i.e., she presses a few big buttons and the devices generates speech. The application is basically a WebView and an additional object in Javascript used to perform and control the speech generation, plus some logic to handle the orientation changes. Html files are generated offline for her specific layout of the talking items. We've also added some music playing and picture viewing facilities to make the device more appealing to her.
Problem is that the home button brings her back into the madness of the Android launcher screen, and that on the test device (Archos 70) the home button is not a physical button but rather shown on the touch screen itself, making it too easy to accidentally hit it.
So I'd like to return to the Android launcher only by pressing a sequence home, back, home with no other action in between.
Can I achieve this by making my application itself the launcher? How can I then get back to the original launcher upon the home, back, home sequence? It seems that this goes deep into the innards of Android, huh?
The only clue I found so far is Overriding Home button for a Car Home replacement app, but this is rated -1 and reported to work in the emulator only. Also I doubt if I could completely abandon the original launcher, as otherwise there is no access anymore to e.g. the USB mass device control to allow new HTML files to be downloaded, the application to be killed and restarted, and so forth.
I'm willing to go for a kludge as well. Maybe a background service could be started that would bring the application to the front again as necessary?
The Home button cannot be overriden. You can write an application that responds to the home intent (that's what a launcher does) but that's all.
Can I achieve this by making my application itself the launcher? How can I then get back to the original launcher upon the home, back, home sequence? It seems that this goes deep into the innards of Android, huh?
Yes. Not too deep into the
innards. You can manually start a launcher by specifying the component, note that this may vary from device to device and user to user, if you're just using this privately you could hard code it, but if you release it you must allow the user to specify their real home app.
/* This should come from a preference that let's the user select an activity that can handle the HOME intent */
String packageName = "com.android.launcher";
String packageClass = "com.android.launcher2.Launcher";
Intent home_intent = new Intent(Intent.ACTION_MAIN);
home_intent.addCategory(Intent.CATEGORY_HOME);
home_intent.setComponent(new ComponentName(packageName, packageClass));
home_intent.addFlags(Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECENTS);
/* Here you should catch the exception when the launcher has been uninstalled, and let the user save themselves by opening the Market or an app list or something. Users sometimes use root apps to uninstall the system launcher, so your fake launcher is all that is left. Might as well give the poor user a hand. */
startActivity(home_intent);
Detecting home/back/home is a bit awkard because home won't come as a onKeyEvent but instead as a new intent. Simply long-pressing the back button then display a prompt is probably a safe/good approach.