jetc.dev Newsletter Issue #19

Published: 2020-06-23

It was a quiet week in the world of Jetpack Compose, but we still take a peek at CameraView, applying Compose to a ViewGroup, and a new slate of community-created samples.

One Off the Stack, One Off the Slack

You’ve got questions. That’s understandable!

Using CameraView in Compose

Someday, perhaps, there will be an official composable API offered by CameraX. Until then, we need to wrap CameraView in an AndroidView and perform quite a few other hacks to get things working.

Reworking Recomposer

A question about why setContent() on a ViewGroup now explicitly requires a Recomposer parameter led to the discovery that setContent() might be replaced entirely in a future Compose release.

Composable Commentary

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

Jetpack Compose: How to Build a Messaging App

Medium user Siva has written an article about how to blend AdapterList, FloatingActionButton, TopAppBar, and other composables into a UI mimicking that of a conversation-list messaging app.

jetpackcompose.app

Vinay Gaba is back with a “if this, then that” style of Web site to help you quickly identify a possible replacement for a classic Android UI construct, ranging from ProgressBar and Theme.MaterialComponents to getDrawable() and android:background.

Resource Roundup

100% pure code!

GitHub: Zpecter / MoviesKotlinDemo

Juan Francisco has published a demo app, demonstrating a movie reservation UI.

GitHub: MoIbrahim15 / AndroidComposeSamples

Mohamed Ibrahim has released an app demonstrating a wide range of composables, using a series of Git branches to iterate through the build-out of the UI.

GitHub: henrikhorbovyi / JetpackComposeParkinho

Henrique Horbovyi has another take on the composable-showcase app, demonstrating a couple dozen different composables.

…And One More Thing

An area that we as a community are going to need to work on are tools and techniques to deal with unplanned composition loops.

Such loops were covered in last week’s highlighted Slack thread. It is possible to get yourself into a situation where your composables never stop composing:

• You call a composable

• …which updates some state…

• …which triggers recomposition of that composable…

• …which updates some state…

• …which triggers recomposition of that composable…

• …which updates some state…

• …which triggers recomposition of that composable…

• …and so on

Repeatedly causing a composable to be recomposed is normal. As Zach Klippenstein noted, that is what animations do. Yet, while we want animations, we do not want to burn CPU cycles constantly having a composable recompose because of pointless state changes. State seems to be tied to object identity, not content identity, so emitting a content-equivalent state as a new object, such as via copy() on a data class, could get you in trouble.

The answer might be some sort of ComposeStrictMode that implements some protections in debug builds and skips them in release builds. For example, there might be a rule that says “unless otherwise noted, fail if we recompose more than N frames in succession”, to help identify these sorts of self-recomposing composables.

One way or another, we will need to find some way to help prevent newcomers to Compose (which, right now, is pretty much everyone) from causing themselves too much grief with this sort of problem.