Android

The world of RecyclerView – parte 1

Posted by on Mar 23, 2015 in Android, RecyclerView | 0 comments

The world of RecyclerView – parte 1

Il  titolo di questa serie di articoli riprende il titolo di una delle più interessanti sessioni del Google I/O del 2010: The world of ListView : la serie invece tratterà  delle RecyclerView.
In quel talk  Romain Guy e Adam Powell spiegavano il mondo delle ListView: uno dei widget più usati e indispensabili nello sviluppo Android.
Il mondo delle RecyclerView è iniziato al Google I/O 2014 con Android 5.0 L chiamato dopo Android Lollipop.
Le Recyclerview e le ListView hanno molto in comune: la visualizzazione di elementi dello stesso tipo.
Si suppone che le recyclerview sostituiranno le listview.

La Recylerview è più avanzata,  flessibile e  veloce  nella gestione di grandi liste di dati. Quando l’ utente scorre verso l’ alto o verso il basso entra in gioco il riciclo degli elementi non più visualizzati: questo riciclo o riutilizzo delle view rende le  recylerview molto efficenti.
Il concetto appare molto simile alle ListView ma con un approcio diverso.
Mentre nelle Listview tutto è collegato: base dati, layout, immagini, componenti,animazioni; nelle recylerview non c’è questo stretto legame: la recyclerview non si preoccupa dove posizionare  gli elementi, nè delle immagini o  layout ma si preoccupa soprattutto del riciclo o riutilizzo delle view e rendere tutto più veloce.
Uno dei benefici di questo diverso approcio  è la possibilità di cambiare (in runtime) tipo di visualizzazione: da visualizzazione a lista verticale a lista orizzontale, da vista a card a vista custom. Vedremo in seguito qualche esempio.
Per la visualizzazione, i layout, la gestione dei  dati la recyclerview delega questi compiti alle sotto classi:

RecyclerView.Adapter
Simile all’ adapter che conosciamo si occupa di ricevere i dati e di creare le view.
Non  utilizzeremo  più ArrayAdapter<Model> ma RecyclerView.Adapter<ReclyclerView.ViewHolder>

RecyclerView.ViewHolder
Crea una cache delle view che servono alla creazione della lista.

RecyclerView.LayoutManager
Si occupa di posizionare le view e di determinare il tipo di visualizzazione.
La libreria mette a disposizione 3 differenti layout manager: LinearLayoutManagerGridLayoutManager,StaggeredGridLayoutManager

RecyclerView.ItemDecoration
Modifica l’ aspetto grafico degli item.

RecyclerView.ItemAnimator
Gestisce le animazioni. In genere le 3 principali azioni: adding, removing and moving

Queste sono le classi che permettono quella flessibilità di cui ho parlato prima.
Le recyclerview sono state sviluppate con lo scopo  di migliorare l ‘ estendibilità (extensibility).
Per cambiare totalmente visualizzazione scegliamo uno dei 3  LayoutManager o uno custom, per avere più  animazioni  personalizziamo  ItemAnimator,  per cambiare  l’ aspetto degli item usiamo ItemDecoration.

Merita attenzione la classe ViewHolder. Il pattern viewholder è sempre stato raccomandato dal team di google per rendere efficente la listview, e nella recylcerview (in ritardo secondo me) ha una vera e propria implementazione e ha un ruolo più importante.

Dimenticavo che possiamo usare le recyclerview anche nelle precedenti versioni di Android perchè sono state aggiunte alle librerie support.
Per Android Studio la dipendenza è:

Nella seconda parte della serie di articoli dedicati alle recyclerview spiegherò un esempio basilare e nei successivi articoli vedremo qualche esempio di personalizzazione e animazione.
Edit: aggiungo il link del primo esempio: RecyclerViewExample

Read More

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