Add recipes for returning navigation results

[jbw0033]

This commit adds two new recipes demonstrating how to return a result
from one screen to a previous one.

The "Return result as Event" recipe uses a ResultStore backed by
Kotlin Channels. A screen can send a result, and the previous screen
can listen for it using a ResultEffect composable.

The "Return result as State" recipe uses a rememberResult composable,
which wraps mutableStateOf. The state is hoisted and can be updated
by a child screen.

[gemini-code-assist]

Summary of Changes

Hello @jbw0033, I'm Gemini Code Assist¹! 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 introduces two new recipes that demonstrate different approaches to returning results between navigation destinations in a Compose application. The first recipe, 'Return result as Event', leverages a ResultStore backed by Kotlin Channels, allowing a screen to send a result that a previous screen can observe using a ResultEffect composable. The second recipe, 'Return result as State', uses a rememberResult composable to manage a hoisted mutable state, enabling a child screen to directly update a value that the parent screen can react to. Additionally, this PR includes a new markdown guide, Nav2ToNav3Snippets.md, which provides extensive code snippets and explanations for migrating existing Navigation 2 patterns to the Navigation 3 framework, covering a wide range of navigation functionalities.

Highlights

• New Navigation Result Recipes: Introduced two distinct methods for returning results from a navigated screen back to a previous one: one utilizing a ResultStore with Kotlin Channels for event-based results, and another employing a rememberResult composable for state-based results.
• Navigation Migration Guide: Added a comprehensive markdown document, Nav2ToNav3Snippets.md, which serves as a detailed guide for developers transitioning from Navigation 2 to Navigation 3, providing side-by-side code examples for various navigation patterns.

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 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

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

1. 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. ↩

[gemini-code-assist]

Code Review

This pull request introduces two new recipes for returning results between screens, one using an event-based approach with Channel and another using a hoisted State. The implementation is a good starting point, but there are several critical issues related to state management in Compose, potential runtime crashes due to unsafe type casting, and incorrect usage of CompositionLocal. I've provided detailed comments and suggestions to address these issues, which will improve the robustness and correctness of the new recipes.

[jbw0033]

@ianhanniballake

[langsmith]

Nice, I've been waiting for this pr for a while 😄 This will help solve my comment at #34 (comment)

[pablichjenkov]

Could it be possible to return a parameterized Result<S, E> class?
if there is an error and I want to return the error information rather than null.
Also, could it be possible to add another result2 screen, to visualize how it would be the case for many result screens.

[ianhanniballake]

@Olabraaten - can you please sign the CLA then run the rescan? That would help fix the last failing check.