feat(ui): improve predictive back animations

[wxxsfxyzm]

Summary

This pull request introduces custom screen transition animations to enhance the overall user experience during navigation.

The key change is the implementation of a custom slide/fade effect for navigating from main screens (i.e., screens hosted in the bottom navigation bar) to detail screens. Transitions between the bottom navigation bar tabs themselves retain a simple, clean cross-fade effect to ensure a fast and smooth user interaction.

This PR also addresses the root cause of an issue where custom animations were being overridden by the navigation library's defaults.

Root Cause

During implementation, it was discovered that custom transition animations defined in the defaultTransitions parameter of the DestinationsNavHost in MainActivity were not being applied. Instead, a default fade-in/fade-out animation was always present.

The root cause was traced to the compose-destinations KSP (Kotlin Symbol Processing) code generator. By default, the generator creates a NavGraphSpec (e.g., RootNavGraph.kt) that includes its own defaultTransitions property. This property, defined at compile-time within the generated graph object, has a higher precedence than the defaultTransitions parameter supplied to the DestinationsNavHost composable at runtime.

As a result, our intended custom animations were being ignored and overridden by the generated default.

Solution

To resolve this precedence issue permanently, this PR adopts the official configuration method recommended by the compose-destinations library.

• The following KSP argument has been added to the app/build.gradle.kts file:

ksp {
    arg("compose-destinations.defaultTransitions", "none")
}

• This argument instructs the code generator to omit the defaultTransitions property from the generated NavGraphSpec.

• By removing the higher-priority, generated default, the defaultTransitions parameter on DestinationsNavHost now functions as the effective default, allowing our custom animation logic to execute as intended.

Animation Logic Details

The new animation logic is conditional and defined within MainActivity. It distinguishes between two primary navigation types:

• Main Screen → Detail Screen:

  • Enter: The new detail screen slides in from the right.

  • Exit: The old main screen slides out to the left while fading out.

• Detail Screen → Main Screen (on Pop):

  • Pop Enter: The main screen slides back in from the left while fading in.

  • Pop Exit: The detail screen slides out to the right.

• Between Bottom Navigation Tabs:

  • A simple cross-fade (fadeIn/fadeOut) is maintained for these transitions to provide a quick and non-disruptive experience when switching between primary sections of the app.

[rifsxd]

Feels like an AI coded PR to me not gonna lie

[0x-br0k3n]

Feels like an AI coded PR to me not gonna lie

Fr 😂

[nanoplayer]

Looks like AI while looking at the description and comments, i doubt anyone writes that much for real

[devnoname120]

No reason not to merge IMO if the PR is good. Whether it was written by slamming one's head against the keyboard, with esoteric telepathy, or using AI, all that matters is the question: is the PR good and maintainable? Everything else is gate-keeping and status signaling.

[wxxsfxyzm]

Feels like an AI coded PR to me not gonna lie

Using AI to generate comments and pr descriptions is not allowed here? I'm new here, if so, I'll be more careful.
The code implementation, however, is my own work, not AI-generated. I first use it in my Andrid Application. After a casual conversation with one of the repository's contributors, he encouraged me to contribute the animation implementation here.

[ghost]

Feels like an AI coded PR to me not gonna lie

What's wrong with that if PR is good?