Move back stack ownership to common/navigation module

[dturner]

What have I done and why
In the current scalable recipe the back stack is owned by the app module. This decision was made because of the requirement that to create the back stack, one needed to supply the start destination. This requirement isn't strictly accurate though. The only requirement is that the back stack have at least one item in it prior to it being supplied to NavDisplay.

This PR moves ownership of the back stack into the common module and allows it to be initialized empty. The app then adds the start destination at runtime. This simplifies the code and gives the back stack a more logical owner.

[gemini-code-assist]

Summary of Changes

Hello @dturner, 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 refactors the application's navigation architecture by shifting the responsibility of back stack management to a more central common module. This change decouples the Navigator's instantiation from its initial state, enabling the application layer to dynamically define the navigation's starting point. The overall impact is a cleaner, more modular, and logically separated navigation setup.

Highlights

• Back Stack Ownership Relocation: The ownership and initial configuration of the navigation back stack have been moved from the app module to the common/navigation module, centralizing its management.
• Navigator Initialization Simplification: The Navigator class constructor no longer requires a startDestination parameter, allowing it to be instantiated with an empty back stack by default.
• Dynamic Start Destination Assignment: The application's ModularActivity is now responsible for explicitly adding the initial ConversationList destination to the Navigator's back stack at runtime within its onCreate method.

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

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 refactors the ownership of the Navigator's back stack from the app module to a common module. This is a good architectural improvement that simplifies dependency management. The implementation is mostly correct, but I've identified a high-severity issue where the start destination is added to the back stack on every configuration change, which can lead to incorrect navigation behavior. I've provided a suggestion to fix this.