Understanding Recomposition in Jetpack Compose

Photo by Denny Müller on Unsplash

Jetpack compose can become hard to understand if the basics are not clear. More and more people are trying to become Android developers and Jetpack Compose forms the basis of Android development.

Previously, I have written about the basics of Android development and recomposition. You can read it here:

Jetpack Compose Masterclass — A Simple Introduction Part 1

So, let us try to understand the concept of recomposition in Android development.

Important points in Recomposition:

• Composable functions can be executed in any order.
• Composable functions can be executed in parallel.
• Recomposition skips as many composable functions and lambdas as possible.
• The recomposition is optimistic and may be cancelled.
• A composable function might be run quite frequently, as often as every frame of an animation.

Recomposition:

Recomposition means re-composing or re-rendering the whole UI of the app. If a change occurs on the UI of the app (the user interacts with the app) the screen re-composes or re-renders. Recomposition is essential to show the change in the UI (the result of the user interaction with the app).

Is it not expensive to re-render the UI of the app for a small change?

Yes, it is expensive to re-render the whole UI. Therefore, Jetpack Compose performs smart recomposition. Smart recomposition only re-renders the part of the UI where the change has been made.

I hope this makes the basics of Jetpack Compose recomposition clear.

Composable functions can be executed in any order:

Screen 1 ()----> Side Effect variable Required
Screen 2 ()<---- Side Effect variable
Screen 3 ()

Recomposition can occur in any order. It means that screens might recompose in any order. It means that if screen 1 requires a variable from screen 2 and if screen 1 re-renders before screen 2. It will be missing the variable that needs to be updated in Screen 1. Therefore, we need to make sure that composable functions are self-contained.

Composable functions can be executed in parallel:

Composable functions can be recomposed on any background thread or recomposed due to animation frames. Therefore, the composable functions should be side-effect-free. Let us try to understand with a simple example:

Wrong way:

@Composable
fun PrintCount(){

var count = 0

count++

Text(Count)

AnimationPlayer()

}

Correct way:

@Composable
fun PrintCount(onClick:(count:Int)->Unit, count:Int){

Text(count)

Button{
onClick(count++)
}

AnimationPlayer()

}

If count++ is inside the composable function, it might update due to list change or animation frame. Therefore wrong count might be displayed on the screen. To avoid this kind of count display, we use callback functions like onClick(). The variable is only updated on the UI thread which means it is thread-safe. Also, recomposition is controlled.

You can understand this with this video:

https://youtu.be/IUpr4X6kU_o?si=yucMGEGbyQFjfjt0

I hope this makes the recomposition more clear. We will explore the rest of the points in upcoming blogs. Thank you for reading.

If I have written something wrong, please forgive me. I hope you enjoyed reading.

Thank you,

Your Captain (the commute)

Hitesh Kohli