Part 2: Jetpack Compose in Our Production Code
After a 2 sprint, we’re shipping our last development code to production. We can claim that Jetpack Compose is stable enough to be used, even though with a few constraints discussed in the previous article, here
In the previous article, we discussed how we implemented Jetpack Compose in our development codebase.
For more details, please read the following article: Part 1: Integrating Jetpack Compose to Our Development Code.
It turns out that the environment on the Android Studio Canary provides so many drawbacks that it makes the refactor process very difficult because there are so many constraints that have to be changed, which are not even related to Jetpack Compose at all. So in this article, we want to discuss the obstacle, its drawbacks, and why we still implemented Jetpack Compose in our production environment even though we were aware of all those drawbacks.
What we have found so far…
In the previous article, we used the android Gradle plugin version 7.0.0-alpha to develop UI using Jetpack Compose. Still, it provides some drawbacks, which eventually became the reason for us to downgrade the Android Gradle plugin version back to 4.1.3, which of course, already supports jetpack compose and is much more stable to implement in the production environment. Here are the drawbacks we have found so far:
- Android Gradle plugin
7.0.0-alpharequires java JDK version 11, this requires a lot of changes in our codebase, plus in our team, 3 developers have different devices/machines with different operating systems, so it will cost a lot of money to just refactor the Java JDK.
Android Gradle plugin requires Java 11 to run. You are currently using Java 1.8.You can try some of the following options:
- changing the IDE settings.
- changing the JAVA_HOME environment variable.
- changing `org.gradle.java.home` in `gradle.properties`.
- We have installed several 3rd party Gradle plugins that have the potential to fail the building process on the CI Pipeline or local machines such as
Triple-T,Jacoco,SonarQube,Hilt,Firebase Crashlytics.
Your project may be using a third-party plugin which is not compatible with the other plugins in the project or the version of Gradle requested by the project.- We are also using an Annotation processor (
kapt) that has the potential to break if it is not fully supported on android Gradle plugin7.0.0-alphaand Java JDK 11. - Related to
kapt, we also haven’t removed some of the dependencies which are directly related tokaptlikeglide,dagger,hilt, etc. Hopefully, some of the libraries that usingkaptwill be removed to increase build time as well. - Some Gradle settings like
configuration cache,parallel,build cache, etc., will have different settings and can also break our code. - We also use the
Kotlin DSL Gradleto manage dependencies in our code. This also needs to be considered if we upgrade the Gradle version; of course, there will be many changes that need to be made and will break the reusable dependencies management approach that we have used. - We are using
coreDesugarLibraryto useJava JDK 8 APIon android versions belowAPI 26. upgrading the android Gradle plugin and Java JDK will result in runtime errors on our system (yes, we are in the process of migrating from java to kotlin) - We are also worried that upgrading the android Gradle plugin to version
7.0.0-alphawill break the unit testing we made on the dynamic feature module due to changes in Gradle behavior.
The things mentioned above finally made us decide to downgrade the android Gradle plugin to 4.1.3 to still use Jetpack Compose with only a few refactors on the Gradle setting and our entire production codebase.
Jetpack compose on android studio 4.1.3
Developing UI with Jetpack Compose on Android Gradle plugin 4.1.3 is not that different from Android Gradle plugin 7.0.0-alpha. But once again, there are drawbacks that we have to accept. One of the drawbacks is we cannot use the preview feature of Jetpack Compose because this feature is only available on Android Studio Canary with Android Gradle plugin 7.0.0-alpha.
We still can use the @Composable annotation and use all components in the jetpack compose library. All functions except preview are run well. For us, this is not a deal-breaker. Hopefully, they can make the preview feature available on android studio production soon.
Even so, in our opinion, you can still develop UI even without the preview feature if you are used to using jetpack compose. at the same time, you can practice blind code skills :)
Conclusion
So far, our approach in implementing jetpack compose has run smoothly. Regardless of some drawbacks, it is still worth it because jetpack composes offers many benefits on increasing development experience and increasing our app performance.
We have decided to wait for at least the android Gradle plugin version 7.0.0 has entered the beta phase, so we are confident to refactor our code by implementing the android Gradle plugin version 7.0.0 and Java JDK 11.
