Android Jetpack/ Android X
When talking about AndroidX…
- What ordinary people think, maybe the new Android Phone model with the screen cut off just like iPhoneX by Apple
- What am I thinking, the 10th Dr.Light’s humanoid called Megaman X
What AndroidX really is, and why it packs together with Android jetpack?
AndroidX is a new library refactored from the Support Library. Before we go deep down in detail, I would like to introduce you the Android Jetpack first.
Android Jetpack
The Android Jetpack is a set of the library recommended by Google. It helps developer accelerate the development, also eliminate boilerplate code, and make sure that the developers build high quality and robust apps. The Jetpack includes both old and new libraries in the set. There are 2 new libraries look interested.
From the figure above, Android KTX and Slices are the new libraries included. If you would like to use it, then add a dependency like an example below.
build.gradledependencies { implementation 'androidx.slice:slice-core:1.0.0-alpha3'
implementation 'androidx.slice:slice-builders:1.0.0-alpha3' implementation 'androidx.core:core-ktx:1.0.0-alpha3'}
At this point, I hope you find something different from the previous dependency adding. You’re right. The artifact name has changed from android to androidx. So androidx slightly get inside your project.
What different between Android Jetpack and AndroidX?
Android Jetpack
Set of libraries, provide recommendation and tools to let you create a good app. It also has a cute logo.
AndroidX
AndroidX is a library itself, which is its feature might or might not in Android Jetpack. Like I was mention before Android KTX and Slices are the AndroidX features and both also in Android Jetpack.
Before AndroidX
Google has developed the Support Library for 7 years, a ton of developers are using it. In-term to improve their library, it’s a good idea to get feedback from developers who use. Their are so many feedback some are at a high level, some are a low level.
However, what Google pay attend is about the fundamental thing, naming packaging thing. Also, the feedback they collect is relevant. For i.e.
“Mismatched artifact/ package name is weird, could be confusing.”
“Developer has to understand the legacy of Support Library …/ not great.”
“Have to update version of Support Library, but nothing new.”
The first support library
Back in 2011, a significant change of Android is Google release the Honeycomb which is support in tablets; and add the fragment library to handle the multi-sizing screen. Let developer write code just one time and support both mobile and tablet. Moreover, soon enough Google also release Support Library to help developer handle Android’s fragmentation.
Support Library has overgrown in past 7 years; it also has Watch component, Auto component, TV component, testing tools. The list down below is an example of the libraries.
First thing I notice is, naming is not consistency for, i.e., support-v4, support-v13. Also, <feature>-v7 and <feature>. What time to bring in the “v.” Alternatively, what time I shouldn’t bring the “v” in it. The only name it confuses already.
Doesn’t “v-#” mean something?
v-x, by the x, mean minimum SDK support. So “v-4” support until SDK level 4. For more information check this StackOverflow, it very clear.
v4 Support Library is for Android 1.6 (API level 4) Android 2.3 (API level 9) Android 4.0 (API level 14) and higher.
v7 Support Library is for Android 2.1 (API level 7) Android 2.3 (API level 9) Android 4.0 (API level 14) and higher.
v13 Support Library is for Android 3.2 (API level 13) and higher. However, the new features in v13 have depicted already.
Now you have to consider to use the support library; Though, you have to know all of this stuff which is not cool.
The version number
The “recommendation” is one of a library which has many version but not updates.
From the list above the version, 24.0.0-alpha1 is not alpha state for the “recommendation” library but Android SDK. When Android SDK has new version all support library update version also even if it has nothing to update. Why? Because Gradle hints you an error if you use the support library different version, check the example below.
dependencies {
implementation ‘com.android.support:animated-vector-drawable:27.0.2’
implementation ‘com.android.support:customtabs:26.1.0’
}
The first Android era is before Samsung Galaxy S II, then the second era of Android development is Support Library. Nevertheless, now we are going to the new era of Android development, AndroidX.
Big refactoring
The Android support library has changed to Android Extension Library, AndoirdX as a nickname.
Artifact
- More logical
- Finer-grain-artifact
- Clearer scope
The positive side of the new artifact pattern, it avoids an umbrella effect from the example above; in the support library if you would like to use the “RecyclerView” — you have to pull down all the widget in “support.v7”; but in the AndroidX, you can pull the “RecyclerView” immediately.
Refined versioning
Previously, the “support library” use version number from SDK version but AndroidX use the “Semantic-version.” It’s going to re-version from 28.0.0 → 1.0.0. So the version number does mean something.
Semantic-version — “major.minor.bug” read more
Finer scope
Make the package scope more precise than before and also has a pattern.
adroidx.<feature>:classname
adroidx.<feature>:<feature>-<subfeature>
Congrats no more v-4 v-7 v-13 v-14, no more!
How about the current project, Can we migrate to AndroidX?
Yes, it can. With the new Android Studio 3.2 canary 15+
What you need. Before migrate? Set “compileSdkVersion” to 28, or you see an error like the image below.
Starting to migrate
- Open your project.
- Check “compileSdkVersion”
- Go to menu Refactor → Migrate to AndroidX
- Check the files change then hit “Do Refactor” button
Migrate tool goes inside your code every kt file, java file even XML file. Then mapping the support library and change it to AndroidX library. The sync the Gradle because also change. Run the app when your sync has done.
Is everything going smoothly?
No! There are some bugs from the migrate tool.
Migrate bug
Some method signature changed
When you update the compile tools some interface signature may change (In my case from 26 to 28). Hence migrating task not check this issue for us. You found it when building the APK.
Fortunately, we can use Android’s studio code inspect to check or of this issue.
In code using the full path instead of class name + import.
Your code may mess up after running the migrating task but still compilable. You can use linter to find and fix this issue.
3rd parties
In Android project often add 3rd parties library. Besides, the library still using support library, there for it shows the “type mismatch” error in IDE. Despite, when compiling it just fine; why?
Jetifier
Jetifier is released which perform refactoring task inside a JAR/AAR file. It’s going to refactor your 3rd parties libraries. Read more link below.
Not using Android Studio?
Google provides CSV files which are mapping support library classes to android classes, let developers do the migrate script by themselves. I recommend using Android Studio.
How about Support 28.0.0?
Support 28.0.0 included AndroidX in it, and the most important.
“No new feature in Support Library 28.0.0”
If you would like to access new features, have to migrate to AndroidX first.
Note: It still alpha state, not recommend to use in production.
What’s new in AndroidX
- recyclerview-selection provides item selection support for RecyclerView
- HEIF Writer provides support for writing HEIF-format still images
- Design Library. Theme.MaterialComponents
- Slices provide a framework for apps to embed templated content from other apps
- Browser actions provide a protocol for app developers to launch a consistent (but customizable) context menu for URLs
Conclusion
It’s a big refactor from Support Library. Technical guarantee about Artficats, Naming, Package. Some features are in Jetpack, and more cool features make your developer life more comfortable. Still, you need to consider to use it because of it still alpha state. Also, in a big project, you may have to take enough intention to migrate your code to AndroidX. The most important you may need some time to do a regression test again.
AndroidX seems to replace the support library; developers may need times to prepare for the change and migrate it. For now, you can prepare yourself as much as possible, when the time being you can estimate time more accurate and sufficient to working plan. Good luck with coding.
Thank you
— end of the story —
