-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[Tracking] Overhaul and streamline Android page navigation transitions #7772
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
Comments
@ADjenkov - do you know if this is going to improve the look of the android transitions? The current I'm specifically referring to the issue I opened here with more detail provided: #7700 The typical If my detail isn't clear, let me know and I'd be glad to explain it better. |
@bradmartin thanks for the detailed explanation. We are using the native default Thinking out loud here: Such transitions effect could be possible If there is an API that can set different exit/enter transition for the corresponding appearing ор disappearing fragment. |
Yeah I know the native slide is being used it's just ugly. No native Android app I've used in the past few years does transitions where it "pushes" the current activity away while sliding in the new activity/fragment. I'm trying to suggest that it shouldn't be so ugly and opposite of what native Android transitions do with native Android apps. I'm happy to change my stance if someone can point me to a well known Android app that does transitions with slide the way NS does 😁 I'm just unaware of any. It's not how it should look IMO that's all. At any rate I look forward to improvements in the transitions 💯 and appreciate the teams work here. I just want NS to behave/look like someone opened Android studio and built an app 👍. |
@bradmartin Can you elaborate more on the Android Studio part? The slide transition I think it looks like a Material Design hierarchical transition like described here - https://material.io/design/navigation/navigation-transitions.html#about-navigation-transitions. If that's the case then I don't think it's a good fit for replacing the native core slide transition. We can create a new one or provide it as a plugin maybe. By "the way NS does", you mean what the |
I don't have a lot of time ATM to make this lengthy so I'll try to clarify it a bit. @ADjenkov comment here is what would be ideal:
So just to get an idea of what I'm referring to is how NS apps apply the From what I recall when showing an activity/fragment on Android the "current" activity doesn't get "pushed" away. Rather the new activity/fragment does slide in but it's "on top" of the current page. I've never seen an app built with android where the new page "pushes" the current activity in the direction the new activity is sliding in. Hope that makes sense. So basically, the current API is fine in terms of it using the native I think the .gifs in the feature issue #7700 (comment) should help visualize what is so 'odd' about how currently the transition is applied to the current page as it leaves. |
@bradmartin I think I get your idea now. I was mixing up NS transitions with Android transitions. So separating the enter and exit transitions will definitely help, but we'll have to implement this for iOS too, which makes it a bigger effort. We have 3 options as I see it:
We'll discuss this internally and get back to you. This is not part of this feature - the removing of animators, but if we decide on an easy solution we might do it now. |
Yea, if #2 was possible in the short term, I think it would be visually more appealing for Android users since it mimics the majority of android apps when showing a new activity. Ideally, long term specific enter/exit transitions would be good, or just disable the EXIT transition so only the new page is animated on top of the back stack pages 👍 Thanks for listening and being open to the ideas 💯 |
Uh oh!
There was an error while loading. Please reload this page.
IN PROGRESS
Transition
setCustomAnimations
from codebaseFragment animations from child fragments and their descendants are now properly handled when animating the parent Fragment
bug is fixed in androidx.fragment:fragment:1.2.0-alpha02androidx.transition:transition:1.2.0-beta01
androidx.fragment:fragment:1.2.0-alpha02
)The text was updated successfully, but these errors were encountered: