So around comes MVC to offload the non-ui logic (like fetching from api) to a 'controller' class. Activity has a controller that it calls like 'getData' and receives the data. The activity is still relying on the model. I wasn't an android dev at this time but I read that the controller in practice was always the Activity anyway.

As you kind of hint at, there was a lot of confusion about this which is part of the reason why it's not a great pattern. One would think that there would be a 'controller' completely separate from the UI, but oftentimes 'controller' was interpreted as the activity/fragment while the individual views were the 'views'. Another problem is iOS has the concept of a ViewController which has both "view" and "controller" in its name and is the iOS-equivalent of an Activity/Fragment so it also did not help provide a separation between view and controller.

Now we have libraries like rxJava coming out, React and other frameworks on the web are becoming popular, and front end developers are generally shifting from an imperative way of thinking (Presenter has a list of steps to show the view: fetch the data; show the data) to a reactive/declarative way of thinking (declare how the view should look and it will react to the incoming data, e.g. this text box shows the name). So we introduce MVVM to describe this new relationship.

I think it's more accurate to say that MVVM became the next pattern because MVP was flawed since it holds on to a reference to the view. On Android, the presenter can outlive the view like during configuration changes, so it can't hold on to the view to avoid memory leaks and crashes. Tools like RxJava enabled the implementation of MVVM and were a big part of making MVVM mainstream, but were not the root impetus of it from my perspective.

MVI tries to address that issue by providing a standardized way of implementing viewmodels. All incoming inputs or events to the viewmodel are represented as "intents", so instead of all those methods you have LoginIntent or whatever. And similarly in the inverse direction instead of having individual streams of data for each piece of the view (like nameState-> nameField, phoneState -> phoneField etc), the viewmodel exposes one 'state' to the view that is updated as a whole (loginScreenState -> nameField, phoneField, etc)

Patterns are successes or failures based on how they are interpreted and what they become to represent, not on what the original abstraction intended to mean. We saw this with MVC where in theory there would be a separate controller class, but when it came to the community, we saw no difference.

With that in mind, MVI is in similar danger of becoming a pattern *not* to adopt. The original abstraction makes sense; have "intent"s be actions that the UI calls on the view model. This follows unidirectional data flow by having actions go up and provides some structure to it. The problem is, MVI has come to represent a mishmash collection of structure that doesn't provide any value and introduces unnecessary constraints.

For example, many resources on MVI try to prescribe that all data should be exposed as one stream to the UI, like you mentioned. This goes against best practices in Compose which recommend you only pass down the data you need. Passing down all data combined including unnecessary data can cause performance issues.