jetc.dev Newsletter Issue #82
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!
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.
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.
Posts, videos, and other new information related to Jetpack Compose!
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.
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.
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.
Siva Ganesh Kantamani is back, this time looking at how to build a
to handle scenarios in your UI where you might have used
Spinner with the classic
ComposeMenu(), in turn, uses the
DropdownMenu() from Compose Material.
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.
Udit Verma continues a tour of the effect API and related concerns.
Udit looked at
LaunchedEffect() for coroutines — this time, Udit looks
rememberCoroutineScope() as another way to get a
CoroutineScope tied to
the lifecycle of your composable.
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.
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.
Other Interesting Links
- Podcast: Talking Compose in Production with Jossi Wolf
- Jetpack Compose - States and Custom Shapes (Part 2)
- Creating a Repeating Button with Jetpack Compose
- Jetpack Compose: InteractionSources, Ripple, and You
- Video: Exploring Advanced Jetpack Compose Features
- Video: Jetpack Compose for Beginners
- Animated Splash Screen in Android Using Jetpack Compose
- Adopting Jetpack Compose with Interop API
- Video: Jetpack Compose Navigation
- Video: Jetpack Compose, Ktor & Coil
- Medium: Jetpack Compose — pros and cons of using it in production
100% pure code!
…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
ComposeView is not just a way to get a composable into an existing layout. It
is also the underpinning of
setContent() on a
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
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
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.
- 2024-02-20: Compose Multiplatform RCs! State! Nested scrolling! @firstname.lastname@example.org on Amper! Compose Cupertino! Compose... Hammer? And... we can memoize lambdas?!?
- 2024-02-13: Compiler 1.5.9! BOM 2024.02.00! New Glance libraries! @email@example.com on Circuit and Compose Multiplatform! Material3! Markdown! MVI! And... testing robots?!?
- 2024-02-06: A Compose Multiplatform survey and a patch! @firstname.lastname@example.org on font scaling! Modal bottom sheet close confirmation! Compose Multiplatform resources! Draggable items in lazy lists! And... @email@example.com talks to some Italians?!?