Can anyone answer this question about the MVI design pattern? Why don’t we model the data flow from the View to the ViewModel simply using methods exposed by the ViewModel? Instead many MVI implementations use a kind of event/messaging mechanism and model the intents as message objects. This doesn’t seam to me very necessary, and it makes the whole architecture needlessly complicated.

Hello. First of all, if this approach works for your project, then I believe you can go ahead with it. Nothing is carved in stone.

Why don’t we model the data flow from the View to the ViewModel simply using methods exposed by the ViewModel

Instead many MVI implementations use a kind of event/messaging mechanism

In this case the view has less dependencies and responsibilities. It is also easier to test in isolation. • The view does not have the responsibility to subscribe/unsubscribe from the state flow. And so usually the view doesn't need to be lifecycle-aware. • The view doesn't depend on the ViewModel - less dependencies is usually better. • The view can be placed alone in a standalone module, without the dependency on the business logic. So the business logic can be swapped, e.g. for different app's brands. • The view can be tested more easily, e.g. via Espresso or screenshot tests. You just show an activity with the view, supply a state and verify the content. Or you just interact with the UI and record the events from the stream. You can easily verify the order of events, as well. You don't need to mock anything (which may slowdown the testing), you also don't need to write any test doubles in this case. Hope this helps.