Jetpack Compose: the future of Android UI
Tags: Android, Android App Development, Mobile App Development, Google, Programming

Learning Android Development

Jetpack Compose: The Future of Android UI

Android has come a long way and Jetpack Compose is there to grow

Photo by Tomasz Frankowski on Unsplash

Recently, I looked into how Android has progressed in how the code interacts with the UI (View) over the years. Much has been happening the last few years… and finally, it is landing with Jetpack Composes.

Of course, the question arises — is this just hype or is it to stay? Should one start learning it, or just wait for the next real messiah?

My view is, even if Jetpack Compose might not be the final way of how Android interacts with the UI, it will definitely be the path moving forward.

Here’s why…

Making XML working with code has never been perfect.

Since day one, XML is the way for one to define the UI of the App.

The little infamous findViewById where every iteration tries to get rid of using it, starting with ButterKnife, then Kotlin Synthetics, and DataBinding, and then ViewBinding of late.

Things have improved over the years, but there’s still imperfection in using the XML approach. The UI logic works best using Kotlin than the XML, hence making two separate UI entity that Google still try hard to reconcile them.

There’s even a try to move the Modal from the Code into XML in the DataBinding feature.

Conventional View Update, where modal is in the code

Data Binding Update where modal is in the XML instead

Still then too much code boilerplate for the support. Moving more things into XML is not desirable.

XML + Code will never be perfect.

Jetpack Compose, on the other hand, removes the need for XML and replaces it with complete Kotlin Code for the UI.

Now, with Jetpack Compose the UI Code and logic can stay within itself, cleanly separate from other parts of logic.

And recently, Chris Banes had explored converting an App from XML to fully Jetpack Compose, it shows improvement both in APK file size and the build time! 🤩

The Architecture Dilemma: Is Activity a View or Not?

When Android was firstly introduced, there was no architecture recommended by Google. Some people coded everything in the Activity. This is bad, as it makes the code spaghetti.

The community itself evolves and MVP (Model View Presenter) becomes the more commonly practiced approach.

Still then, it is very confusing on what an Activity is.

Activity is viewed as the View, as it linked directly to the View (XML) and contains the UI logic sometimes).

Activity is aware of the Live-Cycle, seems like the center of control of everything. (while ideally, the presenter should be more in control)

To address this issue, in 2017, Google came up with Architecture Component. This is great as Google now provides a framework it strongly supports, the MVVM (Model-View-ViewModel) framework.

In it, one of the most important bits (other than the ViewModel) is the LiveData and Live-Cycle Aware Component. This started to shift some of the life-cycle awareness from the Activity to the ViewModel.

Nonetheless, it is still imperfect, as Activity still holds the key for State Restoration and Dependencies Injection.

Beginning 2020, both State Restoration and Dependencies Injection issue mentioned above is handled through SaveStateHandle and Dagger Hilt.

It is clear that Google is trying to move the core of development from Activity to the ViewModel.

Nonetheless, the Activity is still there to tie with the XML UI. Some part of UI logic still resides within the Activity.

In order to totally eliminate the need for Activity to manage any UI code anymore, and just be a conduit, Jetpack Compose is introduced.

All the UI code now resides within the Composable Functions. The ViewModel and Activity no longer need to access the individual UI element to be updated.

It just needs to update the State Variable and the UI will automatically get recomposed. To understand how recomposition works, check out the below.

Activity is now free from all UI logic as well as the need to access the specific UI element to be updated. It just needs to be a conduit between the ViewModel and the Composable Functions.

Declarative UI: The industrial trend across web and app

Declarative UI is not a new thing that Android Jetpack Compose just introduced. In fact, Android native are coming in relatively late in the game.

In the web world, React programming has long existed and is relatively welcome and popular. The App world tries to imitate the success, where we have React Native introduced by Facebook and recently Flutter by Google.

These have reached some level of success, due are crippled at times due to their attempt to support both the iOS and Android world in one goal. Nonetheless, it is still relatively popular and the pursuit to make them work in the app work is still ongoing.

There are many Web developer in the market that is already familiar with the framework. This will make such a development framework easily expanded to a wider community

In the App world, for the iOS community, Storyboard based and InterfaceBuilder approach of UI programming in iOS is always debated. The code generated is unreadable, and hard to be peer-reviewed. There’s also a library called SnapKit to make UI code programming more feasible in Swift directly.

Without hesitation, Apple has first introduced its declarative UI, i.e. SwiftUI to its community, since iOS 13.0. Now they have gone production worthy, and we do see the trend is growing, with much excitement in the community.

Google has been quick to respond as well, in announcing Jetpack Compose way ahead of its readiness during Google IO 2019. Alpha was released, and Beta is now released. It looks clear that in 2021, it’s heading production worthy.

What I like about Jetpack Compose compared to SwiftUI is, it went down to the extent of the basic drawing API control from it. Using Jetpack Compose, I can program custom views such as a Drawing App, Simple Clock Animation, and even Flappy Bird Game.

Flappy Bird by Jetpack Compose

It looks really promising. It’s a proven working UI framework the industry has adopted in the web world, and the app world (both iOS and Android) is heading towards it. It is there to stay.