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.
Related
What is the point of action bars in android if you can just use a custom linear layout and use that? You can add more robust functionality, you can do much more than with the regular app bar, it's less hassle to use. I can only see the advantage when you tie your action bar to the activity, but most of the apps now have different action bars or no action bars at all for different screens.
Why would one choose one over another, or what even is the use case of action bars
As written in the google documentation https://developer.android.com/training/appbar
"The app bar, also known as the action bar, is one of the most important design elements in your app's activities because it provides a visual structure and interactive elements that are familiar to users. [Pay attention to the point 'familiar to users'] Using the app bar makes your app consistent with other Android apps, allowing users to quickly understand how to operate your app and have a great experience. The key functions of the app bar are as follows:
A dedicated space for giving your app an identity and indicating the user's location in the app.
Access to important actions in a predictable way, such as search.
Support for navigation and view switching (with tabs or drop-down lists)."
To your question.
Yes, it is a valid point that custom action bars provide very robust and diverse functionality, but the point here lies in UI/UX part of the software development.
As you saw in the documentation
Familiarity to users
Consistency in design
Users are not comfortable with design changes as in general, because
Most of them do not even care about the design they just have to do what they have to do.
They have to again familiarize themselves to the new design so that they could remember it and navigate through the user interface faster.
So keeping software development aside for a while it becomes a bit difficult for the end-user.
Also, It might be that the default UI elements work better with the operating system [Cache, CPU, etc. ]
This is related to our design , I think when design is sync with Action bar then it is better to use it but if we have flexible design we have to use custom Toolbar.
Some of benefits of an Action bar that cause developers select it at first :
-Makes important actions accessible in a predictable way (such as Search).
-Supports consistent navigation and view switching within apps.(If you use navigation component is very simple to use Action bar)
-Reduces clutter by providing an action overflow for rarely used actions.
-Provides a dedicated space for giving your app an identity.
And finaly Should you replace ActionBar with ToolBar? YES and NO. YES if you want the flexible header that comes with the Toolbar, NO if you don not need those flexible header. by flexibility, you can do things like adding background image, animations,...
I am working on an android app for the first time and my first prototype had modal popups. Most people say that modal popups are not a good design and that sliders / drawers should be used . To be more specific - a Master Detail layout. Is that true ?
A few excerpts from the Android design docs:
Use navigation drawers if:
You don't want to give up the vertical screen real estate for a dedicated tab bar.
You have a large number of top-level views.
You want to provide direct access to screens on lower levels.
You want to provide quick navigation to views which don't have direct relationships between each other.
You have particularly deep navigation branches.
...
Dialogs
Dialogs prompt the user for decisions or additional information
required by the app to continue a task. Such requests can range from
simple Cancel/OK decisions to more complex layouts asking the user to
adjust settings or enter text.
It really depends on how you want your UX to play out. If your app needs a user decision or more information before proceeding with some task, a dialog is appropriate. If a particular screen is not part of a progression but is an entry point, you'd almost certainly want it on a navigation drawer.
I've developed like 5 Android applications using only Activities (and from time to time Fragments for ViewPagers for instance).
I have to develop a new application targeting Android ICS for tablets and handsets, with a very simple and static menu bar on the top (like 4 buttons on a single line). I don't need any single-pane / multi-pane layout depending on if the user has a handset or a tablet.
Each button of the menu bar will open a different screen, always keeping the menu bar on the top of the application. My question is if using Fragments for each screen instead of Activities is the proper way to achieve this.
Apart from avoiding some code duplication (basically the behavior of the menu bar), I don't see any advantage of using Fragments.
EDIT
First of all thanks a lot for answering my question so precisely and so fast.
Your answers have been very helpful for me : for instance I was afraid of having just one single Activity one my app, but I now understand it's rather a good thing.
You wanted to know what my application will actually do, so... there will be like 4 different screens : a News screen, a Videos screen (with live streaming video players), a Search for past videos screen and a basic Contact screen.
My question is if using Fragments for each screen instead of
Activities is the proper way to achieve this.
Your scenario is pretty simple and you could go either way. I would choose fragments over activities mainly because:
always keeping the menu bar on the top of the application. - With a fragment based app you could have a smoother transition between the various screen(and it will also allow you to keep in place the buttons bar).
easier communication between the various screens of the app as you'll have all the fragments in one parent Activity(but as I don't know what your app does I'm not sure this is something relevant).
Your app may be small now but you may get new ideas/requests to improve it in the future and this may be an easier task to do when your app is composed from fragments(which should be designed as loosely coupled components). Again, not knowing what your app does, this may or not may be relevant. An example scenario would be the need(in the future) to insert a ViewPager for the content of the app(so you allow the user to also swipe to a page not only click a Button). Using fragments this would be very simple as you need to setup the ViewPager and insert the content fragments, using Activities would mean a lot more refactoring.
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
Desktop apps have top level menus (File, Edit, Search, ..., Help).
Web apps have very similar thing, menu tabs (Logo, Questions, Tags, Users, Badges, ...).
However I cannot find equivalent of top level menu in Android framework. Assume that my app has 5 main activities. According to menu design guidelines options menu should contain actions related to current activity. So how an app should allow users to easily switch to one of five main activities.
It seems that different apps solve the problem in different ways. Some have a tab list at the top of the screen, some at the bottom. Even Google applications aren't consisted in that field. Google Listen has an options menu item called 'Listen Home', however Listen main activity has no that options menu item. Others have two icons in app luncher which start two different activities from one app.
I realize that due to small phone screens Android apps have to be designed in a slightly different way than web or desktop apps. But I have a feeling that the app top level menu topic was omitted in Android framework. And developers are on their own here. Or am I missing something?
Update: this is Google blueprint for a great app
Update2: this an example app of these patterns
Update3: GreenDroid library helps a lot implementing these patters in your apps. It seems that dashboard and action bar patterns are becoming quite popular.
You should take a look at this Google I/O session: http://www.google.com/events/io/2010/sessions/android-ui-design-patterns.html
They talk about the design patterns they used for the Twitter application and basically the type of concept you are asking about. Basically, your activity should have a top bar that gives the user specific tasks to do in the view or allows them to switch into another activity.
Google has not implemented anything like this into the actual SDK yet so you're sort of on your own in terms of implementing it but the main concept is given in the presentation. This is the direction that Google would like to see Android shift into though.
Hopefully this helps you out somewhat.
The file/edit menus of desktop apps have a very different purpose than the questions/tags etc. tabs at the top of this webpage.
The contents of the file/edit menu should be implemented as in the options menu that appears when you press the menu button. This is, as you noted, to save space on the smaller screens.
App navigation like the questions/tags etc could be implemented using a Tab Layout. You are right that apps vary in whether or not the tabs are on the top or bottom, but I don't think thats a huge deal. In my unscientific look through apps on my phone, the bottom seems to be more common. However, I think it might depend on your specific implementation which you decide.
A lot of apps don't require any sort of navigation like that, and can get away with just having a path forward or back via the back button. I think this is preferable for a lot of applications, but won't work in all cases.
I'm not sure what more you would want built into the framework.. It seems like you can accomplish any kind of navigation desired with the above options.
You can look at the source of the Google IO app
ioshed