hello, Erik!

how can I help you today?

Mark, what's up?

not much... and you?

Can you recommend a section in any of your books giving examples of a shared viewmodel passing data between fragments please?

I don't think I actually have one right now, from the looks of it

I need to add something for that

I will try to add something in *Elements of Android Jetpack* for the next update, though that's probably a couple of months out

sure no prob. Do you have a section talking about advantages of a single activity architecture?

not directly -- on the whole, I try to keep the architectural elements of my books light, just because recommendations keep changing there

plus, in some cases, I need to artificially add activities, just to show how to start activities

for example, in *Exploring Android*, there's no logical reason for the about screen to be its own activity... except to demonstrate starting an activity

but, it's a good point -- right now, Google is pretty firm about minimizing your activity count, so I should cover that too

I read an article saying many fragments and 1 activity is an advantage because you can share data across screens using a shared viewmodel. But you can use a shared viewmodel if you use multiple activities too

"But you can use a shared viewmodel if you use multiple activities too" -- not between activities

(at least, not by default -- I'm sure you could work up something if you really tried)

ok can you explain?

explain... what? :-)

I've used a viewmodel for an activity before

so I don't see why I can't use it again in a second one

you can use the *class* again

however, when you go to retrieve the *instance*, each activity has its own ViewModelProvider, and so each activity gets its own instance

just so I can put in a useful code snippet... are you a Java person or a Kotlin person?

I think you can specify a singleton viewmodel if you use a DI framework

that would fall under "I'm sure you could work up something if you really tried"

and I don't know how you would handle the lifecycles properly

sure, kotlin is fine

basically, when you do something like private val vm: EventViewModel by viewModels(), that viewModels() property delegate is going to work with a ViewModelProvider that is unique to your activity

you can provide an alternative factory via a lambda (by viewModels { ... })

and through that, you could hack something together that could arrange to share a viewmodel between activities

but, I don't know how you will determine when to clear the viewmodel

ok, can you please compare it to its fragment alternative, using 1 viewmodel instead

in a fragment, by viewModels() will use a ViewModelProvider scoped to the fragment

but by activityViewModels() will use a ViewModelProvider scoped to the activity

so if two fragments in the same activity both use by activityViewModels() for the same ViewModel subclass, they both get the same instance

and, if the activity uses by viewModels() for that same ViewModel subclass, it would get the same instance that the fragments do

that viewmodel will be cleared when the activity is destroyed

ok that makes sense now. I appreciate your explanation mark

take care

you too!

and thanks for the suggestions of topics to cover!

looking forward to reading about it in future editions