jetc.dev Newsletter Issue #46
After a brief end-of-year break… it’s time for more Compose!
This time, we have a minor argument about arguments and see whether
is doomed. We look at shapes, unidirectional data flows, and a double dose of
GraphQL. We see a shimmer effect and an experiment in browser-based Compose.
Plus, Jake Wharton rants, and I agree with him!
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
Navigation for Compose is new, so there are a few documentation hiccups. One is that the docs focus on arguments for composable navigation targets, but only discuss having a single argument. Fortunately, we can have more than one argument, as we see in this week’s highlighted Stack Overflow question.
Posts, videos, and other new information related to Jetpack Compose!
Thomas Kuenneth takes a break from writing about Compose for Desktop and gives us
an overview of working with shapes in Compose UI, from the built-in
Circle() to custom ones based on
Etienne Caron did a presentation for GDG Montreal, covering how Compose blends
in nicely with reactive frameworks (RxJava, coroutines’
modern architecture approaches such as unidirectional data flows.
Howie Zuo follows up his original post
(mentioned back in issue #34) with a short
roundup of the reasons why he thinks that creating design systems in Compose UI
is so much easier than for the classic Android
Jake Wharton is a legend in Android app development circles. While he likes Compose… he is less of a fan of the naming scheme. Like me, he runs into problems in explaining the separation of Compose (managing trees of nodes) and Compose UI (a UI framework built on top of Compose).
Most of the stuff written about using Compose for building Web service front-ends focuses on REST. John O’Reilly takes a look at GraphQL, a leading alternative to REST, and shows how Apollo-Android can also be used to drive a Compose UI.
The Curated Reality team held a livestream with Joe Birch, to talk about… Compose and GraphQL! Specifically, Joe elaborated on an earlier blog post on having the server’s GraphQL response more directly drive the actual presentation, through a server-driven UI approach.
100% pure code!
Habib Kazemi offers up a modifier that adds a shimmer effect to any composable.
It is fairly customizable, where you can control the duration and repeat on a
per-modifier basis, plus a dedicated
ShimmerTheme ambient for UI effects
(e.g., alpha, direction).
Compose is for more than mobile, as we see with Compose for Desktop. In the end, Compose is good at updating trees of nodes, and in this repo, Andrei Shikov brings us some Compose logic running directly in the Web browser via Kotlin/JS.
…And One More Thing
Jake speaks truth.
Jake Wharton’s plea for a name change is absolutely correct:
Compose might have been a great name for the code that manages “trees of nodes”, but…
Everybody thinks that “Jetpack Compose” is the UI toolkit
In part, that is because it seems like lots of people at Google think that Jetpack Compose is the UI toolkit. For example, the official Jetpack Compose page has:
Jetpack Compose is Android’s modern toolkit for building native UI
All of the launch discussion referred to Jetpack Compose as the UI toolkit. Just about every resource that I have ever linked to from this newsletter refers to Jetpack Compose as the UI toolkit. And so on.
I have run into the same problems that Jake has of helping people keep Compose and Compose UI separate. For example, developers ask if Jetpack Compose can be used to create app widgets, and the answer is: it depends on how you define “Jetpack Compose”. Compose UI has no real role with app widgets, but Compose might.
But so long as Google itself keeps conflating the two, this sort of confusion will arise. For example, my answer to the Stack Overflow question linked to in the previous paragraph stemmed from this kotlinlang Slack thread, where Google’s Adam Powell said that Compose could be used for app widgets. My reaction was “wait, wut?”… until I realized that he literally meant Compose, whereas I had already made the translation of an ordinary developer’s use of “Compose” to mean Compose UI.
I also agree with Jake that ideally we would have better names for the stuff layered atop Compose. Compose UI is very generic, implying that every UI that will be created using Compose will be made using Compose UI. Alas, I will be surprised if that changes, in part because too much of Google thinks that Compose === Compose UI.
Jake’s conclusion is inescapable: Compose (the thing that manages trees of nodes) should get a new name. Unfortunately, I suspect that this is unlikely to happen, though I can still hope.
Jetpack Attune, maybe?
- 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?