So, philosophical question here regarding compose navigation and view models. At the start of our f...

# compose

[mattinger]

So, philosophical question here regarding compose navigation and view models. At the start of our flow, we load some data for the possible devices the user is eligible to onboard. These devices would be stored in a shared viewModel that is owned by the activity, and passed down the chain to the navigation destinations. The user may then end up having to select (or have auto selected if there’s one option) which device to onboard.

The way i see it there’s two options for this selection:
1. Store the selection in the view model, and have a route like start_onboarding which reads the view model to get the device info.
2. Pass the selection in the route like start_onboarding/111111 which can get the device info from the view model, but the selected device is in the path.
I see option 2 as a little more flexible in that it keeps the viewModel quite a bit lighter and has some possibilities for proper deep linking. But option 1 is more uniform in that all state is stored in the view model instead of being split in two places.

[dorche]

I think the question you need to ask yourself here is "Is the selected_device something core to my whole(most of) app or just a small set of screens use it"

Answering this might actually push you to store the selected device in your Repository layer and then let VMs just observe that.

[mattinger]

@dorche It's a standalone activity that lives within a larger application. The user selects the device and then it's relevant for the rest of the life of that activity, which lives however long it takes to do the onboarding.

[dorche]

Right so perhaps the approach where the "selected" device stays in the repo is pretty clean? You could store the whole object from your list of devices and not worry about passing it around/serialisation

[mattinger]

Yeah, i'm leaning towards keeping it in the view model, backed by SavedStateHandle. This is a transient flow, and doesn't need actual local database storage. It's data doesn't persist across flows.

[dorche]

This is a common misconception - just because something is in a “Repository” doesn’t mean it has to be backed by local db storage or network, it could still just be held in memory only..

Perhaps reading through these (sub)threads will help? https://kotlinlang.slack.com/archives/CJLTWPH7S/p1670605775341849