Does anyone know how to implement a sliding menu like some of the top apps of today?
Other Stack Overflow questions haven't had any answers on how to do this, so I'm trying to gather as much info to help out others. All the applications I mention below do a great job of implementing the slide menu.
1. Google Plus (as of 7/7/12)
You can only go from the first screen to the second screen by clicking the G+ logo in the upper left hand corner. Notice that the entire screen moves from it's position and get's nudged to the right side of the screen (including the action bar). To get back to the first screen you can either slide the right side back into focus or you can click the G+ icon again.
2. YouTube (as of 7/7/12)
You can go from the first screen to second screen using two methods. Either click the YouTube logo in the upper left, or you can use a swipe gesture to move it to the right. This is already different from the G+ app. Secondly, you can see that the action bar stays put (Unlike G+). Lastly, to get the original screen back it works just like G+.
Edit #3:
The Navigation Drawer pattern is officially described in the Android documentation!
Check out the following links:
Design docs can be found here.
Developer docs can be found here.
Edit #2:
Roman Nurik (an Android design engineer at Google) has confirmed that the recommended behavior is to not move the Action Bar when opening the drawer (like the YouTube app). See this Google+ post.
Edit #1:
I answered this question a while ago, but I'm back to re-emphasize that Prixing has the best fly-out menu out there... by far. It's absolutely beautiful, perfectly smooth, and it puts Facebook, Google+, and YouTube to shame. EverNote is pretty good too... but still not as perfect as Prixing. Check out this series of posts on how the flyout menu was implemented (from none other than the head developer at Prixing himself!).
Original Answer:
Adam Powell and Richard Fulcher talk about this at 49:47 - 52:50 in the Google I/O talk titled "Navigation in Android".
To summarize their answer, as of the date of this posting the slide out navigation menu is not officially part of the Android application design standard. As you have probably discovered, there's currently no native support for this feature, but there was talk about making this an addition to an upcoming revision of the support package.
With regards to the YouTube and G+ apps, it does seem odd that they behave differently. My best guess is that the reason the YouTube app fixes the position of the action bar is,
One of the most important navigational options for users using the YouTube app is search, which is performed in the SearchView in the action bar. It would make sense to make the action bar static in this regard, since it would allow the user to always have the option to search for new videos.
The G+ app uses a ViewPager to display its content, so making the pull out menu specific to the layout content (i.e. everything under the action bar) wouldn't make much sense. Swiping is supposed to provide a means of navigating between pages, not a means of global navigation. This might be why they decided to do it differently in the G+ app than they did in the YouTube app.
On another note, check out the Google Play app for another version of the "pull out menu" (when you are at the left most page, swipe left and a pull out, "half-page" menu will appear).
You're right in that this isn't very consistent behavior, but it doesn't seem like there is a 100% consensus within the Android team on how this behavior should be implemented yet. I wouldn't be surprised if in the future the apps are updated so that the navigation in both apps are identical (they seemed very keen on making navigation consistent across all Google-made apps in the talk).
Just recently I forked a current Github project called "RibbonMenu" and edited it to fit my needs:
https://github.com/jaredsburrows/RibbonMenu
What's the Purpose
Ease of Access: Allow easy access to a menu that slides in and out
Ease of Implementation: Update the same screen using minimal amount of code
Independency: Does not require support libraries such as ActionBarSherlock
Customization: Easy to change colors and menus
What's New
Changed the sliding animation to match Facebook and Google+ apps
Added standard ActionBar (you can chose to use ActionBarSherlock)
Used menuitem to open the Menu
Added ability to update ListView on main Activity
Added 2 ListViews to the Menu, similiar to Facebook and Google+ apps
Added a AutoCompleteTextView and a Button as well to show examples of implemenation
Added method to allow users to hit the 'back button' to hide the menu when it is open
Allows users to interact with background(main ListView) and the menu at the same time unlike the Facebook and Google+ apps!
ActionBar with Menu out
ActionBar with Menu out and search selected
There is a great implementation of NavigationDrawer that follows the Google Material Design Guidelines (and compatible down to API 10) - The MaterialDrawer library (link to GitHub). As of time of writing, May 2017, it's actively supported.
It's available in Maven Central repo.
Gradle dependency setup:
compile 'com.mikepenz:materialdrawer:5.9.1'
Maven dependency setup:
<dependency>
<groupId>com.mikepenz</groupId>
<artifactId>materialdrawer</artifactId>
<version>5.9.1</version>
</dependency>
I know this is an old question but the most up to date answer is to use the Android Support Design library that will make your life easy.
Personally I like the navigationDrawer in Google Drive official app. It just works and works great. I agree that the navigation drawer shouldn't move the action bar because is the key point to open and close the navigation drawer.
If you are still trying to get that behavior I recently create a project Called SherlockNavigationDrawer and as you may expect is the implementation of the Navigation Drawer with ActionBarSherlock and works for pre Honeycomb devices. Check it:
SherlockNavigationDrawer github
Related
I'm a long-time Windows developer who is now doing Android development.
I would like to use the exact functionality contained in the following officially documented example on tabs and swipe:
http://developer.android.com/training/implementing-navigation/lateral.html
Deprecated Functionality
However, the downloadable example contains methods & functionality which is deprecated.
I'm confused about why the Android official example which shows how to handle tabs and swiping ends up including code which is deprecated.
Is it not the most recent version?
What Functionality Am I Looking For?
I'll show you two screen shots which display tabs and allow the user to select the tabs to navigate among them or swipe left or right to move through them.
Looks like the following:
I want the user to be able to easily switch between the two tabs and I have a plan to indicate to the user that information on the other tab has been updated by displaying an icon on the current tab.
My Main Question
Is there a similar example which does not include these deprecated
methods?
Related Questions
If I choose to implement the code in my application -- because the solution is quite beautiful and looks easy to implement -- what will the consequences be?
Does it mean that some time in the future the application wouldn't even work properly?
Does it mean that it may not work on some devices (API versions)?
Here's some of the code which is deprecated:
actionBar.setNavigationMode(ActionBar.NAVIGATION_MODE_TABS);
mViewPager.setOnPageChangeListener(new ViewPager.SimpleOnPageChangeListener()
actionBar.setSelectedNavigationItem(position);
actionBar.addTab();
actionBar.newTab();
It seems that the deprecated functionality is actually related to the ActionBar.
After quite a bit of searching, I found a better example of what I wanted -- sans ActionBar and sans deprecated functionality :
http://developer.android.com/samples/SlidingTabsBasic/index.html
When you get to that page, you will see that there is no documentation for the subject. It's odd. Look very closely in the upper right corner and you'll see a download link which will allow you to download a sample. It looks like:
The sliding tab solution is even more elegant and does not include any deprecated functionality.
Here's what it looks like:
The example is fantastic, because you can traverse through the tabs by swiping the bottom panel. Or you can click any of the tabs to move to the associated tab.
Also, the example gives you some more fucntionality above the tabs with the Show Log menu item which switches out the top portion.
Definitely worth a look and this answers my question.
Hope this helps someone else who is looking.
I'm confused about why the Android official example which shows how to handle tabs and swiping ends up including code which is deprecated.
Not all documentation gets updated. There has been stuff that has been out of date for years on the site, and despite filing issues, it does not get fixed. This is not unique to Android; it is reasonably commonplace in software development.
Is it not the most recent version?
It is the most recent version.
Is there a similar example which does not include these deprecated methods?
I do not know what qualifies as an "example". There are many, many implementations of tabs for ViewPager, both from Google (TabLayout) and from third parties (about half of the entries in the "View Pagers" category in the Android Arsenal). Some of those third-party libraries have sample projects as part of their repositories.
Does it mean that some time in the future the application wouldn't even work properly?
Quite possibly, particularly depending upon your definition of "work properly". We have no means of knowing exactly what will happen in the future (as we used up our last flux capacitor a week ago). Deprecated stuff usually keeps working, but it is at somewhat greater risk of bugs simply due to no longer being aggressively maintained. In the case of action bar tabs, the appcompat-v7 action bar backport does not support them at all.
I want to make a moving list appear from the left of the screen of the activity in the android app.
Something like the facebook app shown below :
,,
how can I make something like that in an android app.
Thanks.
This is a very popular UI pattern called a sliding menu / slider. You can search for open source libraries / projects which implement this for you.
Here is the first one I found on google.
This one is useful if you want to support old (pre holo) android devices too. It's an addon to the excellent holoeverywhere library.
And last but not least, take a look at this official pattern by google which also implements the same behavior. The code for creating it is available here.
The concept behind this is that you are taking a screen grab of the current activity and then loading in the menu. Your not actually sliding between activities, your moving the screen shot. Thats a very basic explanation of whats happening.
If you search for slide navigation on github I'm sure you'll find something.
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 have an app that's built for Android 2.2, so I'm not using the 3.0+ built-in ActionBar class but rather building my own custom ActionBar implementation using Google's older UI recommendation that was introduced a couple of years ago.
All of my screens have between 1 and 3 actions that can be performed, so they all fit very nicely into the ActionBar UI (which Google recommends has a maximum of three buttons). The problem now is that none of my screens have a regular options menu and so they do nothing when the user presses the hardware Menu button.
According to Google's interface guidelines, this is correct behavior. If your activity doesn't have an options menu then it should do nothing when the Menu button is pressed. I've found during user testing, however, that users are quite perplexed when they press Menu and nothing happens (and every single user has tried, usually multiple times). They say that they appreciate the actions being exposed on the screen through the ActionBar, but at the same time they want the Menu button to do something.
I've been looking at Google's first party apps and it looks like they just always have enough options available to be able to load up the options menu with stuff after the ActionBar is full. Google+ seems to use the Menu button in the traditional way for overflow options on phones that have one, and they show a dropdown menu in the ActionBar for phones that don't. That would work if I had more than three actions but I currently don't.
It seems that the only way to meet my user's expectations is to put some junk options that have no value into the Options Menu just so that something happens when they push the button. I really don't want to do that. Does anybody know of a good way to deal with this problem? Should I just leave the menu button alone and expect people to figure out that it doesn't do anything?
I think it's safe to assume that most users don't know the menu button exists and having all of the actionable items displayed on screen is best. User testing by Google has revealed this and it is why they have chosen to eliminate the menu and go with the built-in action bar starting with Android 3.0 and culminating in the recent 4.0 release.
Something to think about would be added a single "About" item to the pre-3.0 options menu/post-3.0 overflow menu. This could just popup a dialog with simple info about the application (e.g., version, licensing, link to website, author, etc.). This way there is something there should they happen to press the menu button but it is not required in order to properly use each activity to its fullest potential.
I have an app that's built for Android 2.2, so I'm not using the 3.0+ built-in ActionBar class but rather building my own custom ActionBar implementation using Google's older UI recommendation that was introduced a couple of years ago.
As an author of an action bar library this sentence disturbs me. It's fairly trivial to use a custom action bar implementation on pre-3.0 and the native one post-3.0. Take a look at Google's Action Bar Compat sample.
...or, you know, you could also go with a library like ActionBarSherlock that does this for you! </shamelessPlug>
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