How to Navigate From ViewModels With a Custom Navigator - Android Studio Tutorial

[@denisgithuku8563]

But why handle the navigation (which is ui logic) inside a viewmodel?

[@xybnedasdd2930]

Why not?

[@volod-one]

@@xybnedasdd2930 it violates the separation of concerns principle

[@denisgithuku8563]

@@volod-one please tell him.

[@denisgithuku8563]

The viewmodel shouldn't know anything about ui logic like navigation - just like the ui doesn't know what the viewmodel does. What's next? Are we going to start rendering composables in viewmodels too?

[@sushant-chauhan-08]

@@denisgithuku8563 Are we going to start rendering composables in viewmodels too? 😂

[@martinseal1987]

As ever a great video, I won't be implementing this it feels like you've just created a new problem, but as ever you are a great dev if I did want to do it this feels like a clean way to go about it

[@dev_sonu]

We are already using this navigator but navigation is generally done from activities through events

[@Shakenbeer]

And that's the proper way.

[@Simiblumu]

Furthermore what I like to do with this approach is using delegation and implementing the Navigator interface in the view models. That way (especially for simpler navigations) you don’t have to create the functions in each viewModel

[@shifthackz]

Thanks for the video. It seems more clear when navigation is done from ViewModel (as navigation is also a part of screen business logic). I also end up using approach very close to this one for the navigation in my open-source android app.

[@ThePepaNovak]

We have similar "custom" navigation but recetly migrated to "vanilla" navigation because it didn't play well with deeplinks. Reason was that Compose deeplink navigation didn't use navigation flow from custom nav so whole navigation got into inconsistent state. Plus benefit of navigation by pure callbacks from Compose component is that lifecycle is handled by default.

[@joeymarley]

Thanks Philip, your videos are golden

[@aabhishek4911]

How is this any different from just sending events from Viewmodel and navigating in the Activity/Fragment/Composable ? The ideal setup is just create a navigator class which wraps the navcontroller and all navigation is done within Navigator class itself.

[@vladalexeev8529]

My compose app is recomposing. If a viewstate in mainactivity is changing, it recomposes full navigation as well. This is pain

[@martinseal1987]

@@vladalexeev8529 😅😂😂

[@kethuy5130]

U are keeping navigation logic in Custom Nav Host class and now are u are keeping in viewmodel which is preferrable?

[@martinseal1987]

Whenever I've ever tried to wrap a navigator it has ended in tears

[@yossimaskin1393]

How would you adjust this ObserveAsEvents function to work with KMP while implementing the repeatOnLifecycle part?

[@aabhishek4911]

Who cares about KMP, its all hype

[@renanzalheiros]

@@aabhishek4911 what is the benefit for trashing kmp? it would be incredible for us, android developers, if kmp succeed

[@deviantstudio]

implement it via expect/actual for all platforms

[@ddaypunk]

@@aabhishek4911 is it though? Provide facts please, then I'll listen and maybe believe it.

[@AntliaRodriguez-d9t]

Muchas gracias, soy nueva en jetpack compose y estaba buscando orientacion de como hacer una ruta serializadle para pasarla a una BottonAppBard. Con este video aclaraste mi duda, tus videos son muy buenos, es una lastima que no haya contenido como el tuyo en español, asi que por el momento tambien doy gracias a YT por los subtitulos xD

[@karamba6936]

How about single responsibility rule and that viewmodel?

[@pablovaldes6022]

Instead of a Singleton you can scope one instance per NavGraph

[@renanzalheiros]

how is that possible?

[@markonovakovic3838]

if you take a bit of inspiration from Slack's Circuit, you can make this even cleaner

[@peaceka]

do you have a link for this? im really intrigued on this approach

[@markonovakovic3838]

@@peaceka you'll see that it's not just about navigation but navigation is a part of it

[@peaceka]

@@markonovakovic3838 aight, thanks. found it.

[@notbambang]

@@markonovakovic3838 using compositionLocal right?

[@jsparidaans]

Will you do a video on TDD? I've been looking to apply it, but don't really have a solid workflow for UI tests

[@ninedaniel246]

The biggest problem with TDD in Android development and why there's not many people using it, is because it's a process that implies a very fast compilation time. It's not productive to have to wait 1-2 minutes or even more to do a small change. I love the concept though!

[@the_c1oud]

What are the performance implications of this? Would navigation still be snappy in large applications?

[@Iweb2023]

Hello. I have updated Android Studio to the latest version and now the default parameters are not displayed when creating any component. What do I have to activate to show them again? Your videos are very good! Thank you!

[@FaysalGimo]

Hi.....How to show a floating window over applications in Jetpack Compose Foreground

[@tigranavdalyan900]

what if we need to pass navOptions to navigate action, or we have a bottom nav bar and we need to save 2 nav controllers for that? Then we will save 2 navigators with separate implementation for bottom nav bar and other screens. I think navigator class just a boilerplate and not clean way for navigation handling.

[@deviantstudio]

it's just an abstraction helping you to test the code. you can write all the stuff in single activity, but don't expect to be hired by decent company :)

[@sergioeduardo3797]

How would I go about adding Bottom Navigation in the Home Graph?

[@meshoraouf8929]

If i use compose multiplatform and use voyager for navigation how navigation from any methods like when received data from firebase messaging

[@mesutemrecelenk5447]

Thanks for video Philip. As far as I am concerned we can use the same way to show snackbar message. Isn't it?

[@andreasrichman5628]

Philipp, something is weird... If you hurry immediately press the login button it will go to 2nd screen BUT after some mili seconds it will go back to 1st screen by itself!?

[@andreasrichman5628]

Sorry, my mistake, I turned on the Layout Inspector. Is that normal behavior with layout inspector?

[@babacarfall330]

Hello. guys! Any idea on how to implement this with nested navigation ????

[@alexkoromyslov8537]

I don't see how it will work in case of multimodule project where every feature is a module with own navigation and destinations. The inheritance of sealed interface will not work between modules.

[@PhilippLackner]

Navigation is not the responsibility of a feature module. The app module has to wire everything together either way, or you destroy the reusability of your modules.

[@svilenstrahilov2557]

I will add to this, if you are familiar with iOS, the "Coordinator pattern" aims to centralize navigation logic and make individual modules or view controllers (with their respective coordinators) reusable and independent. In Android, using the app module to coordinate navigation serves the same purpose as a Coordinator in iOS: it decouples navigation from the individual feature modules (or view controllers in iOS), ensuring that transitions between screens are managed centrally.

[@martinseal1987]

@@PhilippLackner would you elaborate on this? I see a module as having an entry point and handling all it's own navigation within itself by a simple interface, pop push etc it gives the main app a list of it's routes

[@pablovaldes6022]

This one is going to be controversial 😅

[@aamirhoda7363]

the most perfect comment. This video is definitely highly controversial. 😅😅 Well, honestly, as far as my opinion goes, I'm on the traditional train & I don't necessarily see the need to jump on this modern train. 😀😀 What's your take on this?

[@pablovaldes6022]

Gotcha 👍

[@pablovaldes6022]

The current approach. Let's say a button clicks, then it calls a function in the VM, then the VM emits a navigation event back to the Composable, then the Composable invokes a callback to the parent Composable. All the way up to the NavGraph declaration where some class instance will parse this event and determine where to go next. I think this is a lot of boilerplate, why not having the class instance that decide the navigation in the VM itself, properly injected. And when the button click event comes, just determine where to go there. No ceremony. I actually like this approach

[@alperenozil]

I send HOF from compose to the viewmodel

[@VitaliyLL]

I love Android evolution: just in 20min+ of ⚡ fast coding + set of supporting libraries you could create navigation between 3 screens 😂😢😂

[@ErfanSn]

Your solution is coupled with Compose Navigation, if we decide to replace it with another navigation library the whole code must be dumped.

[@PhilippLackner]

Where is it coupled to Compose 🤨 In XML you'd just use your XML navigator to navigate when listening to the navigation events and put that in the activity.

[@ErfanSn]

@@PhilippLackner Not Compose, Navigation Library

[@PhilippLackner]

Then create your own NavOptions object and it's uncoupled 🤷🏼‍♂️ seemed overkill for the video.

[@ErfanSn]

@@PhilippLackner This means that a higher abstraction needs to be used in order to use this approach logically, otherwise it just complicates the work.

[@martinseal1987]

I'm not sure this is a good idea, but I will let you cook, what happens when the view is disposed and the view model isn't and it tries to navigate you somewhere that can't exist

[@PhilippLackner]

@@martinseal1987 I'm not sure I'm getting your point with navigating somewhere that doesn't exist.

[@martinseal1987]

@@PhilippLackner yh I might be talking about something that would never happen, essentially you mention the opposite when you said a shared flow would lose emissions while in the background, I'm saying what happens when it starts replaying them and the app is in a different place to where it should be, but I simply mean this could unintentionally navigate a user somewhere without them touching anything I feel navigation should only be handled by the UI

[@itscooldawgdonteventrip]

​@@martinseal1987 I think what he is proposing here was a solution he invented for a usecase with a client or company he worked with and it seemed like what was proposed by default by the framework was not satisfactory so he moved with that. I can see that the whole point of that is to be testable. Basically you test the navigation from testing the viewmodel and swapping the implementation in the UI test because Navigator is an interface. Let me remember.... before compose. yeah we could test it .. OnView blah blah we were doing a text recon to see if after a performClick it was there with compose we are doing the same thing. I think here they are doing that VM driven navigation to centralise the inteligence of the navigation into each part of the app. Meh before we were using state change and the view reacted to that to change what it was displaying and to test we were simply verifying the change of state that should match the usecase... Well I do not see WHY we would do that. clearly maybe it's useless ( but I am surely mistaken just because I do not see something doesn't mean it is not there )

[@dvg-in-eu]

Yeah, I also think that navigating should be handled by ui.

[@ahmetozcan2278]

@@dvg-in-eu It still handled by ui. This is just an abstraction over navgation. Makes tesing easy.

[@msaikrishnapattnaik6564]

First here

[@Ceisluck]

25 minutes of video at high speed just to navigate to another screen, really? Koin a DI, really? Koin is a service locator. Just saying, in today world android is not android anymore, compose ruined it..... easy to buid UI but good luck fixing performance...

[@boskovaskovic]

I do not recommend this.