Hey, Devs! Have you gotten to use the Recomposition State yet? If you haven't and want to know where to look, check out Huyen's quick post on where to find it.
While working on a schedule app for my Droidcon NYC and Droidcon London talks, I finally found and used the Recomposition State in the Android Studio debugger. It's already been incredibly helpful for tracing the source of some tricky recomposition.
Inside the schedule are multiple tracks with multiple classes in each track, and I can change the layout of classes in each track to be either overlapped (where classes that are overlapping are drawn on top of each other) or staggered (where classes that are overlapping are drawn one after another vertically).
I can toggle between these two layouts with a Switch composable in my test application.
The Switch state feeds into a mode
parameter inside of my Track
composable.
If I want to look at how my Track
inputs are changing, and how that's affecting recomposition, I can do the following:
Track
composable's content.I'll now see this "Recomposition State" section.
This Recomposition State lists all of the inputs into my composable and the status of those inputs on this particular recomposition. In the above example, the breakpoint was hit after I hit the switch to toggle the layout mode. In the Recomposition State, the arguments into my Track
are shown, and as expected, the mode
argument is marked as changed.
Recomposition State was released way back in November 2023 in Android Studio Hedgehog. I'm not entirely sure how I missed it completely for almost an entire year, but talking to some other Android devs, I wasn't the only one. Since it only appears at the bottom of the "Threads & Variables," maybe we all have too many variables in our stack frames and never scroll down. After complaining about needing something like this, which can tell us exactly what has changed to cause recomposition, I am just glad it's there and that I know it's there.
I will be using the !@#$ out of it.