Good points. :) Please see the comments below:
1. Yes and no. Per the example above, it is the View which should call the Controller and every view will have its controller.
Let's not confuse the UI with the View. The view is the one which tells the UI to render this data. UI is the one which renders it. Talking in the Android ecosystem, consider the View-controller relationship with the Buttons’ onClick method. Once that button is clicked(from UI-view), the onClick will be called, handled in Controller.
But it will not always be the View(or the user’s input) responsible for calling the Controller. Say there was some output expected from some Rest-Call(maybe at application launch) or something, and based on its output the View need to be updated. In this case that will call the particular Controller, which will indeed update the Model/view then.
2. For simplicity the Code was not that elaborated, to avoid the complexity within mini patterns. What I mean to say is the Controller need not poll data from Model, as the process could have been Sync/async(Like DB calls/Rest calls etc), so its worth using the variations of Subscriber pattern here for Controller to know once the Model has worked upon its data, and it can then communicate that back to the view. But yes it should be a 2-way mechanism, per the example shown above.
3. Let's think about what the presenters are for. Presenter works upon the abstract Model/ViewInterface, so is a simple Java class without any layer of dependency(ideally) on any other component, which makes it testable/independent. Now the question where should it be called from? Let's give it a thought. As the starting trigger is from View(receiving User input to make some changes), which sends it to Model(which has business logic), so it is the responsibility of the View to tell Presenter that this is the Model and the ViewInterface which it needs to work upon. Hope it clears it up.
In my opinion, these patterns are only the View patterns(i.e. how deals with how to present the data), and should not be used for designing the entire application around them. Worth using them as a design pattern instead.
Please refer to the clean architecture, which abstracts away all the logic/presentations/domains etc away, enforcing the Single responsibility principle- post here.
