A while ago, Google announced Jetpack Compose, a new way of writing UI code for Android. This framework is currently being developed with heavy collaboration with Jetbrains, the folks behind Kotlin and Android Studio. But why? Why would Google need to team up with Jetbrains for an Android specific, UI library? Well, it’s not just a UI library, and that’s what makes it so exciting.
Currently in Alpha development, Compose has been actively worked on for a few years now, and if you’re at all familiar with iOS, seems to be the counterpart to SwiftUI. The intricacies with Compose, such as why a Kotlin compiler plugin is required, how and when it draws a view, etc, aren’t in scope for this post. For the first time in what seems like forever, a library is being developed that will work on Android that seems great. A lot of recent Google libraries come out half-baked – a great idea, with huge momentum at the beginning, only to whittle away into some grotesque caricature of its former self, with poor API design and a destiny for deprecation. Something basically useless. But Compose is different. Perhaps it’s because Jetbrains are also working on it to keep Google on their toes, but Compose is the first library developed by Google that has excited me in a long time. Though through talking to people, it seems the reason why isn’t very clear yet. So let’s go over why.
Android has always had XML UI code, and has been fantastic in comparison to the laughable generated code that you get with xibs and storyboards with Xcode. So if XML UI code is already good, why use Compose? Here lays the first common mis-understanding of Compose – it’s not just a different way of writing UI code, but a change in thinking about how UI code reacts to a new piece of data.
Let’s imagine a simple UI for the sake of example. Some detail page, which has a loading state, an error state, and the success state. With the current approach, when using MVVM, your ViewModel would output the current state, and then you’d manually show/hide each view depending on that state. The XML code would have all three views – whether they be included layouts, or all in one file. With Compose, you need to think of this problem in a different way. You don’t have to manually manage which views should be shown/hidden in the previous example, and instead you describe what should happen for a given state. If the output is loading, invoke the Loading() composable. If it’s success, invoke the Success() composable, etc. Then, Compose decides when to redraw/re-compute that view. This has many benefits, including, but not limited to, not having to maintain certain state, race condition issues that would exist with the previous method, delegation of drawing to the framework instead of doing it yourself, etc.
If there’s anything to take away here, let it be this: Compose is a way for you to describe how your UI should look for a given state, where that state is a piece of data.
In addition to this paradigm shift, you also having:
– Themes
– Modularization of Compose
– Colors
– Fonts
– Navigation
– Heavy use of Kotlin syntax
– Open source code
A lot of these are huge pain points with Android development, where the default method of theming in Android is laughably inexcusable in its difficulty; navigation – provided by Google!! – doesn’t even work well with Google’s desire for tabbed applications. Fragments and Activities and the verbosity of their lifecycle.
For me, at this point in its development, this is far from just a UI library. This is the shift in direction that Android development has needed for years, and is finally becoming a reality.
JORDAN DIXON 