Reaching a wide audience is one of the first things an Android Developer learns, the guys at Android give us some great tools, for example the Android Support library to help with this, but, Is it always the best choice for our App?
Anyone who has developed Android Apps is familiar with this problem: you just added Fragments to your App, you’re doing great, but suddenly your App keeps throwing errors, you check the code, and nothing you try to clean the project, and nothing, it’s only until you decide to check the imports section, that you figure out, you’re using two different Fragment classes, one is from the normal Android library and the other is from the Android support library, but why does this happen? Why are there two different libraries? Let’s take a look at the Android support library.
First things first, as you might infer from the name the Android support library is meant to be used when you’re targeting older devices, it helps, bring newer features to older Android versions, hence it supports the devices.
It accomplishes this by creating new classes, interfaces and functions that comply with the specifications of the older Android APIs, this makes it possible to use the latest features in older devices. Of course, it’s not without its problems, this library is incompatible with the standard library, meaning that, while you can mix and match functions, having several implementations of the same library is bound to cause problems, like the one we described in the beginning. The support library has gone and evolved alongside Android, and it keeps evolving.
If you still haven’t done so, the Android team even has a Youtube channel, and here’s a playlist showing many of the interesting and useful features of the Android support library. However, having a look at the playlist, you might notice it’s a bit outdated, last updated in 2018!
Why? Remember we said the support library is evolving alongside Android? Well that’s still true! The support library is now known as AndroidX, which is part of a bigger library known as Jetpack, which comes with its own neat features and perks.
AndroidX also marks another thing, it’s a move from Java to Kotlin as the official Android language, and while Java is still supported, as far as we know, moving forward, everything Android announces will be shown in Kotlin, so it might be a good idea to pick up Kotlin, at least, check out the playground and the docs, to get a feel of the language, so you don’t have to go around looking for Java explanations
Now let’s talk about the advantages and disadvantages of using support libraries
First, the advantages, the biggest one is quite obvious, being able to support a bigger market of devices, means our apps have a better chance of getting to a customer, and getting bigger. As many developers know supporting more devices means more market share, more market share means more downloads, and more downloads mean more revenue.
The disadvantages are not as clear cut, but there are quite a few to note. Specially if you’re using a support library it means you can’t use the latest functions, Android 28 (Pie) is currently the latest released version, and the oldest version that the v4 library supports is, unsurprisingly, Android 4, taking a look at the release schedules, Android 4 was released in 2009, that’s 10 years as of now! Meaning that whatever the library does it has to run on a 10 year old phone.
Here is a quote from an  article, from the guys at MartianCraft, which helps put things in perspective
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.
All in all, the support library cones with some amazing features, and, in most cases, it’s a no-brainer to use it. That’s it, if your objective is to reach a wide audience, moat of the new features are not available at launch in the support library, and in some cases it’s never available. If your objective is innovation, then you might want to forgo backwards compatibility and go all in with the latest version. Speaking of which, you might want to give the Android Studio Canary channel a look, it’s where the new, experimental features go live.
Author: Ing. Erwin Gonzalez