IssueTracker

Oh I forgot to mention that I thought it might be connected to this issue: https://issuetracker.google.com/issues/243778589. But after trying 2.5.2 I can say that the issue persists.

Please provide a minimal sample project along with the minimal steps to recreate the issue in the project.

Sorry for the delay. I got a working example here: https://github.com/Del-S/issues. The project is set up to crash when navigating to ThirdFragment (nested nav graph) with poping the graph.

I poked into it a little bit and it seems to be connected to SafeArgs gradle plugin. When safe args is used to navigate to ThirdFragment (with nested graph poped) it will try to recreate te parent but there were no arguments passed so it crashes.

Steps to reproduce:

1. Navigate from Second Fragment to Child nav graph (with non-nullable parameters).
2. Navigate to Third fragment using SafeArgs and the app crashes.

Crash log:

Process: cz.dels.issues, PID: 1743
java.lang.NullPointerException: null cannot be cast to non-null type kotlin.Long
at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:352)
at androidx.navigation.NavType$Companion$LongType$1.get(NavType.kt:342)
at androidx.navigation.NavArgument.verify(NavArgument.kt:76)
at androidx.navigation.NavDestination.addInDefaultArgs(NavDestination.kt:502)
at androidx.navigation.NavController.addEntryToBackStack(NavController.kt:1865)
at androidx.navigation.NavController.addEntryToBackStack$default(NavController.kt:1813)
at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1721)
at androidx.navigation.NavController$navigate$4.invoke(NavController.kt:1719)
at androidx.navigation.NavController$NavControllerNavigatorState.push(NavController.kt:287)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:246)
at androidx.navigation.fragment.FragmentNavigator.navigate(FragmentNavigator.kt:162)
at androidx.navigation.NavController.navigateInternal(NavController.kt:260)
at androidx.navigation.NavController.navigate(NavController.kt:1719)
at androidx.navigation.NavController.navigate(NavController.kt:1545)
at androidx.navigation.NavController.navigate(NavController.kt:1472)
at androidx.navigation.NavController.navigate(NavController.kt:1930)
at cz.dels.issues.SecondFragment.onViewCreated$lambda-0(SecondFragment.kt:38)
at cz.dels.issues.SecondFragment.$r8$lambda$XDYnOS_cYrafiNQ5rcCu1WCn0IE(Unknown Source:0)
at cz.dels.issues.SecondFragment$$ExternalSyntheticLambda0.onClick(Unknown Source:2)

Note: If in step 2 SaveArgs is not used then navigation works correctly. More information is here: https://github.com/Del-S/issues/blob/master/app/src/main/java/cz/dels/issues/SecondFragment.kt#L37.

Ups a typo: Navigate from Second First Fragment to Child nav graph (with non-nullable parameters).

Note: sorry for the spam but I am not able to edit my own comment.

This has been fixed and will be available in navigation 2.6.0-alpha08

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

• androidx.navigation:navigation-runtime:2.6.0-alpha08

Because, not everybody uses compose navigation. There are third party libraries which best suits for some use-cases. For example, we used Decompose which is multi-platform library. Transition could be managed by parent @Composable function.

Hi, I know some people like me are waiting to see how this develops, and Ian Lake shared an update on Slack today which I thought was very helpful:

[Transitions in navigation-compose are] definitely coming. How transitions in Compose work is that you need to hold onto all state until the exit transition actually completes (otherwise the state just instantly disappears). That's very different from the View world where a snapshot of the Views would be animated out. It means some infrastructural work is needed in Navigation to support that delayed removal of state, but it has also meant that we've been working very closely with @Doris Liu on exactly what that transition APIs should look like to set you up for future work like shared elements, etc.

Re #11 - Navigation Compose is not in beta - it is currently at Navigation Compose 1.0.0-alpha09.

This is still planned for the first stable release of Navigation Compose.

I can see the MR merged... Any plans to release this feature?

This issue isn't market as fixed.

My guess is that the box modification + injected modifier will allow adding modifiers to handle transitioning between screens.

why delayed again and again?

Why not give Navigator Compose a try. It provides some built-in animation as well!

Seems like they are almost there https://twitter.com/doris4lt/status/1405239954809102337?s=20

Sorry I don't get the point. Why always uses Crossfades effect? Could we change to different transition effect?

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.