Newsletter Issue #82

Published: 2021-09-14

This week, we look at the composable equivalent of theme overlays and how to implement a drop-down menu. We explore writing tests for in-progress Compose migrations and look at a syntax highlighter library. We even look at how donut holes relate to recomposition.

Plus, Doris Liu helps us make sense of all the types of animations in Compose UI. So. Many. Animations.

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Passing Identifiers to Viewmodels

Sometimes, we would like our viewmodels to get identifiers as constructor parameters. If you are using Navigation for Compose, SavedStateHandle support makes that fairly easy, as Google’s Ian Lake shows us in this week’s highlighted Stack Overflow question.

How Do We Implement Theme Overlays in Compose UI?

Arranging to override certain colors for certain portions of your app was sometimes a bit confusing with the classic View system. Compose UI makes it blissfully simple, as we see in this week’s Kotlinlang #compose Slack thread.

Composable Commentary

Posts, videos, and other new information related to Jetpack Compose!

Podcast: Compose Tooling

Google’s Diego Perez, Nicolas Roard, and Chris Sinco joined this episode of Android Developers Backstage to discuss how Android Studio is approaching Compose, including how code-based UIs required a new way of thinking for tools like the Layout Inspector.

Video: Animations - with Doris Liu

Ivan Morgillo and Sebastiano Poggi of “Code with the Italians” have another two-hour episode up, this one featuring Google’s Doris Liu, looking at the dizzying array of animation options in Compose UI and how to choose between them and apply them.

Testing Hybrid Jetpack Compose Apps

Annyce Davis wrote about writing tests for apps that are partway through a migration to Compose UI, with a bunch of fragments wrapping ComposeView widgets for displaying composables. Annyce covers how to test this case, when your app is using Jetpack Navigation… but not Navigation for Compose, since the navigation is between fragments, not composables.

Build Android DropdownMenu in Jetpack Compose

Siva Ganesh Kantamani is back, this time looking at how to build a ComposeMenu() to handle scenarios in your UI where you might have used Spinner with the classic View system. ComposeMenu(), in turn, uses the DropdownMenu() from Compose Material.

What is “donut-hole skipping” in Jetpack Compose?

One of the perpetual mysteries of Compose is “when do things gets recomposed?”. Vinay Gaba takes a look at that, with a SideEffect()-based logging composable, to show that what gets recomposed might not be what you expect. And, yes, the explanation involves donuts.

Jetpack Compose Side-Effects II — rememberCoroutineScope

Udit Verma continues a tour of the effect API and related concerns. Previously Udit looked at LaunchedEffect() for coroutines — this time, Udit looks at rememberCoroutineScope() as another way to get a CoroutineScope tied to the lifecycle of your composable.

Emoji Slider in Jetpack Compose using Canvas API

Mohit Sharma created custom SeekBar-style composable, with emojis as the thumbs and showing a resized edition of the emoji while the user is dragging that thumb. In this post, Mohit shows, piece by piece, how to build up this UI, from rendering the emoji to processing the touch events.

Medium: Handling StatusBar colors when using ModalBottomSheets in Jetpack Compose.

Lorenzo Benevento ran into a problem: by default, when using ModalBottomSheetLayout(), the status bar’s color remains the same, even if the rest of your content gets grayed out due to the modality of the bottom sheet. Lorenzo was unhappy about this and elected to use Accompanist, some theme tweaks, and a few composables to address the concern.

Resource Roundup

100% pure code!

GitHub: Madrapps / plot

GitHub user Madrapps offers us a LineGraph() composable for rendering a line graph for multiple data sets. It includes a full set of gestures (e.g., zooming) and is fairly customizable.

GitHub: GerardPaligot / kighlighter

Gérard Paligot created a syntax highlighter based on Text() and AnnotatedString, and supporting both Compose for Android and JetBrains Compose for Desktop.

…And One More Thing

Once again, a couple of weeks ago, a reader asked in Kotlinlang Slack:

Moreover, is there a plan to make Jetpack Compose the primary view system for Android, or just an alternative?

This depends a lot on what one means by “the primary view system”. And, of course, it also depends on the definition of “a plan”, as Google famously tries to minimize any statements regarding future development.

If by “primary view system”, one means “the UI system that ships in the OS”, then no, Compose UI will not be replacing the View system. As I wrote in that Slack thread:

in the end, Compose UI is a very very very very complex custom View

ComposeView is not just a way to get a composable into an existing layout. It is also the underpinning of setContent() on a ComponentActivity. And ComposeView is “just” a View, albeit one with an absolutely massive set of functionality.

So, Compose UI needs the View system to work in Android, as the View system is the way to get to the screen. Between that, 13+ years of legacy code, and Compose’s status as a set of libraries, it is inconceivable that Android will somehow remove View and replace it with Compose UI in some future Android release (e.g., Android W).

If by “primary view system”, one means “the way that Google delivers new UI constructs to developers”, then probably that will be the case eventually. As Compose UI rises in popularity, some Google teams are going to elect to create new UI patterns as composables and either not bother with a View implementation or settle for using ComposeView as the way to bridge the two worlds. A major milestone, years away, will be if and when the Material Components for Android are considered to be frozen and all new Material Design work would be done as part of Compose Material or other composable libraries.

The person who started the Slack thread might have been considering “primary view system” to mean “how Google expects developers to create a UI”, based on the follow-up question in the thread:

I’m wondering how much Google with promote Jetpack Compose as the primary way to make android UI. At the moment it’s the forth tab along to get to Jetpack and then the fifth tab along to get to Compose. I wouldn’t say it’s the mainstay of Android development currently. WIl Google, in time, push it further to the front?

I expect that Google will steadily ramp up the push for developers to use Compose. The analogy I drew in the Slack thread is one that I have used before, which is how Google approached Kotlin:

  • “Would you like another programming language?”
  • “OK, we added support for Kotlin”
  • “We are now ‘Kotlin first’”

And, there is an implied fourth bullet: “Um, why are you not using Kotlin?”. Eventually, while Google will still support Java code, they might elect to stop supporting Java education, and elect to have all future SDK documentation and similar resources be purely in Kotlin. They are fairly far down that path already.

My guess is that we will see a similar progression with Compose UI:

  • “Would you like an overhauled UI system?”
  • “OK, we implemented Jetpack Compose and Compose UI”
  • “We are now ‘Compose first’”
  • “Um, why are you not using Compose UI?”

Right now, we are at the second bullet, but I think we will progress through the other two bullets in the coming years.