Make transition customizable depending on screen

[zach-klippenstein]

Instead of passing in a single BackstackTransition, should take a function of (top: T, below: T, direction) -> BackstackTransition. Should provide a helper to convert a BackstackTransition into a function that returns that transition for all values.

The function could actually be a single-method interface that BT implements, and until fun interface support lands in 1.4 we could provide a transitionFor { top, next, dir -> } builder function.

[zach-klippenstein]

This could be tricky with #17, since the direction could change in the middle of a transition. There might be other cases where we'd want to back out of a transition in the middle though too (eg backstack goes from A → B → A before transition finishes), and those cases could all just be handled as the original transition, instead of choosing a new transition in the middle.

[gustavkarlsson]

How about (active: List<T>, target: List<T>) -> BackstackTransition instead? The concept of going Forward/Backward doesn't always apply for me, as the user might be moving between top screens "sideways" too.

I would leave out the concept of "direction" completely.

[zach-klippenstein]

Do you need the full lists? Would just a from and to be enough?

[gustavkarlsson]

For me, it wouldn't be enough.

In my app, I use one of 3 different transitions depending on the navigation direction: Forward, backward, sideways. Sideways typically means that the top screen is replaced, so the total screen count remains the same. The idea is to only use the "forward" transition when the user can actually go back to the "from" screen using the back button.

Here are 3 scenarios to demonstrate the difference (rightmost screen is topmost):

Scenario 1:
From: a/b
To: a/b/c
Resulting transitions: Forward

Scenario 2:
From: a/b/c
To: a/b
Resulting transitions: Backward

Scenario 3:
From: a/b
To: a/c
Resulting transitions: Sideways

As you can see, I need access to both backstacks to be able to distinguish between these scenarios.

[zach-klippenstein]

That makes sense. Could "sideways" also be called "replace"? Another way of solving this would be to make a third Direction value. I think that would be better, since it would save you from having to check the lists yourself. It's also less flexible, but I think it might be a simpler API that's easier to understand – WDYT?

[gustavkarlsson]

Possibly, but exactly what that means might not always be so clear. The rules of what counts as backward/forward/replace are quite arbitrary, and I would rather interpret that myself.

Another possibility would of course be an overloaded function for more advanced uses.

[zach-klippenstein]

Maybe just the one function that takes both lists, and the library provides a helper method to calculate the simple directions given two lists? Although I'm not sure that follows the "make simple things easy, and hard things possible" rule.

[gustavkarlsson]

I also thought of a helper as an alternative, but I think I'd prefer the overloaded function though. It follows the common practice in compose where you have one simple and one advanced version of composable funcions. The official API:s are full of them.