Skip to content

Need startActivityForResult() equivalent on Flutter #5283

Description

@mehmetf

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.

Activity

  1. abarth commented on Aug 6, 2016

    @abarth
    Contributor

    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.

  2. mehmetf commented on Aug 15, 2016

    @mehmetf
    ContributorAuthor

    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.

  3. added this to the milestone on Aug 15, 2016
  4. Hixie commented on Aug 15, 2016

    @Hixie
    Contributor

    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.

  5. mehmetf commented on Aug 15, 2016

    @mehmetf
    ContributorAuthor

    @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.

  6. Hixie commented on Aug 15, 2016

    @Hixie
    Contributor

    @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.
  7. Hixie commented on Aug 15, 2016

    @Hixie
    Contributor

    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.

  8. self-assigned this
    on Aug 15, 2016
  9. mehmetf commented on Aug 16, 2016

    @mehmetf
    ContributorAuthor

    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.

  10. Hixie commented on Aug 19, 2016

    @Hixie
    Contributor

    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.

  11. Hixie commented on Aug 19, 2016

    @Hixie
    Contributor

    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.

  12. Hixie commented on Aug 24, 2016

    @Hixie
    Contributor

    Finally figured out the aforementioned bug: #5588

  13. 13 remaining items

  14. mehmetf commented on Oct 14, 2016

    @mehmetf
    ContributorAuthor

    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.

  15. Hixie commented on Oct 14, 2016

    @Hixie
    Contributor

    @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...).

  16. abarth commented on Oct 14, 2016

    @abarth
    Contributor

    Either way. If you'd like me to take a look, please assign the issue to me.

  17. added a commit that references this issue on Oct 14, 2016
    ffe14b0
  18. github-actions commented on Sep 5, 2021

    @github-actions

    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.

  19. locked as resolved and limited conversation to collaborators on Sep 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

frameworkflutter/packages/flutter repository. See also f: labels.

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions