A modern programming language that makes developers happier.

kotlinlang

Screen_Recording_20221122_154110_OCM v200 (223261533)-develop.mp4

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

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

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? 

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

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

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

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.

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

<@U02U1ERMBF1> 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` .

&gt;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)

Ok thanks for the info and recommendations <@UMCJAPF63>!