IssueTracker

Thanks! This looks like a bug, thank you for reporting!

Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <jossiwolf@google.com>
Link:      https://android-review.googlesource.com/3278651

Update AnchoredDraggable target calculation logic

Update AnchoredDraggable target calculation logic

We were previously relying on currentValue and the next closest anchor in the drag direction, but the simpler and more reliable way is to look at the left and right anchors as the window.

Relnote: Fixed a bug where positional thresholds passed to AnchoredDraggableDefaults.flingBehavior were not considered correctly in some scenarios.
Test: anchoredDraggable_fling_offsetPastHalfwayBetweenAnchors_beforePosThreshold_doesntAdvance
Bug: 367660226
Bug: 366003852
Change-Id: Ifdf0dfcf3d7ff8288affee56e7092bbed473d6ab

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

• androidx.compose.foundation:foundation:1.8.0-alpha04
• androidx.compose.foundation:foundation-android:1.8.0-alpha04
• androidx.compose.foundation:foundation-jvmstubs:1.8.0-alpha04

Using the new version 1.8.0-alpha04 does not seem to resolve the issue for me. I tested with the same setting as the reported issue:

            // it doesn't matter what you put here a the multiplier, the positionalThreshold is always 50%
            positionalThreshold = { d -> d * 0.9f },
            velocityThreshold = { Float.POSITIVE_INFINITY },

Same. I've run this again on 1.8.0-alpha04. When using

positionalThreshold = { d -> d * 0.1f }

Dragging up to 10% or between 50% and 90% will cause it to snap back to the start anchor. Dragging between 10% and 50% or past 90% will cause it to snap to the end anchor.

I would expect It to only return if dragged less than or equal to 10% and snap to the end if dragged greater than 10%.

When using

positionalThreshold = { d -> d * 0.9f }

It acts as if the threshold has been set to 50%.

From what I can tell, nothing has changed about the behavior.

Thanks, we will investigate and update this issue.

Project: platform/frameworks/support
Branch: androidx-main
Author: Jossi Wolf <jossiwolf@google.com>
Link:      https://android-review.googlesource.com/3343747

Update AnchoredDraggable target calculation logic

Update AnchoredDraggable target calculation logic 
 
There was a missed case when the velocity was negative. 
 
Test: New tests with more parameter permutations 
Fixes: 367660226 
Bug: 376931805 
Relnote: "Follow-up fix for an issue in AnchoredDraggable's target calculation where it could settle at the wrong anchor for specific swipes." 
Change-Id: I23b8773d3a694aa3c8de6a8f34b9d7fb54cfe560

What is the fix version?

We will comment on the issue when it has been included in a release. Until then, you can try the snapshot versions from androidx.dev.

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

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

#15, please report a new issue with a full reproduction case and the versions you are using. Thank you!

Running compose foundation 1.8.0-alpha07

I'm using AnchoredDraggable with nested scrolling. When I drag and release the lazy layout sometimes the draggable settles correctly and sometimes it doesn't even when i drag and release past the threshold (positionalThreshold = { distance -> distance / 2f }.

    internal fun nestedScrollConnection(
        dragState: AnchoredDraggableState<Anchors>,
        decayAnimationSpec: DecayAnimationSpec<Float>,
        orientation: Orientation = Orientation.Vertical,
    ): NestedScrollConnection = object : NestedScrollConnection {

        override fun onPreScroll(
            available: Offset,
            source: NestedScrollSource,
        ): Offset {
            val availableDelta = available.toFloat()

            return if (
                availableDelta < 0f
            ) dragState.dispatchRawDelta(availableDelta).toOffset()
            else Offset.Zero
        }

        override fun onPostScroll(
            consumed: Offset,
            available: Offset,
            source: NestedScrollSource,
        ): Offset {
            val availableDelta = available.toFloat()

            return if (
                availableDelta >= 0f
            ) dragState.dispatchRawDelta(availableDelta).toOffset()
            else Offset.Zero
        }

        override suspend fun onPreFling(
            available: Velocity,
        ): Velocity {
            val availableDelta = available.toFloat()

            val consumedOffset = if (availableDelta < 0f) dragState.animateToWithDecay(
                velocity = availableDelta,
                targetValue = Anchors.Collapsed,
                decayAnimationSpec = decayAnimationSpec,
            ) else 0f

            return Velocity(
                x = 0f,
                y = consumedOffset,
            )
        }

        override suspend fun onPostFling(
            consumed: Velocity,
            available: Velocity,
        ): Velocity {
            val availableDelta = available.toFloat()

            if (
                availableDelta > 0f
            ) dragState.animateToWithDecay(
                velocity = availableDelta,
                targetValue = Anchors.Expanded,
                decayAnimationSpec = decayAnimationSpec,
            )

            dragState.settle(animationSpec = spring())

            return Velocity(x = 0f, y = availableDelta)
        }

        private fun Float.toOffset(): Offset = Offset(
            y = if (orientation == Orientation.Vertical) this else 0f,
            x = if (orientation == Orientation.Horizontal) this else 0f,
        )

        @JvmName("offsetToFloat")
        private fun Offset.toFloat() = if (orientation == Orientation.Horizontal) x else y

        @JvmName("velocityToFloat")
        private fun Velocity.toFloat() = if (orientation == Orientation.Horizontal) x else y
    }

Hi, this seems to be a different issue. Please provide a full reproducer in a new issue so we can investigate. Thank you!

Looking at the release notes (https://developer.android.com/jetpack/androidx/releases/compose-foundation) is likely the most straightforward way. Since this issue has a few +1 votes, please keep the comments to the original issue :)

Unfortunately, this still does not work. I'm on 1.8.0-alpha07 and when I use 0.9f from the original example it still snaps at 50%.

#21, are you using exactly the same code shared in #1?

Yes, I'm the OP.

sdkmanager "build-tools;build-tools-version"

Apologies #23, but I am not able to reproduce the issue with the sample from #1, running on Compose 1.8.0-alpha08. Can you please provide a full reproducer project as a zip? Thanks!

I am experiencing an issue with the transition. When my app is opened, the splash is shown and on exit transition it has a broken crossfade. Also, after this, no interaction is registered by the app. This issue is introduced in 2.4.0-alpha05

I am experiencing the same issue as #28. I believe it is caused by the conditional navigation pattern. My existing code, which looks something like this:

@Composable
fun ScreenThatRequiresAuth(navController: NavController, authenticated: Boolean) {
    if (authenticated) {
        // emit UI content for this screen
    } else {
        navController.navigate("login-screen")
    }
}

no longer works because the navigation no longer happens instantaneously, so navController.navigate("login-screen") is called repeatedly on subsequent recompositions as the animation proceeds. Therefore we are indefinitely navigating and crossfading, resulting in that visual glitch. If there is no way navigate without an animation anymore, then alpha05 breaks most implementations of this officially recommended pattern. My current workaround is to navigate inside of a LaunchedEffect block so that it doesn't happen again on recompositions while animating the transition. The UI content of ScreenThatRequiresAuth is still not shown if we have no auth, but now it is less clean than an if/else statement:

@Composable
fun ScreenThatRequiresAuth(navController: NavController, authenticated: Boolean) {
    LaunchedEffect(authenticated) {
        if (!authenticated) {
            navController.navigate("login-screen")
        }
    }
    if (authenticated) {
        // emit UI content for this screen
    }
}

This works, it just means that the login screen has to fade in from nothing, which may look awkward, and now the code required to implement this pattern is less straightforward. Since we should not be showing ScreenThatRequiresAuth at all if there is no auth, it doesn't make sense to fade it out -- this transition should happen without an animation. When will this be possible?

Navigating on recomposition seems like an anti pattern to me. I think calling 'navigate' should only happen upon a UI event. If you want to show a login screen, you should probably check if the app has persisted credentials and then either show the log-in (if there are no credentials) screen or the main screen (if there are some).

The composable could look like this:

@Composable
fun ContentView(
    registration: Registration
) {
    when (registration) {
        is Registration.Registered -> MainView(...)
        else -> OnboardingView(...)
    }
}

Navigation is then happening inside the MainView composable and the OnboardingView composable. There you have your destinations like such:

@Composable
fun MainView(
    ...
) {
    val navController = rememberNavController()
    val actions = remember(navController) { NavActions(navController) }
    NavHost(navController = navController, startDestination = Destinations.Home) {
        composable(Destinations.Home) {
           HomeView(
               profileSelected = { navController.navigate(route = Destinations.Profile) },
               ...
           )
        }
        ...
    }
}

Handling the credentials could be done in a separate class, which is instantiated in an activity:

sealed class Registration {
    class Registered(val credentials: Credentials): Registration()
    object Onboarding: Registration()
}

class AppState(private val persistence: Persistence): ViewModel() {

    companion object {
        var registration by mutableStateOf<Registration>(Registration.Onboarding)
            private set
    }

    init {
        load()
    }

    private fun load() {
        val credentials = persistence.readCredentials()
        registration = if (credentials != null)
            Registration.Registered(credentials)
        else
            Registration.Onboarding
    }

    fun setCredentials(credentials: Credentials) {
        persistence.saveCredentials(credentials)
        registration = Registration.Registered(credentials)
    }

}

As of compose 1.0.1 many of the Compose Animation APIs are still @Experimental.

In the interest of providing a solution for Navigation with custom Compose Animations as soon as possible, we opted to provide a new module in Accompanist Navigation Animation. Once all the required animation APIs become stable, which is planned as part of Compose 1.1.0, we will move the implementation back into the Jetpack Navigation library from Accompanist Navigation Animation.

The bug we will use for tracking folding the APIs back into Jetpack Navigation is here.

For more details, see the Animations in Navigation Compose blog post.

Should we still be using Accompanist Navigation Animation? We're on Compose 1.2.0-beta02 by the way.

#34 I found it's easier & much more flexible to just implement your own navigation solution. It need not be super complicated in Compose. The Jetpack nav library really isn't worth the hassle.

I can't understand why you have such a negative view on compose and the navigation approach given. I use the AnimatedNavHost together with the recommendations from this talk and had 0 issues so far. With that, you have animations, multiple subgraphs/backstacks, type safe navigation arguments and support for the rest of compose.