Migrating to AndroidX: The time is right! Let’s summarize it!
The final version of the support library is 28.0.0 and it’s no longer maintained. So, If we want bug fixes or new features that would have previously gone into the Support Library, we need to migrate to AndroidX. All new Jetpack libraries will be released in AndroidX namespace.
Why migrate?
There are many reasons to migrate Android Support Library to AndroidX -
- The Android Support Library has reached the end of its life. 28.0 was the last release of the Android Support namespace and the namespace is no longer maintained. So, if you want bug fixes or new features you need to migrate to AndroidX.
- Better package management. With AndroidX, you get standardized and independent versioning, as well as better standardized naming and more frequent releases.
- Other libraries have migrated to use the AndroidX namespace libraries, including Google Play services, Firebase, Butterknife, Databinding Mockito, and SQLDelight among others.
- All new Jetpack libraries will be released in AndroidX namespace. So, for example, to take advantage of Jetpack Compose or CameraX, you need to migrate to the AndroidX namespace.
- Jetpack Navigation Component is imperative to follow google recommended Single-Activity Architecture app approach hassle-free
- Google recommended arch — MVVM pattern with Repos, as well as Arch Components. They’re inevitable to build large scale apps in modular arch to isolate via modules to make the codebase maintainable, scalable, and to get better CC. Writing tests made easy. For large scale applications, MVVM with Clean Architecture ( http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html ) for one step ahead better readability.
Preparing to migrate
Before you start to migrate to AndroidX you should:
- Create a new branch on which to make the migration changes.
- If possible, suspend or minimize development ( at least don’t try to do refactoring or pull in new features ) during the migration, as this will help reduce the number of merge conflicts that could happen.
Migrate
Throughout the migration steps focus on addressing errors, getting your app to compile, and passing all tests.
Step 1:
Migrating directly to AndroidX from an older version of the Support Library, say 26 or 27, isn’t recommended. Bring the app up to date. Update the project to use the final version of the support library: version 28.0.0. This is because AndroidX artifacts with version 1.0.0 are binary equivalent to the Support Library 28.0.0 artifacts. Then address all of the API changes, and ensure your app compiles with version 28.
Step 2:
Update third-party dependencies to the latest. Not doing so could result in unexplained compilation errors.
Step 3:
Enable the following flags in gradle.properties. With Android Studio 3.2 and higher, you can migrate an existing project to AndroidX by selecting Refactor > Migrate to AndroidX from the menu bar.
android.enableJetifier=true— Jetifier helps migrate third-party dependencies to use AndroidX. Jetifier will change the byte code of those dependencies to make them compatible with projects using AndroidX.
android.useAndroidX=true — The Android plugin uses the appropriate AndroidX library instead of a Support Library.
Now, Let me try to answer a couple of common queries -
- Is this absolutely necessary or just a nice to have for new projects — Google recommends using AndroidX libraries in all new projects. I hope the above elaboration could evince it why.
- What is the impact of this on our existing applications, if we do not do this. — Existing apps will work as-is. But, going forward developers will find it to be difficult to maintain the codebase without Jetpack. The approach should be to add new features in the existing apps consuming the latest trends and systematically migrate the deprecating code units too.
- Coding effort/time — Post-migration, foresee mainly package changes. Also, Need to see third party libs conflicts if any.
- Known regression — As described, It shouldn’t cause any regression according to the officials, if we do follow the steps properly. But still, we have to cross-check with the codebase dependencies to ensure nothing breaks.
- Possibility of app break/areas — As I mentioned, AndroidX artifacts with version 1.0.0 are binary equivalent to the Support Library 28.0.0 artifacts. So, update Support Library to the latest prior migration. Then address all of the API changes, and ensure your app compiles with version 28.
- Step by step updates for future — For doing this first and foremost we need to change the app architecture to MVVM with Jetpack libraries. The approach should be New features with New Components and gradually revamp existing code units screen wise to the latest trends.
- QA effort — Need to perform testing across the app mainly focused on the UI/UX, Breakdown the features, and estimate.
Given all of the above, you should not be surprised to learn it’ll take a decent amount of time to upgrade our codebase to AndroidX.
In a nutshell — The time is right, move to Android X now!
