Lo schema Model-View-Presenter (MVP) è utile per Android?

Le applicazioni Android sono fondamentalmente basate su Model-View-Controller (MVC) - MVP suona come la stessa cosa, anche se non ho mai sentito il termine prima. Le attività svolgono il ruolo di Controller, le visualizzazioni XML sono proprio questo (anche se puoi costruirle a livello di programmazione nell'attività - è semplicemente più semplice e più semplice farlo in XML) e il Modello che scrivi tu stesso. Quindi sì, quel modello è abbastanza pratico.

Una possibile ragione per cui potresti non aver sentito molto su questo modello di design è che il framework Android ti obbliga a separare la visualizzazione. Poiché l'applicazione sui dispositivi mobili tende ad essere piccola, le persone non tendono a utilizzare MVC completo; tendono alla vista e ai livelli di azione in cui il livello azione esegue gran parte del lavoro (piccolo) del modello.

Se stai scrivendo un'app multipiattaforma, ti consigliamo di osservare un approccio a quattro livelli: Visualizza, Azione, Logica aziendale e Modello. I livelli View e Action sarebbero specifici della piattaforma, mentre la business logic e il modello non cambierebbero. Fondamentalmente, hai diviso l'interazione di presentatore e utente verso il livello Azione, che chiama il livello della logica di business per eseguire l'azione desiderata dall'utente.

Non ho esperienza sulla programmazione Android, ma avendo un breve sguardo su alcune esercitazioni introduttive sulla programmazione di Android, non vedo un motivo per cui MVP dovrebbe essere meno utile come in qualsiasi altro framework basato su eventi. La classe Activity non è molto diversa da Dialog o Form in altri framework, quindi dovrebbe essere facile creare una classe "Activitity Presenter" per qualsiasi sottoclasse di attività della tua applicazione e inserire la logica di base lì.

Gli eventi inviati alla tua "Attività" devono essere delegati al tuo relatore, e se il relatore intende inviare eventi autonomamente o chiamare altre funzioni dipendenti dal sistema, l'attività deve fornire funzioni correlate tramite l'interfaccia che condivide con il presentatore. Ma questo è fondamentalmente lo stesso di qualsiasi altro framework GUI che conosco.

MVP è sicuramente utile per Android. Aiuta ad organizzare e testare il tuo codice unitario. E la parte migliore è che le nuove persone che leggono il tuo codice saranno in grado di capire il codice e inizieranno a contribuire appena sapranno cosa dovrebbe andare dove. Ecco un link molto utile per comprendere MVP con esempi .

Ecco una breve spiegazione di tutti e tre i componenti di MVP

Visualizza

In Android MVP, una vista contiene due cose Attività - risorsa Android Visualizza - interfaccia java Attività Implementa la vista e si inietta (Visualizza interfaccia) nel presentatore in modo che il relatore possa parlare con l'attività utilizzando l'interfaccia di visualizzazione. I primi tre blocchi del diagramma mostrano la comunicazione tra View e The Presenter.

Presenter

Presenter funge da livello intermedio tra Visualizza e Dati / Modello. Visualizza il relatore dei comandi (Attività) per presentare qualcosa e un presentatore, quindi acquisisce i dati dal database / Modello e restituisce la visualizzazione dei dati presentabili alla vista. Visualizza quindi si occupa di visualizzare quei dati sullo schermo. E ricorda che Presenter è una semplice classe java che non dovrebbe includere alcun componente di Android, altrimenti renderà difficile il test dell'unità del presentatore.

Se si desidera utilizzare il database nel presentatore, creare un'attività creando un'istanza di database e inserirla nel presentatore. Ciò ti aiuterà a prendere in giro il database durante il test dell'unità e ti consentirà di testare la logica di business.

Modello

Il modello in MVP non è altro che la tua fonte di dati. View non parla direttamente con i dati, ma invia Presenter per gestire i dati e restituire le informazioni che possono essere visualizzate senza ulteriori modifiche.