IssueTracker

I'd like to add that this automatic removal of the NavGraph at the top of the stack is also making it hard for me to implement proper lateral top-level navigation.
A practical case where this kind of navigation happens is with a Material Design bottom navigation bar, where I have a NavHost above the bottom bar.

Given this navigation scheme:
A - B   (top-level)
     B1 (first sub-level)

When starting the Activity, the back stack is
0. A
1. NavGraph

If I wanted to navigate to B laterally, I would do:
navController.popBackStack(R.id.navGraph, false)
navController.navigate(R.id.B)

But the resulting back stack is:
0. B

Now, navigating between top-level destinations actually works (though popBackStack returns false); the problem arises again if I navigate to B1:
0. B1
1. B

When navigating from B1 to a top-level destination like A, the stack becomes:
0. A
1. B1
2. B

That is, A is not a top-level destination in the back stack: if I press back from A, I intend to exit the app, but I'm taken back to B1.

It would be nice to have a fixed reference to the bottom of the stack. Right now I'm working around this with a horrible ` while (navController.popBackStack()) continue`.

Is this going to be fixed?

I have the same issue with a setup as follows:

Navigation graph.

    <navigation xmlns:android="http://schemas.android.com/apk/res/android"
        xmlns:app="http://schemas.android.com/apk/res-auto"
        xmlns:tools="http://schemas.android.com/tools"
        app:startDestination="@+id/startupGraph">

        <navigation
            android:id="@+id/startupGraph"
            app:startDestination="@id/launcher_home">
            <fragment
                android:id="@+id/launcher_home"
                android:name="com.example.android.codelabs.navigation.MainFragment"
                android:label="@string/home"
                tools:layout="@layout/main_fragment" />
        </navigation>

        <navigation
            android:id="@+id/homeGraph"
            app:startDestination="@id/flow_step_one">
            <fragment
                android:id="@+id/flow_step_one"
                android:name="com.example.android.codelabs.navigation.FlowStepOneFragment"
                tools:layout="@layout/flow_step_one_fragment" />
            <fragment
                android:id="@+id/flow_step_two"
                android:name="com.example.android.codelabs.navigation.FlowStepTwoFragment"
                tools:layout="@layout/flow_step_two_fragment" />
        </navigation>

    </navigation>
   
MainFragment.

        override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
            super.onViewCreated(view, savedInstanceState)
             view.findViewById<Button>(R.id.navigate_dest_bt).setOnClickListener{
                 Navigation.findNavController(it)
                         .navigate(R.id.homeGraph, null, NavOptions.Builder()
                                 .setPopUpTo(R.id.startupGraph, false)
                                 .build())
             }
        }

FlowStepOneFragment.

        view.findViewById<View>(R.id.next_button).setOnClickListener {
            Navigation.findNavController(it)
                    .navigate(R.id.flow_step_two, null, NavOptions.Builder()
                            .setPopUpTo(R.id.flow_step_one, true)
                            .build())
        }
    }
}

Causes the following error:

E/AndroidRuntime: FATAL EXCEPTION: main
    Process: com.example.android.codelabs.navigation, PID: 12579
    java.lang.IllegalArgumentException: Navigator androidx.navigation.fragment.FragmentNavigator@d70ec6f reported navigation to unknown destination id com.example.android.codelabs.navigation:id/flow_step_two

The original issue was fixed as a result of https://android-review.googlesource.com/833717 and a number of other internal changes and that will be available in alpha08.

Discovered another issue when doing this specific set of navigation actions, so leaving this open until that part is also fixed.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit d3507cb9dab82264070c72a37dbde1dfb43ef578
Author: Ian Lake <ilake@google.com>
Date:   Tue Dec 04 14:24:32 2018

    Split pop and dispatch logic
   
    When using popUpTo, navigate() would
    internally call popBackStack(), resulting
    in additional dispatch calls to
    OnDestinationChangedListener before the
    navigate() operation itself was done.
   
    By separating the logic, we can ensure that
    we don't prematurely remove NavGraph destinations
    that should still exist after the navigate()
    operation and that developers only see a
    single final OnDestinationChangedListener callback.
   
    Test: new test
    BUG: 113611083
    Change-Id: Ib63e4156521259a945ffecf679ccb404ac192017

M       navigation/runtime/src/androidTest/java/androidx/navigation/NavControllerTest.kt
M       navigation/runtime/src/androidTest/res/navigation/nav_nested_start_destination.xml
M       navigation/runtime/src/main/java/androidx/navigation/NavController.java

https://android-review.googlesource.com/840996
https://goto.google.com/android-sha1/d3507cb9dab82264070c72a37dbde1dfb43ef578

It would be interesting to have a "popAll" option, where the whole stack will be erased, so we don't have to keep track who's on the stack to be popped or not. It would speed up things and bring less confusion as well.

I agree completely, similarly to how clearTask worked before it was deprecated.

A couple of points:
1) There really is a bug here - app:popUpTo="@+id/graph" should work as well - that's why I said 'workaround' above, not solution. We will be fixing that bug.

2) Popping everything off the stack is always a sign that you've built your graph incorrectly. That's on us though as we haven't documented well enough how to do conditional navigation (for example, the B->C sign in flow). https://issuetracker.google.com/issues/111762510 is our tracking bug for updating the conditional navigation page (https://developer.android.com/topic/libraries/architecture/navigation/navigation-conditional).

For example, in the example raised in #5, your start destination should be D.
- Splash screen should be using a splash theme (e.g., https://www.bignerdranch.com/blog/splash-screens-the-right-way/) and not be in your graph at all
- B+C should be handled as conditional navigation from D - D starts B and if you return to D without logging in, D calls finish().
- Having D as your startDestination is critical to having the right back stack when deep linking to somewhere in your graph

I realize that this is a bigger mental shift from how you've structured your apps and is a big reason why improving the documentation is an important focus for Navigation over the next few months.

So if I understand this correctly, D is a Fragment and it should call its Activity (the one and only one in the app) finish(), in case there's something wrong, like going back from the login screen?

I find this complicated and can lead to issues that resemble "callback hell", having multiple checks and flags everywhere, to know if we already navigates to some destination and if we are back and without a proper value... Can't we come up with a more streamlined solution?

D can do whatever it needs to if the user chooses not to log in, be it finishing the activity (if you know it is the root of your whole graph), calling navController.popBackStack(), or showing an inline prompt for the user to sign in. This is core business logic for your app.

One thing that you need to keep in mind is that the user can hit the home button at any point then come back to *exactly that same destination in your app* an arbitrary amount of time later. If your logins expire or if users can delete their accounts (just to offer two examples), then *every* login required destination needs to handle this exact case - punting users to your login flow then handling whether they log in or not before showing their protected content. By making that the *only* flow for handling invalid login cases in your app, you can do things the right way just once.

Good point.

About your comment on #8 (mentioned bellow):

 >>> - B+C should be handled as conditional navigation from D - D starts B and if you return to D without logging in, D calls finish().

Basically D needs to know the outcome of a task that was accomplished in B, meaning D needs to know if it was reached through opening the app (since it's a startDestination) or through pressing back in B (meaning the user canceled the login process).

Wouldn't this be a break in abstraction? My understanding was that a destination should receive it's arguments and this should be enough for it to work but in this example D needs to detect it was reached through a BACK press in B.

I don't even know how I would implement such a thing unless I start passing arguments between destinations to know about my navigation history.

I made this work, kind of: splash to main activity; starting destination D. It inflates a layout only to save state and go to the back stack as I bounce to B. If I press back, I go through the steps of restoring D--which briefly makes an appearance on screen--only to finish the activity.

I actually like the thought of an incorrect graph if it lets me handle this stuff precisely without some of the overhead needed to make a generic solution.

I've confirmed that this is fixed in alpha08 as a result of https://android-review.googlesource.com/833717 and a number of other internal changes.

app:popUpTo="@+id/graph" should always work now.