Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
You should just continue to use startActivityForResult+override onActivityResult in your Fragment - this wouldn't be part of your navigation graph.
I'd like to know more about what integration you were expecting and what you'd like to see.
I'd like to know more about what integration you were expecting and what you'd like to see.
an...@gmail.com
One thing that would be interesting is being able to have a response action which could be used with safe args to pass information back to the previous fragment/activity
an...@gmail.com
I imagine something like this would be useful:
findNavController().navigateForResult(R.id.myAction)
And then in myAction:
findNavController().returnWithResult(Bundle or safe-args object)
It would basically bring startActivityForResult into Navigation world, like startActivity has been brought in with current version. Advantages would be:
1. Type-safe argument passing
2. Better Fragment support (startActivityForResult works well for Fragment/Activity starting another Activity, but starting another Fragment is not simple. You can do it with Fragment.targetFragment property, but it creates a lot of boilerplate code, especially if started fragment is not a dialog (there is no simple finish() method on the fragment))
3. Easier result propagation with multi-step screens (screen A could request result from screen B, which would first navigate to screens C and D to get all the info and then return back to the A)
4. Ability to mix regular start and result start (sometimes I might want to display a screen and not care about its result - this would be best handled with Navigation. But if I also needed to get the result in some cases, I cannot use Navigation)
5. Ability to respond to the external Deep Link (Deep Link handling is the biggest feature of this library, with better up support and backstack generation. But if screen can return data back to the deep link initiator with activity result, then Navigation once again cannot be used)
findNavController().navigateForResult(R.id.myAction)
And then in myAction:
findNavController().returnWithResult(Bundle or safe-args object)
It would basically bring startActivityForResult into Navigation world, like startActivity has been brought in with current version. Advantages would be:
1. Type-safe argument passing
2. Better Fragment support (startActivityForResult works well for Fragment/Activity starting another Activity, but starting another Fragment is not simple. You can do it with Fragment.targetFragment property, but it creates a lot of boilerplate code, especially if started fragment is not a dialog (there is no simple finish() method on the fragment))
3. Easier result propagation with multi-step screens (screen A could request result from screen B, which would first navigate to screens C and D to get all the info and then return back to the A)
4. Ability to mix regular start and result start (sometimes I might want to display a screen and not care about its result - this would be best handled with Navigation. But if I also needed to get the result in some cases, I cannot use Navigation)
5. Ability to respond to the external Deep Link (Deep Link handling is the biggest feature of this library, with better up support and backstack generation. But if screen can return data back to the deep link initiator with activity result, then Navigation once again cannot be used)
il...@google.com
I like the proposal, except for `returnWithResult()` which implies that every part of the navigation graph is under the control of the developer.
Instead, the current result flows should be made to work with the navigation graph such that an external activity can be used as destination in the graph and provide results.
Instead, the current result flows should be made to work with the navigation graph such that an external activity can be used as destination in the graph and provide results.
Description
If I have an action that links from the subgraph to the download page that pops the subgraph then no crashes, but clicking the back button takes you back to the main screen, not "page 3" as is wanted.
If I don't pop the subgraph then it crashes both when I navigate to main, and when I hit the back button (the one on the device, not the toolbar). The toolbar back button takes you back to page3 (as expected).
Stack trace:
```
E/AndroidRuntime: FATAL EXCEPTION: main
java.lang.IllegalArgumentException: Navigator androidx.navigation.fragment.FragmentNavigator@ae77e1d8 reported navigation to unknown destination id com.example.myapplication:id/page3Fragment
at androidx.navigation.NavController$2.onNavigatorNavigated(NavController.java:98)
at androidx.navigation.Navigator.dispatchOnNavigatorNavigated(Navigator.java:176)
at androidx.navigation.fragment.FragmentNavigator$1.onBackStackChanged(FragmentNavigator.java:72)
at android.support.v4.app.FragmentManagerImpl.reportBackStackChanged(FragmentManager.java:2704)
at android.support.v4.app.FragmentManagerImpl.executeOpsTogether(FragmentManager.java:2411)
at android.support.v4.app.FragmentManagerImpl.removeRedundantOperationsAndExecute(FragmentManager.java:2338)
at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:854)
at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:797)
at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:844)
at android.support.v4.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:797)
at android.support.v4.app.FragmentActivity.onBackPressed(FragmentActivity.java:186)
at android.app.Activity.onKeyUp(Activity.java:2145)
at android.view.KeyEvent.dispatch(KeyEvent.java:2633)
at android.app.Activity.dispatchKeyEvent(Activity.java:2375)
at android.support.v7.app.AppCompatActivity.dispatchKeyEvent(AppCompatActivity.java:534)
at android.support.v7.view.WindowCallbackWrapper.dispatchKeyEvent(WindowCallbackWrapper.java:58)
at android.support.v7.app.AppCompatDelegateImplBase$AppCompatWindowCallbackBase.dispatchKeyEvent(AppCompatDelegateImplBase.java:316)
at android.support.v7.view.WindowCallbackWrapper.dispatchKeyEvent(WindowCallbackWrapper.java:58)
at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1847)
at android.view.ViewRootImpl.deliverKeyEventPostIme(ViewRootImpl.java:3701)
at android.view.ViewRootImpl.handleImeFinishedEvent(ViewRootImpl.java:3651)
at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:2818)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:137)
at android.app.ActivityThread.main(ActivityThread.java:5041)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
at dalvik.system.NativeStart.main(Native Method)
```
Component used:
android.arch.navigation:navigation-fragment-ktx
Version used:
1.0.0-alpha01
Devices/Android versions reproduced on:
All tested
- Sample project to trigger the issue.
See attached
- A screen record or screenshots showing the issue (if UI related).