Simplifying Navigation in Multi-Module Android Apps

In the world of Android development, we are often judged by the company and the app libraries we choose to keep.

Our journey at Meetup, developing both the “Meetup” and “Meetup for Organizers” apps, led us to an innovative solution for navigation in our multi-module apps: the library Compose Destinations. This blog aims to share our insights and to help guide others finding a simpler path.

The Lay of the Land

Our Android and iOS apps, built on Kotlin Multiplatform (KMP), share business logic, network, database, and resources code. To facilitate development, we’ve adopted a multi-module approach, segregating legacy code from new Compose and KMP modules. This structure, while beneficial, posed significant navigation challenges, prompting us to explore the multi-module capabilities of Compose Destinations.

We wanted to give up Android’s Activities and Fragments in our user interface code and instead use pure Jetpack Compose within a single Activity. Compose Destinations made this possible.

It’s the Journey, not the Destination

Compose Destinations stood out for its type-safe navigation and compatibility with the official Google library. Unlike Jetpack Compose Navigation, it offers built-in handling for returning data after navigation, simplifying our code and enhancing maintainability.

Unlike other Compose navigation libraries, Compose Destinations is built on top of the official Google library (Jetpack Compose Navigation) and merely supplements the official capabilities, rather than requiring that our engineers learn an entirely new third-party system for navigation.

Tying On Our Laces

Integrating Compose Destinations began with adding its Gradle plugin using KSP, along with the Compose Destinations animation-core library to enable smooth transitions. Each module contributing destinations required both an implementation dependency on the animation-core library and a ksp dependency on the library’s KSP plugin.

Our focus was on modules containing Compose code. The goal was straightforward navigation across these modules. This approach streamlined our integration.

Finding a Simpler Route

The biggest hurdle was the complexity of the official examples. We opted for a simpler, more intuitive approach that aligned better with our app’s structure and requirements.

We deviated from the complex nested navigation graphs presented in the official examples. Instead, we created a NavGraphs.kt for each app, defining startRoute and destinationsByRoute. Here's a snippet from our build.gradle.kts file:

ksp {
    arg("compose-destinations.mode", "destinations")
    arg("compose-destinations.moduleName", "sharedAndroid")
}

At this point, we ran Gradle sync and generated code providing each app with all of the destinations from all modules.

Then we wrote our NavGraphs.kt file for each app, much like the following example in Meetup for Organizers, which uses Koin for dependency injection:

object NavGraphs {
    val root = object : NavGraphSpec {
        val authRepository: AuthRepository by KoinJavaComponent.inject(AuthRepository::class.java)
        val profileRepository: ProfileRepository by KoinJavaComponent.inject(ProfileRepository::class.java)
        val isOrganizer = profileRepository.getProfile()?.isOrganizer ?: false

        override val route = "root"
        override val startRoute =
            if (authRepository.isLoggedIn() && isOrganizer) GroupScreenDestination
            else LoginDestination
        override val destinationsByRoute = (androidAppDestinations + sharedAndroidDestinations).associateBy { it.route }
    }
}

You’ll notice that androidAppDestinations and sharedAndroidDestinations are generated Kotlin vals provided for us by the Compose Destinations KSP plugin. They're named based upon the compose-destinations.moduleName specified above in the Gradle config. They're only generated this way ifcompose-destinations.mode is set to destinations.

We then specify NavGraphs.root as the navGraph parameter to the DestinationsNavHost.

This setup enabled us to generate and access destinations across modules seamlessly, keeping our configuration minimal and easy to work with.

Where Did We End Up?

Transitioning from Fragments to Compose with Compose Destinations noticeably improved our apps’ performance compared to the old way using Fragments and Jetpack Navigation. Our staff immediately noticed how quickly new screens loaded on taps.

Our key takeaway is the importance of simplicity. While some apps might benefit from complex navigation graphs like the official examples, many can achieve optimal functionality with a more straightforward setup like ours.

Compose Destinations has been a game-changer for us, particularly with its type-safe navigation and efficient data handling. It has significantly improved the user experience, especially in cases where we would like to remember contextual state when navigating back to a previous screen.

Our experience integrating Compose Destinations has been overwhelmingly positive, offering a scalable, efficient navigation solution. We plan to continue refining our implementation and exploring new ways to leverage this powerful tool in our app development journey.