¿Qué es la aquitectura Model View Presenter (MVP)?

En resumen:
Model View Presenter trabaja en:
• Evita que nuestra aplicación colapse por el exceso de responsabilidad a Main Activity
• Trabaja en hilos diferentes cada uno

Basando en la diagrama, hay cosas que hay saber separar, tenemos
MVP basico y no requiere de interactor y resporitory pero podemos caer en MVC, para ir desacoplando mucho mas usamos el interactor y repository.
MVP + Interactor/UseCase.
MVP + Repository.
MVP + Interactor + Repository.

Comentaste que 1Activity + 1Presenter o 1Fragment + 1Presenter, a veces esto no es tan cierto, hay casos que activity que tiene mucha lógica de vista o muchas interactiones con un Api que puedes llegar a tener muchos mas presenter en una activity o fragment… Todo depende mucho de los casos de usos que puede tener la aplicación…

¿La relación entre Presenter y Model no es bidireccional?

MVP no es una arquitectura sino un patron de diseño

En otro comentario leí que el Presenter y la View tienen comunicación bidireccional. Entiendo que la View debe transmitir sus peticiones al Presenter, por tanto me es logico pensar que debe tener un objeto Presenter. Sin embargo cuando trabajo con una biblioteca como Volley o Retrofit para el consumo de servicios Rest, estas delegan su proceso a un hilo nuevo ¿Cual es la manera más eficaz de que ese hilo sepa que vista debe actualizar? Yo lo hago pasandole el Context o la Activity. Pero siento que no es la mejor manera y produce codigo confuso. Me regalan su experiencia por favor 😄

Yo lo veo muy parecido a un MVC

MODEL VIEW PRESENTER

Model: Doscomponentes: interactor y repositorio. El interactor decide 
que tipo de fuente de datos se va utilizar. Hay varios tipos de repositorios
uno puede ser una APIRest, BD, sharedPreferences. 

View: Activitys, fragments, view. La vista no tiene conocimiento de los modelos.

Presenter:  Para cada activity o fragment, hay un presenter. Se encarga de
    recibir lo que la vista le solicite, primero pasando por el interactor.