IssueTracker

I believe this should be already possible with APIs we expose in 1.4+. The only part needed for usecase is to open the way to remove overscroll from the Modifier.scrollable and/or LazyLists?

Yes exactly. If we have control over the overscroll effect (either to replace or augment the default behavior) then this is already possible.

This should be possible with scrollable which exposes an OverscrollEffect parameter, but not for lazy APIs currently. Probably we will add support for configuring that on lazy APIs as well in the future

Yes this is possible with scrollable although in my experience most people use the (subjectively) more convenient verticalScroll (with the nice default behaviour) and its not exposed on that API.

In any case, we need this on lazy APIs as that what we use for this particular screen (Its a very long list of components and a Column will not suffice)

So I tried this & I was able to very easily implement what we needed with the current apis. I think they are intuitive enough.

The one thing that stood out to me was the fact that scrollable applies the effectModifier directly to the scroll container unconditionally, not a problem for the common case, but for our use case, the header image (that should be scaled) is nested within the scrollable container.

Above just meant that I had to have my effectModifier as a no-op and instead expose the graphicsLayer { scale = ... } modifier directly for the header image to use

The one thing that stood out to me was the fact that scrollable applies the effectModifier directly to the scroll container unconditionally, not a problem for the common case, but for our use case, the header image (that should be scaled) is nested within the scrollable container.

Yes, we plan to separate the controller / effect part of the API, to make it easier to apply the effect separately. Thanks for confirming that this is needed for your use case as well! If you have any sample code you can share of how you implemented this it would be helpful to see and make sure we can support it properly with any new API changes

Yeah sure, the gist of the implementation is basically:

@Composable
private fun rememberScalePhotoOverscrollEffect(): ScalePhotoOverscrollEffect {
  val density = LocalDensity.current
  return remember(density) { ScalePhotoOverscrollEffect(with(density) { 148.dp.toPx() }) }
}

// Todo: Its not possible to actually scale the header photo yet, see b/266550551
private class ScalePhotoOverscrollEffect(private val maxPullDistance: Float) : OverscrollEffect {
  var pullDistance by mutableStateOf(0f)
  val scale by derivedStateOf { 1f + (0.1f * pullDistance / maxPullDistance) }
  val modifier = Modifier.graphicsLayer { scale(scale) }

  override val isInProgress get() = pullDistance > 0f

  // This modifier is unconditionally applied to the scrolling component.
  // Make it a no-op & apply [modifier] to the image instead
  override val effectModifier = Modifier

  override fun applyToScroll(delta: Offset, source: NestedScrollSource, performScroll: (Offset) -> Offset): Offset {
    if (source != NestedScrollSource.Drag) return performScroll(delta)
    // Todo: Handle reverse main axis drag here

    val available = delta - performScroll(delta)
    pullDistance = (pullDistance + available.y).coerceIn(0f, maxPullDistance)

    return delta // consume it all, the system doesn't need it lol
  }

  override suspend fun applyToFling(velocity: Velocity, performFling: suspend (Velocity) -> Velocity) {
    coroutineScope {
      launch { // Fling is our cue to start decay animation, animate back to zero
        if (pullDistance != 0f) {
          animate(
            initialValue = pullDistance,
            targetValue = 0f,
            animationSpec = spring(),
            block = { value, _ -> pullDistance = value },
          )
        }
      }
      launch { // While also performing the default fling
        performFling(velocity)
      }
    }
  }
}

Is it still the plan to overhaul the overscroll implementation?

Amazing. Sounds good. I'll remain on the lookout.

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3300456

Adds overloads for scroll and lazy APIs that allow specifying overscroll

Adds overloads for scroll and lazy APIs that allow specifying overscroll

Bug: b/266550551
Fixes: b/234274772
Fixes: b/224572538
Fixes: b/353805117
Test: new tests
Relnote: "Adds overloads to horizontalScroll, verticalScroll, LazyColumn, LazyRow, LazyHorizontalGrid, LazyVerticalGrid, LazyHorizontalStaggeredGrid, LazyVerticalStaggeredGrid, HorizontalPager, and VerticalPager with support for specifying a custom OverscrollEffect. The provided OverscrollEffect will receive events, and be rendered within the bounds of these components. Note that drawing the same OverscrollEffect twice is unsupported - so you cannot draw the same OverscrollEffect provided to one of these components separately with Modifier.overscroll. The use case of drawing the overscroll outside of the bounds of these components will be addressed separately in the future."
Change-Id: I2dc42851c824a63e495312246eb5389c33121af8

Update: we are currently working on stabilising overscroll, and we just landed a change to expose OverscrollEffect in vertical/horizontalScroll and lazy APIs. However after some discussions we decided not to go ahead with the API separation mentioned previously, this causes a few ergonomic problems and adds a lot of complexity in general in order to improve a minority of cases.

Instead though we can probably just provide a wrapper extension API like OverscrollEffect#withoutDrawing() (naming TBD, note that also this could be written in user code currently) that creates a new OverscrollEffect instance that just calls through to the initial one, but without applying the modifier. This way usage would look something like:

val myOverscrollEffect = remember { MyOverscrollEffect() }

// LazyColumn will dispatch events to overscroll, but will not render anything as this will return an empty modifier
LazyColumn(overscrollEffect = myOverscrollEffect.withoutDrawing()) {
    // some content
    ...
    // Render the custom overscroll effect on the box, which is being driven by LazyColumn
    Box(Modifier.overscroll(myOverscrollEffect))...
}

not sure im getting this, how would this work in a normal lazy column with items? For example i wanna apply the same overscroll effect as in IOS, would the items in the lazy column have bounce effect? or only the box would bounce? Thanks for the feature btw

not sure im getting this, how would this work in a normal lazy column with items? For example i wanna apply the same overscroll effect as in IOS, would the items in the lazy column have bounce effect? or only the box would bounce? Thanks for the feature btw

If you just want the lazy column to apply a different overscroll effect, you can just provide the overscrollEffect parameter to the lazy column. What I mentioned above is for custom cases where you want the overscroll to apply outside the bounds of the lazy column, or to a specific item inside - but not to the entire list and all of its items.

Got it! Very niche usecase but its worth having at least the possibility

Project: platform/frameworks/support
Branch: androidx-main
Author: Louis Pullen-Freilich <lpf@google.com>
Link:      https://android-review.googlesource.com/3328184

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling

Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling 
 
These APIs allow overscroll to have events dispatched to it by one component, and rendered in a separate component. 
 
Fixes: b/266550551 
Fixes: b/204650733 
Fixes: b/255554340 
Fixes: b/229537244 
Test: OverscrollTest 
Relnote: "Adds OverscrollEffect#withoutDrawing and OverscrollEffect#withoutEventHandling APIs - these APIs create a wrapped instance of the provided overscroll effect that doesn't draw / handle events respectively, which allows for rendering  overscroll in a separate component from the component that is dispatching events. For example, disabling drawing the overscroll inside a lazy list, and then drawing the overscroll separately on top / elsewhere." 
Change-Id: Idbb3d91546b49c1987a041f959bce4b2b09a9f61

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

• androidx.compose.foundation:foundation:1.8.0-alpha06
• androidx.compose.foundation:foundation-android:1.8.0-alpha06
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha06
• androidx.compose.foundation:foundation-linuxx64stubs:1.8.0-alpha06

Thank you!