IssueTracker

Thanks fir this feature request.

Tricky request you have here as it involved more than one request to solve this properly :)

Partially this will be possible, but via slightly different API. I need to see for sure, but ScrollableColumn and friends will consume InteractionState that have Interaction.Drag inside when user is dragging, and, probably, settling (names TBD) when it's flinging. This way, you will be able to react and do smth on the interaction that are happening inside the scroll.

By do smth I mean smth that doesn't affect overall scrolling, but it seems like you want to have exactly this (snapping behaviour). This is somewhat tricky to do right, as snapping after the fling has ended will result with the bad user experience as you want to start snapping way before the fling has ended. So, there should be a proper way to make such UI

Several alternatives here (both from our side and your side):

1. Wait until we expose InteractionState and listen to it + scrollState.value to trigger animations. Tricky and fragile as you will have two sources of truth.
2. Make your own component that does that behaviour using current version of nested scrolling. You can make your own component that uses Modifier.scrollable that wraps ScrollableColumn. When ScrollableColumn hits the bound, dragging deltas will flow to the parent above (not fling though), so you can detect it and trigger anything you like.
3. Wait until we provide proper nested scrolling support and do 2 properly to support this.

I will leave this open until we have InteractionState supported, let me know if you have any questions

Thanks for your response

Indeed waiting for the fling to end is bad for user experience.

1. Would this also expose the velocity? I feel like this solution would basically be the same thing than using rawDragGestureFilter with a less-weird api (except the gesture filter is not getting the velocity). If I'm wrong about it being the same kind of solution with a different API please correct me.

The issue with not having the velocity propagated is that the implementation is not great, since we don't know in which direction the scroll was occurring. So we can only snap depending on scrollState.value. This could be solved by saving the initial position when the drag starts and compare with the value when stopping, but it feels really hacky. So having this kind of information in the state (velocity, and thus direction by its sign, and also the initial value from drag started).

2. It does feel like the current implementation of the CollapsingToolbar view implementation. But I'm not sure I understood it completely

When ScrollableColumn hits the bound, dragging deltas will flow to the parent above What do you mean by "hits the bounds"?

Wouldn't the parent wrapping the ScrollableColumn always intercept the scroll events since higher in the hierarchy? I'm not sure how this would work, since it's not a huge priority, I don't mind waiting proper nested scrolling support. Though I'm not sure how this would solve the issue here, so would appreciate more details if you have time to spare :)

I do feel like snapping is a bit tricky to implement, maybe I should've opened a different feature request for this :)

Again thanks for the details

Comment #6, could you file a new bug for that issue? It's separate enough that it is worth tracking apart from this issue. Essentially the difference is by default PullRefresh does not clip, so the indicator is drawn outside the bounds. You can change this in your project by doing:

Box(Modifier.clipToBounds().pullRefresh(state)) {

But maybe we should investigate better documentation for this / considering default behaviour

Hi, in what version can I see this fix ?

It hasn't released yet, but it should be in 1.4.0-alpha03 when it released

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.compose.material:material:1.4.0-alpha03

The Box(Modifier.clipToBounds().pullRefresh(state)) { did not fix the issue. A LaunchedEffect delegated refreshing state fixes the issue:

@Composable
@OptIn(ExperimentalMaterialApi::class)
fun PullRefreshBox(
    modifier: Modifier = Modifier,
    refreshing: Boolean,
    onRefresh: () -> Unit = {},
    content: @Composable () -> Unit,
) {
    // The LaunchedEffect is needed to fix the hiding of the indicator: https://issuetracker.google.com/issues/248274004
    // Without this workaround the indicator would be visible even if the loading finished
    var isRefreshingWorkaround by remember { mutableStateOf(refreshing) }
    LaunchedEffect(key1 = refreshing) {
        isRefreshingWorkaround = refreshing
    }
    val state = rememberPullRefreshState(isRefreshingWorkaround, onRefresh)
    Box(
        modifier = modifier.pullRefresh(state),
    ) {
        content()
        PullRefreshIndicator(
            modifier = Modifier.align(Alignment.TopCenter),
            refreshing = isRefreshingWorkaround,
            state = state,
            contentColor = MaterialTheme.colorScheme.primary,
        )
    }
}

I couldn't reproduce anything with the code provided, please file a new bug with a detailed reproduction, with the latest version of the material library.

I can still reproduce the bug on compose version 1.4.0 without the workaround above, any update about this bug?

Please file a new bug with a standalone sample project that reproduces this issue, I cannot reproduce on my end so it might be specific to your setup.

WorkAround

        if (state.progress > 0 || isRefreshing)  PullRefreshIndicator(
            refreshing = isRefreshing,
            state = state,
            modifier = Modifier.align(Alignment.TopCenter)
        )

Could you share some sample code to reproduce the issue? Thanks

I'm still able to reproduce this issue but in a corner case: the refresh runs too fast and isRefreshing keeps false all the time, and refreshState.distanceFraction will be 1f which makes the indicator visible.
Here is a sample project: https://github.com/Tlaster/PullRefreshIssue

I still have the same issue years later. If I use a pulltorefresh box and in the "onRefresh" don't have a function that takes a process time before setting isRefreshing to false (Like delay or a suspend fun that is not super fast), then the loading indicator will get stuck and never dissapear.

setting a delay of hald a second fixes it but it's not optimal. Please, it's been years and this is an easy fix. Please, fix it.