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!
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!
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
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
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
26 дней назад
Thanks to share this point of view. It makes absolute sense.
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
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?
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?
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?
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.
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
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!
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!
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
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
That's exactly how the documentation tells you to develop navigation
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
Thanks to share this point of view.
It makes absolute sense.
The same as shown in Now in Android google sample app
you should have feature level navigation files to make the navhost more readable this approach won't work if you have 50 screens
Golden content as always!
What's your Android Studio theme? It is really nice, is it possible to download it somewhere?
A worthy video thank you sir ❤
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.
Interesting and good video.
thanks Philipp
Thanks!
wdyt if we inject the composable navgraph into a set and using composition local to provide navigation controller?
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
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?
Does anyone know an Android library for the Matrix protocol.
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?
why not use reflection to autogenerate a route by the class name? wouldn't need to repeat so much code.
Yeah that's the way google recommend 😊
just pass the interface with module navigation into the module and implement it in the app
Thats the point of using MMA
Is it possible to do shared element transition with multi module?
@@mikejawoski5904 of course
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?
Maybe the common-navigation should need to have an interface (for the screens) where each module needs to use ?
why people still use multi module in jetpack compose ?
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.
Clickbaitsssss
Thanks for the feedback
I personally don't care if the content is good
@@PhilippLackner anytime bro
@@viniciussantosmachado4196 maybe if you're a heavy youtube uaer, it'll wear down on you after a while.
9:39 isn't that what you actually deleted? 😅
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
@@SiamakAshrafi if you're a beginner this is everything but obvious 😄
@@PhilippLackner Don't tell us we are doing it wrong!!! We have been doing it this way from day one ... 👎🏾