Model View Presenter – Parte 2

Posted by on Mar 10, 2015 in Android, Design Patterns, Tutorial | 4 comments

Model View Presenter – Parte 2

In questa seconda parte vedremo l’ implementazione del Model View Presenter.

L’ esempio è molto semplice e spesso usato in numerosi tutoria,l si tratta della classica fase di avvio di un’ applicazione: avvio, splashscreen, sync dei dati, activity principale.

Nella prima parte dell’ articolo ho spiegato che uno dei benefici principali dell’ utilizzo del pattern  MVP è tenere separata la UI (la View) dalla gestione dei dati (Model).
La separazione della View dalla logica dei dati (Model) ci permette di:

  • modificare la View senza stravolgere la logica dell’ applicazione
  • testare la View in maniera più efficace; visto che è completamente separata dalla logica
  • cambiare la logica dei dati senza stravolgere la  UI e/o la UX.
  • di conseguenza creare classi con un numero di righe non eccessivo

Lo schema delle relazioni spiega il rapporto tra gli attori:

mvp_schema

In questo esempio la View è  un’ Activity

L’ activity crea un’ instanza del presenter, SplashPresenter,  inviando un riferimento di  se stessa.  La classe SplashPresenter è il nostro Presenter, il mediatore che medierà tra la View e i Model.

L’ interfaccia di comunicazione tra la classe SplashScreenActivity e SplashPresenter è OnPresenter.

L’ activity invoca un metodo del presenter che inizia la procedura di sync dei dati.  SplashScreenActivity  implementa i metodi di OnPresenter che hanno il compito di comunicare all’ utente le varie fasi dell’ avvio dell’ applicazione e alla fine il cambio dell’ activity.

La View è solo questa, non esiste nessun’ altra logica, soprattutto la gestione dei dati o meccanismi di collegamento con la classe che si occupa dei dati, solo  visualizzazione delle informazioni ed eventualmente la gestione dei component come Button, TextView etc. Se in un secondo momento  si rendesse necessario cambiare totalmente o in parte la UI la modifica verrà effettuata rapidamente e senza conseguenze per la stabilità dell’ applicazione.

Il Presenter è la classe SplashPresenter:

SplashPresenter invoca i metodi showProgress,  hideProgress, showMessage e completeConfiguration (righe 12, 13, 19 e 34) gestendo la View e mostrando le varie fasi della sincronizzazione iniziale dell’ applicazione.

Il Presenter  gestisce anche i dati  (Model) usando un’ instanza di SyncComm e  implementando l’ interface OnDataConfiguration. Anche in questa relazione c’è il passaggio di un’ instanza della classe:

OnDataConfiguration:

Il Presenter:

    • ottiene i dati elaborati dalla classe SyncComm
    • gestisce la funzionalità di sync adattando il comportamento in funzione della risposta di SyncComm
    • gestisce anche la View informando l’ utente delle varie fasi della sync

Ecco la classe che gestisce i dati:

La classe simula soltanto una sync,  modificando i metodi è possibile creare una vera e propria comunicazione con un WebServices per esempio.
SyncComm utilizza l’ instanza del Presenter per comunicare i risultati della sync:  simula prima una connection failed con doGetConfiguration e poi un recupero dei dati in locale doGetLocalConfiguration (un db per esempio).

Una volta recuperati il Model di configurazione DataConfiguration viene inviato al Presenter che utilizzerà showMessage della View per mostrare una data di aggiornamento.

La logica è nel Presenter così che  la View e il Model svolgano il loro compito in autonomia.

Conclusioni

Le specifiche di un’ applicazione non dovrebbero mai cambiare, soprattutto quando si è in fase di sviluppo o quando un modulo dell’ app è stato già sviluppato ma succede spesso e MVP si adatta benissimo a questa esigenza. Il caricamento dei dati può essere cambiato in qualsiasi momento senza conseguenze nel workflow dell’ applicazione; la View essendo indipendente dalla logica dei dati può essere testata con tutti i tool o framework di testing.

MVP esempio su Github

Prossimamente descriverò come utilizzare Dagger con MVP.

4 Comments

  1. Anche io sto utilizzando questo pattern ed è veramente utile soprattutto per agevolare la scrittura dei test. Parlerò di questo argomento anche nel mio talk al Droidcon a Torino, se ci sei ci vediamo lì!
    Ciao, Fabio

    • Si ho letto su cosenonjaviste; anche di Dagger 2. Sicuramente seguirò il tuo talk Fabio. Ci vediamo a Torino

    • Si ci sarò… e non vedo l’ ora di seguire il tuo talk, soprattutto per Dagger 2.

      • Dagger 2 è stato pensato molto bene, speriamo sia disponibile presto la versione definitiva!

Trackbacks/Pingbacks

  1. Model View Presenter – Parte 1 | Giuseppe Sorce - Android Developer - […] seconda parte descriverò e spiegherò un esempio concreto di implementazione del Model View […]

Leave a Reply

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *