Calling Activity.setContentView again breaks recomposition of composables in the view hierarchy [197773820]

Fixed

Bug

Status Update

No update yet.

Description

lo...@gmail.com

created issue #1

Aug 26, 2021 10:51AM

Hello,

I found a bug that cost me one day to understand what triggers it, and I want to thank Adam Powell for helping me a bit to figure out what's going on.

TL;DR

In short, if you call setContentView with the same view hierarchy a second time after the initial render, the composables in the hierarchy will stop recomposing, which breaks/freezes everything in them.

Jetpack Compose release version: 1.1.0-alpha02 (also reproduces with 1.0 and 1.0.1)

Android Studio Build: irrelevant

Kotlin version: irrelevant

Reproducer

I attached a self-contained Kotlin file (MainActivity.kt) that reproduces the issue.

You can paste it in any Compose project over the existing MainActivity and try yourself.

However, I put below reproducing steps anyway.

Steps to Reproduce:

Create a ComposeView that displays a State that changes over time.
Put that instance into a local property.
Call setContentView passing that instance in the onCreate function of the host ComponentActivity.
Launch a coroutine in lifecycleScope
Call awaitFrame(), or delay(1500)
Call setContentView again, with the very same instance of the ComposeView created earlier.

Expected outcome

The composable keeps display the updates of the State instance.

Actual result

Once the setContentView is called the second time, the composable stops displaying the updates of the State instance.

The Slack thread from start to finish

If you want to see what was the process from facing the issue, to finding why it happened, you can take a look at this thread on Kotlin's Slack:

https://kotlinlang.slack.com/archives/CJLTWPH7S/p1629894233127300

What is likely the culprit IMHO

In the Android platform, the setContentView method in Activity is idempotent. Calling it a second time with the same view hierarchy while the Activity is not in the destroyed state will have no effect.

However, that contract seems to have been broken by the ComponentActivity class from AndroidX, as it's also calling a function named initViewTreeOwners().

The name of that function indicates that it's been designed for initialization, something which by definition, is supposed to happen only once. However, a setter doesn't generally have such constraints, at least, not because it's a setter (as the setContentView function is).

I think that this initViewTreeOwners() function being called again is what messes up ComposeView or its underlying mechanisms, putting them in a state they should not be in.

However, the issue might not be in ComponentActivity itself, but in the Compose runtime, or both.

Thanks for reading, and have a great day!

Louis CAD

MainActivity.kt

2.2 KB

Download

Comments

je...@google.com <je...@google.com> Aug 26, 2021 12:00PM

Assigned to ad...@google.com.

lo...@gmail.com <lo...@gmail.com> #2Aug 26, 2021 12:55PM

Please ensure this works with LazyColumn, LazyRow and LazyVerticalGrid when this change is implemented. Thanks!

ad...@google.com <ad...@google.com> #3Aug 27, 2021 09:11PM

Accepted by ad...@google.com.

Thanks Nick, LazyList is the internal component that all these composables are built out of.

lo...@gmail.com <lo...@gmail.com> #4Aug 27, 2021 10:17PM

If I could add a small additional feature request here:

Hopefully the implementation of focus scrolling in lazy lists leaves room for the easy customization / overriding of the behavior, since TV UI often has unique snapping requirements around the focused item.

I've started to come up with my own compose API for this, and while I'm happy with the results so far, I'm hoping that any future built-in scrolling functionality will play nicely with it, or as a better alternative - provide all of the necessary configurations.

ap...@google.com <ap...@google.com> #5Oct 1, 2021 08:19PM

Marked as fixed.

To add a specific case to #4's comment on configurability:

In View Android apps, scrolling typically occurs once focus is moved to an item outside the viewport. With such behavior, however, the user is given no indication that there are more items to see. To solve this, it would be useful to be able to specify a scroll offset or similar that triggers scrolling even before reaching an item that is outside of the scroll viewport. This could for instance be a fixed dp value or .5 "list item heights" ahead. That way, the user would be informed that there is more to see.

In any case, glad to see this being of high priority!

lo...@gmail.com <lo...@gmail.com> #6Feb 9, 2022 09:13PM

Looks like focus support for LazyLists did not make it to 1.1.0-beta01.

Custom implementation that scrolls a LazyList to bring the focused element to view still almost works, but occasionally the focus moves to a random input node. The random input node can be uninitialized causing an exception at:

2021-11-01 09:54:51.247 E/MessageQueue-JNI: java.lang.IllegalStateException: KeyEvent can't be processed because this key input node is not active.
    at androidx.compose.ui.input.key.KeyInputModifier.processKeyInput-ZmokQxo(KeyInputModifier.kt:75)
    at androidx.compose.ui.platform.AndroidComposeView.sendKeyEvent-ZmokQxo(AndroidComposeView.android.kt:439)
    at androidx.compose.ui.platform.AndroidComposeView.dispatchKeyEvent(AndroidComposeView.android.kt:446)