What I learnt building a tweet screen using Jetpack Compose

I talked about Jetpack Compose(FR) days ago and this new UIToolkit is freaking good! They completely change the way we’ll write UI for android.
After days looking at it, it’s not fun to go back writing XMLs. I have the same felling when I discovered Kotlin and came back to the real life of writing java code 😂

So you see it above. I challenged my self a lil bit to replicate the tweet detail screen. I talked about it on twitter. And I loved doing it. It’s not exactly like the tweet screen but almost. And I happy with the end result. I learnt a lot along the way and I’ll talk about it down below.

Jetpack Compose is mature

What I mean by that is the fact that you can do everything you can do with the old UiToolkit. At least they provide the building blocks for that.
If your app use the Material Design UI system, you just need to add the appropriate dependencies and start using it.

You can also create your own design system. For the majority of us, we’ll never need to go that far.

Column/Row vs ConstrainLayout

Since they announced ConstraintLayout, I stopped using the other ViewGroups. It’s more flexible and powerful.
Using it on Compose was fun because instead of defining the constraint over XML, I can use my preferred programming language. I do not check if the api is complete, compared to his XML counterpart but it’s good enough to offer you the flexibility of positioning your composable where you want.
One of the main reason why android dev preferred ConstraintLayout is because you can build a flat hierarchy that is good for your app performance when you UI is complex. But With Compose, having multiple level of Composable is not an issue.

Note: In the View system, ConstraintLayout was the recommended way to create large and complex layouts, as a flat view hierarchy was better for performance than nested views are. However, this is not a concern in Compose, which is able to efficiently handle deep layout hierarchies.

Extracted from the documentation of ConstraintLayout.
So it’s more about preference than performance.
Using ConstraintLayout implies lot of verbosity compared to Row/Column/Box/

Using Row/Column can add nested Composables but you can easily extract Composable so this is also not a big deal.
So for me Row/Column for simple UIs and ConstraintLayout for complex ones.

Theming

This is so easy to handle now. You just need to understand a little bit about Material Design, understand the API(it’s Kotlin so you can discover everything if you know a bit how Jetbrains Tools works).
Adding Dark mode is just a matter of if/else and providing the correct color palette

You can build a color palette using utilities like lightColors() or darkColors() . You can use the dependency below for all things material

Image processing

We all know how easy it is to process a picture on Android using Glide or Picasso. Well, same thing with Composables.

Yes! It’s that simple. Just provide rememberCoilPainter() to your painter attribute. A painter is something that can be drawn like your picture.
On this example above I use Coil. An image loading library based on Kotlin Coroutines. But you can also use Glide.

Tooling

The tooling is one of the most important peace that will make Compose successful. It must build fast, the preview should be exactly what we will get on a real device. Well, It’s not done yet…
I encountered lot of bugs with android studio preview:

• The preview cannot render an Image composable( I saw that you need to use the correct tooling version otherwise it will not render. We are not supposed to handle that)
• The preview colors is not accurate on Android Studio
• Sometimes the rendering fails for random reasons

It’s not all bad. I like the color picker on the left side that generate kotlin code using the RGBA constructor of Color class.
You also have live Edit of literals. It works very well on real devices and on the emulators. It didn’t work when the data was stored on resources. Maybe they’ll handle this on the finale version of compose tooling 🙏🏾

I do not test animations and profiling Compose, so I cannot talk about that.

Code smell

If you checkout my tweet code you will see all the mess there 😂🤭. Composables all over the place. This can be really dirty. You should try to structure your Composables in a way that it easy to read. So do not abuse with nested code even if it is not a performance issue now. It’s more about readability and future maintenance.

I do not see a pattern emerging on how to structure your Composables. But some basics programming concepts are applicable here.

• Keep your Composables short. 50 to 100 lines. Like functions. The longer the harder to read and understand
• Make them reusable. That means stateless and unique purpose
• Use compose preview. So that developers understand at first glance the purpose of the Composable without reading the code
• Group them by feature or use cases. Don’t put them all in a composables.kt files.

You get it. Use your programming best practices for compose. It’s about functions so you know how to write them already 😊

Wrap up

Compose is great. You can be productive with this release candidate release.
We can be optimistic about the upcoming finale release. My expectation will not be too high because it is not easy to build a complete UI Toolkit with all the building blocks up and running. But I’m confident enough. At least for all things APIs but less for the tooling part.

soulesidibe/TweetCompose

Jetpack Compose le nouveau UIToolkit de Android