VIPER

La Clean Architecture risulta uno strumento di qualit`a, ma rimane comun- que un’astrazione. Una delle sue applicazioni pratiche nell’ambito Mobile `e Viper, utilizzato soprattutto in progetti di grandi dimensioni. Inizialmente `e stato pensato per gestire i progetti in ambito iOS, quindi per lo sviluppo sui

device di casa Apple, ma `e stato presto esteso anche allo sviluppo sulle altre piattaforme.

Figura 2.9: Immagine rappresentante la connessione tra i componenti VIPER VIPER `e l’acronimo di View, Interactor, Presenter, Entity, Router. Di seguito verr`a fornita una descrizione di ogni componente con particolare rife- rimento a contesti reali nell’ambito dello sviluppo Android.

• Interactor: ereditando dalla Clean Architecture, anche in Viper esiste il concetto di Use Cases, che sono responsabili di gestire la Business logic incapsulando comportamenti piccoli ma ben definiti. Generalmente la feature di ogni Sprint va sviluppata creando un nuovo package all’inter- no dell’IDE contenente la struttura delle classi in stile VIPER, quindi l’Interactor di ogni modulo rappresenta un singolo Use Case all’interno dell’App. Contiene la Business logic legata alle Entities o ad operazioni di Rete o pi`u in generale a meccanismi per prendere i dati da una certa fonte. In Android l’Interactor dialogher`a con delle dipendenze esterne a Viper e proprie del Framework di Google, come ad esempio un Service o dei Manager utili al fetching dei dati. Il lavoro svolto dall’Interactor dovrebbe rimanere totalmente indipendente dalla View.

• Entities: i cosiddetti POJO (Plain Old Java Objects), da non confondere con il data access layer, del quale `e invece responsabile l’Interactor. Sono oggetti Java utilizzati per rappresentare la realt`a del sistema. Un oggetto dell’Entity non `e mai manipolato dal Presenter o da altri componenti di Viper: solo l’Interactor ha la responsabilit`a di gestirli.

• Presenter: `e considerato il motore della UI, invoca i metodi dell’Interfac- cia dell’Interactor e una volta che lo stesso gli restituisce i dati, contiene

la logica necessaria per renderli fruibili alla View. Come si pu`o evincere dall’immagine sopra riportata, oltre che mandare richieste all’Interactor, pu`o quindi aggiornare la View a fronte di alcuni eventi (spesso scatenati dall’utente). Nei progetti reali i campi di una classe dell’Entity sono so- litamente di numero superiore rispetto a quelli realmente necessari alla View, inoltre sono spesso in un formato non adatto. Per fare un esem- pio concreto, la classe Persona (Entity) potrebbe contenere un campo long rappresentante la data di nascita in formato timestamp: il Presen- ter generer`a un oggetto (in Mango viene chiamato viewModel) il quale oltre che contenere solo i campi necessari per la View del modulo attivo in quel momento, avr`a un campo birthdate in formato String e ben formattato, pronto per essere dato in pasto alla GUI.

• View: la View `e passiva, non fa altro che aspettare che il Presenter gli dia i dati per poterli mostrare sul display. Il Presenter non conosce gli elementi propri della View, che in Android possono essere un’Activity, un Fragment, un Adapter, un Button e cos`ı via. Il Presenter conosce soltanto il contenuto dei dati che la View va a mostrare; sar`a la View a preoccuparsi di come questi dati devono essere visualizzati.

• Routing: `e il responsabile delle connessioni tra i moduli Viper, si pre- occupa dell’andamento del flusso di lavoro, ovvero di come passare da un modulo all’altro (o se vogliamo, in termini Agili, da una feature all’altra). Il Router `e gestito unicamente dalla View e dal Presenter. Esempio classico `e quello di una app rappresentante una lista di elemen- ti: nel momento in cui l’utente clicca su un determinato elemento della lista, la View, tramite un listener associato alla pressione dell’elemen- to, notificher`a il Presenter, il quale chiamer`a un metodo dell’Interfaccia del Router (che molto probabilmente avr`a una signature molto simile a onItemClicked(int index); la classe che implementer`a l’interfaccia del Router si preoccuper`a, tramite un Android Intent, di aprire una nuova Activity, scatenando l’introduzione di un nuovo modulo Viper. Tale mo- dulo avr`a il compito di ripetere l’intero processo di Viper (quindi anche coinvolgendo Interactor ed Entities) per andare a fare il fetching di tut- ti i dettagli associati all’elemento cliccato dall’utente, che verranno poi mostrati a video una volta terminata la richiesta (che sia una richiesta di rete o una query su un Database locale). In Android, la classe che im- plementa l’Interfaccia del Router `e solitamente l’Activity stessa, la quale si preoccuper`a di lanciare altre Activity. Nei progetti dove `e coinvolto Viper, l’Activity `e considerata il cuore, un ingranaggio di fondamentale importanza che permette di gestire il flusso stesso di tutto il sistema che si va a sviluppare.

Come si pu`o notare, anche in Viper vi `e una netta divisione dei compiti. Il motivo principale per cui si `e deciso di utilizzare Viper in Mango `e proprio il “Single Responsibility Principle”, molto simile alla Dependency rule della Clean Architecture: ogni partizione di Viper ha la sua responsabilit`a, il codi- ce di ogni parte si pu`o sostituire senza difficolt`a e senza generare l’instabilit`a dell’intero Sistema. Viper risulta quindi uno strumento utile per gestire al meglio ai cambiamenti futuri. Un esempio calzante `e quello di Android Wear, che come gi`a accennato, subir`a nelle versioni successive un cambiamento nel metodo di comunicazione con la Rete: la versione 2.0 di Android Wear porter`a ad un’indipendenza tra Smartwatch e Smartphone. Gli sviluppatori dovranno usare altri metodi per il recupero dei dati, potrebbe cadere il concetto di Da- taItems e Messages ed essere sostituito con altri meccanismi. Se si sviluppa con Viper, questo non costituisce alcun problema: le signature delle Interfacce dell’Interactor, che si occupa di prendere i dati, rimangono le stesse; va sosti- tuita solo la loro implementazione. Inoltre, cambiare il modo in cui avviene la connessione alla Rete non porter`a ad un cambiamento della struttura delle Entities, n´e si dovranno apportare variazioni al Presenter e alla veste grafica.