Now that Android 11 has been around for a while, we already start hearing about new features in Android 12. Google has been fast paced regarding Android ever since. And I doubt this will change anytime soon. Since about two to three years we see a huge tendency of shifting apis relevant to app developers from the core platform to libraries. Of course support libraries have been around for about a decade, but Jetpack has become the preferred way of using crucial app features. And Google is continuously deprecating platform apis. I have written about an example in As time goes by. And I will continue in this article.
But why is this? Why isn't Google just evolving the platform? The answer is fragmentation. While Apple is in complete control of the hardware (and compared to Android the number of different models is ridiculously small) Google always needed to rely on manufacturers. And unfortunately they had a tendency of updating late or never. Yes, we have seen a lot of improvement in the past years. And Android gained important features that make life for oems easier (Treble and Mainline). Nonetheless there seem to be way more old than new Android versions in use. Both app devs and Google need to deal with them. And that's why Jetpack is an incredible idea, as it brings new features to old devices. But why deprecating platform apis?
As long as the usage of a feature is not discouraged, devs will continue to use it. So, by deprecating platform apis Google essentially says Hey devs, stop using this, it may not be there sometime in the future. So far, this sounds convincing, right? But in my opinion it also puts a burden on Google, to evolve its platform apis wisely. That means:
- deprecating only if there is an adequate, stable replacement
- introducing new apis only if they are needed
- make developers' lifes easier
Let's test this. In api level 30 for example android.widget.TabHost has been deprecated. The docs say: new applications should use fragment APIs instead of this class: Use TabLayout and ViewPager instead. Fair enough. Looking at Jetpack components however we see Viewpager. The front page reads: Display Views or Fragments in a swipeable format. If possible, use viewpager2 instead.
So, a replacement for a platform feature is replaced. Do we think that this makes developers' lifes easier? No.
Next one. android.preference.Preferenceand its accompanying classes and interfaces have been around since api level 1. They have been deprecated with Android 10. Developers are encouraged to use androidx.preference instead. Fair enough. Back in September 2020, Jetpack DataStore went alpha. Google explains: Jetpack DataStore is a data storage solution that allows you to store key-value pairs or typed objects with protocol buffers. DataStore uses Kotlin coroutines and Flow to store data asynchronously, consistently, and transactionally. If you're currently using SharedPreferences to store data, consider migrating to DataStore instead.
Right, it's just consider. But now the dev has to decide. To make a solid judgement we must know both solutions, their advantages as well as their disadvantages. Gaining that knowledge costs time. Is this really necessary?
A final example. android.util.SparseArray gets a new method on api level 30: boolean contains(int)
The docs say: Returns true if the key exists in the array. This is equivalent to indexOfKey(int) >= 0.
To safely use this method, we need to check the Android version at runtime, which bloats the code. So I could not wholeheartedly encourage anyone to use the method. Which in turn begs the question: Why is it there?
Now, what do you think? I would love to hear your thoughts.
Top comments (0)