Skip to content

Completes our navigation story #1313

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

Merged
merged 2 commits into from
May 13, 2025
Merged

Completes our navigation story #1313

merged 2 commits into from
May 13, 2025

Conversation

rjrjr
Copy link
Contributor

@rjrjr rjrjr commented May 13, 2025

Optimize central unwrap implementations.

The default implementation of Unwrappable.unwrap creates a Sequence that is almost never necessary (but it is at least fail-safe so I think we should keep it). Here we provide improved implementations for Wrapper and BackStackScreen.

Introduces NavigationMonitor

Takes advantage of unwrap() and Compatible.keyFor() to provide navigation logging by reporting the top (read: last-most inner-most) sub-rendering, which conventionally is the one that is visible and accessible to the user. Reports each time the Compatible.keyFor the top is unequal to the previous one, which conventionally indicates that a new view object will replace the previous one.

The default implementation of `Unwrappable.unwrap` creates a `Sequence` that is almost never necessary (but it is at least fail-safe so I think we should keep it). Here we provide improved implementations for `Wrapper` and `BackStackScreen`.
@rjrjr rjrjr requested review from zach-klippenstein and a team as code owners May 13, 2025 18:40
@rjrjr rjrjr force-pushed the ray/nav-polish branch 2 times, most recently from a311082 to d5f09d6 Compare May 13, 2025 18:44
skipFirstScreen: Boolean = false,
private val onNavigate: (Any) -> Unit = { println(it) }
) {
private var lastKey: String? = if (skipFirstScreen) null else ""
Copy link
Contributor Author

@rjrjr rjrjr May 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pyricau @steve-the-edwards We have only ever used our flavor of this on the main thread with the Main.Immediate dispatcher, so this simple implementation has been just fine. Should we stick with what we know, or should this field be marked @Volatile, or…?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My gut is to leave it this way. It's such a trivial class that anyone doing something more interesting and finding flaws could so easily fork it.

Should I put something in the kdoc warning of its limitations?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Enforce that it's single threaded.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or make it volatile it's simple enough and not that expensive.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that's the sanity check I was hoping for, "@Volatile is just fine."

Takes advantage of `unwrap()` and `Compatible.keyFor()` to provide navigation logging by reporting the top (read: last-most inner-most) sub-rendering, which conventionally is the one that is visible and accessible to the user. Reports each time the `Compatible.keyFor` the top is unequal to the previous one, which conventionally indicates that a new view object will replace the previous one.
@rjrjr rjrjr merged commit ee4f864 into main May 13, 2025
42 checks passed
@rjrjr rjrjr deleted the ray/nav-polish branch May 13, 2025 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants