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!
Related
Because API 19 (KitKat) is still very popular, it's a good choice to support this release. However, it does not support many features, such as backgroundTint and ImageTint. This puts me in various compatibility issues and design choices.
I have several icons to load on a screen and I'm currently using setImageTintList to make the app dynamic.
The "faces" and "bucks" should change color according to the element in a recyclerView. What is the best way to support this function on systems with API <21?
I'm not sure what APIs you exactly mean by saying "backgroundTint and ImageTint", but there's a compatibility ViewCompat class which will backport some functionality up to API 4.
Amongst them are:
setBackgroundTintList(View, ColorStateList)
setBackgroundTintMode(View, ColorStateList)
If by saying "ImageTint" you meant android:tint or setImageTintList(), then this answers your question.
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.
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.
Considering Android Design Guidelines announcement what is the best way to make apps which are compliant with them on Android 2.x phones? E.g. what is the best way to implement the ActionBar pattern?
ActionbarSherlock is a starting point. It includes the compatibility libraries from Google and comes provided as a project rather than JAR offering greater flexibility, should you need to alter anything. Version 4 is on the way which will also include ICS stuff.
As far as I am aware I believe ABS is backward compatible to 1.6, and makes use of the minSdkVersion and targetSdkVersion. It uses an extended version of the holo theme to create a light and dark version that includes the extra ActionBar goodness, which in turn you can extend to style your app.
I recorded a tutorial on YouTube to get people started.
I think it's better to use the compatibilty libraries directly, instead of another library based on those. Additionally, refer to the Google I/O App as stated at the bottom of the first link I gave. You can find the best practices about implementing a UI for several devices with compatibility libraries.
I found ActionBarSherlock to be pretty good. It will emulate ActionBar on older devices and use the native one on modern ones. It's an extension to Android compatibility library - so you will also get fragments and other ICS stuff.