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.
Related
I'm working with Xamarin.Android.
Appcompat is actually necessary for use material design because the nougat package (Android.support.design) requires it.
But why, for example, if I work only with API 27, I must add the AppCompat package? In my toolBox i've not the floatingActionButton, NavigationDrawer etc.. so I must add this packet to unlock them.
What is exactly this package? I've read on the web that this package works with backward compatibility but I only work with new APIs, so why I must install it?
Thanks.
AppCompat should add the 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:
https://developer.android.com/topic/libraries/support-library/features.html
The Xamarin.Android.AppCompat is just what it says. Its a library for App Compatibility for backward compatibility for previous versions of Android and more specifically this version (v7) brings support for Action Bar support. Read more here :
AppCompat
They are libraries used for accessing the latest features of an Android OS version. It is backward compatible by the way.
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.
When I created a new app, I got this
class NewApplicationActivity extends ActionBarActivity{... }
So I have read that, if you want to use a new feature from a newer API level, you better make it such that there is an alternative option for the App to combat any situation for the minSDKVersion that you plan to support.
Assuming this is true, lets say I decide to build my App against targetSDKVersion = 21(which I did in the above example), I would get the base Activity class as ActionBarActivity. Now this is from support library and works for older version(down to Android 2.1 I guess..).
The thing is, I am stuck with these alternative set of support libraries rather than platform libraries. Am I gonna miss something significant if this happens? Will I get a chance to incorporate the platform specific code from API 21 into my App ever? The majority of Apps are made with compatibility in mind. How do you people handle this?
Support Libraries such as AppCompat (which is what ActionBarActivity and its replacement AppCompatActivity are part of) are designed to reflect the latest platform changes and backport as much as possible. Thereby by using AppCompat, you are already using a large number of API 21 features (such as material theme).
Of course, there is nothing stopping you including any API from any level in your application: just make sure that they are guarded by the appropriate API level checks: this is exactly what many of the Compat classes in Support v4 such as NotificationCompat and ViewCompat do for you.
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.