The Reality of AndroidX
As a matter of fact, Android Jetpack is set of libraries, tools, and guidance for modern Android development, which has been introduced by Google recently. Furthermore, AndroidX is the package name for all libraries within Android Jetpack. Basically, AndroidX is a significant enhancement to the original Android Support Library. This essay will discuss some concepts and best practices in using AndroidX for your Android projects.
Introduction and Overview
As you know, Android Jetpack is set of libraries, tools, and guidance for modern Android development. Currently, there are four categories for using Jetpack, which includes: Architecture, UI, Behavior, and Foundation. In other words, these best practices help developers for writing high quality Android apps easier, limiting boilerplate code, and simplifying complex tasks. As a result, you can now focus on the code that you really care about. In addition, AndroidX is the package name for all libraries within Jetpack. Therefore, you can think of AndroidX as the open source project that you can be able to use to develop, test, version, and release Jetpack libraries. In fact, in I/O of 2018, Google has announced that they refactored the Support Library to the AndroidX namespaces. Thus, they did this similar task with Support Library 28. Also, they announced AndroidX 1.0. Basically, AndroidX is a considerable enhancement to the original Android Support Library that is no longer maintained. AndroidX packages completely replace the Support Library by providing some new features and libraries.
Artifacts within the
androidxnamespace comprise the Android Jetpack libraries. Like the Support Library, libraries in theandroidxnamespace ship separately from the Android platform and provide backward compatibility across Android releases.
Now, the primary question is that why should we migrate to AndroidX?
Reasons for migrating to AndroidX
- Version 28.0.0 is the last release of the Support Library. This namespace android.support has no longer maintaining. So, if you want to fix bugs or use advanced features that normally would have eliminated in the Support Library, you have to migrate to AndroidX. All new feature development will be found in the androidx namespace.
- Currently, you can be able to have better package management. This means unlike the Support Library, androidx packages are separately maintained and updated. The androidx packages use strict Semantic Versioning, starting with version 1.0.0. In short, you can have better standardized naming and more frequent releases.
- Other libraries and third party libraries have migrated to the androidx namespace such as Google Play services, Firebase, Butterknife, Mockito 2, and SqlDelight. Besides, all new libraries are releasing and utilizing in AndroidX such as Compose or CameraX.
Main steps to prepare for migrating to AndroidX
- You should backup your Android project. Probably, most developers might be using Source Control tools. In any case, you should make a backup of your project because the migration will change many of the files in your Android project.
- You should minimize feature development during the migration process. Furthermore, you should try to make these migrations on a separate branch when you are using a Source Control tool.
Recommended approach by Google on how to migrate
- Updating the Support Library to version 28.
As a matter of fact, if you have used an older version of the support library such as 26 and 27 versions, and try to make the migration to AndroidX, the first suggestion is that you should try to update to version 28. Also, you should address all of those API changes, and get your app compiling with 28. At that point, make them jump over to AndroidX. In fact, AndroidX artifacts with version 1.0.0 are binary equivalent to the Support Library 28.0.0 artifacts.That means just only the package name changes between two versions. It means all the APIs are similar. Thus, you will probably have a minimal set of things, which you require to fix between migrating from 28 to AndroidX.
2. Enabling Jetifier in your Android application
Initially, Jetifier will help you migrate your third party dependencies to use AndroidX. This means is that Jetifier will change the dependencies to be compatible with your project that is using AndroidX. It will not change your source code, nor will it migrate your generated code. To use this feature, you should add a couple of lines to your gradle.properties files. In other words, useAndroidX is set to true, along with enableJetifier.
android.useAndroidX: If this flag is set to true, the Android plugin uses the appropriate AndroidX library instead of a Support Library. So, when you perform code auto completion and you import libraries, you will import the AndroidX version of that library instead of the old support Library version.
android.enableJetifier: If this flag is set to true, the Android plugin will automatically migrate existing third-party libraries to utilize AndroidX dependencies by rewriting their binaries.
3. Updating your dependencies
Obviously, a number of third party dependencies may require to be updated before you want to start the migration process such as Butterknife, Glide, Mockito 2, and SqlDelight. So, if it is possible, you should try to update your third party dependencies first, before starting the migration. Now, if you are using a code generation library, Jetifier will not modify these. Therefore, you might need to check if the code generation library is compatible with AndroidX or not. Additionally, some common errors might occur if you want to skip steps 2 and 3. For instance, a third part library code that you are using is not compatible with AndroidX. Or, if you have an Android project that is partially migrated, you might get a duplicate class error.
4. Using Android Studio and bash script
In fact, from Android Studio 3.2 stable version and above, there is a handy migrate to AndroidX button. So, this button will perform the migration of your source code, and this will work for a majority of cases. However, some development teams may not use Android Studio. Also, there are some more sophisticated app architectures that the tool cannot exactly automate. As a result, there are two options in this situation. First, you could be migrated the source code by itself, and another option would be a bash script (you should replace all source code instances of support library packages with their AndroidX version). Another option is you can accomplish it manually. So, if you run into issues with migration as a manual option, you can be able to refer to tables to demonstrate the proper mappings from the support library to the corresponding AndroidX artifacts and classes:
Manual intervention
There are some situations that we cannot automate migration. This means some situations need manual intervention such as version configuration files, Proguard files, and Build scripts. Therefore, if you are using these features and you are also having package names in them, you will need to edit manually. For instance, to do version configuration in your build.gradle, you can be able to observe the versions variable numbers have not been changed after running the automate tool. So, it is clear that you will need to do a manual update on them.
Merge conflicts
To do merging process, Google has recommended to slow down or pause development. In fact, this manner diminishes the amount of merge conflicts that will occur. If it is possible, you should have a few people on your team for just only focusing on the migration process. Besides, you should try to do the migration on a separate branch. When you are doing this migration, it would be a great idea to just focus on addressing the errors, and getting your app to compile, and all tests passing again. In short, you should not accomplish and try to do refactoring, or do not try to pull in new features during this period of time. Furthermore, when you run the migration tool, you may have an alpha version or a stable version of the library, depending on the most recent release. In this case, depending on your particular needs in your project, you may want to use the alpha version or maybe you prefer stable. Thus, this is an issue that you will need to go back and manually check to observe which version it migrated to. Also, you should make sure that your selected version is appropriate for your needs.
In conclusion
As you can see, Android Jetpack is set of libraries, tools, and guidance for modern Android development, which has been introduced by Google recently. Moreover, AndroidX is the package name for all libraries within Android Jetpack. Initially, AndroidX is a notable enhancement to the original Android Support Library. This article considered some concepts and best practices in using AndroidX for Android development based on Google resources.
