Navigation In Multi-Module Android Apps - Why You're Doing It Wrong!

[@hovseparakelyan7655]

Great video! I noticed that when working with deeply nested composable functions, managing navigation through lambdas can become cumbersome. To address this, I implemented a modular Navigator pattern for each feature module. Here's how it works: 1. Each feature module has its own Navigator (injected via DI) that emits navigation actions using a Channel or StateFlow. 2. The feature module's root composable listens to the navigator and communicates with the main app (e.g., MainActivity) via a callback. 3. Nested composables can directly trigger navigation events (e.g., navigator.event(NavAction.Back)), avoiding the need to pass lambdas all the way back to the root. The key benefit is that this pattern allows me to keep my feature modules completely independent of the app's NavController, as the Navigator is part of the submodule itself. This makes the modules reusable, decoupled, and easy to test. Let me know what you think, and thanks for sharing your insights in this video!

[@StreetsOfBoston]

Makes absolute sense :) If you have separate (and uncoupled!) features, using Dependency Inversion for navigation (and any other (shared) dependencies they may rely on) is the way to go!

[@AndrewDChristie]

Thanks!

[@yashtalreja1946]

sir currently i am watching your jetpack compose playlist and i feel its very structural and very understanding but i have one request for you is that i want you to create a playlist on creating projects like E-commerce app ,Food ordering app , Cab booking etc by using kotlin and jetpack compose ,Firebase which will help us all in learning android app developer in efficient way and project based learning

[@fabiovokrri517]

That's exactly how the documentation tells you to develop navigation

[@RanbirSingh-dl9co]

This approach works well for two to three screens per module, but as the number of screens grows, Compose Navigation might not support maintainable code. The use of lambda functions increases, and writing all the screens in the home screen will cause issues. You might consider creating feature modules for navigation control extensions and passing lambdas to those, or handling everything in the main screen. Either way, it can lead to complications. I recommend using Voyager, where you can access a local Navigator object that is independent of the main screen or any module

Thanks to share this point of view. It makes absolute sense.

[@ngapps]

The same as shown in Now in Android google sample app

[@warTag68]

Golden content as always!

[@jakubmyka1240]

What's your Android Studio theme? It is really nice, is it possible to download it somewhere?

[@unknownBoy85lover]

A worthy video thank you sir ❤

[@amalhanaja]

wdyt if we inject the composable navgraph into a set and using composition local to provide navigation controller?

[@Ceisluck]

what if feature A or B have more than 1 screen, is a overkill to emulate navcontroller, then the options left is to pass down the naController or make a navhost inside feature A or B, wich is BS in a way to see it. But I am ok with what google is recommending in the nowInAndroid sample app

[@ajailani4]

I think so. What if the screens are going to grow to hundreds and the modules are dozens? It's kinda hard and takes so much effort to stitch them all in an app module. Looks like a boilerplate too. Or does anyone have a proper solution for that?

[@user-rz1hv]

@@ajailani4 that's google for ya, they overuse best practices "mechanism" (as a connection with android devs) by pushing literal workarounds. That's why their best practices are shit.

[@grossadmiralthrawn8769]

Does anyone know an Android library for the Matrix protocol.

[@ShivaPrasad-hm5lk]

I am making an app now using jetpack compose in which I have used single activity and then in each composable I have one or more apo calls called in coroutines foe sthis mean I am not doing a lot of work on main thread?

[@mikejawoski5904]

Is it possible to do shared element transition with multi module?

[@PhilippLackner]

@@mikejawoski5904 of course

[@grossadmiralthrawn8769]

Interesting and good video.

[@shreyassathya374]

Great informative video on multi module, Is it possible to please make a video on Event Bus, and use case with a sample app, Thanks in advance.

[@hackmedia7755]

why not use reflection to autogenerate a route by the class name? wouldn't need to repeat so much code.

[@Tomas-g2j4f]

you should have feature level navigation files to make the navhost more readable this approach won't work if you have 50 screens

[@osisuper98]

Won't that lead to coupling the navController to the feature modules?

[@ajaygupta3160]

Hello Sir, I’m an aspiring Android developer working on a multi-module Jetpack Compose stopwatch app. I’m using a foreground service to manage stopwatch logic and display a persistent notification. However, the app gets killed by Android after a few minutes when I put running stopwatch in the background, causing the stopwatch to stop prematurely. Could you please suggest a possible solution to resolve this issue? please help. Please help.

[@TheFlexath]

thanks Philipp

[@devatrii]

What if we've 100 buttons? Should i pass 100 functions?

[@osisuper98]

Haven't yet seen an app with hundred buttons or clicks on one single screen. 😂

[@devatrii]

@osisuper98 what about nesting inside screen?

[@tiltedbybox6118]

9:39 isn't that what you actually deleted? 😅

[@sebastianseno9285]

why people still use multi module in jetpack compose ?

[@TheMikkelet]

multi module is great in theory, but usually end up with giant core module (essentially an app in it self) and a few, small feature modules - too small to get benefit from compiler... mosty multimodule is good for data layer, like remote and/or local that you can use in any app your need

[@TheCypriot09]

Why have the common-navigation if you need to decouple the modules? the main application shouldn't care about the screens at the first place. it should care about the navigations to a different screen and not the actual screens. right?

[@TheCypriot09]

Maybe the common-navigation should need to have an interface (for the screens) where each module needs to use ?

[@tasnimulhasan7329]

Yeah that's the way google recommend 😊

[@baadrqaaba9529]

Thats the point of using MMA

[@deviantstudio]

just pass the interface with module navigation into the module and implement it in the app

[@lale5767]

FYI philip I personally hate these kind of titles 'Why you'rr doing it wrong'. How are you aware of what I'm doing? Are you spying on me? 😂 Seriously though, I find it insulting and I'm sure I'm not the only one who finds it tacky.

[@Mike-er2ih]

Clickbaitsssss

[@PhilippLackner]

Thanks for the feedback

[@viniciussantosmachado4196]

I personally don't care if the content is good

[@lale5767]

@@PhilippLackner anytime bro

[@lale5767]

@@viniciussantosmachado4196 maybe if you're a heavy youtube uaer, it'll wear down on you after a while.

[@SiamakAshrafi]

You should never pass anything complex to your Composable. It should be side effect free and stateless. The ViewModel should do all the work ... so this is obvious :-) Thanks

[@PhilippLackner]

@@SiamakAshrafi if you're a beginner this is everything but obvious 😄

[@SiamakAshrafi]

@@PhilippLackner Don't tell us we are doing it wrong!!! We have been doing it this way from day one ... 👎🏾