What would be better to integrate in the application- all options (for new screens) in menu, customized for each screen or have it on top of screen as tab bar- squishing the screen? what do normal android users prefer using? and from design perspective is it okay to keep changing items in menu bar in the app?
It should be a combination.
Different Views into your app data can go as Tabs.
Quick actions like search can be ActionViews.
You can also show different tabs depending on the context.
An old question but for future generations:
In my case, it was the task to replicate an existing iOS app with iOS UITabBar, so playing with the bottom-navigation Android pattern I found that it is much easier to use FragmentContainerViews than the official bottom-navigation pattern from the Android Architecture repository. Check the repository, there's a test application that you can run to check if the solution matches your expectations: https://github.com/Codeveyor/Android-Tab-Bar
Related
I cannot find either one of these two views in the source, but have seen them both in many apps. Can anyone please tell me what they are called?
Thanks
The second one is an options menu from the action bar. I think it is implemented as a ListPopupWindow.
The first one is not part of the Android SDK, though there are various implementations floating around. Here is an example of one designed for use with Google Maps, for example. Here is one designed for the "quick actions" pattern.
I'm going to assume that they're custom made ones, so you won't find them in the standard Android libraries.
The second one I think is just the way that the default menu looks in ICS (and honeycomb for that matter). If you build for 4.0 and include the code for an options menu I think you'll get that UI by default. If you are looking to customize it check out this page http://developer.android.com/guide/topics/ui/actionbar.html and pay close attention to the "Adding drop down navigation" section.
The first one is not a part of the android UI, that is something specific to the facebook app.
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'm currently working on a port of an iPhone app into an Android. The iPhone app has a custom global navigation menu at the bottom of the screen, and when bringing this over to Android, it was suggested to replace this custom menu with the generic Option Menu (invoked via the option key on the device) to give it a more native Android look and feel.
The issue is that the menu itself has several layers (e.g. Three main option like A, B, C, and sub-options like A1, A2, A3). I've looked around but have not seen this sort of multi-level option menu on Android apps, so am looking for some guidelines on how this may be best achieved.
I've seen some questions on customizing the Option Menu such as this one; Android: customize application's menu (e.g background color); and they seem to suggest that the native framework doesn't support many options.
Should I be looking at a bit of hacking into the option menu (is this a good idea?), or looking at some other approach to modifying the app flow? Trying to understand what would be the best way to maintain a consistent user experience on Android, while reducing the level of variation from the iPhone app.
Thanks!
I've looked around but have not seen this sort of multi-level option menu on Android apps, so am looking for some guidelines on how this may be best achieved.
Options menus support sub-menus, but only one level deep (i.e., the menu can have a sub-menu, but a sub-menu cannot have a sub-sub-menu).
If you really need that (and want to violate the Android platform standards regarding menu depth), then you can easily implement this by using an AlertDialog with lists for every nested level of your menu. Visually those appear exactly the same like an options menu.
I've done something similar to what banana suggested. I would just add the reasoning behind the limitation is the myriad number or devices and screen resolutions that need to be supported. Multiple nested menus might look good on a tablet but not on a 5 inch screen so we need to keep that in mind.
For me, adding
android:onClick="onOptionsItemSelected"
to nested menu items worked.
I'm developing an App in iPhone and a version for Android.
The iPhone version of the App uses a Tabbar on the bottom of the screen (for other screens / ViewControllers: Home, Favorites, Search in a list, ...).
I want to make the layout of the 2 versions of the App (the one for iPhone and the one for Android) the same as much as possible according to the best layout guidelines.
Android App's usually uses not a tabbar, but it's with a SubMenu. But, I find more an more Android App's that uses a tabbar at the bottom of the screen in stead of a submenu for handling this. I know that a TabBar on the bottom of the screen is not usual for an Android App and may seem strange for those users.
So, what I want to know is may it be OK to use a tabbar like iPhone at the bottom of the screen, or is it NOT DONE for Android? (Also according to screen use optimalisation and the android UI patern guidelines : by this I mean uses the mast of the screen for the App itself and not for navigating through the App).
The equivalent Android pattern for the 'Tabbar' is 'ActionBar', you can find more information on this widely-used pattern here: Android Patterns - ActionBar
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