A modern programming language that makes developers happier.

kotlinlang

Also, if I use the same view model for multiple routes, how do I get the appropriate route from the savedStateHandle in the viewModel? Use `toRoute()` multiple times and catch each one until the right one is found, or maybe make them inherit from a base sealed interface and use `toRoute()` on that (is that supported)?

I ran into this in my app as well. I know that calling `toRoute()` with a sealed interface type when passing in the concrete implementation for the route doesn’t work out of the box. You can maybe get it to work by providing your own `NavType` impl. I ended up refactoring these screens to actually be a single route by moving them out into their own nav graph so they can be routed to from multiple other nav graphs.

I'd say just don't use the same VM for all of them.
Have a dedicated VM per-screen, and then extract all the logic of them to one shared class.
In the VM, do the ssh.toRoute&lt;&gt;() and pass the necessary data to that shared class.
This should make your life so much simpler tbh

Yeah, well, I'm trying to refactor an app I didn't code... so I'm trying to do things step by step, breaking the least amount of functionality as possible until I manage to understand why they did things the way they did...

Delegating should then be a great way, since you get the opportunity to split things up in more readable chunks.

How all of our VMs look like for example is:
```internal class FooViewModel(
  private val someInteraction: SomeUseCase,
  private val savedStateHandle: SavedStateHandle,
) : MoleculeViewModel&lt;FooEvent, FooUiState&gt;(
    FooUiState.Loading,
    FooPresenter(someInput = savedStateHandle.toRoute&lt;&gt;().someInput, someInteraction = someInteraction),
  )```
and the presenter does all the work.
That's what I'd do here, so each screen has one VM and grabs its own SavedStateHandle, but you share the logic somewhere else.

Yeah, that could be a nice idea, thanks! I'm still wondering if they really thought twice before making those four routes... they all have more or less the same structure... it might be that later I'll discover that all I needed was one path! That's really why I was avoiding the separation until I get to know the code-base better. I might not have a choice though...

Btw, you defined that MoleculeViewModel? I'm a bit curious how you structured your code to use it... I'd guess FooPresenter is the composable with all the logic?

<https://github.com/HedvigInsurance/android/blob/38ba5b991ae2bd1436bce78c571959bcbfdbba6f/app/molecule/molecule-android/src/main/kotlin/com/hedvig/android/molecule/android/MoleculeViewModel.kt#L22|https://github.com/HedvigInsurance/android/blob/38ba5b991ae2bd1436bce78c571959bcbf[…]kotlin/com/hedvig/android/molecule/android/MoleculeViewModel.kt>
<https://github.com/HedvigInsurance/android/blob/38ba5b991ae2bd1436bce78c571959bcbfdbba6f/app/molecule/molecule-public/src/main/kotlin/com/hedvig/android/molecule/public/MoleculePresenter.kt#L8|https://github.com/HedvigInsurance/android/blob/38ba5b991ae2bd1436bce78c571959bcbf[…]/kotlin/com/hedvig/android/molecule/public/MoleculePresenter.kt>
Example usage:
<https://github.com/HedvigInsurance/android/blob/583ebed023ba32f169926b53f8e535d7c7e3479c/app/feature/feature-profile/src/main/kotlin/com/hedvig/android/feature/profile/tab/ProfileViewModel.kt#L26|https://github.com/HedvigInsurance/android/blob/583ebed023ba32f169926b53f8e535d7c7[…]tlin/com/hedvig/android/feature/profile/tab/ProfileViewModel.kt>

I also made this <https://github.com/StylianosGakis/molecule-aacvm> for an easy way to start with it