jetc.dev Newsletter Issue #47

Published: 2021-01-12

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!

Laying Out with layout()

Creating custom 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 operations, and layout() is useful as a direct way to express size and position rules, as we see in this week’s highlighted Stack Overflow question.

Composable Lambdas as Factories

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.

Composable Commentary

Posts, videos, and other new information related to Jetpack Compose!

Video: Jetpack Compose Navigation and Passing Data

Kilo Loco returns with a short video on Navigation for Compose and its system for passing arguments, including how to pass arbitrary Parcelable objects to composable destinations.

Custom Side Drawer in 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” Scaffold() itself. This demonstrates animations, Z-axis ordering, and WithConstraints().

Drawing and Painting in Jetpack Compose

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.

Animations in Jetpack Compose

Rasul Aghakishiyev brings us an overview of how to use transitionDefinition() and 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.

Video: Introducing Compose for Desktop

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.

Compose Academy and Discord

Joe Birch’s Compose Academy site now offers a Discord server as a support point for developers learning Compose and Compose UI.

Resource Roundup

100% pure code!

GitHub: cl3m / multiplatform-compose

Clément Beffa is experimenting with adding another Compose UI target: iOS! This is very much a work-in-progress, yet some basic composables are showing up in the iOS simulator!

Gist: madushans / compose-glide-blurred-load.kt

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).

Gist: AdrianoCelentano / DashPathEffect.kt

GitHub user Adrian offers a quick demo of using DashPathEffect with drawPath() on a Canvas(), to draw dashed lines.

GitHub: pyricau / SharkApp

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.