Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The purpose of MultiKey #255

Closed
Tagakov opened this issue Apr 23, 2017 · 2 comments
Closed

The purpose of MultiKey #255

Tagakov opened this issue Apr 23, 2017 · 2 comments

Comments

@Tagakov
Copy link

Tagakov commented Apr 23, 2017

Hi. I am trying to implement a fairly complicated navigation in my app using Flow.

In my app I have several sequential screens, they are "nested" one in another (just like in TreeKey example). It is simple if my understanding of TreeKey is correct. (but why does getParentKey() always return a new instance of parent key rather than get its instance from the constructor, is it a limitation of a state restoring process?)

The complicated part is that every screen can have several different "slave" screens (just like in master\slave case), they are just like ChildFragments from pure android. "Slave" screens can replace each other with complicated rules and animations and the "slave" container should have its own backstack, but when the master screen goes out or is destroyed "slaves" should be hidden or destroyed as well.

Should I use MultiKey for this purpose? Or should I use nested Flow instances (not sure that it is possible)?

@Zhuinden
Copy link

Zhuinden commented Apr 25, 2017

(but why does getParentKey() always return a new instance of parent key rather than get its instance from the constructor, is it a limitation of a state restoring process?)

You don't have to do that, you can just provide the parent key as a constructor parameter.

Or should I use nested Flow instances (not sure that it is possible)?

That's not possible.

Should I use MultiKey for this purpose?

I'd assume this is what MultiKey is for, although I somewhat wonder because they are then "multiple children" which is problematic because of #202 not being merged.

Unfortunately I can't help you on this front.

@loganj
Copy link
Collaborator

loganj commented Apr 28, 2017

MultiKey is meant for the purpose you describe.

The fact that MultiKey is itself a key is probably a mistake. See #208. I probably wouldn't bind services to the MultiKey itself. If you have a MultiKey that's essentially (Main,Detail) then you probably want to navigate from (Main, DetailA) to (Main, DetailB). If you want to navigate away entirely, say back to Login, then you nav from (Main, DetailB) -> Login and both Main and DetailB will be cleaned up.

@loganj loganj closed this as completed Apr 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants