Non c'è esatto/definizione corretta di attuazione MVP in Android
Per rispondere alla tua domanda, a mio avviso il Presenter
non avrebbe alcuna logica Android.
Come tale, il Adapter
sarebbe un "View
" allora cioè presentatore prevede che i dati (attraverso il Activity
o Fragment
) e si occupa solo con il modo di presentare questo.
Vorrei fare MVP come segue.
Modello - POJO di, analisi, Memorizzazione (SqlLite) e il recupero dei dati (http). Ovviamente dividerei il POJO, l'analisi e la logica DB in sottocartelle - ma tutto questo ricade in Model per me.
View-Activity
, Fragment
, Adapters
- Attività & Frammento attesa riferimento ad un presentatore che dà loro dati da visualizzare. Come vengono visualizzati questi dati/messaggi, aspetto + tatto ecc. Viene trattato nel View
.
Presenter - L'uomo di mezza, fornisce la logica agli ingressi cioè Clic dei pulsanti, il recupero dei dati, la validazione degli input & passa quindi il risultato di nuovo alla vista (Activity
o Fragment
)
Ecco un grande articolo su MVP
Ecco una semplificata diagram di MVP
risposta modificato da questa question (risposto anche da me)
Penso che gli adattatori vista Android sono puramente roba V-campo di applicazione, e se le schede sono presentatori - questi presentatori sono da qualche parte interna in un'implementazione vista . Inoltre, i presentatori non dovrebbero contenere la logica aziendale in quanto sono solo mediatori tra M e V. Nel mio attuale progetto basato su MVP, i relatori non sono affatto a conoscenza degli adattatori di lista poiché non dovrebbero preoccuparsi di come viene visualizzata una lista di qualcosa_ (ad es. un relatore spiega una vista: "mostra percorsi in qualche modo", e ascolta solo un evento vista "onRouteSelected" poiché il percorso può essere ottenuto da qualsiasi tipo di widget, non necessariamente da una lista). –
Quindi, hai un riferimento a un presentatore all'interno dell'adattatore? O aggiungi ascoltatori agli eventi degli adattatori e poi reindirizza al [email protected] –
Sì, il secondo caso: gli adattatori possono interagire con le viste di hosting e quindi una vista particolare decide come trasformare/delegare un evento a un presentatore (o un listener di presentatore - dipende da come si separano le interfacce di presentatori e ascoltatori). –