7 Annoying things about Jetpack Compose
Jetpack compose is arguably one of the most exciting innovations in the world of Android development. It's been a breath of fresh air from the aging xml UI system and has brought numerous improvements. On top of that, the rate of its development is also staggering. It's been almost a year since it went stable and is being adopted by various teams. But not everything is perfect. Jetpack compose still has some areas that are not fully mature or not yet developed. In this article, I will go over some annoying bugs and missing features that I have personally encountered while working full-time migrating a legacy app to compose and some side projects of my own.
1. Preview performance
In Android studio, we can set up previews in order to see the designs we are implementing in compose. But this preview is a far cry from the old XML preview, in terms of performance. Changes are not instantly visible on screen and require a rebuild to see them. But with time, the compose preview will get there and probably surpass the XML preview. There have been recent updates to enable interactivity and also preview animations.
2. Lack of libraries
Depending on when you started using compose, you would have found very little UI libraries compared to what we are normally used to. I have ended up creating custom solutions for some common problems (On the bright side, this gave me more experience writing composables). This is of course expected since compose is still relatively young.
3. Performance monitoring
Performance is a very crucial part of an app, and it is our job as developers to maintain a smooth experience for our users. Unfortunately, we can not do so without proper tools to debug performance. We still have access to the tools we had for debugging the old XML UI, but I would argue we need new tools and systems for compose's declarative system. In my experience, most UI lag in compose has been caused by a misunderstanding of how state works, ending up in multiple unnecessary recompositions. The Google Play team also realized this and built a custom modifier for tracking recompositions as they were optimizing. Tools like this should be made more accessible, right into compose. There can also be warnings in Android Studio to avoid common antipatterns that lead to UI lag.
4. Ads
Most apps rely on advertisements for revenue. So chances are that you would need to implement ads in your app in one way or another. But if you are using compose in your app, you may run into some scenarios when you would have to switch to xml views. Ad libraries are not yet available natively in jetpack compose. This becomes an issue especially with native ads, when you define the text elements of the ad in xml but still need to match it with the design from the compose theme. The AndroidView does offer really great interoperability, but I think that is just a stepping stone to bridge the two worlds for now. For a great experience, ad libraries should offer composable versions of their ad containers.
5. Navigation animation
Any app with more than one screen definitely needs a system to manage navigation through the app. Jetpack navigation is the officially recommended way, but yet it has a weird bug that is hard to overlook. There is a fade animation between screens, and this is not configurable and can not be turned off. There is another issue tracking when animations will be added while navigation, but as for now, you could use Accompanists navigation library and tweak or turn off the animation.
6. List animation
Gone are the days of writing adapters and ViewHolders for a RecyclerView. Now we have LazyLists that we can create in seconds. But in terms of animation, It can not still match up to the RecyclerView. There have been some updates adding reordering animations (although there have been some issues reported on that), but there still is not an official implementation for adding and removing animations. I have been using this solution in my apps until there is an official and stable implementation.
7. Fling bug
This last one seems like a small one but has a big impact on how users perceive the app. Nested scrolling is a common building block in some UI patterns. Whether it's a collapsing app bar or a modal with a list in it, there are numerous uses for it. In these cases, scrolling performance should be reactive and smooth. Failure of which, the app might feel janky or not native. The fling bug provides wrong velocity values while scrolling, which causes the list to stop scrolling instantly or even start scrolling in the wrong direction.
Those are 7 annoying things have encountered while migrating to compose. If you would like to share in my frustration, or you have found a proper solution to any of these issues, please let me know
Thanks for reading and good luck!