Has anyone here migrated from Accompanist SwipeRefresh to the new pullRefresh modifier and suddenly ...

# compose

[harry248]

Has anyone here migrated from Accompanist SwipeRefresh to the new pullRefresh modifier and suddenly experienced a stuck indicator (like in the video)?

Screen_Recording_20221122_154110_OCM v200 (223261533)-develop.mp4

[harry248]

Only seems to happen when there are nested lazy layouts (here a LazyGrid with inner LazyRow's).

[Louis Pullen-Freilich [G]]

There are two known issues that should be fixed for the next release:

1. Apply Modifier.clipToBounds() before the Modifier.pullRefresh()
2. What is happening inside onRefresh - are you setting refreshing to true for the indicator?

[harry248]

Will try first, the second point we are already doing.

[Louis Pullen-Freilich [G]]

It depends how you are setting it, if you do something like:

var refreshing by remember { mutableStateOf(false) }

val state = rememberPullRefreshState(refreshing, onRefresh = {
    refreshing = true
    refreshing = false
})

(or some other conditional delay that may be less than a frame in length)

Then this could also cause the problem

[Louis Pullen-Freilich [G]]

So you could try by adding some delay between true and false

[harry248]

Adding an additional delay did work. Beforehand we set the state depending on the request/response time which may be very fast if the response was served from the http cache - though that wasn't a problem using the accompanist variant.

[jasu]

This swipe animation of top bar (including offer, textfield) is very smooth. can u brief how did you achieve this?

[harry248]

@jasu That uses the ScrollableState to determine whether or not it should collapse. The "extra" app bar contents (the textfield, the filter button and the large title), the app bar elevation and background color then hide/show using a mix of AnimatedContent and animateXasState. We are also using a SubcomposeLayout to pass the app bar height as PaddingValues to the lazy layout so that it can use that (top value) as the contentPadding .

[jasu]

Ooo, I see. Thanks for that brief

[Louis Pullen-Freilich [G]]

Adding an additional delay did work. Beforehand we set the state depending on the request/response time which may be very fast if the response was served from the http cache - though that wasn't a problem using the accompanist variant.

Yes this is a bug - the fix will be available in the next release so you won't need to add the delay (although for good user experience you may want to consider showing the indicator for a minimum amount of time so the user knows the refresh was successful / happened)

[harry248]

Ok thanks for the info and recommendations @Louis Pullen-Freilich [G]!