Mastering Multi-Module Navigation with Jetpack Navigation 3

 How to leverage the api/impl split and Jetpack Compose to build high-performance, multi-module Android apps.

Mastering Multi-Module Navigation with Jetpack Navigation 3

Building a large-scale Android app is like organizing a massive library. If you throw every book into one giant pile, finding anything becomes a nightmare. In Android development, that “pile” is the monolithic :app module.

As apps scale, modularization is the only way to keep build times low and developers sane. With Navigation 3, Google has introduced a Compose-first approach that treats navigation as a contract rather than a static graph.

The Strategy: The api and impl Split

The gold standard for modularization is separating what a feature can do from how it does it. This prevents “circular dependencies” and massive recompilation chains.

  • :feature:api: Contains Navigation Keys (destinations) and shared models. Other modules depend on this to know where they can go.
  • :feature:impl: Contains the heavy UI (Composables), ViewModels, and the "Entry Builder." This module remains hidden from other features.

Step 1: Defining Navigation Keys (The API)

In Navigation 3, every destination is a NavKey. To ensure these keys survive process death and handle state restoration, we mark them with @Serializable.

// In :feature:profile:api
@Serializable
data class ProfileKey(val userId: String) : NavKey

// Best Practice: If 'UserId' is a shared primitive, extract it 
// into a :core:model module to keep feature APIs lean.

Step 2: Implementing the Destination (The Impl)

The impl module registers how a NavKey maps to a Composable. We use extension functions on EntryProviderScope to keep the UI logic private.

// In :feature:profile:impl
fun EntryProviderScope<NavKey>.profileEntryBuilder() {
    entry<ProfileKey> { key ->
        // ProfileScreen is internal to this module
        ProfileScreen(userId = key.userId) 
    }
}

Step 3: Wiring it All Together in :app

The :app module acts as the "glue." It depends on all feature impl modules and assembles the final navigation provider.

// In :app
val appProvider = entryProvider {
    profileEntryBuilder() // Provided by :feature:profile:impl
    searchEntryBuilder()  // Provided by :feature:search:impl
}

NavDisplay(
    backstack = myBackstack,
    entryProvider = appProvider
)

Scalability: Using Dependency Injection (Hilt/Dagger)

For massive projects, manually adding builders to :app is tedious. Using Dagger Multibindings, you can "contribute" these builders to a centralized set automatically.

To make this work cleanly, define a typealias for your contribution:

typealias EntryBuilder = EntryProviderScope<NavKey>.() -> Unit

Then, provide it in your feature module:

@Provides
@IntoSet
fun provideProfileBuilder(): EntryBuilder = { profileEntryBuilder() }

Note on Dynamic Delivery: This pattern is particularly powerful for Dynamic Feature Modules. Because the :app module only needs to know about the API at compile time, you can load the implementation and its corresponding EntryBuilder at runtime without breaking your navigation structure.

Why Navigation 3 is a Game Changer

  • No XML/Safe Args Bloat: Type safety is handled by Kotlin classes, removing the need for extra Gradle plugins.
  • Total State Control: The backstack is just a List<NavKey>. You can inspect, mutate, or save it as easily as any other UI state.
  • Parallel Builds: Since :feature:search:impl only knows about :feature:profile:api, changes to the Profile UI won't trigger a re-build of the Search module.

Frequently Asked Questions (FAQs)

Can I still use Navigation 3 with Fragments?

Navigation 3 is built for Jetpack Compose. While interop exists, the library treats destinations as functions, making it most effective in 100% Compose environments.

How does this handle Deep Linking?

Navigation 3 provides the primitives, but doesn’t force a specific deep link strategy. Most teams parse the deep link at the entry point, map it to a NavKey, and manually update the backstack list.

Is the api/impl split overkill for small apps?

If your app is under 10 screens, a single module is fine. Start modularizing when your build times exceed 2 minutes or when multiple teams begin working on the same codebase.

What do you think?

  • How are you currently managing shared data classes between feature modules?
  • Would you prefer a manual entryProvider assembly for transparency, or a DI-based one for automation?
  • Are you planning to migrate from Navigation 2 (XML/Compose) to Navigation 3 soon?

Video Reference

For a deeper dive into the API design and adaptive layouts, check out: Navigation 3 API Overview & Demo (Android Dev Summit)

📘 Master Your Next Technical Interview

Since Java is the foundation of Android development, mastering DSA is essential. I highly recommend “Mastering Data Structures & Algorithms in Java”. It’s a focused roadmap covering 100+ coding challenges to help you ace your technical rounds.


Comments

Post a Comment

Popular posts from this blog

Stop Writing Massive when Statements: Master the State Pattern in Kotlin

Image
 Tame Your Codebase with Elegant, Scalable, and Type-Safe State Machines Do you manage complex objects that change their behavior dramatically based on their internal status? If so, you’ve likely battled a common foe: the sprawling  when  statement that haunts every method in your class. It looks something like this: fun handleAction () { when (state) { State.A -> { /* logic for A */ } State.B -> { /* logic for B */ } State.C -> { /* logic for C */ } // ... and the list keeps growing! } } Every time you add a new state (e.g.,  State.D ), you have to hunt down and update  every single function  with a new case. This is a maintenance nightmare, a direct violation of the  Open/Closed Principle  (OCP), and a major code smell. Your logic is scattered by  action  when it should be grouped by  state . The solution? The  State Pattern . And with modern Kotlin, we can implement it w...
Read more

Coroutines & Flows: 5 Critical Anti-Patterns That Are Secretly Slowing Down Your Android App

Image
 Stop sneaky performance killers. Spot and fix Kotlin issues that cause crashes, memory leaks, and laggy UIs. Coroutines and Kotlin Flows are the bedrock of modern asynchronous programming on Android. They allow us to write clean, sequential-looking code that manages complex background operations, network calls, and database transactions. But power comes with responsibility. Many developers, despite using Coroutines daily, unknowingly introduce subtle mistakes —  anti-patterns  — that lead to memory leaks, silent crashes, data loss, and UI jank. Based on insights from top-tier Android development, here are five critical Coroutine and Flow anti-patterns you must identify and fix today, plus one bonus pitfall I often see in code reviews. 1. The Main Thread Trap: Heavy Work in  viewModelScope When you launch a coroutine inside a  ViewModel  using  viewModelScope.launch { ... } , where do you think that work runs by default? The  Main Thread ! If your...
Read more

Master Time with Kotlin's Stable Timing API: Beyond System.nanoTime()

Image
 Learn how to use type-safe Durations, measure execution time, and simplify unit testing with Kotlin 1.6+. Managing time in software is a ubiquitous challenge. From measuring performance to scheduling events, accurate and robust timing is crucial. For years, many Kotlin developers relied on manual  Long  calculations with  System.nanoTime() . While functional, this approach was prone to unit confusion and lacked type safety. Enter the  stable  kotlin.time  API  (fully stable since Kotlin 1.6). This powerful toolset provides a type-safe, idiomatic, and highly readable way to handle durations. It eliminates the guesswork and boilerplate, allowing you to write cleaner, more maintainable code. Quick Tip:  To follow along with the examples below, you’ll want to include this import at the top of your file:  import kotlin.time.* Why Ditch Manual Long Calculations? Imagine you’re tracking the execution time of a critical network request using th...
Read more