A Search Icon appears in Kindle footer area (which I think is sort of an actionbar). It always appears on all my activities but I don't have search functionality on every activity. How do I get rid of it? Please note, I think there is a way since I have seen applications that do not have the search in the footer menu/actionbar on every screen.
According to the Kindle Fire User Guide page 8, section Content Bar, the search button helps users search their content library, not search within the current app.
You can partly hide the whole Content Bar by making your app full screen but you can't hide it completely as it replaces the functionality of the home & back buttons on non-kindle android devices. There is no documented way on the Amazon Developers blog on how to remove individual buttons from the soft key bar.
Related
fullscreen hides both the Android navigation and status bars (requiring you swipe from the bottom to show the navigation bar over the app), and standalone hides neither, when it comes to the display property of the PWA's manifest.
Simply, I want the bottom Android navigation bar to always show but without showing the top status bar. I wonder if I am missing some HTML meta or manifest JSON property or some other way to accomplish this?
I will expect most users to install the PWA via the web, not via the Play Store (so no TWA, Android application wrapper, etc.)
As far as I know this is not possible.
With the web-manifest you have different choices: default, standalone, fullscreen (see screenshots below):
On the Google docs page, also a "minimal-ui" value is available:
This mode is similar to fullscreen, but provides the user with some means to access a minimal set of UI elements for controlling navigation (i.e., back, forward, reload, etc).
Note: Only supported by Chrome on mobile.
Reading the description it seems this is what you are looking for, but unfortunately the top status bar and also the page address (read-only) is displayed. Therefore I do not think you can achieve what are you looking for with the standard display values of the web manifest.
I'm using a Chrome Custom Tab on my app and I'd like to be able to disable a few buttons that pop up automatically when I launch it to open a Google drive file, namely the button for bookmarking the page and the button for downloading it. I've searched throughout the web with no luck whatsoever.
Below is the image highlighting which buttons exactly I seek to hide in my custom tab. Anyone knows how to achieve this?! Thank you so much in advance.
There is a "hidden" API that lets you hide these buttons: add an extra with the key org.chromium.chrome.browser.customtabs.EXTRA_DISABLE_STAR_BUTTON and the value true to the Intent before launching it to disable the bookmark button, and one with the key org.chromium.chrome.browser.customtabs.EXTRA_DISABLE_DOWNLOAD_BUTTON to disable the download button.
Note that this doesn't fully disable the functionality: It's still possible to reparent the custom tab to Chrome and add a bookmark or download the page there.
Also note that this is not a public API, so it might disappear in future versions of Chrome.
Navigation with Up and Back buttons is quite complicated (at least for me)
As the android documentation states,
You have the ability to make the Up behavior even smarter based on your knowledge of detail view. Extending the Play Store example from above, imagine the user has navigated from the last Book viewed to the details for the Movie adaptation. In that case, Up can return to a container (Movies) which the user hasn't previously navigated through.
http://developer.android.com/design/media/navigation_between_siblings_market2.png
I am exploring Google IO 2013 application for best practices and as far as I can see the mentioned above navigation rules are not taken into consideration.
Here is the picture:
https://dl.dropboxusercontent.com/u/6129677/do_not_delete/iosched2013.png
I launch the app and the main screen opens (#1). I tap on 'Browse sessions' -> second screen opens. Then I tap on a session - its detailed view is opened (#3). UP button says that this is 'Google+' category, and I expect to navigate to list of 'Google+' sessions after clicking on this button. Instead, the first screen is opened again (see picture).
Is this a correct behaviour and I am missing something?
Android design says that the up button goes up to the container regardless of what the icon is. It also says that the icon in the top left should be of the app. So in this case you could say that it violates the design by having a g+ icon.
That being said it is okay to violate android design if you have a specific reason to, in this case Google decided that it would like to show the icon of the category to give the user an indication of what category is without having to show 2 icons. In this case, they didn't want to alter the design all the way so as to go back to g+, but to assume the user understands that they are replacing the app icon with the category icon. So while they could show your 4th screen, they aren't necessarily required to and it depends on what you think will be best for user flows. Android design is meant to guide your individual design and doesn't need to be followed strictly (though it should be most of the time).
Hope that helps, I'm happy to answer any follow up questions.
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
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