Should you use Jetpack Compose?
Reasons for and against Jetpack Compose in Android development.
Are you used to the good old View system? Or maybe you learn Android development and you are overwhelmed by tons of materials when some of them tell you how to write XML layouts and others show you completely different Jetpack Compose?
After a year of using Jetpack Compose in production, I want to make a quick recap. Basically, in 2023 you can do the same things on both technologies in 98% of cases, so here we will focus on another type of thoughts. I hope it will make the choice clearer.
Why use
Another level of flexibility
Usually, in XML it takes some effort to change the existing layout.
For example, If you need to add a View to the layout, you have to create a View object, you have to add it once and track the state of addition to not add it twice.
On the other hand, in Compose having/not having an element costs you literally one if or similar logic.
Of course, with the View system, we can always set visibility as gone, but in Compose we can just skip the existence of an element with the same ease.
After some time of using this new system your way of thinking changes too. You literally may want to write something that you had no time or energy to do before.
Google actively promotes it
We saw the same story with Java/Kotlin. Nowadays Java has quite limited scope of application in typical Android development. Looks like it’s the same with Compose. Google has invested quite a lot in Jetpack Compose since it was in alpha in 2020.
Google even has a list of companies that use Jetpack Compose. Some well-known companies like Lyft and Reddit are listed there.
It’s multiplatform. Kind of
Limited but promising. The last major piece of Kotlin multiplatform puzzle that may make it a big player like Flutter or React Native. It works on a desktop. iOS support is in the alpha stage but the direction is clear.
The fact that you already can apply your knowledge of writing Android UI to make desktop applications opens some new doors. Imagine if one day you can just compile your Android app as an iOS app with no or little effort.
Why maybe not
Huge legacy Android codebase and you can’t invest time in it.
Not every project can afford to put a lot of time into migration to new technology if the previous works well. Also, it may be hard to accept the fact that all the knowledge that you acquired through years of hard work with the View-based system is now not necessary. But it happens in our industry.
Fortunately, as one of the possible migration strategies you can start implementing Compose step by step only in new screens inside Fragments or Activities.
You rely on Custom Views
Using a library that provides View-based functionality?
Have something like custom charts or fancy animated logic in your codebase? Be prepared to spend extra time rewriting it with new principles.
Fortunately, you can use such Views inside Compose.
You want to achieve maximum performance on a low-level
Although Google shows good samples of performance, it may be that in your case you utilize some features of the View system that can make it more beneficial than Compose. For example, you count every byte of your APK and use default Views from the platform. Or maybe you draw using OpenGL on SurfaceView and you just don’t need something else.
Conclusion
These were some high-level points to think about if you are not sure what to choose. While the technology appears modern and promising, the final decision should be tailored to the specific needs of the project. Feel free to add your thoughts in the comments if you have some scenarios.
By the way, this is how Google describes why to use Compose.
Thanks for reading!
