I’m using Compose + Hilt. I have this ‘onboarding’ set of screens. Screen A makes a backend request,...

# compose

[Tim Malseed]

I’m using Compose + Hilt. I have this ‘onboarding’ set of screens. Screen A makes a backend request, and then passes the data to Screen B. It’s a simple POJO, and I don’t have a persistence layer.

I’m trying to decide if I should use one ViewModel for both screens, and just hold this data in the VM. But, if the user navigated from B back to A, I’m going to have to notify the VM and keep it in-sync with navigation state, which just smells a little to me.

Or, I can use a separate ViewModel for Screen B, and pass the data (somehow), via navigation arguments..

Thoughts?

[dewildte]

Shared VM sounds like a good idea here.

[dewildte]

Why does the VM have to know about navigation?

[Tim Malseed]

That’s a good question, and I think the answer is: it doesn’t!

[Tim Malseed]

I’ll give this a crack with a shared vm. I think the problems I was worrying about are trivial to solve anyway

[Colton Idle]

I would also vote for a shared VM. Let us know how it goes!

[Tim Malseed]

So far, I haven’t really been able to work it out.. the shared VM thing is weird because I model the ‘view state’ for both Screen A and Screen B in the same VM. Which means, if you hit the back button from Screen B and go back to Screen A, you end up retaining a Screen B ‘view state’ that is no longer current.

[Colton Idle]

I believe you should be able to have VMA, VMB, and then SharedVM. Only put shared stuff in the shared VM.