jetc.dev Newsletter Issue #50
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
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!
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.
IOW, when do you pass things in as parameters (in this case, an Android
object, and when do you pull them from ambients? We briefly examine this topic
in this week’s highlighted Kotlinlang Slack thread!
Reviewing the release notes for the latest Jetpack Compose update!
The callback-style APIs of
onActive() are now
deprecated — please move to
Other renamed items include
Scrolling is moving more towards coroutines; functions like
suspend functions are deprecated. Also,
ScrollableRow() are deprecated — please either use
or a regular
Row() with a scrolling modifier. If you are using
functions are now extension functions, requiring manual imports. A bunch of classes, such as
AnnotatedString, are no
data class implementations.
Icon() now request
WithConstraints is now
BoxWithConstraints. We have a new
add to our ambient toolbox. Vector graphics supports tints better. Coordinate
systems are moving from global to window-based.
A bunch of composables no longer have the
ExperimentalMaterialAPI annotations, which is nice.
If you were changing ripples using
AmbientIndication, please switch to
Posts, videos, and other new information related to Jetpack Compose!
Adam Bennett continues his exploration of Compose UI and how to migrate existing
apps to it. This time, he looks at
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.
Siva Ganesh Kantamani reviews the role of
Modifier along with several of the
most common modifiers. Siva also peeks at creating custom
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.
100% pure code!
…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
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:
BasicText()from the Compose Foundation library
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
MaterialThemeand 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.
- 2022-05-17: Google I|O 2022 videos! Compose beta01! Layout()! State! drawBehind()! Credit cards! App intros! And... what's a horologist?!?
- 2022-05-10: StateFlow vs. State! Design systems! MotionLayout! Text editing problems and solutions! And... modal sheets that are actually modal?!?
- 2022-05-03: @aditlal and @JorgeCastilloPr on design systems! KMP + Compose + SwiftUI! Dropdowns! FABs! And, what does Google I|O 2022 have in store for Compose UI developers?