Discovering Jetpack Compose: key takeaways from my first project

Yoann Delouis
Nov 25, 2020 · 6 min read

Jetpack Compose has been released as alpha a few weeks ago, now. I took some time to experiment a bit with it in my side project: a custom launcher. In this article, I share my small experience with it.

Getting onboarded

To discover the framework and how it works, I followed the Jetpack compose pathway from Google. It’s an ordered list of videos, articles and codelabs that help to discover and learn what Compose is, what we can do with it and how to use it. The pathway starts with simple things (creating a simple UI) and ends with more advanced things (custom layouts, theming, managing states).

Jetpack compose is very well introduced and I liked the diversity of format: videos, articles and codelabs. If you’re looking to get started quickly with JetPack Compose, I’d say the three videos are enough without going through the codelabs & articles as well. The more so as if you are familiar with this UI paradigm, which is similar to the one used by Flutter. Codelabs and articles focus on some parts of the videos and explain them more in detail and at your own pace.

Also, you’ll need to download Android Studio 4.2, which is a canary version for now, in order to access the preview of your “views” in Android Studio. Then, you won’t need to assemble and launch the app, building the module is enough to see what the “view” will look like.

Image for post
Image for post
Preview of Compose functions inside Android Studio

Enjoy the power of Kotlin everywhere

Jetpack Compose is written for Kotlin, and all you’ll have to write is Kotlin code. You no longer have to write xml layout files. This has some advantages :

  • Code related to views is no longer scattered in Kotlin and XML files nor in different folders (src/main/kotlin, src/main/res/layout, src/main/res/anim, etc.). So UI code is easier and faster to explore, read and write.

Advantages of the declarative UI paradigm

Jetpack compose embraces the declarative UI paradigm. Which means that all you have to do is to declare how the UI looks like at the current state, and the framework will take care of updating the UI for you. When I tested Flutter some years ago, I really liked this paradigm. I found the learning curve not so hard, and it has some advantages over the current way of coding UI for Android :

  • Less code. With Jetpack compose, the UI is redeclared (or recomposed) each time the UI state changes. So, you declare views only if they are shown, and you don’t have to change their state afterward. You only create them with the current state. View creation, initialization and binding are all in the same function.

Simpler view API

On Android, all views are subclasses of View. This class is really complex and deals with so many things such as margin, padding, background and foreground drawables, state, touch, click, scroll, focus, accessibility, autofill, visibility, rotation, etc… (Did you know that `View.java` file is 30,000 lines long ?! That’s why I can’t enumerate all things dealt by View). And all those things can be overridden by subclasses.

This makes the API hard to discover and understand. And leads to some behavior inconsistencies you have to be aware of to master the API.

With Jetpack Compose, @Composable functions are focused on only one responsibility. That makes UI components simple to learn and maintain. And they are still customizable thanks to the parameters of those functions which can be regular data values (Boolean, String, ImageAsset, etc.), functions, or a Modifier.

Function parameters enable us to easily declare inner parts of a component by passing another @Composable function. They are also useful to define listeners to some events.

Modifier is a set of attributes associated with a @Composable function used to customize the appearance and behavior of a component in a way that can be common to all components. It enables to avoid having components from inheriting a common class (composition over inheritance). For instance, a modifier can add padding, a background, a clickable behavior, information about the sizing of the view, etc. Modifier API can vary depending on the layout of parents, thanks to extension functions. So, it’s quite flexible while keeping only one entry point for all those customizations.

Lack of docs and community support

  • At the moment, all the documentation we have to learn Jetpack Compose is the pathway, some samples and the API reference and its kotlin doc. The pathway covers basic things and a few advanced things. The API reference is quite well documented for an alpha project. I didn’t browse all the samples, but when I wanted to implement something similar to what I saw in a screenshot of a sample, the feature was marked as TODO in the code. So, you have to be ready to explore by yourself

So, there are some things that I didn’t manage to do (but also didn’t investigate so much) :

  • Adding some animations :
    - when pressing and releasing a view
    - when making view appear and disappear
Image for post
Image for post
When trying to get some answers about Jetpack Compose

Poor tooling integration

  • As Jetpack Compose uses an AndroidComposeView to render all its content, LayoutInspector brings no useful information about the hierarchy.

Conclusion

My small experiment with Jetpack Compose confirmed that I really like the Declarative UI paradigm and I find the Modifier API more convenient than the Flutter API, because it helps to keep the “view” hierarchy smaller.

But it’s too early to introduce it into a production app, because even if the API might have reached a quite stable stage, the documentation and community support are still too poor.

I’ll keep exploring it and playing with it to know if I can make the UI as good as I could with the current View framework.

And I encourage you to give it a try, the more so as if you haven’t used any framework using this paradigm yet (Flutter for instance).

360Learning Engineering

Coding the future of Collaborative Learning and sharing what we learn.

Thanks to Yevhenii Kanivets and Liam Boogar-Azoulay

Yoann Delouis

Written by

360Learning Engineering

In this blog, the 360Learning Engineering team shares lessons learned from building the future of Collaborative Learning.

Yoann Delouis

Written by

360Learning Engineering

In this blog, the 360Learning Engineering team shares lessons learned from building the future of Collaborative Learning.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store