View Model Concepts

[KevinSchildhorn]

There are multiple PRs for ViewModel refactors, I figured it made sense to start a discussion about the differences and preferences.

PRs:

• View Model Refactor Concept - Shared Interface #206
• View Model Refactor Concept - Interface Implementations #217
• ViewModel Refactor Concept - Expect/Actual #218

Basically looking for which one is preferred, what are the pros/cons with each, other notes.

[KevinSchildhorn]

One thing I wanted to bring up that has come up, is that in iOS we sometimes want to have a ViewModel for a View. For example if we have a re-usable view for logging into a service, or data entry, it makes sense to have a ViewModel attached to that view so it can be re-used as well.

However, ViewModels in android are tied to the fragment/activity, so you can't really make a ViewModel for specific views, just the overall fragment/activity.

So one thing I was wondering is how to handle this topic, and best practices.
The way I see it there are a few options:

1. Always Keep the ViewModel and all functionality in a Fragment/Activity or ViewController
2. Keep the root ViewModel like above and have interfaces or subclasses for the re-usable views that are implemented
3. Have Separate ViewModels for each View and pass the viewModelScope in Android to other re-usable views and manage their lifecycles

I'm sure there are more approaches, but I'm interested if anyone has opinions on this.

[KevinSchildhorn]

Found this article, where the ViewModel in iOS contains Service's, which is similar to option 1, but breaks up functionality into services like in 2.
https://medium.com/flawless-app-stories/mvvm-in-ios-swift-aa1448a66fb4

Another thing to mention is the term Service in iOS, which is a naming convention for objects similar to Models. It handles business logic.

[faogustavo]

The third model can also fit this specification. Each platform can decide how to expose the "ViewModel". The iOS sources can name them Services.