You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Need startActivityForResult() equivalent on Flutter #5283
On mobile, it is common for a state to persist over several screens. For instance, while filling out a form, you might want to invoke a new page asking for additional information then go back to the original form. To support this, we need two things:
A mechanism to push a route to the navigator and get results from it.
To save the state of the previous route so it can be revived upon user's return to the page.
A mechanism to push a route to the navigator and get results from it.
The navigator currently has a mechanism for a route to return a value. We use it for popup menus and similar things. It might be a good building block for this.
There's a really easy way to do this that we could do in about 10 minutes, just have the navigator not destroy invisible routes.
The tricky part is doing that while still freezing animations (and rebuilds in response to other state changes, like animated GIFs loading, timers firing, etc) in that part of the tree.
@Hixie Agree with the no cutting corners approach. If the proper fix can't be done in the Q4 timeframe, I am open to suggestions on how to work around it so we can do this in a Flutter friendly way.
@mehmetf I hope we'll have this fixed before Q4. Just need to figure out how first. :-)
Some half-formed ideas:
Having an inherited widget which tells you if you should have animations. Bad idea because nobody would actually check it. Doing the right thing is hard in this model.
Calling deactivate on that part of the tree but not actually take it out of the tree, and then stop rebuilding that part of the tree until it's time to come back. This is scary because it's a change to the "deactivate" semantics. Until now, calling deactivate meant you would be taken out of the tree and then would either have build or dispose called immediately. Also we don't usually kill resources in deactivate, we wait til dispose.
Calling dispose and then later calling "resume". This is super scary because people aren't good at reviving dead widgets.
I spoke with @abarth about this and he suggested we should just do the ten minute fix and then deal with the battery issues separately. We do already have this problem in general; if you put e.g. a spinner in an Offstage widget it'll still consume resources.
OK.. Just to let you know this is not a "common" use case for us. We have around 40-50 page flows at the moment and about 10% of them require this flow. So if a potential solution affects performance/battery life, it would be nice if we can have some level of control whether the previous route needs to be "saved". A rough idea:
I understand this is not ideal since you probably want to get to a point where this is just returned by the navigator and it is always useful as opposed to sometimes but it could be a decent interim solution.
the fix is up at master...Hixie:5283-future-navigation if anyone wants to review it. I have to work on some graph-related stuff before I can track down the globalkey bug.
Discussed this with @Hixie . Need to reopen this as the Navigator.push()/pushNamed() API does not return a Future which makes getting the value at the call site difficult.
@abarth if you're not deep in something right now this would be a good one to pick up, so that we don't delay the scrollable refactor even more (but if you're doing something else already, this gives me the perfect thing to procrastinate with, so...).
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
abarth commentedon Aug 6, 2016
The navigator currently has a mechanism for a route to return a value. We use it for popup menus and similar things. It might be a good building block for this.
mehmetf commentedon Aug 15, 2016
Please assign to an appropriate milestone as this will block leafy from releasing its prototype by end of Q4.
If unlikely to happen, we need to discuss appropriate workarounds.
Hixie commentedon Aug 15, 2016
There's a really easy way to do this that we could do in about 10 minutes, just have the navigator not destroy invisible routes.
The tricky part is doing that while still freezing animations (and rebuilds in response to other state changes, like animated GIFs loading, timers firing, etc) in that part of the tree.
mehmetf commentedon Aug 15, 2016
@Hixie Agree with the no cutting corners approach. If the proper fix can't be done in the Q4 timeframe, I am open to suggestions on how to work around it so we can do this in a Flutter friendly way.
Hixie commentedon Aug 15, 2016
@mehmetf I hope we'll have this fixed before Q4. Just need to figure out how first. :-)
Some half-formed ideas:
Hixie commentedon Aug 15, 2016
I spoke with @abarth about this and he suggested we should just do the ten minute fix and then deal with the battery issues separately. We do already have this problem in general; if you put e.g. a spinner in an Offstage widget it'll still consume resources.
mehmetf commentedon Aug 16, 2016
OK.. Just to let you know this is not a "common" use case for us. We have around 40-50 page flows at the moment and about 10% of them require this flow. So if a potential solution affects performance/battery life, it would be nice if we can have some level of control whether the previous route needs to be "saved". A rough idea:
navigator.pushNamed("page2", onReturn: (T data) {});
I understand this is not ideal since you probably want to get to a point where this is just returned by the navigator and it is always useful as opposed to sometimes but it could be a decent interim solution.
Hixie commentedon Aug 19, 2016
I have a fix for this but it exposes a mysterious underlying bug in the GlobalKey logic so I'm going to have to track that down before it can land.
Hixie commentedon Aug 19, 2016
the fix is up at master...Hixie:5283-future-navigation if anyone wants to review it. I have to work on some graph-related stuff before I can track down the globalkey bug.
Hixie commentedon Aug 24, 2016
Finally figured out the aforementioned bug: #5588
13 remaining items
mehmetf commentedon Oct 14, 2016
Discussed this with @Hixie . Need to reopen this as the Navigator.push()/pushNamed() API does not return a Future which makes getting the value at the call site difficult.
Hixie commentedon Oct 14, 2016
@abarth if you're not deep in something right now this would be a good one to pick up, so that we don't delay the scrollable refactor even more (but if you're doing something else already, this gives me the perfect thing to procrastinate with, so...).
abarth commentedon Oct 14, 2016
Either way. If you'd like me to take a look, please assign the issue to me.
Navigator.push and Navigator.pushNamed should return Futures (#6333)
Roll engine to 40a3712
Roll engine to 40a3712 (#17702)
github-actions commentedon Sep 5, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.Fix the losing of state when pushing opaque routes (flutter#5624)