Hi, I'm facing weird behavior of `mutableInteractionSource's` pressed state. So simplified version o...

# compose

[Erlan Amanatov]

Hi, I'm facing weird behavior of mutableInteractionSource's pressed state.
So simplified version of my composable looks like this

@Composable
fun Sbn(
    interactionSource: MutableInteractionSource = remember { MutableInteractionSource() }
) {
    val pressed by interactionSource.collectIsPressedAsState()
    val target by rememberUpdatedState(newValue = if (pressed) Color.Red else Color.Green)
    Box(
        modifier = Modifier
            .padding(24.dp)
            .size(64.dp)
            .background(color = target)
            .clickable(
                interactionSource = interactionSource,
                indication = null,
                onClick = {}
            ),
    )
}

It works fine, but if I put it in a scrollable column, the pressed state works with some kind of delay. Any workarounds?
Video in thread

[Erlan Amanatov]

mis.webm

[Colton Idle]

I'm assuming scrollables have a delay in dispatching events to children because it doesn't know whether you're going to scroll or click?

[Cicero]

This looks odd, it’s a really long delay

[Albert Chang]

This is also the case for the view system. The delay is controlled by ViewConfiguration.getTapTimeout(), which defaults to 100ms in AOSP.

[Erlan Amanatov]

@Albert Chang never noticed that, ty

[Louis Pullen-Freilich [G]]

I think the problem here is not the delay, but you are doing:

val target by rememberUpdatedState(newValue = if (pressed) Color.Red else Color.Green)

If the press is short, pressed will go from false to true and back to false so quickly that it will never be reflected on screen, because the change will happen within one frame

[Louis Pullen-Freilich [G]]

What you probably want to do instead is to show the press color for a minimum duration, similar to how ripples / other press indication works

[Louis Pullen-Freilich [G]]

If you press and release the non-scrollable example within one frame you would probably notice the same thing, but it just happens more often in the scrollable case because of the logistics of how the delay is handled

[Erlan Amanatov]

As you can see on video it works fine when the column is not scrollable

[Louis Pullen-Freilich [G]]

Yes, when the column is scrollable, there is a minimum delay as mentioned above. So we delay emitting the press until we know it is a press. When you release, we emit the press and the release sequentially, which will often happen inside the same frame

[Louis Pullen-Freilich [G]]

It’s not a bug in the scrollable handling, it’s just how the delay has to be implemented for this to work prpoerly

[Erlan Amanatov]

I see, ty

[Louis Pullen-Freilich [G]]

You should be able to test this by `collect`ing the interaction source manually and launching an animation, instead of just setting the state to true and false