Exploring the Key Principles of Compose

In the first chapter of this book, we built and ran our first Jetpack Compose app. Then, in Chapter 2, Understanding the Declarative Paradigm, we explained the imperative nature of Android’s traditional UI toolkit, illustrated some of its weaknesses, and saw how a declarative approach can overcome them.

In this chapter, we build upon these foundations by examining a few key principles Jetpack Compose relies on. This knowledge is essential for writing well-behaving Compose apps. This chapter introduces these key principles.

In this chapter, we will cover the following topics:

• Looking closer at composable functions
• Composing and recomposing the UI
• Modifying the behavior of composable functions

We will start by revisiting composable functions, the building blocks of a composable UI. This time, we will dig much deeper into their underlying ideas and concepts. By the end of the first main section, you will have...

Technical requirements

Please refer to the Technical requirements section of Chapter 1, Building Your First Compose App, for information on how to install and set up Android Studio, as well as how to get the sample apps. This chapter covers the ColoredTextDemo, ColorPickerDemo, and ModifierDemo samples.

Looking closer at composable functions

The UI of a Compose app is built by writing and calling composable functions. We have already done both in the previous chapters, but my explanations regarding the structure of a composable, as well as its internals, have been quite basic—it’s time to fix that.

Building blocks of composable functions

A composable function is a Kotlin function that has been annotated with @Composable. All composables must be marked this way because the annotation informs the Compose compiler that the function converts data into UI elements.

The signature of a Kotlin function consists of the following parts or building blocks:

• An optional visibility modifier (private, protected, internal, or public)
• The fun keyword
• A name
• A list of parameters (can be empty) or, optionally, a default value
• An optional return type
• A block of code

Let’s explore these parts in greater detail.

The default visibility...

Composing and recomposing the UI

Unlike imperative UI frameworks, Jetpack Compose does not depend on the developer proactively modifying a component tree when changes in the app data require changes to be made to the UI. Instead, Jetpack Compose detects such changes on its own and updates only the affected parts.

As you know by now, a Compose UI is declared based on the current app data. In my previous examples, you have seen quite a few conditional expressions (such as if or when) that determine which composable function is called or which parameters it receives. So, we are describing the complete UI in our code. The branch that will be executed depends on the app data (state) during runtime. The web framework React has a similar concept called Virtual DOM. But doesn’t this contradict my saying Compose detects such changes on its own and updates only the affected parts?

Conceptually, Jetpack Compose regenerates the entire UI when changes need to be applied. This, of course...

Modifying the behavior of composable functions

Unlike components in traditional imperative UI frameworks, composable functions do not share a basic set of properties. They also do not automatically (in the sense of inheriting) reuse functionality. This must be done explicitly by calling other composables. Their visual appearance and behavior can be controlled through parameters, modifiers, or both. In a way, modifiers pick up the idea of properties in a component but enhance it—unlike properties of components, modifiers can be used completely at the discretion of the developer.

You have already seen quite a few modifiers in my examples, such as the following:

• width()
• fillMaxWidth()
• fillMaxSize()

These control the width and size of the corresponding UI element.

background() can set a background color and shape, while clickable {} allows the user to interact with the composable function by clicking on the UI element. Jetpack Compose provides an extensive...

Summary

This chapter introduced you to the key principles of Jetpack Compose. We closely looked at the underlying ideas and concepts of composable functions, and you now know how they are written and used. We also focused on how to create and update the UI, as well as how Jetpack Compose achieves what other frameworks call repainting or updating the screen. When relevant app data changes, the UI changes, or so-called recomposition, takes place automatically; this is one of the advantages over the traditional View-based approach, where the developer must imperatively change the component tree.

sWe then expanded our knowledge of the concept of modifiers. We looked at how modifier chains work and what you need to keep in mind to always get the intended results. For example, to receive clicks inside padding, padding {} must occur after clickable {} in the modifier chain. Finally, you learned how to implement custom modifiers.

In Chapter 4, Laying Out UI Elements in Compose, we will...

Questions

• Composable functions usually do not specify a return type. Please list three that do.
• What does state hoisting mean?
• What are the key differences between properties in class-based UI frameworks and modifiers?