Model View Presenter – Parte 1

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

Model View Presenter – Parte 1

Nello sviluppo Android uno dei Pattern più efficaci è il Model View Presenter (MVP).
MVP permette di separare la vista dalla logica dei dati, in modo che tutto ciò che riguarda l’ interfaccia sia separato da come deve essere rappresentato sullo schermo. MVP è similie al MVC, la principale differenza è che il Presenter gestisce la logica tra la View  e il Model. MVP e MVC condividono la separazione tra la UI, i controller e la base date (i Model), ma l’ implementazione del Presenter permette di gestire la UI e soprattutto il collegamento tra UI e base dati in maniera più efficente.

Prima di descrivere e mostrare qualche esempio è importante ricordare che MVP non è un architectural pattern ma si occupa solo di presentare e gestire i livelli: Model e View.

In Android abbiamo spesso il problema che l’ interfaccia è strettamente legata ai meccanismi di accesso ai dati. Pensiamo al CursorAdapter che è un mix tra views, cursors e modelli di dati. Le applicazioni devono essere facilmente manutentibili o estendibili nel tempo, cosa succederebbe se il recupero dei dati non avvenisse più da un db locale ma da un servizio Web? La soluzione è cambiare la View in modo tale che l’ accesso dati non sia più sincrono ma asincrono.

MVP permette di rendere le View indipendenti dalla gestione e creazione della base dati dividendo la logica dell’ applicazione in 3 livelli distinti, livelli che possono essere testati separatamente. La possibilità di poter testare i livelli separatamente è una delle caratteristiche del MVP.

Esistono diverse varianti di MVP o diversi modi di implementarlo e dipendono molto dal grado di responsabilità che deleghiamo al Presenter.
Descriverò brevemente gli attori di questo pattern per poi dedicarmi nella seconda parte alla spiegazione del codice di esempio.

Presenter
Il Presenter è il mediatore tra la vista e il modello, recupera i dati, i Model e li invia alle Views ma a differenza di MVC, decide anche cosa succede quando si interagisce con la vista.

View
La View quasi sempre implementata da un’ Activity o Framents (può essere anche una View o Custom View dipende dalla struttura) conterrà un riferimento del Presenter in genere inviato attraverso un dependency injector come Dagger oppure utilizzando altri medoti che permettono di creare un riferimento al Presenter.
L’ unica cosa che la View dovrà fare è richiamare un metodo del Presenter ogni volta che ci sarà un’ interazione tra l’ interfaccia ( per esempio un clic su un Button) e l’ accesso alla base dati.

Model
Qualsiasi applicazione che abbia un minimo di struttura manterrà la base dati, i Model, separati dall’ interfaccia.

Conclusioni

Separare la UI dalla logica in Android non è sempre immediato ma il pattern Model-View-Presenter rende questo compito più facile evitando di creare classi che si occupano sia dei dati che delle interfacce, classi che spesso superano il migliaio di righe di codice.
Nelle applicazioni più grandi e complesse è obbligatorio organizzare bene il codice, altrimenti diventa impossibile estenderle e mantenerle nel tempo.

Nella seconda parte descriverò e spiegherò un esempio concreto di implementazione del Model View Presenter.

No Comments

Trackbacks/Pingbacks

  1. Model View Presenter – Parte 2 | Giuseppe Sorce - Android Developer - […] prima parte dell’ articolo ho spiegato che uno dei benefici principali dell’ utilizzo del pattern […]

Leave a Reply

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