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!

[@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

[@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!

[@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

[@fabiovokrri517]

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

[@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

[@jakubmyka1240]

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

[@ngapps]

The same as shown in Now in Android google sample app

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

[@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

[@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.

[@warTag68]

Golden content as always!

[@grossadmiralthrawn8769]

Interesting and good video.

[@amalhanaja]

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

[@unknownBoy85lover]

A worthy video thank you sir ❤

[@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?

[@deviantstudio]

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

[@TheFlexath]

thanks Philipp

[@hackmedia7755]

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

[@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?

[@grossadmiralthrawn8769]

Does anyone know an Android library for the Matrix protocol.

[@AndrewDChristie]

Thanks!

[@tasnimulhasan7329]

Yeah that's the way google recommend 😊

[@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 ?

[@mikejawoski5904]

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

[@PhilippLackner]

@@mikejawoski5904 of course

[@baadrqaaba9529]

Thats the point of using MMA

[@sebastianseno9285]

why people still use multi module in jetpack compose ?

[@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.

[@tiltedbybox6118]

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

[@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 ... 👎🏾