IssueTracker

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

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

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.

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!

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)

Apologies for pinging this thread. I'm also having the IllegalState exception issue from above. Should this be pulled out into a separate ticket as opposed to part of this one or is it all sort of the same thing? From our perspective we can get by with a custom implementation similar to above if it's stable (until the out of the box implementation is sorted later on).

As an aside thanks for all your hard work on this. Compose is a pleasure to work with!

Compose status update: Please update the Status and Status Summary fields of this bug! (or Public Status/Public Status Summary)

We just updated to Compose 1.2.0-beta01 in our project and it works much better - but we still experience a few issues witht the focus jumping around.

In our setup we have a list of LazyRow in a LazyColumn. Simplified our setup can be stated like this (the issue is also with this example):

LazyColumn {
    items(20) { verticalIndex ->
        LazyRow {
            items(20) { horizontalIndex ->
                var color by remember { mutableStateOf(Color.White) }
                Text(
                    text = "$verticalIndex,$horizontalIndex",
                    fontSize = 50.sp,
                    textAlign = TextAlign.Center,
                    modifier = Modifier
                        .size(100.dp)
                        .border(2.dp, Color.Gray)
                        .onFocusChanged { color = if (it.isFocused) Color.Red else Color.White }
                        .background(color)
                        .focusable()
                )
            }
        }
    }
}

When moving within a row by holding down the d-pad (left or right) it might sometimes lag a bit, but in the end it will end up giving focus to an expected item. However, if we navigate between the rows by holding down the d-pad (up or down) it just circles the visible views. Same goes if you just tap the d-pad quickly, but it's more consistent when holding it down.

Are we using the combination of LazyLists wrong or is there still a bug with this custom case?