Why do we need Jetpack Compose?
There has been much excitement in the Android community since the announcement of Jetpack Compose at Google I/O 2019, with a vast number of blog articles, talks, and sample apps advocating for this new approach to developing user interfaces on the Android platform. This article aims to take a step back and look at the bigger picture to answer the question — why do we need Jetpack Compose? It does not aim to teach how to use Jetpack Compose but will give a list of recommended resources at the end of the article.
What is — the current state of the Android UI toolkit
Let’s start by thinking about the current state of the Android UI toolkit — the “what is”. This reflects how Android developers are creating their user interfaces every day, and I’ll be highlighting some of the pain points that these developers are experiencing on a day-to-day basis.
Pain point #1: A different world from 10 years ago
When the Android UI toolkit was first created, the world looked very different from what it does today. Devices considered high-end then are almost comically primitive today. They were clunky, with much lower processing power, very limited memory and storage space, and low-resolution displays. Android users had much lower expectations of their apps — they were satisfied with minimal interfaces with simple controls and animations. Android developers had a more primitive toolbox of languages, paradigms, and tools to work with.
However, ten years later, this is no longer the case. Devices are more sophisticated, capable of creating delightful and immersive experiences, and users expect that from their apps. So it follows that Android developers both need and prefer more powerful languages, paradigms, and tools to keep up with the demands of their users.
Pain point #2: APIs are showing signs of ageing
With time, all APIs start showing the signs of ageing. Popular programming concepts of ten years ago have been refined and new paradigms have come to the fore. For example, the Android UI toolkit is heavily based on the inheritance concept of object-oriented programming, but even that classical concept is less prominent now.
And as APIs evolve, they accumulate what can be called code cruft, like the anecdotal View class with its thirty thousand lines of code. And while it may be possible to clean up some of the cruft, there’s always the danger of breaking something, somewhere that relied on that little piece of cruft.
Pain point #3: UI toolkit bundled with Operating System
The Android UI toolkit team are actively enhancing the current way of building user interfaces and fixing bugs. However, since some of the UI toolkit is bundled with the operating system, developers are heavily dependent on device manufacturers to roll out the latest versions of the operating system to the end-user. This takes some time if indeed it happens.
The only solution is to unbundle the UI toolkit from the operating system in a support library.
Pain point #4: Not very Kotlin-ey
When the Android UI toolkit was first introduced, Java and XML were some of the most popular and powerful languages. But when Kotlin became a first-class language for the Android platform, developers discovered Kotlin’s more modern and powerful features and very quickly began migrating their apps. However, the way they developed their user interfaces remained mostly the same — far from the beautiful and idiomatic Kotlin code of the rest of their apps.
Pain point #5: Material Design introduced later (2014)
Design systems like Material Design weren’t around ten years ago. User interfaces were very primitive, with little or no thought put into following design or user experience principles. The fields of design and development were yet to start collaborating, and very often the developer *was* the designer and put together the user interface as best they knew how.
However, the fields of UX/UI design and development are now expected to collaborate to create a delightful user experience. But nothing is more disappointing for designers to discover that their designs are not possible, too tricky or time-consuming with the current implementation of the toolkit.
The only way to incorporate Material Design is with the Material Design Components — which is still in development.
But — there is hope!
What can be — the future state of the Android UI toolkit
Let’s now have a look of the future state of the Android UI toolkit — the “what can be”. This reflects how Android developers will be creating their user interfaces someday in the future with Jetpack Compose, and I’ll be highlighting the wonderful benefits of this addition to the Android platform.
Benefit #1: Modern languages, paradigms, and tools
Jetpack Compose is written in Kotlin, for Kotlin. No longer are some parts written in Java or Kotlin, and some parts in XML. Instead, everything is Kotlin. We can take advantage of all the benefits of idiomatic Kotlin no matter what part of the app we’re writing. That means modern language features, paradigms like functional programming, conciseness, readability — phew! You get the point.
Jetpack Compose also learnt from other frameworks and platforms like React, Vue.js, and Flutter on creating composable user interfaces. In these frameworks, user interfaces are broken up into small components, where state flows down from larger, parent components and events bubble up from the smaller, child components. In Jetpack Compose, these components are called composable functions.
But the Android UI toolkit team also knows that they need to provide the tools we need to build in this new world. So Android Studio is being built in lockstep with Jetpack Compose to support Android developers in creating their user interfaces.
Benefit #2: Single source of truth
It is not always evident in the current Android UI toolkit what the single source of truth is. For example, if I have a checkbox allowing the user to connect to the internet, what ensures that the state of the control matches reality? It would seem that the checkbox is the source of truth because when the user clicks it, actions are taken to connect. But if the connection fails, should the checkbox know to uncheck itself? It’s quite confusing!
But in Jetpack Compose, it’s simple and much less buggy. You own the state, and you pass the state into the composable so that it can observe the state and update itself accordingly. When an event occurs, nothing in the composable changes, and it passes the event to you. The responsibility for updating the state is yours.
Benefit #3: Efficient and performant
The team building Jetpack Compose have carefully studied how user interfaces work, optimising for the common scenarios. They are using data structures and algorithms specifically geared towards making the composition and recomposition of composable as efficient and performant as possible.
Benefit #4: Material Design from the start
Jetpack Compose supports Material Design theming and components and animations from the start, allowing developers to focus on creating beautiful user interfaces that much quicker.
However, because everything in Jetpack Compose is either configurable or composable, designs that were difficult to create before, are suddenly easy. I’m sure that in future, we’ll start seeing rich libraries of composable that can be used to create even more delightful experiences using Jetpack Compose.
Benefit #5: Compatible with existing UI hierarchies
You might be wondering: am I going to have to rewrite all my layouts to start using Jetpack Compose? The answer is a resounding NO. Composable functions become usable directly in XML layouts using an annotation so that you can migrate to Jetpack Compose incrementally.
However, at the time of writing, Jetpack Compose is still in pre-alpha and not recommended for use in production. But hopefully, this article has fueled your excitement for this wonderful addition to the Jetpack family. If you have the time, I would recommend working through the following resources and trying your hand at writing a sample app. However, note that sometimes features discussed are either out-of-date or not yet implemented in the resources, with the exception of the JetNews sample app, which seems to be the most up-to-date.
Recommended resources
Sample apps:
JetNews from Google: https://github.com/android/compose-samples/tree/master/JetNews
Talks:
- The Compose Runtime, Demystified by Leland Richardson at Kotlinconf 2019: https://www.youtube.com/watch?v=6BRlI5zfCCk
- Compose Yourself: Designing a Kotlin First UI Toolkit by Anna-Chiara & Clara at Kotlinconf 2019: https://www.youtube.com/watch?v=WqnR_XhEiVI
- Understanding Compose by Leland Richardson at Android Dev Summit 2019: https://www.youtube.com/watch?v=Q9MtlmmN4Q0
Blog series:
- Exploring Jetpack Compose by Joe Birch: https://joebirch.co/exploring-jetpack-compose/ It is also my understanding that Joe is writing a book on Jetpack Compose.
Other:
- Kotlinlang Slack — channel #compose
- Jetpack Compose by Example by Vinay Gaba — https://github.com/vinaygaba/Learn-Jetpack-Compose-By-Example
