Model-View-Presenter e Android Application Design

Question

The Problem: Classi di attività molto grandi e contorte. Difficile da leggere/capire e modificare. Difficile da provare.

La possibile soluzione: Model-View-Presenter (forse con l'iniezione delle dipendenze). E Mock Test Objects!

Sto pianificando di implementare Model-View-Presenter nella mia applicazione Android. Questa è fondamentalmente una variante del Model-View-Controller. In sostanza, rendi l'attività un gestore di layout glorificato e rimandi qualsiasi logica aziendale al Presenter. Un altro modo di guardare il Presenter è che è come una classe Helper creata in un'Attività per eseguire il sollevamento con l'attività che fornisce un'interfaccia/callback che può essere utilizzata dal Presenter.

Mi piacerebbe avere alcune riflessioni della comunità su questo. Ad esempio: Quali interfacce sono implicite da questo?
Quali responsabilità avrebbero il modello e la vista rispetto al presentatore.

Per Presenter suppongo che l'Activity implementerà le interfacce necessarie per Presenter?
Quali tipi di cose dovrebbero andare in Presenter contro Attività?

Un presentatore sarebbe uno a uno con un'attività? Che dire di un'attività con più frammenti che visualizza diversi widget ciascuno con il proprio adattatore? Ora abbiamo bisogno di più relatori o ancora di uno solo?

Che dire di Presenter vs. Adapter?

Come dovrebbe relazionarsi un relatore per dire un'attività con ListView e ListViewAdapter? Cosa succede nel Presenter rispetto all'adattatore?
Il relatore deve scegliere l'adattatore da utilizzare? O l'attività dovrebbe prendere questa decisione? Il Presenter deve elaborare i dati del modello o l'adattatore? C'è un conflitto tra gli adattatori e i presentatori? Sono presentatori di adattatori? o qualcosa di meno/di più. Solitamente gli adattatori sono solo per widget come ListViews all'interno di un'attività. Non fanno le chiamate che ottengono i dati stessi, penso.

Quindi in modellista-presentatore la cosa fondamentale è davvero decidere cosa va nel presentatore rispetto alle altre classi e quale dovrebbe essere la comunicazione tra il presentatore e le attività, gli adattatori e le viste/inclusi i frammenti.

Model-View-Presenter è una pessima idea per Android? Oppure si adatta bene con Android Framework?

Ricorda che ci sono numerosi esempi al di fuori di Android di SDK molto maturi che necessitavano ancora di una micro-architettura come MVP. In effetti abbondano esempi: es. Flex era un SDK molto maturo per Flash e tuttavia necessitava ancora di framework MVP e MVC per quasi tutte le principali app.

EJB aveva bisogno di Spring per semplificarlo e organizzarlo. MFC/Struts ecc e l'elenco potrebbe continuare all'infinito. Perché Android dovrebbe essere diverso? Perché dovremmo supporre che l'SDK abbia tutto il necessario nel caso di Android senza uno schema di progettazione come MVP?

Bello sapere prima di spendere centinaia di ore su questo, non esitate a commentare/rispondere a qualsiasi parte di questa domanda.

Answer 1

Android punisce il povero design MV (P | C) più di qualsiasi piattaforma che abbia mai incontrato. Dimentica i metodi maldestri che fornisce lo stato di passaggio su e giù per lo stack di attività.Ottieni quanto più stato e logica possibile dalle tue attività. Spostalo in Servizi, ContentProvider e SharedPreferences come appropriato. Cerca di rendere la tua attività pura visione. IMO, i servizi non hanno mai ricevuto sufficiente attenzione nelle esercitazioni Android. Anche il libro di programmazione Android di O'Reilly dà loro solo un quarto di pagina!

Diffidare di estendere l'applicazione. Se si avvia un servizio nel proprio processo (ad es. Per consentirne il blocco in modo corretto quando si verifica un arresto anomalo di un'attività), il servizio disporrà della propria copia della propria applicazione.

Answer 2

Solo per fornire un riferimento per gli altri che potrebbero essere interessati. Stavo pensando la stessa cosa alcuni anni prima. Quando applichiamo MVC/MVVM/Presentation Model all'app per android, ciò che vogliamo veramente è avere un progetto chiaro e strutturato e, cosa più importante, più facile per i test unitari. Al momento, senza un framework di terze parti, di solito hai un sacco di codice (come addXXListener(), findViewById() ...), che non aggiunge alcun valore commerciale. Inoltre, devi eseguire i test unitari Android invece dei normali test JUnit, che impiegano anni per essere eseguiti e rendono i test unitari un po 'poco pratici. Per questi motivi, alcuni anni fa abbiamo avviato un progetto open source RoboBinding: un framework modello di presentazione dati vincolante per la piattaforma Android. RoboBinding ti aiuta a scrivere codice UI che è più facile da leggere, testare e mantenere. RoboBinding rimuove la necessità del codice non necessario come addXXListener o così e sposta la logica dell'interfaccia utente in Presentation Model, che è un pojo e può essere testato tramite i test JUnit normali. RoboBinding viene fornito con oltre 300 test JUnit per garantire la sua qualità. Altre alternative: Android-Binding, Bindroid e MvvmCross.