Is it correct that back button is available in all android phones/tablets API-8 and above ? Since if it is not a standard feature I would like to put ActionBarsherlock in my app for navigation
My app totally relies on the existence of a back button is it correct approach or should the action bar must be provided on certain versions ?
Thank you
yes it is available on all API-8 + android phones, to keep consistancy though, the home icon in the action bar should be used as a back button as well :
from http://developer.android.com/guide/topics/ui/actionbar.html#Home
Note: Up navigation is distinct from the back navigation provided by the system Back button. The Back button is used to navigate in reverse chronological order through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy structure (which is the basis for up navigation).
Related
I'm coming from the iOS world and need to port an app with the typical tabbar/navigation pattern to Android. The UI design is the client's decision, so I can't change it (I'd still like to hear from you if you think it's appropriate or not for Android).
So the idea of the app is the following:
3 Tabs are always shown on the bottom of the screen. Inside each tab there can be a hierarchy of screens, with the title and up-button showing in the action bar on the top.
How do I implement this in Android? Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity? How should the hardware back button behave? Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
As you can see I'm struggling with all these basic concepts and I'm very thankful for any tip that can help me to implement this navigation structure.
Edit:
Thanks to the competent answer of CommonsWare and looking deeper into it, I realise that I really should push the client to use an UI that's more suitable for the platform. (Also, I know I should use an Android device for some time to get used to the concepts, but I can't change that for now. So I'm sorry for these newbie questions).
The thing is, the app existed before as a web container app with an ugly jquery mobile UI with the above described UI elements. The idea is now to make the app navigation native with native animations, while keeping the content views in html/css/js inside webviews. So while it's possible to adapt each platform's UI principles, I cannot change the general structure of the app, which is: 3 different main entry points, and in each of them the content is navigated hierarchically. I've implemented that in iOS with a tabbar and navigation controllers which works great. The challenge is now to implement it in Android. To reassure that I'm on the right path and understood the points of CommonsWare correctly as well as to maybe receive more tips, I'm writing down what my thoughts on the steps involved:
As CommonsWare suggested, I could replace the tab idea with action buttons in the action bar, which will work well as there are only 3 of it. So it's appropriate to use action buttons for navigation? There will be an additional button for switching the language (Yes I know, usually I should pick the current language of the system, but in this particular app language switching is important and the user will switch it several times while using the app). To separate the navigation action buttons from the language switcher, which works on the current content and is a bit less important, I put the language switcher under the so-called "action overflow" (the 3 dots on the upper right corner).
Now there is an action bar button for each "tab", so far so good. But is there a way the user can tell on which "tab" he is? Or should I only show two action bar buttons at any given time, hiding the one he's currently "in"?
Each of these action bar buttons starts a new activity (with it's own action bar, right?). Inside such activity, the user can navigate hierarchically and back using the up button or back button. He can also use the hardware back button to go back to the last "tab"; would this be appropriate?
Every screen in the navigation hierarchy is a separate activity with a title and a webview.
In the end, to make the whole app compatible back with gingerbread, I would use the actionbarsherlock library, right?
3 Tabs are always shown on the bottom of the screen
That violates the Android design guidelines. On Android, tabs go at the top.
Inside each tab there can be a hierarchy of screens
Outside of a Web browser, I truly detest this navigation concept.
Am I correct in that the tabs need to be a fragment which need to be implemented in every single activity?
You do not appear to have more than one activity in your proposed design.
Say if I switch to a certain tab and then press the back button, should the tab change back or should it mirror the up-button's functionality?
And this is one of the reasons why I truly detest in-tab navigation. Tabs are for presentation of content, not as a navigable container in their own right.
should it mirror the up-button's functionality?
Since you do not appear to have more than one activity, it is unclear to me that you even have an up button.
How do I implement this in Android?
Ideally, you dump the tabs and use action bar items to switch between the different navigable areas, each of which would be its own activity. In that case, back (and to a lesser extent up) will flow more naturally.
If you had more than three tabs, you might go with the navigation drawer pattern, with the navigable areas each having an entry in the drawer. Three, though, would make the drawer look rather empty.
There is plenty more on app structure in the Android design guidelines that can help.
The UI design is the client's decision, so I can't change it
The objective of an app is to allow the users to accomplish their objective. Using design patterns native to a platform help in this regard, by allowing the users' existing experience to guide them in the use of the new app. This is not to say that true innovation beyond the guidelines is inappropriate, but it requires experience and deft hand.
Your client appears to be saying, "hey, this one firm came up with a design pattern for their platform, so therefore let's use it everywhere, as we want a consistent UI design". The problem is that nobody cares about consistency between platforms except them. Few people own mobile devices from multiple platforms, let alone use the same app on both, let alone expect the same UI design on both. Certainly, design touches (e.g., color scheme) could be similar, and the objectives of the app will be similar if not identical. But the delivery of that functionality should use design metaphors and patterns that are native to each platform, as the user is far more important than is your client.
(and if your client says "well, we are the users", because this is an internal-use-only enterprise app, kindly explain to them the concept of the passage of time, introduce them to the notion of employee turnover, and point out that they won't be the users all that long compared to the possible lifetime of the app)
Your client, if they ran a US-based car rental agency, would argue that their firm should rent left-hand-drive cars in the UK, for a consistent UI experience, despite all the accidents that will cause in a left-hand-traffic country.
Now, let's pretend for a moment that you need to write this app following their UI design anyway. Hostages are being held at gunpoint, somebody has a nuke on a hair trigger, the bad guy is demanding the app, the clock is ticking, you're Kiefer Sutherland, and so on.
(and if you really are Kiefer Sutherland, ummm... hi!)
You will wind up with a single activity for this core UI. Ancillary stuff (e.g., preferences, help) would be separate activities, but the three-tabs-to-rule-them-all UI would be in one activity.
The tabs themselves probably would use a FragmentTabHost, perhaps with modifications to better support tabs on the bottom. This is not a common choice, but it's the best fit. ViewPager and a tabbed indicator would be another possibility, if the client does not consider a horizontal swipe to change tabs to be "the devil's gesture" or something. Action bar tabs are at the top and are not always tabs, as they sometimes convert to drop-down navigation in certain screen size and orientation combinations.
Each tab would be a fragment and most likely would use nested fragments for the in-tab navigation between panes of content. Again, there are other possibilities (e.g., lots of hiding and showing of widgets within a single fragment to handle the navigation), but I think you'll go crazy trying to manage all of that.
With respect to the BACK button, without knowing the context of the tabs, my gut instinct would be to follow the tabbed browser metaphor of "BACK is local to a tab". I think that you'll need to manage this manually, unless it magically works because you are using nested fragments, and I don't think that's the case. When you are at the beginning (nested) fragment for a tab, and the user presses BACK, exit the activity.
I am trying to understand what happens when you press the back button. how does the system manipulate the back stack? From where does it get the window handle to the top window?
I have looked into the PhoneWindowManager.java, but couldn't find what I am looking for. Has anybody seen this code earlier?
What you are refering to as the "back button in the action bar" is called the "up button". The difference between the two is well explained in that article from the documentation: Navigation with Back and Up.
In short:
The Up button is used to navigate within an app based on the hierarchical relationships between screens.
The system Back button is used to navigate, in reverse chronological order, through the history of screens the user has recently worked with. It is generally based on the temporal relationships between screens, rather than the app's hierarchy.
Difference is well market for instance when you navigate to an app from another app. E.g.: you are accessing an application's Google Play screen from a link in your mailbox. Once in Google Play:
Up will take you to Google Play's home for applications
Back will take you back to the GMail application
Well, this will take you back, as like the back button would:
super.onBackPressed();
The documentation for onBackPressed() says that the Back button simply ends the current activity. No back stack manipulation is needed.
At a deeper level, Android does maintain a stack of activities inside of a Task, and it can determine which activity to show next when the top activity finishes. But those mechanisms live in native code and are probably beyond the scope of what you're trying to do. As far as I know, the best you can do from Java is to use RunningTaskInfo (source code here), which will expose the "base" and "top" activities in the current Task.
If you're trying to implement complex app navigation, there are a number of flags that you can use to control the way in which activities are placed on the stack.
I am trying to create an android app that has the following:
Theme set to #android:style/Theme.Black
Bottom options menu button on all activities except for one.
I am trying to remove the bottom menu button from the activity that I do not want it to appear on by returning false in the OnCreateOptionsMenu method. This doesn't work...
So if I compile my app to target sdk version 14 the menu is gone from every activity...
How can I achieve this?
Assuming you are thinking of the standard Android MENU button, this cannot be removed. Keep in mind that on many older phones, this is a hardware (physical) button.
I recommend reading the advice I received in the following link, regarding the MENU button and the various issues pertaining to the changes from earlier version of Android to ICS.
Handling the missing MENU button in new versions of Android (3.x and up)
Also, I would pay attention to the following official info from Google, and strongly considering rebuilding the app to not be dependent on the MENU button.
http://android-developers.blogspot.no/2012/01/say-goodbye-to-menu-button.html
Not only should your apps stop relying on the hardware Menu button, but you should stop thinking about your activities using a “menu button” at all.
I'm about to start porting an existing iPhone app to Android. The iPhone app's navigation is based on a UITabBarController, with a separate view controller for each of the 5 functions of the app.
I've never programmed an Android before, never owned an Android before, heck, never even used an Android before for more than a minute at a time.
So what's the most intuitive way to redesign the UI? How would the majority of Android users expect the application to work?
Is there some equivalent of a UITabBarController that's widely used on Android? If not, how intuitive would it be to present a simple list of app functions in a "master" activity, then open up a new activity for each function when the user clicks on it, and rely on them hitting the "back" button to go back to the master activity?
Thanks,
-Numegil
Use a TabHost
And buy an Android / borrow one from a friend.
Also consider using a TabBar in iOS and using the options menu in Android. So in Android the user pushes/taps the menu button and can navigate from the pop up options menu. In iOS, I have a tab bar for the same navigation choices at the bottom of the screen.
So when the use hits the back button you return from the selected options screen to the Main screen in Android.
TabHost is the tab equivalent. If you have some dough, buy a cheap Android tablet (I have a Cruz Velocity T301 from Radio Shack - $150) to use for dev work.
Otherwise use the built in emulator. It's slow, but you can use it to develop for multiple screen sizes.
If you dev in Eclipse, get used to setting up different Debug configs or the Run configs for the different screen sizes. Best book I've found for getting you up to speed quick is this:
http://www.amazon.com/Android-Application-Development-Dummies-Felker/dp/047077018X
According to iOS guidelines the tab bar controller should be used for navigating between separate sections of your app (flat navigation structure). The Android equivalent for this is the navigation drawer. For an example, compare the Apple Music app on iOS with Apple Music for Android. Do not use tabs for navigation between sections of your app. Use tabs only for switching views on the same screen.
I have seen couple of Android applications when I came across one common practice. Navigation header does not have a Back button. Since then I was quite confused so as to place the same in the Navigation header of my application.
Should back button be placed in Navigation (Header) or we should leave keys to handle it? What is the best practice we should follow?
Thanks
My personal view is that each platform has its own way of handling certain functions. An apple device will have a back button on its navigation bar because that is the place where an iphone user will look for it.
As far as Android is concerned, because we are supplied with a physical back button, we must leave it at that because that is the first place an android user will look to if he wants to go back.
Therefore since user satisfaction and ease of use is the main concern, i would not play with the back button (unless i have to).
Similar to the responses above, however for the sake of simplicity I have taken a central approach in which I actually keep a back button in the navigation header however user can still press the hard key back button and the code actually performs the same functionality.
Essentially what it does is to cover both set of users, some really new ones who do not understand Android hard-keys yet, like people used to iOS (pun intended) and the other more suave Android users.
oI believe there could not be best approach. It depends on your custom UI and how much screen estate your navigation consume. The best approach is to buil two variants ant alllow to beta-testers decide.
Allthow back button on the screen could be as much handy, so much annoying.
What the "Back" button actually does, is to close your current activity and bring the previous one to the front.
You can do the same by calling finish() in your current activity. It will remove the current activity from activity Stack and take you to the previous one.
Asaf Pinhassi