https://github.com/pablichjenkov/nav3-playground
Playing a bit with nav3
https://github.com/pablichjenkov/nav3-playground
android compose compose-nav3 compose-navigation metro nav3
Last synced: 3 months ago
JSON representation
Playing a bit with nav3
- Host: GitHub
- URL: https://github.com/pablichjenkov/nav3-playground
- Owner: pablichjenkov
- Created: 2025-06-28T01:06:39.000Z (about 1 year ago)
- Default Branch: main
- Last Pushed: 2026-03-21T01:09:36.000Z (4 months ago)
- Last Synced: 2026-03-21T16:54:01.176Z (4 months ago)
- Topics: android, compose, compose-nav3, compose-navigation, metro, nav3
- Language: Kotlin
- Homepage:
- Size: 270 KB
- Stars: 1
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
## Nav3 Blocks
### Project Architecture
#### 1. Module Depepndencies
This project inter-modular dependency uses a Diamond shape dependency structure.
In such architecture, feature modules do not depend directly on each other. They all depend on a **common** module which contains the public APIs each of this module exposes to its clients. On top of the diamond, you see the integrator module, this is the app module. It basically acts like a coordiantor between all the modules.
#### 2. Nav3Block
Each feature of this project provides a **Nav3Block** implementation to be consumed by a **TopLevel Nav3 Navigator**. A TopLevel navigator could be a NavigationDrawer navigator, a BottomBar navigator, a BottomSheet navigator, a Floating Buton + Floating Menu navigator, you pick. However, no matter what navigator is selected, the feature modules will behave the same and will adapt to each navigation type constraint.
That is the power of modulirization and componentization.
### Navigation
This project uses google compose only **nav3** navigation library. In this architecture each module is responsible for its internal navigation. Some modules contain an internal NavDisplay as an example of **nested NavDisplays**.
The integrator module on the top of the diamond, this one is in charge of the **General App/Module Navigation**. This top module is also in charge of tasks like **App Startup**, **Notifications Routing**, **DeepLink Routing** and such a global application stuff.
### Dependency Injection
The DI framework of choice is Metro, go check the [Metro Repo](https://github.com/ZacSweers/metro), highly recommended.
In the diamond architecture, each module exposes the public abstract API in common. Metro will bind the actual implementations from the feature modules or the app module.
Bellow is a diagram representing how block classes are scoped in a block and how the block are scoped in the App scope.
Below is a more realistic representation of how a Block looks like.
Visual representation of a **Nav3Block**.
Notice the project does not use the term **SharedViewModel** but rather **SharedUiDataManager** or **SharedDataManager** or **SharedSateManagerr**. This is in purpose because in general the term "SharedViewModel" is not confusing. Confusing because the ViewModel pattern explicitly mention that **the relation between a View and a ViewModel is a One to One**. A SharedViewModel breaks this principle, because now the View will have its own ViewModels plus a shared one. So this project removes that terminology.
### Demo
In the demo below you can notice how nested NavDisplays interact when the user visit the differenttabs and navigate deeply within them.