I can't tell if they're the same thing or not and they seem to have different methods for removing them but I'm not sure if those are just multiple methods to do the same thing or not.
So is there a difference and if there is what is it?
Ref:
https://developer.android.com/reference/android/R.id.html#title
https://developer.android.com/reference/android/app/ActionBar.html (with material design, it is usually represented by a Toolbar)
The Title bar is a small part of the UI that you can supply with some text and a color. You see it on a lot of Android 2.0 Apps. See here
The Actionbar is the bar with buttons that has back navigation etc. If you can chose, you use it instead of the Titlebar. See here
Different thing.
TitleBar - small (usually grey) strip at top of screen that lists your Application Name (mostly not used anywhere)
ActionBar - the core navigation component of modern Android apps - this is where you will put the main navigation components (including actions on the things in your activity, a title explaining where you are in the app, Share links, etc); To support this in all modern Android versions, you will need to use a library to implement this. ActionBarSherlock is a very popular one, and there is now ActionBarCompat, which was released in the latest Support Library.
Bottom line, TitleBar should be disabled in favor of ActionBar for applications targeting modern design standards
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?
Background
setListNavigationCallbacks is used to allow the user to switch between different views of the current screen easily via the ActionBar, as shown here and here.
The problem
I've noticed it got deprecated as of API21 (Lollipop), and that all the documentation says is to look for other navigation solutions, but it doesn't say what's the best one that fits the same point:
This method is deprecated. Action bar navigation modes are deprecated
and not supported by inline toolbar action bars. Consider using other
common navigation patterns instead.
All other functions/classes that are related to this function are also deprecated, such as setNavigationMode, OnNavigationListener, ActionBar.NAVIGATION_MODE_LIST .
What I've tried
The navigation drawer is for navigation of different screens, and not different views of the same screen.
adding an action item that will provide a way to switch between the modes, but that's a bit weird...
using a ViewPager, but that's also weird as it doesn't really switch views, plus it takes more space.
Using tabs, but I think that's also deprecated in some way, plus it takes more space this way.
The question
What should be the best alternative to this way of navigation?
This post explains why not only list-, but ALL navigation modes have been deprecated. It became too difficult to make it able to customize Actionbar's navigations. Toolbar is the new Actionbar (also available in the appcompat-v7 support library). However, you won't find these methods there either. Instead, you need to supply your own optional (navigation) view(s). Then you can use it like a normal view in your layout.
I found this library and liked it. Know i am searching info how to use it. I am creating app which support from SDK 2.1 to 4.*.
So i downloaded ActionBarSherlock version 4.0. Imported library and made dependence to that library. I was needed to use Api level 15, because it is requirement for library usage.
So i imported project Demo from samples.
Everything look fine, but i really don't like this:
[2012-03-29 11:18:46 - SampleList] Displaying it with 'Locale Language ___Region __, sw320dp, w320dp, h533dp, Normal Screen, Long screen aspect ratio, Portrait Orientation, Normal, Day time, High Density, Finger-based touchscreen, Soft keyboard, No keyboard, Exposed navigation, Trackball navigation, Screen resolution 800x480' which is compatible, but will actually be displayed with another more specific version of the layout.
However i need this library creating navigation bar on top of all my layouts and change buttons action up to which layout i am.
So my target is to do this NavigationBar:
Maybe someone have done this with ActionBarsherlock and could help me ?
Also is it possible with ActionbarSherlock to do on Top Navigation Bar and on buttom Tab Bar with images ?
it should look similar:
Thanks
The library was designed to mimic the Ice Cream Sandwich action bar which has fundamental differences in both design and interaction patterns. I'm fairly certain that you could bastardize ActionBarSherlock into looking somewhat like UIToolbar, but it would be far easier to just create custom views to do this for you.
Also, please do not do this. Not a single Android user on the planet will thank you an iOS interface on an Android device.
http://developer.android.com/design/index.html
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.