How can I avoid recomposition of certain areas of a screen? In my example I use an AndroidView (to s...

# compose

[Tobias Gronbach]

How can I avoid recomposition of certain areas of a screen? In my example I use an AndroidView (to show diagrams) and also I display some Dialogs depending on the ScreenState. Everytime a dialog is shown or hidden the AndroidView gets recomposed. How can I avoid it? Is it possible to scope recomposition only to specific states?

[myanmarking]

post code please

[myanmarking]

in my experience, recomposition of non-common part of the screen like yours is related to non-skippable composables and or lambdas accessing non-stable state. So its hard to guess without any code

[Ronald Wolvers]

@Tobias Gronbach do you display a dialog in Compose (e.g. AlertDialog()) or from your AndroidView()? If AndroidView() is creating the dialogs then what comes to mind is to use the compose variant. You would have to propagate state to the composable somehow though, so you could use a StateFlow and call collectAsState() on it, which will give you exact control over the recomposition. I guess that's a lot of work but that's the approach I use a lot and does get the job done so to speak.

[Ronald Wolvers]

That's if I even understood correctly 😃

[Ronald Wolvers]

And actually not so much work if you use a view model, but can lead to having a lot of state flows.

[Tobias Gronbach]

Thank you for your answers and thoughts. For the code is a bit long I removed some parts.

@Composable
fun AnalyseScreen(
    viewModel: AnalyseViewModel = hiltViewModel(),
) {

    val chartDataPackage by viewModel.chartDataPackageFlow.collectAsState()
    val screenState by viewModel.screenState.collectAsState(AnalyseScreenState())

    val menuBackgroundColor = Color(0xFF957B1B)
    val menuBarHeight = 50.dp

    var isMenuOpen by remember { mutableStateOf(false) }
    var showTimeSelectionDialog by remember { mutableStateOf(false) }

    if (showTimeSelectionDialog) {
        // ... calls Dialog 
    }

    if (screenState.showDiagramSelectionDialog) {
        //... calls Dialog
    }

    Column(
        modifier = Modifier.background(Color(0xFF423F34)),
        verticalArrangement = Arrangement.SpaceBetween
    ) {

        Row(
            modifier = Modifier.fillMaxWidth().height(200.dp)
        ) {
            Chart(chartDataPackage) // opens AndroidView
        }

        Row(modifier = Modifier
            .height(menuBarHeight)
            .fillMaxWidth()
            .background(menuBackgroundColor)
            .padding(5.dp),
            horizontalArrangement = Arrangement.SpaceBetween,
            verticalAlignment = Alignment.CenterVertically) {

            // .... more composables
        }

        if (isMenuOpen) {
            Box(
                modifier = Modifier
                    .fillMaxSize()
                    .padding(0.dp, 0.dp, 0.dp, menuBarHeight),
                contentAlignment = Alignment.BottomEnd
            ) {
                // Menu
            }
        }
    }
}

As soon as a dialog is shown / hidden or Menu is shown / hidden the Chart also gets recomposed and I don't want that.

[Ronald Wolvers]

Understood! I think the reason that the chart gets recomposed is because the composition literally goes back to the point where remember[...]() was called and then after the if switches simply hits the part of the function again where the chart is drawn. If you would put the dialogs logic after drawing the chart, I'm pretty sure it won't get recomposed.

[Ronald Wolvers]

That is, as far as it's possible to put it after the chart logic

[Ronald Wolvers]

What I said could also very well be false as the dialogs overlap the chart I assume and a recomposition happens anyway, but I'd say definitely worth trying to put the logic after it

[Tobias Gronbach]

Thank you for your thoughts! I put the logic behind the drawing of the chart but nothing changes. The Dialog is drawn above the chart, so maybe your guess is right. But I guess there must be some kind of a solution. The Charts are animated and each time a dialog or menu pops up the animation starts again. That's a bad user experience.

[Tobias Gronbach]

This is Chart-Composable (there the correct Chart is selected)

@Composable
private fun <T> Chart(chartDataPackage: ChartDataPackage<T>) {
    when (chartDataPackage.diagram) {
        Diagram.OverviewChart -> {
            val stats = chartDataPackage.data as List<StatisticsData>
            StatsOverviewChart(stats.first())
        }
   
        Diagram.BarChart_XNameValence_YAmount,
        -> {
            val chartData = chartDataPackage.data as List<BarEntry>
            val meta = chartDataPackage.meta
            meta?.let {
                BarChartCompose(chartData, it)
            }
        }
   
        Diagram.PieChart_XNameValence_YAmount,
        -> {
            val meta = chartDataPackage.meta
            val chartData = chartDataPackage.data as List<PieEntry>
            meta?.let {
                PieChartCompose(chartData, meta)
            }
        }
}

This is PieChart with AndroidView as example

@Composable
fun PieChartCompose(chartData: List<PieEntry>, meta: ChartMetaData) {
    AndroidView(
        modifier = Modifier.fillMaxSize(),
        factory = { context ->
            PieChart(context)
        },
        update = { pieChart ->
         
            pieChart.apply {

		// ... PieChart Settings
}}})

[Ronald Wolvers]

One way you could rule out whether it's Compose recomposing as opposed to the View being re-drawn is putting a LaunchedEffect() in the Chart() composable and then seeing if that gets executed. If it doesn't then it must have something to do with AndroidView() of which I don't know the internals. How Compose decides whether or not to re-draw an old school View is territory probably best avoided until there's no other option, lest you would have to re-do the whole thing in Compose 😬

[Ronald Wolvers]

*executed when opening or closing a dialog

[Tobias Gronbach]

Not sure if I do it right (i'm still a beginner). I added the following in the Chart-Composable:

LaunchedEffect(chartDataPackage) {  //used chartDataPackage as Key
        println("Recomposition Launched Effect")
 }

 println("Recomposition") // added this as well outside of launchedeffect

Output is:

"Recomposition Launched Effect" when diagramm opened first time
"Recompostion" after show/hide of dialogs and menus

If I interpret this correctly I would say it's Compose recomposing

[Ronald Wolvers]

Yeah, that's what I meant by "Compose recomposing" indeed! Next I would probably put print statements up in your top level composable as well as down to where you use AndroidView(). Just wanted to double check too that the dialogs don't touch the state?

[Ronald Wolvers]

Also a beginner! Never not been one 😆

[Tobias Gronbach]

I'm very thankful you give me ideas how to approach the problem!

If I open Menu, that's the Composition-Order

AnalyseScreen Recomposition (Top Level)
Chart is recomposed (Chart Composable)
PieChart Composition (Composable that contains AndroidView)

[Ronald Wolvers]

The first print statement is before the first collectAsState() call?

[Ronald Wolvers]

If so, you could try passing in the `StateFlow`s as arguments instead of the view model, which is what I'm guessing @myanmarking meant by unstable arguments

[Tobias Gronbach]

I also changed TopLevel Composable to :

@Composable
fun AnalyseScreen(
    viewModel: AnalyseViewModelCompose = hiltViewModel(),
) {

    val chartDataPackage by viewModel.chartDataPackageFlow.collectAsState()

    println("AnalyseScreen Recomposition")
    Box(
        modifier = Modifier.fillMaxSize().padding(0.dp, 0.dp, 0.dp, 50.dp)
    ) {
        Chart(chartDataPackage)
    }


  .... // rest of states and composables
}

[Ronald Wolvers]

And if you also put a print statement before the line that says val chartDataPackage (...)?

[Ronald Wolvers]

If that does not get executed then something somewhere must be changing the data package

[Tobias Gronbach]

New Output:


AnalyseScreen before Collection of State
AnalyseScreen Recomposition
Chart is recomposed
PieChart Composition

[Ronald Wolvers]

Weird!

[Ronald Wolvers]

Okay yeah I would put the `StateFlow`s directly as arguments!

[Tobias Gronbach]

I will try that tomorrow. For today I have enough. Thank you so, so much Ronald for your thoughts and help! I'm grateful you took that time! Have a nice evening!

[Ronald Wolvers]

And then if the print statement between the beginning of the function and the call to collectAsState() is happening is still called, it must be something that AndroidView() is doing where it recomposes the whole thing

[Ronald Wolvers]

Sounds good. My pleasure! Keep us posted 😊

[Tobias Gronbach]

Will defintely do!

[Ronald Wolvers]

You have a nice evening as well and thanks! 🌉

[Tobias Gronbach]

@myanmarking also thank you very much for your help! I'm not sure if you can see what you need to know in the code examples i posted. If not I'm glad to provide more information! There are no other Compose-Functions called just a bunch of Standard Composables.

[myanmarking]

Do you have any lambdas in the screen? Are the composables top level classes ?

[myanmarking]

Thse are important questikns regarding rwcomposition. But i suspect the cause is ChartDataPackage not being stable. Please check that

[Tobias Gronbach]

Guys, it's finally working! It feels so good! Let me tell you what I've done and what I think now .
I also read this article from Zack Klippenstein, which was claryfing and finally helped me solve the issue:
https://dev.to/zachklipp/scoped-recomposition-jetpack-compose-what-happens-when-state-changes-l78

First I Changed my Top-Level Composable

@Composable
fun AnalyseScreen(
    viewModel: AnalyseViewModelCompose = hiltViewModel(),
) {
    Surface {
        println("AnalyseScreen Recomposition")
        Box(
            modifier = Modifier.fillMaxSize().padding(0.dp, 0.dp, 0.dp, 50.dp)
        ) {
            Chart(viewModel)
        }

        Box(
            modifier = Modifier.fillMaxSize(),
            contentAlignment = Alignment.BottomEnd
        ) {
            ChartMenu(viewModel)
        }
    }
}

As you can see I took the content (a lot of nested Composables) below the Chart and added it to a seperate @Composable-Annotated-Function. I passed to both
@Composable-Functions (Chart and ChartMenu) my viewModel (which could be done in other ways as well). In Zachs article he writes
"Functions are a natural delimiter for re-executable chunks of code, because they already have well-defined entry and exit points.". So
I thought this was a good idea and suddenly it worked as expected BUT I still didn't understand why?
Because I thought the content of the ChartMenu was also before wrapped in Columns and Rows (and wondered if this aren't good entry and exit points), etc. and so I still wondered why a Menu Popup or Dialog Popup would force
the whole Screen to recompose. Then again in the article Zach writes "You might be surprised to find out (and I often forget) that common layouts like Column, Row, and Box are all inline functions."
and "Because the body of inline composable functions are simply copied into their call sites, such functions do not get their own recompose scopes."
That got me interested and I changed the function declaration from

fun ChartMenu(viewModel : AnalyseViewModelCompose)

to

inline fun ChartMenu(viewModel : AnalyseViewModelCompose)

... and guess what? Right, again it didn't work! So it's really important to understand recompose scopes and realize that Column, Row, Box etc. are inline functions without own recompose scopes!
I hope I got it right and I hope you could also learn something! Thanks again so much for your kind help, i really appreciate that!

[Ronald Wolvers]

That's awesome! Very happy to hear that it works and thanks for sharing! That inlining might come in handy 🤔