Newsletter Issue #50

Published: 2021-02-02

alpha11 is out, so we take a tour of the release notes! There were a lot of changes this time around!

Beyond that, we look at View interoperability and testing, integrating Compose UI with ActivityResult APIs, and a piano-style keyboard composable. Plus, I fret about collisions between app-specific design systems and third-party composable libraries.

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Arctic Foxes and Clickables

So long as we are using pre-release versions of Compose, we are going to run into occasional problems when moving to new IDE versions. In this case, the latest Android Studio canary build does not necessarily like every version of Compose, as we see in this week’s highlighted Stack Overflow question.

Resources as a Parameter

IOW, when do you pass things in as parameters (in this case, an Android Resources) object, and when do you pull them from ambients? We briefly examine this topic in this week’s highlighted Kotlinlang Slack thread!

Alpha Analysis

Reviewing the release notes for the latest Jetpack Compose update!

Compose Runtime Alpha 11 Release Notes

The callback-style APIs of onCommit(), onDispose(), and onActive() are now deprecated — please move to DisposableEffect and SideEffect instead. Other renamed items include invalidate() (see currentRecomposeScope) and CompositionLifecycleObserver (see RememberObserver).

Compose Foundation Alpha 11 Release Notes

Scrolling is moving more towards coroutines; functions like scrollBy() that were not suspend functions are deprecated. Also, ScrollableColumn() and ScrollableRow() are deprecated — please either use LazyColumn()/LazyRow() or a regular Column()/Row() with a scrolling modifier. If you are using LazyColumn()/LazyRow()/LazyVerticalGrid(), your items() and itemsIndexed() functions are now extension functions, requiring manual imports. A bunch of classes, such as AnnotatedString, are no longer data class implementations. Image() and Icon() now request a contentDescription.

And there are many more changes — you really want to review these release notes!

Compose UI Alpha 11 Release Notes

WithConstraints is now BoxWithConstraints. We have a new AmbientSavedStateRegistryOwner to add to our ambient toolbox. Vector graphics supports tints better. Coordinate systems are moving from global to window-based.

There is a lot more in these release notes, though it largely overlaps the Compose Foundation ones from above.

Compose Material Alpha 11 Release Notes

A bunch of composables no longer have the @Experimental or ExperimentalMaterialAPI annotations, which is nice. If you were changing ripples using AmbientIndication, please switch to RippleTheme() instead.

Once again, there is a lot more in these release notes, though it largely overlaps the Compose Foundation and Compose UI ones from above.

Composable Commentary

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

Migrating Your Design System to Jetpack Compose Part 3: Interop & Testing

Adam Bennett continues his exploration of Compose UI and how to migrate existing apps to it. This time, he looks at ComposeView and AndroidView for bi-directional interoperability with classic View-based UIs. And, he also examines how testing works, both in terms of screenshot-based test assertions and Espresso-esque assertions to confirm nodes have the desired characteristics.

Jetpack Compose Components (Part 3): Modifiers

Siva Ganesh Kantamani reviews the role of Modifier along with several of the most common modifiers. Siva also peeks at creating custom Modifier extensions, particularly for patterns that are common in your specific app.

Kilo Loco returns with a screencast looking at Compose UI rendering user-selected images. He blends the ActivityResult APIs (for getting that image) with Glide, showing how to get a composable to react to the user selection.

Kharan Dhillon takes a quick peek at Navigation for Compose and how we can use it to route among various composables in a fragment-free app.

Jetpack Compose: Custom List? Such ez, much wow.

MJ Manaog offers a basic intro to Compose UI, with an eye towards implementing a scrolling grid of cards. His focus is on comparing a RecyclerView implementation with the Compose UI equivalent.

Resource Roundup

100% pure code!

GitHub: fluxtah / pianoroll

Ian Warwick is working on a Compose Material library that renders a piano-style keyboard, with highlights to show specific piano chords.

GitHub: Veriqus / goldpare

GitHub user Veriqus is working on a Kotlin/Multiplatform project for examining the price of gold. The Android app uses Compose UI, and common code across Android and iOS uses SQLDelight.

…And One More Thing

There are design systems, and then there are design systems.

The argument that Google has made on a few occasions is that Compose Material is just one design system. Development teams are welcome to:

  • Just use Compose Material directly

  • Create their own design system that layers atop Compose Material

  • Create their own design system that avoids Compose Material and works with lower-level composables, the same way that Compose Material does

This is fine if we only think about the app’s code in conjunction with the various Compose libraries. The development team can aim to stick with their own design system’s functions when writing their own code.

The problem comes with third-party libraries.

These abound in classic View-based Android development. The expectation is that there will be many more for Compose, as creating a custom composable is so much easier than is creating a custom View.

The question then becomes: how does the third-party composable integrate with an app-specific design system?

For example, suppose that the library needs to render some text. The options are:

  • Use BasicText() from the Compose Foundation library

  • Use Text() from the Compose Material library

  • Somehow use the desired function from the app’s design system… except that the library does not know what that function is

I opened a Kotlinlang Slack thread on this. Google’s Adam Powell chimed in on it, and we had a fairly extensive discussion.

For lower-level composables — a date picker was the example we used — either:

  • The composable will need to expose a bespoke API for configuration details like fonts and colors, even if those might be available in some theme mechanism; or

  • The composable will assume MaterialTheme and use it, making Compose Material be part of the API

Perhaps some third-party independent theme engine will gain prominence and that will become a popular option.

Composables will exist at various levels though. An about screen will be a composable, for example. Ideally, there would be some relatively easy way to teach an about screen composable about how to blend into the app’s design system.

Regardless, I still have concerns about the intersection of app-specific design systems and third-party composable libraries. I guess we will learn over time how well these will integrate.