Graduating from View IDs

I found an old screen in Cash App today that wasn’t retaining its scroll position across configuration changes. A peek into git history revealed that the author forgot to assign an ID to its scrollable layout for enabling state restoration. And would you even blame them? Sure, View IDs are necessary, but maintaining them manually is such a chore. It’s even easier to forget about them when layouts are built in Kotlin using contour, where findViewById is no longer needed.

This is one of the many reasons why I’m so excited about Compose UI — it makes View IDs practically obsolete for state restoration. When rememberSaveable is used for saving values across Activity recreations, assigning a unique key (analogous to View IDs) is no longer needed. The Compose runtime is able to automatically generate unique keys for every exact location in your code!

@Composable
fun NewMessageField() {
  var text by rememberSaveable { mutableStateOf("block.xyz") }

  TextField(
    value = text,
    onValueChange = { text = it }
  )
}

What’s even better is that composables such as LazyColumn automatically use rememberSaveable under the hood so state restoration works out of the box with zero effort (in most cases).

@Composable
fun MessageList(messages: List) {
  LazyColumn {
    items(messages) { message ->
      MessageRow(message)
    }
  }
}

Here’s to making better apps with less effort using Compose UI!