jetc.dev Newsletter Issue #47
While we await the first Compose update of 2021, we look at
layout() as an
alternative to sticking to composables like
Box() for layout. We peek at
Parcelable objects as navigation arguments, using animations (especially
for custom drawers), and an experiment in running Compose in iOS. 🤯
And we look at the ramifications of calling a composable lambda multiple times, and how that plays into the sorts of tools that we are going to need to succeed with Compose.
One Off the Stack, One Off the Slack
You’ve got questions. That’s understandable!
ViewGroup implementations was painful, as it was very confusing
to handle the measure and layout passes, particularly for anything complex.
Compose has a
layout() function that offers a simplified API for those
layout() is useful as a direct way to express size and position rules,
as we see in this week’s highlighted Stack Overflow question.
Composables often accept a composable lambda expression as a parameter. How safe is it for us to invoke that lambda multiple times? The answer is “it depends”, as we see in this week’s highlighted kotlinlang Slack thread.
Posts, videos, and other new information related to Jetpack Compose!
Amr Yousef shows us how to extend
Scaffold() to support a right-side drawer, as
an alternative to the left-side drawer that comes “built into”
This demonstrates animations, Z-axis ordering, and
Thomas Kuenneth returns with a pair of posts on
Canvas(), Compose UI’s lower-level
composable for rendering arbitrary stuff using drawing and painting primitives.
His first post covers the basics of using
Canvas() for drawing lines and painting
simple shapes. His second post
looks at rendering text and the complexities that arise from that, owing to an
incomplete façade around platform APIs.
Rasul Aghakishiyev brings us an overview of how to use
transition() to animate values that we can then use in composables —
in this case, animating the X axis position of a card in a list.
JetBrains’ Sebastian Aigner did a presentation for the Kotlin Budapest User Group, with an overview of Compose for Desktop and how to get started experimenting with this new approach for desktop app development.
100% pure code!
Madushan Siriwardena put together a bit of code that loads a thumbnail image, blurs it, and uses that as a placeholder while loading the real image. The image loading is handled by Glide, without a wrapper library (e.g., Accompanist).
Pierre-Yves “Py” Ricau is perhaps best known in the Android developer community for his work on LeakCanary, a legendary Android library for helping to detect memory leaks. He is experimenting with using Compose for Desktop to create an app to explore heap dumps.
…And One More Thing
Compose, Compose UI, and their spinoffs (e.g., Compose for Desktop) work. However, the more complex our UI gets, the more likely it is that we will run into the sorts of problems mentioned in this week’s One Off the Stack post. There, a composable that works in some cases fails in others, because of subtleties that we cannot see, courtesy of the Compose compiler plugin. While that plugin is wonderful in how it simplifies our composables, sometimes it hides too much, as I pointed out a couple of months ago.
At some point, we are going to need a tool that can help us visualize the composable hierarchy that we are building at runtime, so we can better diagnose problems like the one mentioned above.
By “tool”, I do not necessarily mean some IDE plugin or desktop utility, though that is certainly not out of the question. A “tool” can be in the form of a debug drawer or other in-app facility. LeakCanary is a tool for finding memory leaks, just one that happens to be packaged in a library.
At some point, we are going to need to be able to see:
What are the distinct nodes in this tree of nodes that we are building?
What specific bits of our code are those nodes tied to?
How do things like calling a composable lambda multiple times affect our tree of nodes?
What nodes were recomposed on the last recomposition?
We do not need to see this sort of detail all the time, which is why hiding these details via a compiler plugin is reasonable. However, there is a vast gulf between “not all the time” and “never”. Some sort of opt-in mechanism to see what our code is creating seems like it will be essential for long-term Compose use.
The good news is that such a tool ought to be able to be created by the community. Just as Py created LeakCanary, somebody should be able to create a ComposeInspector or something that offers us the detail that we need. Perhaps that tool will be standalone, or perhaps it will be a plugin to Flipper or something. Google needs to ensure that such a tool could exist, in terms of exposing the APIs needed to collect the requisite data. Google does not necessarily need to create the tool… though I would not complain if they did!
(well, OK, maybe I would complain — I complain a lot)
This is a theme I expect to return to from time to time in this space: what do we need in order to succeed with Compose? I think that even now, during Compose’s early days, we can identify common itches that will need to be scratched. Alas, finding developers with time to scratch those itches is the bigger problem, one that I cannot solve.
- 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?