Consider a way to merge Multistack into the library

[Zhuinden]

The "multistack" approach is interesting, because the callbacks it currently exposes are the same as what BackstackHost calls on a Backstack.

So it seems unreasonable to expect people to add their own retained fragment to hide the callbacks (or more-so, automate them), because I am already doing something similar.

However, Navigator returns a Backstack with getBackstack, and I don't really want that to return a Multistack; and I definitely don't want a "multistack can only be acquired if you initialized with multiple tags" or whatever. But I also don't want a MultstackNavigator.getMultistack because that name is a handful.

[Zhuinden]

There is the option of making "Multistack" an implementation detail, and expose it only through a setSelectedStack method that takes a String tag.

You could set the stacks to create on start-up with a list of stacks (with their initial keys), and this could happen via BackstackDelegate/Navigator.

If this is not set at all, I could use a __INTERNAL__SIMPLE_STACK_DEFAULT_TAG__ or so.

---

I'm not that happy about the idea though because I wanted to kill BackstackDelegate, but a MultiStack would definitely need to manage multiple Backstacks.. 🤔

[Zhuinden]

I'm definitely killing the BackstackDelegate.

The real question is how that'd change the Navigator.install call.

[Zhuinden]

I can't do this because it would hard-code the number of available stacks on a given level, but this can vary depending on authentication state, etc. so it's up to apps to handle this sort of thing, sorry.