I planned to support Android 2.2+ with my app, and to make it look Holo I included ActionBarSherlock, but now I have to higher the limit to 3.0 because a couple of methods (e.g. PreferenceFragment) aren't available in lower APIs (and I do not want to rewrite all those methods for 2.2).
Are there advantages of ActionBarSherlock over the normal ActionBar(Compat) on API 11+? Should I remove the library to reduce the app's size or are there reasons why I should keep it?
because a couple of methods (e.g. PreferenceFragment) aren't available in lower APIs (and I do not want to rewrite all those methods for 2.2)
There are plenty of ways address this, while maintaining backwards compatibility. Not only did somebody else backport this (IIRC), but with a couple of lines of code you can support the older Android versions, as I demonstrate in this sample project.
Note that I am not saying that you should not be raising your android:minSdkVersion, just that this specific reason is not an especially good reason. If your reason is "gee, is it really worth supporting a declining number of devices?", that's perfectly reasonable, particularly for new apps.
Are there advantages of ActionBarSherlock over the normal ActionBar(Compat) on API 11+?
First, the AppCompat action bar would not change your preference issues.
Second, since there are approximately zero devices running API Levels 11 through 14, if you are going to raise your android:minSdkVersion, go to 15. At that level, there is nothing the action bar backports will really add for you at this time.
If, however, you do decide to support API Level 11 as your minimum, there were a few things added to ActionBar in API Level 14, that ActionBarSherlock offers (and perhaps AppCompat, though I have not checked), that would be unavailable in the native action bar.
Related
I have been really confused on this. I want to be able to have a lot of people use my app, but as of this post, this seems difficult unless you set your minimum API down to 16-17 or so.
Even if I am setting my API to this level, is there any point to me using things like AppCompatActivity / the Support Library?
If I want to use a Material theme, do I either have to set minimum API to 21 or use AppCompat?
Are "ActionBars" still a thing, or are they deprecated? I'm trying to find something that will allow me to display the bar on all preference screens (including nested screens). I'm also trying to include icons in both the bar and the preference items.
So I am unsure what API I need to use / what libraries to use.
Your question is similar to this previously asked question
Should I use AppCompat v7 if minsdk is 14
AppCompat libraries allow you to provide features and capabilities that are in later releases of Android to earlier releases that dont have them in their SDK versions. Theme features and capabilities are part of this, but certainly not limited to that. Example that you already stated is the material design one. If you want widgets and views that are introduced in SDK 21+ supported in say API 15 (ICS) then you would use AppCompat 21+. However, features that are in AppCompat +7 (example AnimatedVectorDrawable) would not be needed since Api 15 would already support that.
So effectively it depends on the feature you want to support and the minimum SDK you are targeting.
Hope that helps!
I understand that it is considered good practice to program for Android using the AppCompat support libraries for backwards compatibility. However, for this specific project, the minimum API level I am to support is Android 5.0 (level 22).
However all information I can find for new Lollipop features always points towards the AppCompat support libraries. Must I do this, or are there vanilla equivalents that do not require AppCompat themes, classes or attention to backwards compatibility (ie. a plain CoordinatorLayout in layout XML instead of android.support.design.widget.CoordinatorLayout)?
First, Andorid 5.0 is API 21. If you set the min SDK to 21, most features like material design theme comes by default, you don't need any libraries. But I think the CoordinatorLayout is only in the com.android.support:design library, you have to include the library to use it.
You will need to use various support libs for certain functionality.
The CoordinatorLayout exists in the design library, and not in the OS framework.
This can actually be quite useful. Use of the design library means you can use these components independently from the OS version of the user's device. Meaning you can get updated functionality without the user updating their OS.
And won't experience breaking API differences depending on what OS the user runs.
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.
Android documentation encourages to use Fragment Dialogs on older versions of ADT by adding the support library. It claims that just using Dialogs can issue some memory problems. However when I added support library to my project it increased my footprint from 400K to 700k, so my application is just same size as the support library. It was a price to just show one simple dialog.
So question is really I have to sacrifice my application footprint by adding the library because Dialog implementation has real problems, and in this case I had to do that, or I can live with standard dialogs implementation?
Attention to moderators, it isn't duplication of How Android Support Library work?
since I am asking of an impact not using fragment dialogs and the support library on an application stability.
I think if you are only running API 10 and lower, but nothing higher, you might not want to add the support library. Seeing as you won't be using anything else (I'm guessing here from what you are saying), the footprint might not be worth it. The support library is meant for backwards compatibility, and since your intent is not to do that, remove it and use plain old Dialogs. If they are not deprecated then I don't see why not. Just make sure there are no performance issues (which is my guess as to why the doc encourages the use of the DialogFragment).
That being said is there any reason you are designing an app like that (pre honeycomb only app)? You really should be using Fragments. If you really don't want to use the support library, then design your app for API 12 and up. Not supporting older versions is more viable solution nowadays (if the adoption metrics mean anything). Plus its tried and true, so you will encounter less problems with the support (no pun intended) around it.
I understand that for Android below 3.0 i need to use ActionBar from v7 support lib
My question is how v7 ActionBar behaves on phones above Android 3.0. Does is use native ActionBar or v7 ActionBar?
I am asking if v7 ActionBar on phones with Android 3.0 and above will be of less quality
(may be less features) than regular ActionBar
Thanks
If you decide to use ActionBarCompat - all your devices will get action bar from compat library. Of course you can have some really tricky API version checks and choose one over another in runtime, but efforts and code complexity just don't worth it. I wouldn't say it is going to be "less quality" since Google guys are really trying hard to make it look the same. Also Im pretty sure list of interfaces is exactly the same as native implementation.
From another hand, there is obviously a risk to hit some nasty bug which is not present (or already fixed) in native implementation, so it is all up to you to take this risk to the benefit of supporting older platforms.