animatedVectorResource AVD repeating animation is not repeating [199304067]

Fixed

Bug

Status Update

No update yet.

Description

lc...@gmail.com

created issue #1

Sep 9, 2021 04:11AM

Component used: androidx.compose.animation:animation-graphics

Version used: 1.1.0-alpha03

Devices/Android versions reproduced on: all devices and android versions

If this is a bug in the library, we would appreciate if you could attach:

Don't think this is a bug, more like a feature gap?

Code snippet of my avd composable

@ExperimentalAnimationGraphicsApi
@Composable
fun AnimatedVectorDrawable(
    modifier: Modifier = Modifier,
    @DrawableRes id: Int,
    startAnimation: Boolean = false
) {
    val image = animatedVectorResource(id)
    Image(
        painter = image.painterFor(startAnimation),
        modifier = Modifier
            .wrapContentSize(align = Alignment.Center)
            .then(modifier),
        contentDescription = null
    )
}

Avd repeating animations are not repeating, and looks like the current painter api also does not support this use case. Does not seem to respect the avd's android:repeatCount="-1" attribute. Avd used to replicate "issue" attached.

circle_progress_spinner_avd.xml

3.4 KB

Download

Comments

ma...@google.com <ma...@google.com> Sep 13, 2021 06:00PM

Assigned to nj...@google.com.

nj...@google.com <nj...@google.com> #2Sep 13, 2021 06:18PM

Reassigned to ya...@google.com.

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

lc...@gmail.com <lc...@gmail.com> #3Dec 7, 2021 11:47AM

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

lc...@gmail.com <lc...@gmail.com> #4Dec 17, 2021 04:51AM

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.

ya...@google.com <ya...@google.com> Mar 23, 2022 08:36AM

Marked as fixed.

ap...@google.com <ap...@google.com> #5Mar 23, 2022 08:37AM

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!

lc...@gmail.com <lc...@gmail.com> #6May 17, 2022 06:06AM

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)

lc...@gmail.com <lc...@gmail.com> #7May 19, 2022 04:09AM

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!

lc...@gmail.com <lc...@gmail.com> #8May 25, 2022 03:26PM

Whoever accepted this issue, you probably have 67 thousand issues, but since the error message is the same, can you please check if this focus changing keyevent stuff problem is the same as with BasicTextfield ?

https://issuetracker.google.com/issues/215186908
<3

an...@sigma.software <an...@sigma.software> #9Jun 26, 2024 10:27AM

Project: platform/frameworks/support
Branch: androidx-main

commit ef81023fc0de83421e4779f6bef8e14d4ef6a158
Author: Ralston Da Silva <ralu@google.com>
Date: Mon Feb 14 18:00:04 2022

Refactor focus search to accept a lambda

Refactoring the focus search code so that it runs a lambda
once it finds the next item. This is needed so that we can
request focus on the next item when the next item is beyond
visible bounds. We need this because beyond bounds layout
requests return a block and the items are guaranteed to be
available only within the scope of the block.

For more info, see go/compose-focus-beyondbounds

Bug: 184670295
Test: Internal refactoring, existing moveFocus() tests
Change-Id: I6545ef1a094f5bbe37eb6f861d1ea5ab6a7ec926

M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/OneDimensionalFocusSearch.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusTraversal.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/FocusManager.kt
M compose/ui/ui/src/commonMain/kotlin/androidx/compose/ui/focus/TwoDimensionalFocusSearch.kt

https://android-review.googlesource.com/1985706