Useless MvxViewModel behavior

[iXamDev]

🏗 Enhancement Proposal

Hi!

I would like to talk about ViewModel Lifecycle. As we can see in https://www.mvvmcross.com/documentation/fundamentals/viewmodel-lifecycle
MvxViewModel has few methods releted to Android lifecycle: SaveStateToBundle, ReloadFromBundle.

In which usecase this methods should be execute?

I my opinion it's useless logic, that should be never used.
Although I have been using at Mvvmcross for about 3-4 years and have not once felt the need for them. But I use custom implementation of IMvxAndroidViewPresenter based on custom fragment backstack, which gives me opportunity to handle complex navigation scenario.
For a long time I doubted and thought that maybe I do not understand something.
And did not dare to ask you such a question.

But now with Android Q and Android jetpack we can see how Google implement own ViewModel and AndroidViewModel. And we may notice that there no such kludge behavior.

In my mind, the ViewModel remains in memory throughout the entire life cycle of the application (or until screen dismiss), the screen View elements (Activities/Fragments) can be recreated. When you recreate the them, it is enough to select the ViewModel that already exists for it from the cache. And you never need to save VM state and recreate VM itself. And google developer say the same thing.

Pitch

Just remove all android specific logic from MvxViewModel.

Platforms affected (mark all that apply)

• 📱 iOS
• 🤖 Android
• 🏁 WPF
• 🌎 UWP
• 🍎 MacOS
• 📺 tvOS
• 🐒 Xamarin.Forms

[iXamDev]

I assure you it happens.

Yes, and I my oppinion that it should not happen. In rare cases, when VM consumes too much memory you should solve it somehow by youself and not include it in MvxViewModel. In most cases VM does not store lots of data, so it can be just useless boilerplate code.

[aaaabcv]

@iXamDev it happens more often than you might think. And if you read the Android documentation closely you'll notice that the Android ViewModel will only be cached during configuration changes i. e. screen rotations. You might consider enabling the developer option to "not keep activities" and see for yourself. It will enforce destroying activities whenever they go off screen.

Regarding Google not needing a similar concept. They do. They just not implemented it in their first go, but a ViewModel is not a means to replace persistence in case of activity pause resume scenarios. They added a lob later for exactly that purpose.
You might consider having a read in their Dev tutorials for instance.

https://codelabs.developers.google.com/codelabs/android-lifecycles/#6

The basic thing is, there is state which is persisted in the view itself (like scroll positions, test in text fields, check button states...) and there is state in a Model. But at times there is state in a ViewModel too and it seeds to be persisted as well. And while a cache might mitigate further the destruction and recreation of Activities and Fragments, there is also the option that the Android process is killed as whole. State is still preserved in the bundle, however, but any in memory cache for this scenario will fail. So it's a good thing to save state in the bundles anyway and also to use the Dev tools to test these scenarios.

Lifecycle-Aware Components