AndroidX, one month in
2018-10-21 • Márton Braun
AndroidX first appeared back in May as the upcoming replacement for the support libraries we’re all used to when doing Android development. It promised better organized artifacts, more sensible package names (no more meaningless v4
and v7
, yay!), and semantic versioning of aforementioned artifacts after a reset to 1.0.0
.
Months went by, we all slowly adapted to the changes that came with Android Pie, and in September, the AndroidX libraries became stable and officially production ready. Almost at the same time, we got a “stable” release (depending on who you ask) of Android Studio 3.2 after it went through several beta versions - and with it came the magical button that lets you migrate your project from the old support library setup to the shiny new AndroidX world.
The experience
As a library dev
I am the maintainer of an up and coming Android library, namely, MaterialDrawerKt. My library is just a DSL wrapper around another library by Mike Penz, which implements all its functionality.
During the alpha phases of AndroidX through the summer, Mike has released a couple RC versions of his library in which he made sure it works properly with the new system, and when AndroidX became stable, he published a stable release of his library almost immediately.
I’ve followed these developments closely, and I’ve used the Android Studio migration tool to move my library and its sample project to AndroidX as well. This was painless enough, it required only about half an hour of manual work after it ran, which consisted of adding some more explicit imports for RecyclerView
classes and fixing imports in about a dozen files.
Since I was prepared in advance, I could release version 2.0 of MaterialDrawerKt on the 22nd of September, within half an hour of the base library’s first stable AndroidX release. For some reason this got quite popular on reddit, and the library’s GitHub page saw a significant boost in stargazers. (Note that there were no new features since the last non-AndroidX version.)
As an app developer / employee
At work, I’ve performed the migration for one of the projects I’m working on, which is a mid-sized, 100% Kotlin application with about 14k lines of code, a couple Gradle modules, and a couple dozen dependencies.
Just like my library, this project was already using the 28.0.0
version of the support library, so all updates that had to be done during the conversion were purely due to the AndroidX package name changes. This process took me about 2 hours after running the migration tool. Again, lots of imports to fix, and this time, I even had a couple dependencies to untangle, which I imagine will be somewhat common if you have more than a Hello World application (something about how the Firebase WorkManager dependency included a bad version of androidx.media
transitively).
Again though, everything worked just like it did before the conversion, and all the dependencies the project had that haven’t been moved to AndroidX were still functioning just fine thanks to the jetifier.
We did see Android Studio have some issues with resolving references between AndroidX packages and references in dependencies to old support library classes - but thankfully it was nothing that cleaning a project, invalidating caches, and restarting Studio didn’t fix. Hopefully this will become even better in bugfix releases of 3.2.
Adoption rates
To finally get to the reason I’m writing this article now: MaterialDrawerKt is downloaded from Bintray around 2000 times a month, which gives me at least some insight into how AndroidX adoption is growing.
Versions 2.0.0
and 2.0.1
(in shades of purple on the graph) accounted for 28% of downloads for the library in this first month of stable AndroidX.
This 28% of the projects using my library have already been migrated to AndroidX already, and there could be even more that are on AndroidX and are using an older version of MaterialDrawerKt with jetifier (either the maintainers haven’t noticed my library’s new release, or didn’t care to update to it).
Of course this is a very limited data set with not that many users, they are probably more keen to try new things since they are already Kotlin users as well, some might be new users, some might be upgrading, these are just the download numbers and only from Bintray, etc.
Here’s the original library’s numbers for comparison though (which is a lot larger data set). In this graph, versions 6.1.0-rc01
and later are the AndroidX versions, totaling about 25% of downloads.
Honestly, these numbers were better than I expected. This looks like a solid upwards curve for AndroidX adoption, even though my personal experience is that most Android developers still don’t quite understand the difference between Jetpack and the AndroidX changes.
Conclusion
We don’t have much of a choice - 28.0.0
was the last major release of the support library, and we’ll all have to move to AndroidX by next year if we want to keep using the latest versions of Google’s libraries. This AndroidX future is brighter by the day though as tooling is getting better and better.
If your application’s code base is large and you have to ship new features and versions frequently, you might want to hold off with the migration a little more. But if your code base is smaller, and you have a couple hours to resolve some import and dependency issues, you might as well take the leap now.
You might also like...
Wrap-up 2021
Another year over, a new one's almost begun. Here's a brief summary of what I've done in this one.
The conflation problem of testing StateFlows
StateFlow behaves as a state holder and a Flow of values at the same time. Due to conflation, a collector of a StateFlow might not receive all values that it holds over time. This article covers what that means for your tests.
A Bit of Gradle Housekeeping
While cleaning is traditionally a spring activity, let me invite you to do it at the end of summer this time around. In this article, we'll take a look at some Gradle configuration that you can probably clean up in your Android project.
All About Opt-In Annotations
Have you ever encountered APIs that show warnings or errors when you use them, saying that they're internal or experimental? In this guide, you'll learn everything you need to know about opt-in APIs in Kotlin: how to create and use them, and all their nuances.