10 Reasons to Learn Jetpack Compose UI Now

Neil Davies
The Startup

--

Jetpack Compose has been in developer preview and now alpha for some time. It hasn’t reached a stable release yet and is still under heavy development from the people at Google. So why should you, as an Android developer, start learning it now? After all, views written in XML work fine.

Just to be clear, I’m not saying that you should use Compose in your production app just yet, but I definitely think now is a good time to learn it and start experimenting with how it can be used in your apps. If you have an existing project, create a branch and try reimplementing a few views in compose, or alternatively, just make a new playground project. Here I’ll give you ten good reasons why now is the time to start. Hopefully I can save you some time reading through a lot of articles and documentation, and watching a lot of YouTube presentations about Compose. I’ve done that for you! So let’s get to it, here are my top reasons to learn Jetpack Compose UI now:

1 - Creating your first Compose project is easy

Creating your first Jetpack Compose project is surprisingly easy. Just download the latest Canary version of Android studio and select a new Compose project from the list of possible Android projects.

Android Studio has a template for quickly creating a Compose project

To start you’ll have a simple “Hello world!” Text composable. Yes it’s basic, but 5 minutes isn’t bad to have your first Compose app up and running.

2 - There are lots of good resources for learning Jetpack Compose

So you’ve got your first project up and running in AS, but now what do you do? Fortunately there’s already a wide variety of tutorials and workshops to help you get up to speed. Start with the official Android Jetpack Compose basic tutorial. This will take you through the basics of layout components such as Column and Row and also show you how to add images and text to your Compose UI. Once you’ve got the basics, check out this Android course which contains a video and codelabs to help you get up to speed with Compose.

Of course this is just the start, there are lots more resources on Jetpack Compose once you start searching on the web.

3 - Android Studio already has great support for creating Compose UIs

With the latest Canary version of Android Studio, you can create Compose apps. To make things easier, the Canary versions also have a great preview feature that allows you to see how your UI looks before deploying it to a device.

Android Studio showing a preview of a Compose UI

Using the @Preview annotation, you can see what your UI will look like in the preview window. Since the @Preview annotation supports passing arguments, you can also see multiple previews at once showing different variations, such as how the UI would look for light and dark themes or on different sizes and types of devices.

But if you still want to see how your UI looks on a device or emulator, it is also possible to deploy just the preview to a device — that’s just the preview not the whole app.

Lastly, Android Studio also provides an interactive mode. This allows you to interact with the UI in the AS preview. While in interactive mode you can click or type on UI components and they will respond as if installed on a device. For more information check out the official documentation on previews in Android Studio.

4 - Compose already has a fully featured set of components

Although Compose is still in alpha, it already has a fully featured set of material components and layouts that can be used to create rich and complex UIs. From simple layout components such as Row and Column, to the more complex Constraint layout, there’s plenty of ways to construct your UI. For components, we have everything from simple Text and Button composables to more complex TextFields that allow you to build forms for your UI. If you still need some inspiration on what can be achieved with Compose, there are some great examples in the Jetpack Compose sample apps. Here you can see that there’s not much you can’t do with Compose that is achievable with existing views.

5 - No more recycler views

In Android we started with ListViews and then progressed to RecyclerViews, which were seen as a big step forward when dealing with large sets of data that need to be rendered onto a device. As the name implies, views are recycled to be used on the screen to display large sets of data. This is a great way to efficiently use views and make sure that the UI remains responsive. While RecyclerViews did this job very well, they were not without their drawbacks. There was a learning curve to using them. Concepts such as Adapters and View models had to be understood, plus there was not an insignificant amount of boilerplate code that had to be written to implement these components. With Compose, the implementation of vertical lists or horizontal carousels that can recycle their composable components in each item is incredibly easy, there are just two components that are needed — LazyColumn and LazyRow. To implement a lazy row we just do:

Using LazyRow to create a row of car composables

As you can see, this is much simpler than any solution that involves a recycler view. All we are doing here is calling the items function on LazyListScope and passing in a list of cars. Each car is then passed to the CarComposable that is then added to the row.

For examples on how to use LazyColumn and LazyRow, take a look at the sample code here.

6 - Compose works with legacy code

If you want to try out Compose in an existing app, then the last thing you want to contemplate is rewriting the whole of your UI, which could be a major undertaking. Fortunately, compose supports integration into legacy code in a number of ways.

Firstly, if you want to migrate a whole screen to Compose, this can be easily done by calling the setContent method in your Activity or Fragment and passing your composable:

Using setContent to apply a Compose UI

Now your whole UI for this screen can be implemented in Compose. This is great if you want to migrate a feature in your app to use Compose. But what if you don’t want to migrate the whole of the screen? Luckily Compose also supports adding a composable to an existing view hierarchy. To do this we can add a ComposeView to our xml. Just add the Compose view into the xml like this:

Using ComposeView to add a Compose UI to an existing View hierarchy

Now in the Activity we can call setContent on this view to apply our composable to this area of our UI:

Applying a composable to the Compose view declared in our XML

Lastly, you may also want to use a View in your composable hierarchy. This can be useful when we need to use views that don’t have an equivalent composable, such as a map view. Here you can use the AndroidView composable to provide these legacy views in your composable UI.

By using these techniques it can be relatively easy to try new implementations of your UI in Compose. Whether it’s just a small part of your UI or a whole screen, the options for integrating Compose gives you the flexibility to try it in the way that suits you best. For more information on integrating Compose with legacy code, check out this video here

7 - No more XML

If you are updating an existing app, you may have to deal with XML for a while yet, but with Compose, XML is not needed. While XML works well enough, there are a number of drawbacks with using it. Firstly, the fact that we need to be switching back and forth between XML and Kotlin while creating our apps is not entirely frictionless. Just being able to create your UI and the rest of your app in Kotlin really does make things feel a little more straightforward. But there are also a number of additional downsides to using XML.

XML itself is not a programming language and so this creates a number of compromises when using it. In XML the attributes and layout parameters are not type safe and, although Android Studio can help give the correct suggestions that are specific to a particular View, it is still possible to add irrelevant and redundant attributes. Since composables are written in Kotlin, we have the concept of scope and types. For example, this means that we simply cannot call a function on a Modifier if it is not applicable to the scope from which it is being called. Having proper scopes and types can be very helpful when we need to discover and understand what functions are available for a UI component.

It’s also been argued that XML layouts create a false separation of concerns. By using XML, we can have quite a lot of coupling between ViewModels and the layouts, especially when using function calls such as findViewByID which require knowledge of the UI hierarchy created from the XML.

Lastly, XML layouts are completely static. Once you have dynamic logic in the UI then XML layouts start becoming just what the layout looked like at one point in time. To change the layout at runtime, we need code that hooks into and changes the initial layout defined by the XML. So we end up writing glue code that allows the state of the UI to be updated. This is where a lot of bugs can be introduced. Compose allows you to write UI code that defines a UI that is valid for all states. The logic for dynamically changing the UI as a result of state changes is inherently part of composable functions, so there is now no artificial separation of initial UI state from the logic that drives the dynamic UI state. Also, because Compose uses the concept of a single source of truth for state, we do not have to write any of the complex error prone code to wire our view models to our UI, i.e., we have reduced coupling in our code.

For more background on why XML might not be the best solution for writing UIs, Leland Richardson has written some great articles on understanding Jetpack Compose.

8 - Simpler state management

If you’re already writing your apps using ViewModels and patterns like MVI, you’re off to a great start in simplifying the management of state in your app, but if you start using Compose you’ll be able to simplify it further.

With Android’s view hierarchy we have a tree of UI widgets. To apply our state to this hierarchy we have to use functions like findViewById to obtain a reference to each individual view and then call methods such as setText or setImage etc. to update the UI. This wiring code between the state and the UI can be tedious and error prone to write, and has the potential to introduce bugs into the code.

In Jetpack Compose, we use an entirely different declarative component based approach. This means we describe our UI as functions that transform our data into a UI. The functions themselves have the logic to handle the state within them. So when the underlying data changes, the UI hierarchy is automatically recomposed to reflect the new UI state.

To help with the wiring of the state to UI, and the management of this unidirectional data flow, Compose has interfaces such as State. To use a LiveData in compose, we can create a State object using the observeAsState extension function. Once we pass this State into a composable, any change to the LiveData will cause a recomposition of the Compose tree and any changes to the state will be handled by each composable.

9 - It’s cross platform

Initially Jetpack Compose was developed for building Android UIs only, but recently there have been several initiatives to expand the platforms that are supported. JetBrains have started an open source project to develop a version of Compose for desktop devices. More recently, they have also been working on a demo project for the web as well. As a developer this means that you can now use your Compose skills across multiple platforms. Who knows which platforms might be supported in the near future? So if you already know Kotlin then Compose has to be the UI framework of choice, as the barrier to entry is low and the potential applications are growing quickly.

10 - It’s the future

Using declarative UI frameworks is a proven way to write concise, maintainable UI code with high coherence and low coupling, and there are already a number of competing successful technologies out there that use this approach. It makes writing UI code faster, easier and more fun, while also making the code simpler and easier to test.

Google is putting a huge amount of effort, developer time and resources into creating Compose. Their focus is very much on improving Compose and not maintaining and updating the older View based system. Additionally, other companies such as JetBrains are also actively developing versions for platforms such as desktop and possibly Web.

With its ease of use and potential to reach platforms outside of Android, Jetpack Compose really does look like a worthwhile technology. Importantly, a stable beta release doesn’t look too far away. By investing time and effort now you’ll be able to hit the ground running, and when the beta arrives, you’ll be creating production ready apps that will be faster to develop and easier to maintain.

--

--