Learning Android Development
Jetpack Compose: The Future of Android UI
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.
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.
How Android Access View Item: The Past to the Future
The evolution Android Development on accessing view
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.
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! 🤩
Jetpack Compose — Before and after
How the build speed, APK size and source line count changed after migrating the Tivi sample app to Jetpack Compose
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.
Understanding Live Data made simple
LiveData is one of the major component of Architecture Components. Let’s learn about it more in-depth with simple…
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.
Year 2020: Migrating from Activity to ViewModel
For a span of 10 years, 2007 till 2017, Android development revolves around Activity/Fragment as the heart of its…
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.
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.
Jetpack Compose… is there to stay and grow
It is clear to me that with the birth of Jetpack Compose
- Google has managed to eliminate the XML proprietary approach of development, which has so many limitations that Google tried to solve in the past
- A much clearer architecture of UI vs Logic is introduced, in line with the Architecture Component that Google has come up with, and free up Activity from all the UI burden.
- It is now adopting an industrial standard of UI development paradigm. It can now get more development communities i.e the Web UI Community, to join the fun of development in Android as well.
As long as Google is able to deliver a stable release of Jetpack Compose for production, there’s no doubt this will be the future of Android Development.
Bonus point, one will not need to worry about should I use Fragment or Activity anymore. Fragment might be gone too 😜