Image for post
Image for post
Picture by Alexas Fotos on Pexels

Paradigm shifts with declarative UI

Roberto Orgiu
Apr 27 · 4 min read

Declarative UI is not a new concept in the development world, but it’s lately gaining momentum on mobile native SDK, probably after a few other cross-platform frameworks started exploring these approaches. Learning how to use them implies changing the way we imagined layouts, and overall graphical user interfaces, for the past years.

As SwiftUI approaches on iOS, Jetpack Compose is being built in the open for the Android ecosystem.

At the time of writing, Jetpack Compose is still being heavily developed, and many things change by the day.

I wanted to give Compose a try and use it to create a small app that, given the Lego set number, will retrieve the basic information of such a kit: a picture, the title, and the link to the instructions.

Image for post
Image for post

Overview of the functionalities

As a developer, it’s pretty easy to highlight the main points in the aforementioned example:

Inside the comfort zone

Being familiar with the Android ecosystem, I pointed myself in the direction of using a whole bunch of well-known libraries to help me get the job done, and those include RecyclerView, Retrofit, KotlinX Serialization, Picasso, and Dagger.

The use of a dependency injection framework such as Dagger might seem overkill for such a small app, but in a real project, it should be the go-to for building your objects. In this case, using such an articulate framework that involves the use of kapt could cause a conflict with the Kotlin plugin needed for Compose, so I decided to put both into the mix and see what happened.

The important bit is the use of Picasso (or any other image downloading tool): we normally would call it as close as possible to the view layer, as each of these libraries works best with a reference to the View where the image will be downloaded.

The new way(?)

As of today, there is no easy way to provide an image asynchronously with Compose. It is certainly being worked on (as we can understand by the comment left in the code, at least for what concerns loading from resources), but it’s not present in the SDK just yet:

Image for post
Image for post
A screenshot showing the comment in the documentation

In an ideal world, I would expect to tell an Image where to fetch its content from and it would automatically show it for me, but it is not yet the case. It wasn’t until now, and it’s certainly not yet the case.

So, I decided to try something different, that could be easily replicable again. Instead of passing down the URL, I would wrap the Picasso call inside a coroutine and download the images before I send the model to the UI, right after the API call:

The good, the bad, and the ugly

While this solution works (good), it is a feasible procedure only when we know that the amount of images we are downloading is fairly limited (bad), and it is overall a bad practice (ugly): we don’t want to fetch more data than the amount our users will see, and we certainly would prefer to download the images in a separate chain.

One more thing…

Another thing that hit me (in a positive manner indeed!) is the fact that Composable components do not manage the state: as of now, every change to the state should be managed from a specific object, that should be tied to the Composable. Let’s see an example:

The important part is related to line 6: if we removed the onValueChange parameter as a whole, we wouldn’t be able to either see what was being typed inside the text field. This is, in my opinion, a huge leap forward: with the current approach, it’s never clear where and when the state of a Widget is saved and updated. Managing the state of a View is no easy task, but the path drawn by declarative UI frameworks will make developing graphical interfaces easier and less chaotic in the long run.


It is an easy solution (most certainly there are other ways to perform the same task on the web) to a problem that I was facing, and it made me realize that declarative UIs, such as Compose, are bringing a shift in the way we shape our code, and this is something to keep in mind.

Furthermore, with this approach, we are certainly closer to the real idea of a ViewModel compared to what we do now, but I’m sure this is only one of the millions of small changes that this new wave of UI frameworks.

Thanks to Daniele Bonaldo, Fabio Collini, and Florina Muntenescu for proofreading this post.

Google Developers Experts

Experts on various Google products talking tech.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store