Here's one way we can allow different transition types for different pages. One drawback is that this is not dynamic at all - the transition type can't adjust if the page varies. E.g. the Pesto demo uses the slide-from-right transition because it's added by the framework in MaterialApp, even though it has a drawer. (It's still unclear what we want to happen in that case, though.)

This is a bit bikesheddy, but I think we need a better name than MaterialMainPageRoute. I couldn't tell from the name before looking at the code if a main page was one that did the iOS thing or not.

I think the routes that have this animation are subsidiary pages. Pages that are subpages of other pages, as opposed to pages that are top-level, like full-screen dialogs or the app's main page.

Consider a case where you have three pages, A, B, and C, and the B->C transition is iOSy, and the A->B transition is not, and the user goes back twice in quick succession. If I'm interpreting the code correctly, it'll transition incorrectly because B is going to attempt to apply an iOS-like transition to the A->B path. Am I right? I'm not sure.

I just tested out your A->B->C example after enabling escape transitions, and this whole approach breaks down - even transitioning one at a time. The problem is that the animation should be a property of the transition, while separating these classes makes it a property of the route.

For example, say you have:

• A is an IOS route.
• B is a non-IOS route.

The transition from A->B should use a non-IOS transition. But since the animation is part of the route, A uses an iOS escape transition (sliding off to the left), and B uses the non-iOS entrance transition (sliding up from the bottom).

I didn't notice it before because I had disabled the escape transition.

We found a Contributor License Agreement for you (the sender of this pull request) and all commit authors, but as best as we can tell these commits were authored by someone else. If that's the case, please add them to this pull request and have them confirm that they're okay with these commits being contributed to Google. If we're mistaken and you did author these commits, just reply here to confirm.

I found a way to fix the problem I described regarding the escape transitions. I'm now ignoring the forwardAnimation whenever the nextRoute is not using an ios-style transition.

I've tried a bunch of combinations of quick A->B->C transitions (pushing and popping), and everything looks correct to me.

Isn't that what the canTransitionFrom/canTransitionTo stuff is about?

CLAs look good, thanks!

Ah, so it is! I removed my hacky thing and overrode canTransitionTo instead. It works the same.

Probably needs a test that we don't do this transition if we're not going subpage-to-subpage.
With the logic moved into the sub page route so that the gesture only works for the cases where we do the animation, LGTM.

@sethladd, @HansMuller, and I just examined a bunch of iOS apps from Apple and Google and have the following proposal:

• When you do a regular push/pop (not one driven from a user gesture), we always do things the regular material way, sliding in from the bottom as it fades in.
• When you do a back gesture on iOS, we do the iOS transition. When you let go, we fling (based on whether you're <0.5 or >0.5 when you let go).
• When you do the back gesture thing, we disable all heroes (including the toolbar) for that transition.

(This most closely matches Google Play Music on iOS.)

OK, the PR now implements your proposal.

Thanks! Can't wait to try it :)

Please add a test that verifies that the back gesture is the only way to get things to appear to move horizontally.
Please add a test that verifies that heroes don't do anything when a gesture is triggered.