jetc.dev Newsletter Issue #25
This week, we look at upcoming state changes (literally, changes to
We also get a Google-level look at using
@Preview, learn how to integrate ExoPlayer
into Compose, and see a swipe-to-dismiss modifier implementation. And, I spend some
time hoping for API design guidance from Google, as what they are learning now we need
to learn before crafting a zillion Compose libraries.
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
Alas, we continue to collect few good answers in Stack Overflow in
Posts, videos, and other new information related to Jetpack Compose!
In this YouTube video, Google’s Diego Perez demonstrates the Android Studio
preview pane and its use with the
@Preview annotation, including using
@PreviewParameter to supply sample data to your composable preview.
The counterpart to that video is this issue comment, where Google confirms that
composable previews are presently broken in the current Android Studio 4.2 canary builds,
if you are using
dev15 or newer builds of Compose. The comment indicates that
this will be fixed in 4.2 Canary 8.
Parthasarathy wrote up some notes on how to get the
compose-desktop AOSP module building
and running on Linux. This involved replacing the
a new JetBrains library offering a Kotlin/Multiplatform wrapper for
Back in Issue #14, I showed you a project from Andrei Shikov, where he drove the content rendered in Web browser from a Kotlin server using Compose’s tree-manipulation logic. In this post, Andrei explains a bit more about how his experiment works.
100% pure code!
John O’Reilly has put together a Kotlin/Multiplatform project that uses Compose and Swift UI, for supporting Android, iOS, and macOS. The app uses the CityBikes API for helping you find bike-share locations.
Brandon McAnsh demonstrates a
swipeToDelete() modifier for implementing
a swipe-to-dismiss pattern, such as for a vertically-scrolling list.
…And One More Thing
This week’s “One Off the Slack” highlights a challenge with Compose: designing the right API. We all want APIs that are easy to understand and easy to integrate, but we are still learning how best to do that in the world of Compose.
For example, the swipe-to-dismiss modifier
mentioned earlier in this issue is a simple
Modifier extension function. This is
nice, in that it can be easily added to a
Modifier chain alongside all of the
other modifiers that we use. Simply calling
swipeToDelete() seems like it qualifies
both as “easy to understand” and as “easy to integrate”.
However… is this modifier designed to be used anywhere?
This is one of the risks of defining top-level
Modifier extensions: they are usable
from any scope. That only works well if the modifier makes no assumptions about
its surroundings. In this case, that probably is indeed true, and any conflicts
are simply unfortunate (e.g., trying to drag horizontally in a horizontally-scrolling container).
However, in some cases, it may make more sense to tie a modifier to some
particular scope, the way that
Google is working on documentation to help guide us in these decisions — Adam Powell has hinted a few times that he is working on such a guide. It seems likely that such guidance will be delayed until after the first alpha release, as today’s rules might run afoul of tomorrow’s breaking API changes.
And, no doubt, we will make mistakes along the way. For third-party developers, mistakes can be fixed. Google will not be afraid to make breaking changes — that is a big benefit of Compose being a library. However, there is some amount of “institutional knowledge” inertia that builds up the longer an API is around, so Google may be less inclined to make changes that will confuse a generation of developers.
As Compose proceeds through alpha and beta releases, there may be a bit of a “gold rush” mentality, as developers strive to be “the first on the block” to have a Compose-specific solution for some common problem, whether that is pager indicators or rich text editors or debug drawers. Hopefully, we will get that official API design guidance from Google before the rush really begins, as we will need that knowledge to design APIs that stand a chance of holding up as Compose continues to accelerate.
- 2024-02-20: Compose Multiplatform RCs! State! Nested scrolling! @email@example.com 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! @firstname.lastname@example.org on Circuit and Compose Multiplatform! Material3! Markdown! MVI! And... testing robots?!?
- 2024-02-06: A Compose Multiplatform survey and a patch! @email@example.com on font scaling! Modal bottom sheet close confirmation! Compose Multiplatform resources! Draggable items in lazy lists! And... @firstname.lastname@example.org talks to some Italians?!?