In the MVP architecture, how should the Model layer get its data

Here is an example of what the interface between the View and Presenter could be, from this article

interface MessageView {
  // View methods should be directives, as the View is just executing orders from the 
  // Presenter.

  // Methods for updating the view
  void setMessageBody(String body);
  void setAuthorName(String name);
  void showTranslationButton(boolean shouldShow);

  // Navigation methods
  void goToUserProfile(User user);
}

interface MessagePresenter {
  // Presenter methods should mostly be callbacks, as the View is reporting events for the
  // Presenter to evaluate

  // Lifecycle events methods
  void onStart();

  // Input events methods
  void onAuthorClicked();
  void onThreeFingersSwipe();
}

Here are a couple of interesting points to notice about this interface:

• The methods to update the view should be simple and targeted on a single element. This is better than having a single setMessage(Message message) method that will update everything, because formatting what should be displayed should be the responsibility of the Presenter. For example, you might want to start displaying “You” instead of the user name if the current user is the author of the message, and this is part of your business logic.
• Lifecycle events methods on the Presenter are simple and don’t have to map the (overly complicated) Android lifecycle ones. You don’t have to implement any of them, but you can implement as many as you want if the Presenter needs to take specific actions.
• Input events methods on the Presenter are kept at a high level. If for example you’re trying to detect a complex gesture, like the 3 fingers swipe example, all the gesture detection should be done in the View. You can see that there are MessagePresenter.onAuthorClicked() and MessageView.goToAuthorProfile() methods. The implementation of the View will probably have a click listener that calls this Presenter method that will call goToAuthorProfile(). Should you skip all this and just directly go to the author profile from the click listener? No! The decision of going to that profile when the author name is clicked is part of your business logic, and belongs in the Presenter.

There are several variants of the MVP around since its original design in 1996 by Mike Potel. Martin Fowler discusses some of them in another article on GUI architecture.

One of the key differences between the variants is whether the view is totally isolated from the model or not:

• In the first case, the presenter is the man in the middle of a "passive view" and the model.
• In the second case, the presenter is a "supervising controller", but there are interactions directly between the view and the model. Potel's paper describe well the kind of interactions: the view can request data from the model, and the model can notify the view of some events.

In none of the case would the view directly change the model. The change of the model goes always via the Presenter (or the controller in an MVC).

Remark 1: The MSDN article shows only one arrow directly from the view to the model, in its introduction on the MVC (Model View Controller) part. The arrow is in the wrong direction, but the text is correct: the view can access to the model, and change itself (i.e. not the model, but redraw itself) upon change of the model's data.

Remark 2: The MSDN article also shows Microsoft's MVVM pattern, which is roughly a MVP, but the presenter is ambiguously called "ViewModel". But again, the View therein doesn't updated the model directly.

Your edit:

The code of your edit shows a bidirectional data binding, where update of data in the view would trigger directly a change in the model. This indeed contradicts the original MVP pattern where the View informs the Presenter of desired changes via an "Interactor" and the Presenter has the monopoly to invoke "Commands" to update the Model.

Remark 3: I think the author of this MSDN blog was more interested in introducing the MVVM architecture than writing a comprehensive in-depth article, like Martin Fowler did, on the other architectures. I think also that Microsoft's ADO databinding architecture dating back to the early days of the .net framework favored such a mixed design and made a classic MVP less trivial to implement (it required a DataObjectSource to isolate data model access).