Intercept touch events only on non-current entry. (#196) #198
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @cy745, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request enhances the user experience during navigation transitions by refining how touch events are handled. It specifically addresses the issue of preventing interaction with the new screen while an old screen is still animating out. The change allows for more fluid forward navigation by making the incoming screen immediately interactive, while still preventing accidental interactions with outgoing content.
Highlights
- Improved Navigation Responsiveness: The pull request refines the touch event interception logic during navigation transitions. Previously, all touch events were blocked while any transition was active. Now, touch events are only blocked on non-current (outgoing) navigation entries, allowing the current (incoming) entry to be interactive immediately. This significantly improves the perceived responsiveness and smoothness during forward navigation.
- Conditional Touch Interception: A new
isCurrentcheck has been introduced within theNavigationcomposable. This check determines if anEntryContentcorresponds to thetargetEntryof the navigation state. ThepointerInputmodifier, which intercepts touch events, is now conditionally applied only when!isCurrentandtransition.isRunning, ensuring that only background or outgoing screens are non-interactive during a transition.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Code Review
This pull request enhances the navigation user experience by intercepting touch events only on the outgoing (non-current) screen during transitions, allowing users to interact with the incoming screen before the transition completes. A suggestion has been provided to improve code clarity and performance by using reference equality for NavEntry comparison.
| EntryContent(it) | ||
| // prevent clicks during transition animation | ||
| if (transition.isRunning) Box( | ||
| val isCurrent = remember(it, state) { it.contentKey() == state?.targetEntry?.contentKey() } |
There was a problem hiding this comment.
Using direct reference equality (==) instead of comparing contentKey() strings can improve code efficiency and clarity, as NavEntry instances are unique and AnimatedContent receives the targetEntry instance directly.
| val isCurrent = remember(it, state) { it.contentKey() == state?.targetEntry?.contentKey() } | |
| val isCurrent = remember(it, state) { it == state?.targetEntry } |
|
@cy745 The case that
You CAN navigatie to another screen during transition (LaunchedEffect may call another nav action right when composable appeard on screen, and it will happen during the animation) Simple explanation why we need to intercep both destination: image 2 screens A & B Now imagine i will click in the middle of the screen constantly So as result - we have to block both destinations from interactions |
With touches...my bad.
It is an extremely situation that normal user would not do.
These two are incorrect behavior.
This is correct behavior, since it is an extremely situation. My thought is that we should make sure the behavior is correct and make it smoother at the same time. i think the correct behavior is that touches is all consumed by the current screen. 20250716-105740.mp4Check this, the red background is the intercept box area, the behavior is the third one you metioned, i think it is correct and smoother with touches. @vkatz |
|
@cy745 Overall idea to only block the screen that's |
|
@cy745 
Then point PR onto We will wait for a few days, in case of troubles - we can make same changes by our own and mention you in the PR. Thanks |
|
@vkatz Appreciate to all your works, i hope this lib be better and better |
• remove unnecessary wrappers and platform code • implement lifecycle for all platforms • adjust compose code • fix view model store ovner • serializable args • Intercept touch events only on non-current entry. (#196) (#198) --------- Co-authored-by: Qiu <[email protected]>
3 participants
link to issue: (#196)
I firstly just feel about the preventing logic is not cool that i have to wait for the transition fully finished then i can navigate to another screen, then i found the double-tap problem you metioned, so i try to handle it by myself. @vkatz
I make a plan that intercept touches while forwarding and ignore touches while backwarding, but there is no pointerInteropFilter() on Compose Multiplatform, and the structure in AnimatedContent can't fit for sharePointerInputWithSiblings(), i found no way to ignore touches on the top entry while backwarding.
Only optimization i can do on is the intercept touches logic, now the navigation will be more smooth while forwarding, since no changes while backwarding.