Fixed
Status Update
Comments
pb...@google.com <pb...@google.com>
ap...@google.com <ap...@google.com> #2
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.
ap...@google.com <ap...@google.com> #3
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
ap...@google.com <ap...@google.com> #4
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)
pr...@google.com <pr...@google.com> #5
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
AndroidX tracking bug forhttps://crbug.com/373558938
This API will allow app developers to delete all browsing data for a given WebView profile, or delete all data for a specific site