I have a pretty simple question about the Android ActionBar... is this intended to be present in the app, to use as a sort of header, or is it only intended to show when the user hits the setting button on the device?
I'm trying to implement a menu that is always present in the app, like a logo for branding, and some other actions, like a search icon and perhaps a map icon to see the map functionality. Any suggestions? Also see this post here
The ActionBar is always displayed. Check out the Android Developer Site for more information on the ActionBar UI patterns and usage.
You can use the excellent ActionBarSherlock library to provide an ActionBar on 2.x devices.
The ActionBar sounds perfect for the branding/icons you want. You would use your logo as the icon, and then have Action Items for Search and Map functionality.
Have you put your android:targetSdkVersion to 11 or more ? ActionBar is available only for Honeycomb and ICS :)
Related
I'm having a "this can't be right moment" trying to learn Android app development. I want to add some buttons to the top bar (app bar, toolbar, action bar, etc) of my Activity. Apparently this thing is called the app bar. But when I read the docs, I feel like I'm taking crazy pills:
This class describes how to use the v7 appcompat support library's Toolbar widget as an app bar.
Why do I have to use something called "appcompat" to add a toolbar? I don't care about backwards compatibility right now, I'm just coding an app to learn. Normally backwards compatibility shims/layers are an optional thing. I just want to do this in the most straightforward way at the moment - it'll be easier for me to learn that way.
There are other ways to implement an app bar—for example, some themes set up an ActionBar as an app bar by default—but using the appcompat Toolbar makes it easy to set up an app bar that works on the widest range of devices, and also gives you room to customize your app bar later on as your app develops.
Again, this sounds like the docs are saying that the method they advocate is not the simplest and most basic way, and that there's another. Then one of the very first steps in the tutorial is:
In the app manifest, set the element to use one of appcompat's NoActionBar themes. Using one of these themes prevents the app from using the native ActionBar class to provide the app bar.
Huh? So the first step to getting a toolbar is to turn off the toolbar? At this point I feel like I can hear clown horns going off. Am I being pranked? I don't think Google realize how bonkers this all sounds to a complete beginner.
Is there a way to add buttons/actions to the default Material UI ActionBar in an Activity, without going through the appcompat package?
How can I create an Actionbar title with scrolling where clicking on a particular title item moves to the corresponding page?
You can see this functionality in Google Drive app in android mobile phones:
You could create a custom actionBar with a textView for the title that has:
android:scrollHorizontally="true"
That should get the desired effect.
I have created a library called Veni Divi that provides you with a custom action bar title that behaves like the one from Google Drive app.
In case someone needs this functionality, the source is available on GitHub.
You may see a demo app on Google Play.
I want to get two action bars in my application, like this:
Is it possible? If yes, how to implement it? It also must be working on Android 2.x.
Is it possible? If yes, how to implement it? It also must be working
on Android 2.x.
Yes this is possible. This is a normal ActionBar with a Spinner, a few Actions and an overflow icon(actually two, but you can only have one, so that might be almost impossible).
The ActionBar on the bottom is a split ActionBar.
You can use ActionBarSherlock for backwards compatibility.
Recently I became the proud owner of an Android 4.0 tablet and have been snooping around trying to create some apps. Now that I have the basics covered, I'm diving more into the "what's good/what's wrong" parts.
As far as I understand, the old "menu/settings"-button is deprecated (in the sense that you shouldn't use it anymore) and now the ActionBar is the way to go. Upon reading further, I came across this: http://developer.android.com/resources/samples/ActionBarCompat/index.html
It shows how to use the ActionBar on pre-API 11 systems. On the left you can see the typical menu where all options are shown a developer decided weren't important enough to be in the actual UI (the "wrong" way, but programmed using the newer ActionBar API). On the right, that same menu is now on the ActionBar.
My question is: Since it's been said such an "overflow"-menu is bad design on older mobile devices, is it also bad design when it's on the ActionBar as a button like shown on the right screenshot? Or is it only considered bad design because on a lot of devices it required you to press a physical off-screen button which makes it a non-issue when it's a virtual button on the ActionBar?
In short: Should I avoid it or not? Frankly, I like the idea of having a menu on the far right with all options that either don't fit or aren't important enough to be their own entity on the ActionBar.
Please also point out if any of the information I gathered and explained here is wrong.
The options menu hasn't been removed, it's just moved. It used to be hidden "behind" the Menu button on the device, but it's now moved to the ActionBar. Items on the menu either show as icons on the ActionBar, or on the overflow menu. You use exactly the same code to add items, whether to the old style menu, or the new style ActionBar.
A big part of the improvement that's been made is there is now a visible button on the top-right of the screen to open the "menu" (ActionBar overflow), which is right next to the other options. this is much better than before where the menu button had no visual connection to the app.
I suggest you look at ActionBarSherlock, http://www.actionbarsherlock.com, as it makes it pretty easy to add the full ActionBar to pre Android v3.0 devices.
http://developer.android.com/design/patterns/actionbar.html
Finally, I'd suggest that you follow the UI guidelines from Google. If they say the ActionBar is the right approach for navigation, then use it. It's best to use the provided UI patterns, and focus on the domain-specific stuff in your app.
Is there any way to change the content of the title bar when it's in Tab(If it wasn't in tab I would have done it but tried couldn't find any solution). E.g. Suppose I have created a custom title bar with few buttons on it, and now I want to change the content of the title bar(Drawables, Title and the functionality).
It would be great if someone could tell me if i can implement Action bar in versions below 3.0 ? I am creating this project in 2.1 (I'd like to create action bar from scratch).
or if there's any way beside inserting an image and placing buttons on it(This methodology would be good enough)?
If you're just looking to implement the ActionBar paradigm in pre-Honeycomb versions of Android, I suggest you look into using the ActionBarSherlock library.
The library will automatically use the native action bar when
available or will automatically wrap a custom implementation around
your layouts. This allows you to easily develop an application with an
action bar for every version of Android back through 1.6.
twaddington and pjco's answers are correct, you need to use ActionBarSherlock if you want to be compatible with every SDK levels.
I want to add you can have a custom actionbar or a custom view for your actionbar tabs using the method actionbar.setCustomView(view) or tab.setCustomView(view)
Anyway, play with ActionBarSherlock demos, there are a few cool use cases.
The other option worth looking at is ActionBarCompat, which I think comes with the SDK 14 api demos. However, ActionBarSherlock seems to support many more features so that may be the better solution.