I’ve seen this asked & answered in the #compose channel plenty of times (myself included), but I haven’t quite got my head around a good implementation. Let’s say I’m using route-based navigation, and I want to pass some complex data between routes. The suggestion is to stash that object somewhere, and then pass an identifier via navigation args, then use that identifier to retrieve the object. I’m fine with this when my data has an identifier, and exists in a repository somewhere. But, let’s say I have two Composable screens, StoreList and StoreDetails. And, let’s say each screen has its own ViewModel,

StoreListViewModel

and

StoreDetailsViewModel

StoreList lets me retrieve a list of

Store(val name: String, val lat: Double, val long: Double)

And StoreDetails renders some UI for a particular

Store

. There’s no real ‘identifier’ for a Store, though I could use the hashcode or something. And there’s currently no cache for Stores. Where do I stash this Store object? I don’t particularly want to share the

StoreList's

ViewModel

with the

StoreDetails

screen, as it contains properties and functions that don’t relate to StoreDetails. Do I create a 3rd ViewModel for sharing between the two screens, and set the Store on that VM?

I'd put it in a repository, and if you are worried about memory consumption, scope it narrower than singleton (i.e. create your own scope, I assume you are using som DI framework that allows that)

I’m not sure how you’d narrow the scope of a repository to the lifecycle of two screens - it feels like this is beyond the concerns of the repository

yeah shared viewmodel is the easier approach but makes it more complex to test potentially (if you have to create/mock dependencies that are not used by the details screen)... but hey, who's testing anyway 😆

Or just pass the object, if it really only exists at the UI layer: https://developer.android.com/guide/navigation/navigation-kotlin-dsl#custom-types

I think what you're saying Ian, is that in order to survive process death, the repository is going to need a database or disk persistence layer anyway, and once it has that, it may as well have an in-memory cache as well, and now it can serve multiple screens as required..?

More that if the repository changes from an in memory cache (and requerying your server or whatever when it finds it doesn't have any data loaded) to a persisted database, the rest of your layers don't need to care - your repository, in either case, is the single source of truth for all screens to retrieve those objects

OK. So, if the data is somewhat transient (let’s say, held for the duration of a couple of screens and never used again) - is it just premature optimisation to worry about how long this data lives in the cache?