Managing State of Your Composable Functions

In Chapter 4, Laying Out UI Elements in Compose, I showed you how to set the red, green, and blue portions of a color by dragging sliders. We used state to store the color portions and passed simple values and callbacks that are invoked when value changes are due to composable functions. Quite a few other sample apps of the previous chapters dealt with state too. In fact, reacting to state changes is critical to how modern mobile apps work.

So far, I have described state as data that can change over time. You learned about a few important functions – for example, remember { } and mutableStateOf(). I also briefly touched on a concept called state hoisting.

This chapter builds on these foundations. For example, you will understand the difference between stateless and stateful composables, and when to choose which. Also, I will show you how events should flow in a well-behaved Compose app.

The main sections of this chapter are...

Technical requirements

Please refer to the Technical requirements section in Chapter 1, Building Your First Compose App, for information about how to install and set up Android Studio, as well as how to get the sample apps. This chapter covers the FlowOfEventsDemo, StateDemo, and ViewModelDemo samples.

Understanding stateful and stateless composable functions

In this section, I will show you the difference between stateful and stateless composable functions. To understand why this is important, let’s first focus on the term state.

In the previous chapters, I described state as data that can change over time. Where the data is held (e.g., a SQLite database, a file, or a value inside an object) does not matter. What is important is that the UI must always show the current data. Therefore, if a value changes, the UI must be notified. To achieve this, we use observable types. This is not specific to Jetpack Compose and is a common pattern in many frameworks, programming languages, and platforms. For example, Kotlin supports observables through property delegates. Let’s see how they work.

Please note that the following code snippet is not an Android app. While you could execute it in Android Studio using a Scratch File, there’s a much easier way – Kotlin...

Hoisting state and passing events

So, state is any value that can change over time. As Jetpack Compose is a declarative UI framework, the only way to update a composable is to call it with new arguments. This happens automatically when state that a composable is using changes. State hoisting is a pattern of moving state up to make a composable function stateless.

Besides making a composable more easily reusable and testable, moving state up is necessary to use it in more than one composable function. You have already seen this in quite a few of my sample apps. For example, in the Composing and recomposing the user interface section of Chapter 3, Exploring the Key Principles of Compose, we used three sliders to create and display a color.

While state controls the visual representation of a composable function (that is, how it looks on screen), events notify a part of a program that something has happened. Let’s focus a little more on this. My sample FlowOfEventsDemo app...

Surviving configuration changes

Recall that our definition of state as data that may change over time is quite broad. For example, we do not specify where the data is stored. If it resides in a database, a file, or some backend in the cloud, the app should include a dedicated persistence layer. However, until Google introduced Android Architecture Components back in 2017, there had been practically no guidance for developers on how to structure their apps. Consequently, persistence code, UI logic, and domain logic were often crammed into one activity. Such code was difficult to maintain and often prone to errors. To make matters a little more complicated, there are situations when an activity is destroyed and recreated shortly after. For example, this happens when a user rotates a device. Certainly, data should then be remembered.

The Activity class has a few methods to handle this. For example, onSaveInstanceState() is invoked when the activity is (temporarily) destroyed. Its counterpart...

Summary

This chapter aimed to provide a more detailed look at state in Compose apps. We started by exploring the differences between stateful and stateless composable functions. You learned their typical use cases and why you should try to keep your composables stateless. Hoisting state is a tool to achieve that. We covered this important topic in the second main section. I also showed you that you can make your composable functions more reusable by passing logic as parameters, rather than implementing it inside the composable. The previous section explored the integration of a Compose UI hierarchy in activities related to how to retain user input. We looked at the differences between remember {} and rememberSaveable {}, and I gave you a glimpse of how bigger Compose apps can benefit from ViewModel classes.

Chapters 1 to 5 introduced you to various aspects of Jetpack Compose, such as composable functions, state, and layout. Chapter 6, Building a Real-World App, will focus on one...

Questions

1. What are the key differences between stateless and stateful composable functions?
2. What does the term idempotent mean?
3. What is a simple way to retain state across configuration changes?