Why should we choose using the Sherlock Action Bar in Android rather than the Support Libraries ? Is there a solid reason for using one above the other ?
Sherlock Action Bar purpose is to add the ActionBar visual concept implementation for API level below 11 (since ActionBar was added in API level 11). Taken from ActionBar javadoc: "A window feature at the top of the activity that may display the activity title, navigation modes, and other interactive items."
Support library (as the name describes) is a jar that provides APIs added in newer versions of Android to older ones. The best example I can think of is the Fragment implementation: Added in API level 11 made it so easy to integrate different parts of UI accross the application. But that was only for API level 11 above. So when the support library was released it provided this feature for API levels below 11.
So these 2 are separate concepts (one is for UI only, while the other is for supporting newer APIs in older Android versions). To add more, Sherlock AB uses support library.
The Support Libraries did not have compatibility for the Action Bar pre Support Library revision 18 and therefore the natural choice was the ActionBarSherlock library.
However as of revision 18 release in July sometime it is now supported, how good it is I am unsure as I have not used it but in future projects I will be leaning towards the Support Library as its supported by Google.
The link to the Support Library revision notes is here.
If I'm not mistaken, the ActionBar is only available in API 11+ and the support library do not include the an ActionBar Library for API < 11. ActionBarSherlock is a library that let's you support an ActionBar in API 7+.
PS: I believe google is gonna include a ActionBar API in the support library soon. So they said in Google I/O this year.
Update:
Google added ActionBar (for API 7+) in the support library.
Related
I have found this after a google search about the android design support library.
It states: "Android Design Support Library brings a number of material design components that are compatiable [sic] with all Android 2.1 or higher devices."
I am wondering if this means that the android design support library should only be used with pre-lollipop devices or if it is the same thing as using material design in api-21 now.
Thanks for your help!
The Design Support Library only provides some components introduced by Material Design.
To use the Material Design theme, you have to use AppCompat Support Library (or set your minSdkVersion to 21 or higher).
So even if you are developing for API 21+, you still won't have access to those components (Floating Action Button, Snackbar, NavigationView, ...), as they are not included in Android.
You can get more information about the Design Support Library in the official announcement.
I'm a new Android developer who is trying to find the best balance for API level support. I think my indecision stems from a lack of understanding of the benefits and disadvantages of using the AppCompat Library over newer Android features such as Holo themes and the action bar.
Of course, I know that Holo is unavailable before API Level 14 and the Action Bar is unavailable before API Level 11. If I want to make my apps available to the broader Android userbase, I will need to lower my minSdkVersion and use the AppCompat Library.
My question is, are there any significant recent features of the Android OS that just aren't supported or are unable to be implemented through the AppCompat Library? Adding on to that, if you set your minSdkVersion to say API Level 7 and build your app with support for AppCompat (say, with your app themes being Theme.AppCompat.Light), will devices running an API greater than 11 or 14 for example use default Holo or action bar features or be restricted to AppCompat? I'd like to know if supporting older APIs will disadvantage users with newer and more capable devices.
Anyway, regardless of the outcome, I'll probably still go for supporting say API 7-8. This is more of a curiosity question on my part. I hope it makes sense!
Thanks, Klep
AppCompat should add functionality of the latest API to older APIs when needed. For instance, lollipop added the CardView class, which can be used in older Android APIs when AppCompat is used, with some minor differences (some of the Android L animations may not apply on older versions of Android for example). It is recommended to use AppCompat in most cases, since more users will be able to run your app when you do (depending on your MinSdkVersion). If you want to know what classes you can access in AppCompat, you can take a look at the features here.
Regarding the Styles: through Platform.AppCompat style the Theme.Appcompat inherits, and then overrides some properties, from Holo (11+) or Material (21+) if these are native on the running device.
In what API level was introduced Navigation Drawer? I tried to search and find what was introduced in API 14 but I am not sure.
DrawerLayout is included in the v4 support library, so it can be used on any platform version starting from API level 4.
The support library was specifically designed to bring newer features and ui patterns also to older device and provide a consistent user experience throughout the whole platform.
As I know 14 is correct, but to make sure, try to implement a NavigationDrawer and set your APILevel lower than 14. Normally e.g. claims that at least lvl 14 is needed
The Navigational Drawer is part of the suport library v4.
From the Android doc:
Support android.app classes to assist with development of applications for android API level 4 or later.
So you can use the navigation lib from api 4 onwards.
you can check in this link
As google announced a new navigation pattern called Android navigation drawer. Along with guideline and sample which requires latest version of android support library v13
I'm starting a new android project, and want to support api 8 onwards. I'm looking at the ActionBar class, which is only available in api 11 onwards. The compatibility library has classes like "ActionBarDrawerToggle" as of the May 2013 release - but is there a standalone ActionBar compatibility class for us to use now?:
http://developer.android.com/tools/extras/support-library.html
or do we still have to use ActionBarSherlock?
Thanks
You have to use ActionBarSherlok. Which more easy to use, and works on all platforms.
I recently read about the action bar implementation in android in the dev site.But i found that it requires a minimum api level of 11.Can someone tell me whether it is possible to implement action bar in Api levels less than 11 such as 8 or 9.If yes how can i do this?
ActionBarSherlock at http://actionbarsherlock.com is an Android library for implementing the action bar design pattern using the native ActionBar on 3.0+ and a third-party library on pre-3.0.
There is now also ActionBarCompat - part of the Android Support Library: http://android-developers.blogspot.co.uk/2013/08/actionbarcompat-and-io-2013-app-source.html
There are third-party implementations of the action bar available. See this library project at github: android-actionbar. The manifest says the minimum API level is 3, target API is 8.
If you are looking for a simplistic Actionbar solution you might want to give a look to ActionBarCompat from the Google Official examples