When to use support library

Question

I am confused on the purpose of the Android support library and when it is needed. It is my understanding that the major plus of using the support library is for Android to implement themes and UI features on its own in older versions without the need for the developer to explicitly define them. One of these key UI features is the Action Bar, which was introduced for tablets in Honeycomb, then added to the entire platform in Ice Cream Sandwich.

That said, let's suppose I want to develop an app that targets KitKat (the most recent API at the time of writing), but I only want to support back to API 16, the earliest version of Jelly Bean.

Jelly Bean includes the Action Bar, and there were few major UI changes between 16 and 19. Should I use the support library in this case? What benefit does it provide if I do use it? I am looking for an answer which explains the benefits of the support library, and an example use case.

Answer 1

The Support Library is generally used when you want to easily support a wider range of OS versions with less version specific source - with it you can use features introduced in higher version of the OS on older platforms without having to worry and check whether this platform has that feature and do something in case it doesn't.

There are several versions of the support library - v4, v7, v8 and v13. They all add functionality that is introduced in the higher versions of the API then the version of the library. For example v4 may add functionality from API 5, 6, 7, 8... , while v7 - only from API 8 and above.

Other major feature of the libraries is that they are regularly updated so you may choose to depend on the support library for some feature rather than on the current OS version installed (which may introduce bugs in that feature).

Of course they have their downside too - the support library is an additional dependency for your project.

Answer 2

Here is your answer—Always!

The following reasoning is copied straight from Big Nerd Ranch's Android Dev book. Emphasis mine:

This book uses the support library implementation of fragments over the implementation built into the Android OS, which may seem like an unusual choice. After all, the support library implementation of fragments was initially created so that developers could use fragments on old versions of Android that do not support the API. Today, most developers can exclusively work with versions of Android that do include support for fragments.

We still prefer support fragments. Why? Support fragments are superior because you can update the version of the support library in your application and ship a new version of your app at any time. New releases of the support library come out multiple times a year. When a new feature is added to the fragment API, that feature is also added to the support library fragment API along with any available bug fixes. To use this new goodness, just update the version of the support library in your application.

As an example, official support for fragment nesting (hosting a fragment in a fragment) was added in Android 4.2. If you are using the Android OS implementation of fragments and supporting Android 4.0 and newer, you cannot use this API on all devices that your app supports. If you are using the support library, you can update the version of the library in your app and nest fragments until you run out of memory on the device.

There are no significant downsides to using the support library’s fragments. The implementation of fragments is nearly identical in the support library as it is in the OS. The only real downside is that you have to include the support library in your project and it has a nonzero size. However, it is currently under a megabyte – and you will likely use the support library for some of its other features as well.

We take a practical approach in this book and in our own application development. The support library is king.

So... There will always be a support library because you will almost always have to support older devices for a variety of reasons:

Device owners may not be able to update to the latest version because:

• Service providers and manufacturers are not bothered about updating a non-flagship type phone - costs money to regression test their bloatware on top of a new version of Android.
• Some device owners (thankfully not all!) care very little about the Android version on their phone. Totally different situation with the Tinder app though.
• Device owners may not have the resources to upgrade to a latest/newer device. App developers in developing countries probably face this issue. Google's Platform Versions statistics are not region specific, even though they probably should be!

Anyway, here is the gist: support libraries have the exact same functionality as OS/framework APIs and they have a compact size—since they have to be included in your APK, they don't increase the size very much. So we have established that there is no downside to using/including them. Now, the upsides are tremendous - look at the Fragment example above.

Answer 3

There is different version of the support library because each version contains new features not available in the previous ones.

On this page you can see each version with the modifications included. http://developer.android.com/tools/support-library/index.html

The purpose of this support library it to give you access to features that the version you are targeting doesn't include. Is there anything in the latest API that you want to use but that the version you are targeting doesn't include ? if yes then you have to include the latest version of the support library (check before on the page above that the support library include what you need).

Answer 4

I find a good article at http://martiancraft.com/blog/2015/06/android-support-library/

It mentions:

Furthermore, in some cases, developers may think they have the choice between framework and support implementations of a particular feature, only to find out that support dependencies dictate that decision for them. For example, the v7-appcompat library enables developers to use Material Design UI features introduced in API 21. However, doing so requires that all activities extend from AppCompatActivity, which extends from the v4 support FragmentActivity. So, developers targeting anything less than API 21 and wishing to use Material Design UI features are forced to use v4 support Fragments, rather than framework Fragments.

Google considers use of the support libraries a best practice, even if not necessarily required. It includes v7-appcompat and v4 libraries in most of its sample code as well as in Android Studio’s new project templates. Google is clearly investing significant effort in these compatibility libraries and expects developers to heavily rely upon them.