So I have a few questions about implementing the Android action bar. Up to this point I haven't really made any apps that were (in my opinion) good enough to put on the market. This really seems to be my inability to understand how the layouts and action bar will work in different versions of Android.
Of course Google seems to be the best bet for this, but I come across a few grey areas that maybe someone can clear up. I can see that the Action bar was implemented in API level 11, but then what happens when I try to run it on a device lower than 3.0? Also, this seems to be the most helpful when understanding on how and where to use the Action bar, but does this mean the action bar is done all programatically and not in the layout? I guess it's safe to say that I'm a bit "intimidated" by using the action bar because of the different layouts I'll get in different devices... so is there a way to make it "look" like I have an action bar even though it's done purely through layouts? Or is that a bad habit to get into?
I have heard that maybe the compatibility library might work well, but I don't really know what it does and I'm not yet savy enough to understand the android documentation on what it "really" does. If it really is "that" helpful at supporting older devices, why isn't it built/come standard in the SDK?
I know this is a very broad question, but when it boils down to it, I just want to know if there really is a way to make all of my layouts look and work the same, or if it's even worth my time and just have the action bar auto downgrade for old devices.
Just an additional question, I have a Galaxy Nexus and all of the core Google Apps look awesome with the action bar, but is there a way to see these updated apps running on API 11 or lower?
Lastly, if anyone has stumbled upon a great tutorial on any of this please list it. I'm really trying to become knowledgeable on how Android layouts work in all API levels.
I can see that the Action bar was implemented in API level 11, but then what happens when I try to run it on a device lower than 3.0?
By default, the user will get options menus, as before. Or, use ActionBarSherlock to have an action bar working back to Android 2.1, as Mr. Weening noted.
but does this mean the action bar is done all programatically and not in the layout?
It is the same as options menus, using mostly menu resources and Java code.
If it really is "that" helpful at supporting older devices, why isn't it built/come standard in the SDK?
You are welcome to create a time machine and go back in time to add that code to Android devices dating back to 2009. You might be able to find a lightly-used flux capacitor on eBay, though tracking down a Mr. Fusion unit may be somewhat more troublesome. Or, if you're in the UK, see if you can find a used TARDIS dealer.
The rest of us, in the meantime, will use the Android Support package in part for its backports of fragments, GridLayout, etc., so we can use new capabilities that are not native to older devices, while maintaining API fidelity with the native implementations on newer devices.
To support older version of android with a same looking action bar you could take a look at Action Bar Sherlock
http://actionbarsherlock.com/
From their website:
The library will automatically use the native action bar when appropriate 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 from 2.x and up
This works fairly well.
If you're a little more adventurous and you'd want more control over it's layout, look and feel, you could always try to implement it yourself. It's not an easy task but the action bar is more of a ux design than an actual component. The code for the compatibility libraries is a good place to start then.
The easy way if you just need a menu, a title and an icon up there:
choose a Theme with ActionBar, e.g. 'Theme.Holo'
create a new menu i.e. actionbar.xml
Implement this in your Activity
#Override
public boolean onCreateOptionsMenu(Menu menu){
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.actionbar, menu);
return true;
}
Since this is roughly the same as a menu in older versions, the older versions just lack the ActionBar and have the old menu instead.
Or
If you want the same ActionBar in all your Versions including before API 11, as Geert already suggested:
http://actionbarsherlock.com/
If you try to use the ActionBar on a version of Android that is not supported then it will just crash your application. To get around this, you can implement the library ActionBarSherlock which uses the native ActionBar if available, otherwise it creates its own that has the same functionality. You can also check the Android version during runtime and handle it yourself. I would check this link out as it actually has an ActionBar example:
http://developer.android.com/training/basics/supporting-devices/platforms.html#version-codes
Related
I'm newbie in development for Android platform and trying to understand how do I know or predict when I have to use support classes? This is probably stupid question, but let me give you a simple example. Let's say I want to add a sharing functionality to my application so I go to DAC and see there an example of how this can be done. I read the manual carefully and see the note about limitations i.e.
Note: ShareActionProvider is available starting with API Level 14 and higher
It seems this is OK for me since the minSdkVersion is set to 14 in my app. I copy-paste that snippet to my project, launch the application and... it crashes with the following error:
05-21 12:42:07.638: E/AndroidRuntime(25291): java.lang.UnsupportedOperationException: This is not supported, use MenuItemCompat.getActionProvider()
I update my sources to use the following code instead the one which I found in documentation:
MenuItem menuItem = menu.findItem(R.id.action_share);
ShareActionProvider mShareActionProvider = (ShareActionProvider)MenuItemCompat.getActionProvider(menuItem);
Starting app. At first sight it's working but instead of share icon I can see text SHARE in the ActionBar. Humm, after googling around I replace the following line in menu layout
android:actionProviderClass="android.widget.ShareActionProvider"
to
app:actionProviderClass="android.support.v7.widget.ShareActionProvider"
Hooray! Finally I've got what I want!
This is not the first time I experience such obstacles while learning the Android platform so I'm trying to find whether there is any rule of thumb which will help me to predict such situations?
As for support library, not that I've added it for purpose. This library was added automatically when I created project in Android Studio. After playing a little bit with Android Studio I've figured out that it automatically adds it to the project unless the min SDK is set to latest 21 or 22 versions. So technically almost all applications have to use this library to be run on wider range of Android devices. If this is true then why Android training and guide materials don't use support classes in examples?
Any help and advice will be highly appreciated.
I'm trying to find whether there is any rule of thumb which will help me to predict such situations
I have no idea what "such situations" are beyond the one that you have cited here.
In this specific case, the menu resource cited in the first step uses android:showAsAction="ifRoom" instead of something like app:showAsAction="ifRoom". The latter is required if you are using the appcompat-v7 action bar backport. Hence, this sample must not be using the appcompat-v7 action bar backport.
There is little question that the documentation could be improved in this area, to either provide instructions for both action bar implementations, or to at least positively state which action bar implementation that they are using.
So technically almost all applications have to use this library to be ran on wider range of Android devices.
No. Zero applications have to use appcompat-v7 to be run on a wide range of Android devices, going all the way back to API Level 1.
However:
If you want an action bar on devices running Android 1.x/2.x, you need an action bar backport, and appcompat-v7 is the only currently maintained full-featured backport that I am aware of (given that ActionBarSherlock is deprecated)
If you want to try to have a UI that resembles Material Design on devices running Android 4.4 and below, current editions of appcompat-v7 do that as well
I was using ActionBarSherlock to make my app run with app version of android and use actionbar, but now I don't need to support the old version and it is enough for me to support 4 and above , is there any benefit of ActionBarSherlock still for my case ?
Not really. Feel free to use the native API Level 11+ implementation of the action bar.
Note, though, that some things in Android may steer you in the direction of using an action bar backport... though the appcompat one published by Google, not ActionBarSherlock. For example, the recommended version of MediaRouteActionButton requires the appcompat action bar, though I am maintaining a port that works with the regular action bar.
The application currently has tabulations and bar custom made (by previous guy) from fragments to copy cat Apple design.
I want to move toward Android action bar to provide Android experience and usual behavior.
Should I implement Action Bar Sherlock or Action Bar Compat?
Pro ABS:
Lots of documentation
Action bar Tabs is well known (that's what I need to do)
About Holo theme? ABS is great to support it, how perform ABCompat?
Pro ABCompat:
Supported by Google (better in the long run?)
Better connection with navigation drawer (but I will not use one)
No external dependencies in Java Build path
What others arguments help decide? Which one should I pick ?
From my point of view, provided I succeed to do a action bar with fixed tabs, the Action Bar compatibility is the best choice (but not by much).
Thank you for helping me! (even providing arguments I missed)
The main reason that made me switch to ActionBarCompat is the Menu appearence in devices with android <= 2.3. With ActionBarSherlock, the menu appears very ugly, with the default menu of the device. With the ActionBarCompat, the menu appears the same way it appears when you open it in devices with Android >= 4.0 and hardware menu key.
But, be aware that the ActionBarCompat has some bugs to be resolved yet. I'm dealing with this bug:
SearchView taking all the space in the new ActionBarCompat
UPDATE:
Another bug:
https://code.google.com/p/android/issues/detail?id=58321&thanks=58321&ts=1375277660
UPDATE:
I've created a patched version of the ActionBarCompat to solve the issue with the ActionMode. See here:
The ActionMode is being created twice with the ActionBarCompat r18
The reasons why I migrated my app from ABS to Action Bar Compat were as follows:
I have only a very basic implementation of action bar tabs and I could see it would be simple to migrate
I prefer the Google documentation - it is clearer and more complete
Software maintenance will be simpler and less error prone because I now have no external dependencies.
I had run into a problem with ABS whereby I wanted to handle an orientation change (but you can't because of the way ABS hooks in to Android).
I haven't seen any statements from anybody connected with ABS about their long term plans for ABS. So I'm not convinced they are going to continue to support it. I may be wrong - but I haven't seen anything.
Performance is not really an issue for me, but I can't see why Google's "native" implementation would run slower than ABS and I suspect that it may perform better.
These are just my personal impressions.
I think that ActionBarSherlock was a brilliant piece of work, and a great service to Android developers. (By the way I don't have shares in Jake Wharton its developer.) Google have paid it the best compliment possible by including something that does essentially the same thing in essentially the same way (as far as I can tell) in the v7 support library.
But now that the functionality is officially supported some standard arguments apply as to which to choose.
ActionBarSherlock is a third party dependency, which represents a risk in terms of ongoing support. Unless it does something you really need that is not done by ActionBarCompat, or the latter has a bug which you can't work around or wait for a fix for, there's very little argument in favour of sticking with the former.
I recently migrated from ActionBarSherlock to ActionBarCompat and found only one or two minor issues, the main one being that a minor adjustment was required to the stock 9-patch images used for the action bar tab indicator backgrounds, in order to produce the standard tab behaviour on earlier android versions, in my case 2.2==API level 8==Froyo. (Specifically I adjusted the vertical stretchable regions so that they were not adjacent either to the top edge or the colored indicator bar at the bottom of the image.)
These are my doubts while using ActionBar.
1) To make it prevalent across various tabs, I had to repeat the same code in all the tabs. Is there a better way to rewrite this part? I could have one ActionBar class which I can call everywhere, but that won't make it dynamic. (More options in certain tabs.)
2) I'm presently defining a menu and inflating it. Is it the best way to go about it? The problem I am facing here is I'm definitely not using the entire space and always running out of space to put in more actions. How to rectify it?
3) The third problem that I'm facing is a bug when I use Theme.Light. The app crashes. If I use Theme.Holo.Light, the app doesn't. Though, it still crashes in a 2.3 supporting phone. Anyway to rectify that? I mostly feel that I've missed out on backward compatibility or is Action bar not compatible with certain themes?
This answers your 3rd question, straight from docs here:
Beginning with Android 3.0 (API level 11), the action bar is included in all activities that use the Theme.Holo theme (or one of its descendants), which is the default theme when either the targetSdkVersion or minSdkVersion attribute is set to "11" or greater.
If you want to use ActionBar APIs, such as to add navigation modes and modify action bar styles, you should set the minSdkVersion to "11" or greater. If you want your app to support older versions of Android, there are ways to use a limited set of ActionBar APIs on devices that support API level 11 or higher, while still running on older versions. See the sidebox for information about remaining backward-compatible.
Sidebox info
If you want to provide an action bar in your application and remain compatible with versions of Android older than 3.0, you need to create the action bar in your activity's layout (because the ActionBar class is not available on older versions).
To help you, the Action Bar Compatibility sample app provides an API layer and action bar layout that allows your app to use some of the ActionBar APIs and also support older versions of Android by replacing the traditional title bar with a custom action bar layout.
I'm trying to port a Monotouch app to Monodroid. My app has to target Android 2.1 as a minimum, but the Action Bar only seems to be available for Android 3.0 and upwards.
The iOS app is making use of the title bar all the time, so I'm looking for some action bar replacement that can be re-used from action to action.
What are my options for solving this problem? I know there are native android libraries tackling this problem (i.e. https://github.com/johannilsson/android-actionbar), but communicating with them through JNI looks quite error-prone and tedious. Is there any better solution?
Thanks,
Adrian
please look at my implementation of ActionBar here https://github.com/soundnRg/ActionBar. Hope it will help you.