Jetpack Compose: Basic concepts you need to know

“API Design is building future regret.” — Chet Haase

UI development should be easy. Developers shouldn’t spend most of their time building and fixing UI issues but rather focus on other important business logic. After all these years, Google has also understood this pain point of developers and has come up with a new UI toolkit.

Jetpack Compose is a next-generation UI toolkit for building native android UI. It’s entirely written in Kotlin and helps in building high-quality android applications easily and quickly. Google has been working on Jetpack Compose as an open-source project since 2019 and at the time of writing this post, it’s in beta. Now let’s discuss why we need a new toolkit in the first place.

1. There was a need to change the way we develop UI and use the Android UI toolkit.

Image from Google IO 2019

The above image shows the history of android releases over the last 12 years. Even though Google has added many features along the way like ART, Recycler View, Arch Components etc., they have never changed the UI toolkit itself fundamentally. So a need to change the UI toolkit was always lurking around the corner.

2. Developer community most asked demand from Google regarding UI toolkit was “Unbundle the UI toolkit”

The current UI toolkit is bundled with Android SDK and released every year. If developers need any new feature to be added or bugs to be fixed in the UI toolkit, they need to wait for at least a year before it reaches the customers.

3. Android Views are mutable

Currently, we can access UI elements(views) in our activity/fragment code using findViewById and change the state/behaviour of those views. This mutability of view can sometimes create hidden bugs when our UI is being updated from multiple places. We can forget to update the view in some particular scenario creating an inconsistent UI state.

These are just some of the main issues which come to my mind. There are some more issues that really makes us rethink the current approach of building UI. Can we do better?

Jetpack Compose to Rescue

Jetpack Compose solves all the above-mentioned issues with the current UI toolkit and makes the developer’s life easier. Compose makes it easier to write and maintain your app UI by providing a declarative API that allows you to render your app UI without imperatively mutating views.

Historically, an Android view hierarchy has been representable as a tree of UI widgets. As the state of the app changes because of things like user interactions, the UI hierarchy needs to be updated to display the current data. Manipulating views manually increases the likelihood of errors. If a piece of data is rendered in multiple places, it’s easy to forget to update one of the views that shows it. It’s also easy to create illegal states, when two updates conflict in an unexpected way. Over the last several years, the entire industry has started shifting to a declarative UI model, which greatly simplifies the engineering associated with building and updating user interfaces. The technique works by conceptually regenerating the entire screen from scratch, then applying only the necessary changes.

Let’s get started with Compose and see how a simple compose UI looks like. Try downloading the latest Android Studio (at least Arctic Fox (2020.3.1)) as it comes with the default compose activity template as you can see below.

Let’s try to understand the default files generated by this empty compose activity template. We have ui.theme package which contains colors, themes and shapes information and we have MainActivity.kt which is our empty compose activity. The interesting thing to note in MainActivity.kt is @Composable annotated methods.

A simple composable function that is passed data and uses to render a text widget on the screen

Let’s understand some important things about this special @Composable function.

• This annotation informs the Compose compiler that this function is intended to convert data into UI.
• The function takes in data. Composable functions can accept parameters, which allow the app logic to describe the UI. In this case, our widget accepts a String so it can greet the user by name.
• The function doesn’t return anything. Compose functions that emit UI does not need to return anything because they describe the desired screen state instead of constructing UI widgets. This is a very important feature that makes these emitted elements immutable in nature.
• In general, we should always remember to not use any global variable or state in @Composable functions to avoid any side-effects when called multiple times.

There is one more important concept we have to learn about compose which is Recomposition. In an imperative UI model, to change a widget, you call a setter on the widget to change its internal state. In Compose, you call the composable function again with new data. Doing so causes the function to be recomposed — the widgets emitted by the function are redrawn, if necessary, with new data. The Compose framework can intelligently recompose only the components that changed.

A paradigm shift in UI building is coming and we can only delay it in adopting but can’t really avoid it. Although the existing UI toolkit is not going anywhere in near future, Google is going to focus more n more on the Compose and we will be seeing lots of improvement and feature addition in this area. Stay tuned and Happy Composing!