<@U1KMZR9C3> I believe both options are roughly eq...

# android-architecture

[talosdev]

@sam
I believe both options are roughly equivalent (though we could argue about which one is more testable), but I think both of them go against the spirit of MVP.
In MVP the aim is to decouple the View from the Presenter, but in your example you are not achieving this. Optimally the View should be passive and respond to the presenter's instructions. The presenter should be free to call any method in the view, because the logic it contains might be complex and not be limited to success and fail scenarios. In your example you have a method that takes in 3 callbacks (which is already too many) - and obviously this doesn't scale well: the presenter might need to do multiple stuff like show loading, hide loading, show network error, show other error, enable a widget or disable it etc.
Also you are tightly coupling the View with the Presenter: in standard MVP, the View should call the presenter to tell it which operation it should perform and then forget about this; then the presenter will instruct the view what to do. In your example the View needs to know the possible outcomes of the operation and how to handle them (so that it can provide the callbacks). So you are not extracting any presentation logic to the presenter actually.
TL;DR: Neither. Better stick with traditional MVP, where the presenter holds a reference to the view interface and calls public methods of it.