Is the arch guide that google has actually just MV...

# android-architecture

[Colton Idle]

Is the arch guide that google has actually just MVVM? (notes in red are mine)

[Pablichjenkov]

The Google version I would call it. When you read a book of mvvm outside of android realm, it is a bit different

[Pablichjenkov]

In general it is pretty much the same, Views just listen for changes in its ViewModel and propagate events to it.
How you inject the ViewModel in the View and is what varies per platform. In Android there is this weird/legacy design where an Activity is recreated when configuration changes. It brings complexity to the VM creation because you cannot just pull your ViewModel from a dependency container. You really have to pull a factory from the dependency container of choice and pass this factory to a lifecycle owner element that will control the life of the VM.

[Pablichjenkov]

All that, to be able to restore the Activity State after a possible process death due to low memory, that you LL never seen most likely.

[Pablichjenkov]

Sorry for writing too much, I just stress out with Android API design some times. Other platforms don't complicate things that much

[Francesc]

a possible process death due to low memory, that you LL never seen most likely

have you tried to return to your app after opening the camera app? 😄

[Pablichjenkov]

Many times, I would agree 8 years ago, but these days you rarely see it crashing. And, in the case of a crash, me as a user would prefer the App to start from zero than showing the last screen where I left it.

[Pablichjenkov]

But well, Android is used in embedded devices with low memory too. So the process death oriented design will exist for ever

[Pablichjenkov]

In any case, I would place important data in rom/solid_state storage rather than ram.

[gildor]

that you LL never seen most likely

It’s totally wrong, not only camera, many other actions can cause it, things like call, any other app opened or even critical things, like link opened in browser of file picker.

And it’s not only Android thing, process can be destroyed on iOS too

I would agree 8 years ago

No, it’s not only 8 years ago, perfectly reproducible in the wild with modern devices

Other platforms don’t complicate things that much

Well, yes, desktop and web apps usually just don’t care about it and use many times more memory in extreme cases

And, in the case of a crash

How does process crash related to this? In case of crash app of course is not restored. Process kill by the system is not crash, and of course user want to restore it

And returning back to Colton’s question. Yes, it’s classical MVVM, I really don’t see any problem with it, lifecycle of VM or way to create VM completely unrelated to this

[gildor]

I don’t say that Android is perfect or something but it helpful to understand why things works the way they work

And valid problem with complex configuration change is finally solved by Compose

[curioustechizen]

@Colton Idle Where do you see this diagram? I don't see it in the updated Guide to App Architecture (https://developer.android.com/topic/architecture/intro)

[Pablichjenkov]

@gildor I did a quick look up on the internet and it seems there is a significant amount of Android low end devices running out there. Not every person in the world can spend 800+ dollars in a decent device. In that regards, I got to admit I was wrong in what I said. I also apologize for confusing process death with a crash, I don’t know why anytime I listen to process death the word crash comes to my mind.
On the other hand, I have no problem at all with the way the framework handles process death and configuration changes. I am more than happy with that and also glad Android takes really serious the lifecycle of an Application and created a strong api around it.
The problem I have, is the fact that they picked the ViewModel term for something that perhaps should be named different. Lets say, *ActivityStateHolder*/*FragmetStateHolder* or LifecycleStateHolder or LifecycleOwnerStateHolder or ConfigurationChangeStateHolder I don’t know. Some name that represents a framework class and is explicitly tied to the framework. Then live the term ViewModel out of the framework. Let this generic term be implemented by developers as whatever they are willing to. That way developers can have easier equivalence with iOS and so.
But since the class is in the framework and forces you to have a ViewModelStoreOwner + LifecycleOwner in order to use it, it makes the conversation with other platforms a bit less trivial.

[Colton Idle]

I did a quick look up on the internet and it seems there is a significant amount of Android low end devices running out there. Not every person in the world can spend 800+ dollars in a decent device. In that regards, I got to admit I was wrong in what I said. I also apologize for confusing process death with a crash, I don’t know why anytime I listen to process death the word crash comes to my mind.

Wow. what a reasonable thing to say. love to see it!

The problem I have, is the fact that they picked the ViewModel

I think Yigit boyar talked about this on reddit and basically said naming is hard, and yes the name is unfortunate.

[Colton Idle]

@gildor you said "Yes, it’s classical MVVM," what about that chart points out "classical MVVM"? Is it the fact that the VM has an observable data holder (LiveData?)

[Pablichjenkov]

I haven't seen the Yigit reddit, I do agree, really hard to find a good name

[Francesc]

@gildor you said "Yes, it’s classical MVVM," what about that chart points out "classical MVVM"? Is it the fact that the VM has an observable data holder (LiveData?)

It's the multiple livedatas for state. On MVI you would have a single observable that represents the whole state of the screen, as opposed to a myriad of observables for different pieces of the screen. The other difference, which is not shown in that diagram, would be how the actions or intents go to the viewmodel, in MVI you would funnel all those through a reducer to mutate the state, while on MVVM that's a bit all over the place.

[mattinger]

To be honest, MVVM doesn't require individual pieces of state. It's perfectly valid to have a single state object drive your user interface. Regardless of whether you are using compose or databinding, it should work fine. The caveat, of course is that that state itself should be immutable, and whatever your binding framework is (LiveData, Flow, MutableState) should replace the entire state object at once. But all the frameworks are smart enough to handle this.