The July release of Android Jetpack Compose has some improvements and it is faster, but is it what we want?

A recent question on a news forum asked "Why is Android development so complicated"? The answer is very obvious -  "Because it has no clear leadership". This is very clear from the way that we are being urged to adopt Jetpack Compose and all things declarative.

The latest features are all about geewiz effects such as the new shared element transition. This allows the same content to be displayed in different composables. The description of how this works leaves much to be desired. You basically have to trust the magic under the hood. The same thing goes for the new lazy list animations which let you accept an animation of items being added and removed from the list.

Compose is also spreading. Compose for TV 1.0.0 is now in beta and Compose for Wear OS is moving from beta to stable. We also have version 1.1 of Glance, a framework for building widgets. The final good news is that Compose is now 17% faster at an initial render. 

This is all great - I like and admire the design of Jetpack Compose. It is very clever and it makes good use of Kotlin's language features. But we need to keep in mind that we are building a UI. There is a long tradition of UIs having easy-to-use drag-and-drop designers - Swing, XAML, Windows Forms and the traditional XML-based Android UI. This made it easy to put together a UI and then get someone else to tweak it.

Jetpack Compose on the other hand has some good tools to tweak and polish a UI, but no drag-and-drop designer on the horizon. Tools such as preview and live changes help but do you really want to specify the position and size of everything in pixels? Or build a hierarchy of components by writing code? Personally, I regard UI construction as a dull and boring task made more boring by having to specify it in code.

The craziest example of this move to declarative is to be found in the compose approach to the constraint layout manager. This was the pinnacle of XML UI development and it promised to make handling different size screens easier. In practice, it was very difficult to get right and without the help of an interactive graphical editor it would be much harder. Now we are supposed to hand code the constraints in a declarative way - a nearly impossible task.

Do we need a drag-and-drop editor for Jetpack Compose? Yes, yes and yes, if only to avoid the advice I found on a recent Android blog:

"We shared an exciting live demo from the Developer Keynote at Google I/O 2024 where Gemini transformed a wireframe sketch of an app's UI into Jetpack Compose code, directly within Android Studio."

So let me get this right - the Android team don't think we need a drag-and-drop editor, but they do think that showing a drawing to an AI and getting it to generate the code is desirable? Maybe I'm out of touch, but is replacing a simple reliable tool with a hallucinating, hugely expensive, AI really the way things are going?

Jetpack Compose is a cleverly designed and efficient UI framework. It just needs better and more appropriate tooling as not everyone is an expert.

More Information

What’s new in Jetpack Compose at I/O ‘24

3 fun experiments to try for your next Android app, using Google AI Studio

Related Articles

Jetpack Compose Improves Performance

Android Jetpack Wear OS Libraries Now Stable

Android Jetpack Confusion As V1 Approaches

Google Jetpack Compose UI Toolkit Now In Beta

Android Jetpack Compose Is Welcome, But What About The Churn?

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info