Correct implementation of the View in android MVVM

Question

so in MVVM architecture even in google samples we can see things like this:

class CharacterListActivity :BaseActivity() {
    
    val ViewModel: MainViewModel 

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        viewModel.getData()   // Bad!!!
        ...
        viewModel.state.observe(this) { state ->
            when(state) {             // handling state is not views job
                Success -> { navigatetoNextPage() }  // navigating is not views job
                Progress -> { showProgress() }         
                NetworkError -> { ShowSnackbar(viewModel.error) }   // I,m not sure about this one either
                Error -> { showErrorDialog(viewModel.error)         
            }
    }

We know that any architecture has its own rules that makes the code testable, maintainable, and scalable over time. in MVVM pattern according to both Wikipedia and Microsoft docs this is the View:

the view is the structure, layout, and appearance of what a user sees on the screen.[6] It displays a representation of the model and receives the user's interaction with the view (clicks, keyboard, gestures, etc.), and it forwards the handling of these to the view model via the data binding (properties, event callbacks, etc.) that is defined to link the view and view model.

each view is defined in XAML, with a limited code-behind that does not contain business logic. However, in some cases, the code-behind might contain UI logic that implements visual behavior such as animations.

XAML is a Xamarin thing, so now let's get back to our code:
here, since activity decides what to do with the state, the activity works as Controller like in MVC but, activity supposed to be the View ,view is just supposed to do the UI logic.
the activity even tells the ViewModel to get data. this is again not the View's job.

please note that telling what to do to the other modules in the code is not the View's job. this is making the view act as controller. view is supposed to handle its state via callbacks from the ViewModel. the View is supposed to just tell the ViewModel about events like onClick().

since ViewModel doesn't have access to View, it can't show a dialog or navigate through the app directly!

so what is an alternative approach to do this without violation of architecture rules? should I have a function for any lif cycle event in ViewModel, like viewModel.onCreate? or viewModel.onStart? what about navigation or showing dialogs?

For The Record I'm not mixing Up mvc and mvvm, I'm saying that this pattern does which is recommended buy google.

This is not opinion-based, surely anyone can have their own implementation of any architecture but the rules must always be followed to achieve overtime maintainability.

I can name the violations in this code one by one for you:

1) UI is not responsible for getting data, UI just needs to tell ViewModel about events.

2) UI is not responsible for handling state which is exactly what it does here. more general, UI shouldn't contain any non-UI logic.

3) UI is not responsible for navigating between screens

Answer 1

the activity even tells the ViewModel to get data. this is again not the View's job.

Correct. The data fetch should be triggered either by ViewModel.init, or more accurately the activation of a reactive data source (modeled by LiveData, wrapping said reactive source with onActive/onInactive).

If the fetch MUST happen as a result of create, which is unlikely, then it could be done using the DefaultLifecycleObserver using the Jetpack Lifecycle API to create a custom lifecycle-aware component.

Refer to https://stackoverflow.com/a/59109512/2413303

since ViewModel doesn't have access to View, it can't show a dialog or navigate through the app directly!

You can use a custom lifecycle aware component such as EventEmitter (or here) to send one-off events from the ViewModel to the View.

You can also refer to a slightly more advanced technique where rather than just an event, an actual command is sent down in the form of a lambda expression sent as an event, which will be handled by the Activity when it becomes available.

Refer to https://medium.com/@Zhuinden/simplifying-jetpack-navigation-between-top-level-destinations-using-dagger-hilt-3d918721d91e

typealias NavigationCommand = NavController.() -> Unit

@ActivityRetainedScoped
class NavigationDispatcher @Inject constructor() {
    private val navigationEmitter: EventEmitter<NavigationCommand> = EventEmitter()
    val navigationCommands: EventSource<NavigationCommand> = navigationEmitter

    fun emit(navigationCommand: NavigationCommand) {
        navigationEmitter.emit(navigationCommand)
    }
}

@AndroidEntryPoint
class MainActivity : AppCompatActivity() {
    @Inject
    lateinit var navigationDispatcher: NavigationDispatcher

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        navigationDispatcher.navigationCommands.observe(this) { command ->
            command.invoke(Navigation.findNavController(this, R.id.nav_host))
        }
    }
}

class LoginViewModel @ViewModelInject constructor(
    private val navigationDispatcher: NavigationDispatcher,
    @Assisted private val savedStateHandle: SavedStateHandle
) : ViewModel() {
    fun onRegisterClicked() {
        navigationDispatcher.emit { 
            navigate(R.id.logged_out_to_registration)
        }
    }
}

If Hilt is not used, the equivalent can be done using Activity-scoped ViewModel and custom AbstractSavedStateViewModelFactory subclasses.