Tutorial

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.

Read More

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.

Read More

Aggiungere la nuova ActionBarCompact

Posted by on Nov 2, 2013 in Tutorial | 0 comments

Aggiungere la nuova ActionBarCompact

In questo breve tutorial spiegherò come aggiungere alle nostre applicazioni la nuova ActionBarCompact che ci permette di utilizzare tutte le funzionalità dell’ ActionBar classica supportando anche le API Level 7.

L’ adozione dell’ ActionBar risale alle API Level 11 con HoneyComb e da li in poi Google ha sempre consigliato di utilizzarla per maggiore integrazione tra le applicazioni e il sistema operativo e uniformità tra le app. Purtroppo per poter adottare la classica ActionBar occorre  sviluppare per un minSdk 11 quindi tagliare fuori una buona fetta di device (prima più di 50% ora 28%). Grazie al lavoro (stupendo aggiungerei) di Jake Warton abbiamo per un po di tempo integrato una “fotocopia” della classica ActionBar, la ActionBarSherlock (ABS abbreviato).

Usando ABS possiamo sfruttare (emulando) tutte le potenzialità di una classica ActionBar rispettando cosi le linee guide di Google.  ABS è stata usata da Google stessa per sviluppare il Play Store che per ovvi motivi deve essere compatibile per il maggior numero di dispositivi.

Per fortuna Google ha provveduto da poco (in ritardo) a colmare questa mancanza di supporto rilasciando con Android 4.3 una nuova libreria di supporto la v7 che comprende anche l’ ActionBarCompact (ABC abbreviato).

Utilizzare ABC per le nostre applicazioni è molto semplice e richiede pochi secondi e poco lavoro.

Per prima cosa assicuriamoci di aver scaricato la libreria di supporto. Per controllare ed eventualmente scaricarla useremo il tool Android Sdk Manager. Troviamo Android Sdk Manager nella cartella {sdk}/tool/ oppure possiamo lanciarlo con il comodo pulsante di Eclipse/Adt.

asm

Scaricando l’ ultima versione di ADT avremo già tutto il necessario per usare ABC. Assicurarsi di avere il progetto appcompat in:

{sdk home}/extras/android/support/v7/

Bene abbiamo tutto possiamo iniziare.

In Eclipse File->New e scegliamo l’ ultimo menu Other…; nella finestra apriamo la cartella  Android e poi scegliamo Android Project from Existing Code.
Nella successiva finestra clicchiamo su Browse… e andiamo a cercare il progetto appcompat nell’ sdk Android. I percorsi saranno diversi dal mio ma dovreste avere un path simile a questo:

{percorso diverso}/sdk/extras/android/support/v7/appcompat/

 

Cliccando su Finish  vedremo il progetto android-support-v7-appcompat nella lista dei nostri progetti. A volte seleziono la voce Copy project into workspace in modo tale che Eclipse copierà l’ intero progetto nel nostro workspace.  Scelgo questa opzione perchè quando consegno i sorgenti a clienti o a aziende inserisco anche il progetto android-support-v7-appcompat cosi che chi utilizzerà i sorgenti avrà tutto pronto senza dover scaricare e aggiungere nulla e i percorsi saranno relativi al nostro progetto o al workspace usato; oppure se spostate il progetto su altri pc non occorre una volta importato andare a cambiare il percorso delle librerie.

Adesso possiamo creare il nostro progetto Test.  Una volta creato andiamo ad aggiungere come libreria il progetto android-support-v7-appcompat.

Modifichiamo la nostra MainActivity

 

Come codice abbiamo finito. Per far funzionare ABC dobbiamo cambiare il tema di default. Possiamo farlo in due modi: cambiare il tema nel Manifest o modificare il tema principale. Vi consiglio di modificare il tema principale in modo tale che in futuro magari aggiungerete altre modifiche come il colore della barra etc.

Nel Manifest basta cambiare il tema scegliendo per esempio Theme.AppCompat.Light

Modificate il tema principale e lasciate invariato il tema nel Manifest quindi modifichiamo il file res/values/styles.xml

E’ giunto il momento di provare il nostro progetto. Io ho usato un Nexus One che ha ancora Android 2.3.6 e funziona correttamente.

Una cosa che forse non noterete subito è la mancanza della classica icona settings di default nei file di meni oppure se provate ad aggiunge altre icone personali al soft menu non funzioneranno. Per mostrare le icone si deve modificare il file menu/main.xml aggiungendo un namespace. Qui sotto il codice che mostra l’ icona settings.

E’ tutto ma nel prossimo tutorial vi spiegherò come utilizzare la nuova ActionBarCompact per modificare il titolo o aggiungere il classico tasto home/back.

Ho creato i progetti che per adesso potete scaricarli da questo link AppCompact

Mi raccomando per qualsiasi chiarimento commentate o scrivetemi su giuseppe.sorce@warpmobile.it

Read More