Picture by Alexas Fotos on Pexels

Paradigm shifts with declarative UI

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.

Overview of the functionalities

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

  • A network request is needed to fetch the data from the web
  • The backend will most probably return a link to the image so that it has to be downloaded later
  • Data should be displayed on a list

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:

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.

Conclusion

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.

Experts on various Google products talking tech.

Recommended from Medium

Trustworthy way to get location on android

An Introduction to Custom Views on Android — Part 1

Displaying Images in Android Studio using Activity Result APIs in Kotlin

Permissions given to app in Manifest file

Android Hacking Fundamentals -Part-2

Creating a List easily using Android’s ViewBinding, RecyclerView, and DiffUtil

Difference between activity and fragment android

Handling AccessToken — Repository Pattern (Kotlin): Part I

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
Roberto Orgiu

Roberto Orgiu

Android developer and GDE for Android

More from Medium

Sending View Model Events to the UI

Migrating an Existing App to Jetpack Compose: Where to begin?

Swipe to delete in Jetpack Compose Lazy Column Android

Introduction to Jetpack Compose - 2