One of the hardest problems to solve is to solve a problem for someone who doesn’t know that they have a problem in the first place. Many Android developers did not know they needed to move away from the View system until the Jetpack Compose team told them so. Most Jetpacks Compose introductory tutorial mentions that Jetpack Compose is Android’s new UI toolkit for building Android apps in a declarative way and then jumps right into describing composables. Meanwhile, Joe Schmo across the room is busy optimizing his custom view derived from ConstraintLayout to support refrigerator apps. Why would he unlearn view/data binding, list adapters, fragment, XML layout files, and jump on the Compose bandwagon?
Reasons Why You Should Adopt Jetpack Compose
- It is more productive – Jetpack Compose accelerates UI development and makes Android engineers more productive. That was a bold claim from Google, and I can attest to that. With Compose you structure your code base to achieve what Leland Richardson described as Cohesion instead of Coupling. A simple productivity gain example is that you can implement performant list rendering with just LazyColumn without needing a ViewModel, LayoutManager, and Adapter.
- It’s the future – It is the responsibility of the platform owner (the Android team @ Google) to climb the tree from time to time and look out to the future five to 10 years ahead. And what they saw is that the industry is moving toward a declarative UI paradigm. Thanks, React.
- It’s easier – It turns out that the Engineers working on the Android toolkit @ Google are also humans who enjoy working with newer code bases instead of battling aging, fragile APIs. The View class has been around from API Level 1; just imagine the fun of modifying it. If the Android team found it easier to start from scratch, maybe you should too.
- It’s frequently updated – The times are changing fast! Consumer expectations, developer demands, competitive landscape, and market forces all require constant changes and updates to the Android UI system and the Android team wants to help. There is only a little problem. The Android UI toolkit is bundled with the Android OS. So all UI tooling enhancements have to follow the OS release cadence. Compose presented an opportunity to break this coupling.
- It is Kotlin – And on the seventh day, the Lord said let there be Kotlin! Out of the gate, Kotlin went after XML and findViewById. From the deprecated Kotlin synthetics to Jetpack View binding, numerous attempts have been made to simplify the context switching of working with XML. Jetpack Compose presented the ultimate simplification. It eliminated XML and lets you stay in Kotlin land 100% of the time. Everything about Compose from the compiler to the UI is Kotlin.
- It is interoperable – Compose is a Jetpack Component, which means that, in theory, it could co-exist with Fragment-based code. This will allow you to introduce Compose to your project slowly. In my experience, this works only if you make a steady, sustained effort towards full Compose adoption. Compose and XML-based layout are two vastly different development approaches and the mental bandwidth of maintaining and switching between the two is not sustainable long term.
- It is here – The community has spoken, and it is widely adopting Jetpack Compose. Poor Joe Schmo might not be aware, but the ship has sailed. At some point, organizations with legacy XML/View-based code-based will have a hard time attracting talent. So it is not a question of if but when will Joe get on board? My guess is by version 1.5! If he waits until Jetpack 2.0, I would suspect, he may have to re-learn Android development all over again.