Scuola Politecnica e delle Scienze di Base

Corso di Laurea in Ingegneria Informatica

Elaborato finale in ingegneria del software

Design Patterns for mobile applications

Candidato: Relatore:

Federica Musella Prof. Stefano Russo

Settembre 2018

Ringraziamenti

Indice

Introduzione 3

1 Design Patterns 51.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Cosa sono i Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Classificazione Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Design Pattern Creazionali . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4.1 Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Design Pattern Strutturali . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5.1 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.5.2 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6 Design Pattern Comportamentali . . . . . . . . . . . . . . . . . . . . . . 111.6.1 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.7 Architectural Design Patterns . . . . . . . . . . . . . . . . . . . . . . . . 131.7.1 MVC (Model - View - Controller) . . . . . . . . . . . . . . . . . 13

2 Design Pattern nello sviluppo mobile 152.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Vincoli nello sviluppo Mobile . . . . . . . . . . . . . . . . . . . . . . . 152.3 Diverse tecnologie Mobile . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Utilizzo e variazioni Design Patterns classici 193.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 MVC: un parallelismo tra le diverse tecnologie . . . . . . . . . . . . . . 19

3.2.1 MVC in iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2.2 MVC in Android . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3 Variazione di MVC: MVVM in Windows Phone . . . . . . . . . 23

3.3 Composite in iOS: Organizzazione Viste . . . . . . . . . . . . . . . . . . 243.4 Observer in iOS: Sistema di notifiche . . . . . . . . . . . . . . . . . . . 253.5 Adapter in Android: RecycleView . . . . . . . . . . . . . . . . . . . . . 283.6 Abstract Factory in Android: MediaPlayer . . . . . . . . . . . . . . . . . 29

Conclusioni 33

Bibliografia 35

i

1

Introduzione

L’elaborato tratta l’utilizzo dei Pattern all’interno dello sviluppo software, focalizzandosinello specifico sullle tecnologie mobili. Nello sviluppo software è importante garantireattributi attesi software come manutenibilità, riusabilità, estensibilità. Tra i vari strumentiutilizzati per creare sistemi software ben progettati, con attributi di qualità alti ci sono iPattern. Essi nono sono altro che soluzioni a problemi ricorrenti che si presentano durantetutto il processo di realizzazione del software: per questo sono utilizzati in tutte le fasi delciclo di vita del software. Il concetto di Pattern non è nuovo: la prima definizione è statadata già nel 1970, mentre nell’ambito dell’informatica essi sono stati descritti e catalogatinel 1995. In questo elaborato sono trattati in modo approfondito i Pattern architetturalie di progettazione, usati per definire il dominio della soluzione nello sviluppo software.I Design Pattern sono utilizzati nella progettazione Object-Oriented come strumento perfavorire il riuso e non dover riscrivere codici da zero, ma non solo. Infatti essi sono spessousati come punto di partenza allo scopo di definire una strategia comune nella risoluzionedi problemi tipici. Inoltre, hanno il vantaggio di standardizzare la progettazione, fornendouna documentazione semplice e chiara.

Sebbene i Pattern architetturali e di Design forniscono uno strumento indispensabile perla progettazione, essi necessitano di una revisione per adattarsi alle nuove architetture deidispositivi mobile: gli smartphone. Sviluppare sistemi e applicazioni per smartphone nonè analogo a sviluppare software per computer, in quanto essi possiedono caratteristicheintrinsecamente diverse. Bisogna valutare diversi fattori, come ad esempio l’ambientemaggiormente dinamico e le risorse computazionali limitate : CPU, Storage, Batteria..Inoltre, è errato parlare di «tecnologia mobile» perchè il mondo mobile è vasto e varioed è necessario riferirsi alle diverse tecnologie che si sono evolute parallelamente: Apple(iOS), Android e Microsoft (Windows Phone).

L’obiettivo di questo elaborato è mostrare l’approccio che le tecnologie mobili hannoadottato nell’utilizzo dei design pattern “classici”.

Nel primo capitolo sono descritti i design pattern dandone una visione di insieme, illu-strandone l’uso e le motivazioni, presentando una breve descrizione della loro cataloga-zione, di seguito sono approfonditi i Design Patterns più diffusi.

3

Introduzione Introduzione

Nel secondo capitolo invece si introduce lo sviluppo delle applicazioni cellulari, illu-strando novità, esigenze, limitazioni, fornendo una panoramica delle varie tecnologiemobili.

Infine, il terzo capitolo mostra l’utilizzo dei Design Pattern descritti nel primo capitolonel contesto delle applicazioni mobili, mostrandone alcuni esempi.

4

1 Design Patterns

1.1 Introduzione

In questo capitolo sono presentati i Pattern come strumento nell’ambito dello svilupposoftware, seguendo l’approccio utilizzato da Ralph Johnson; Richard Helm; Erich Gam-ma; John M. Vlissides noti anche come «Gang of Four» nel loro testo “Design Patterns: Elements of Reusable Object-Oriented Software” [1995]. È data una breve descrizionedei Pattern, una loro classificazione, ponendo l’accento sui Design Pattern. Infine sonoanalizzati nel dettaglio i Pattern Architetturali e di Design di maggiore rilevanza per losviluppo mobile, fornendone una presentazione generale. [1]

1.2 Cosa sono i Design Patterns

La definizione di Pattern è stata data per la prima volta nel 1970 dall’architetto Christo-pher C. Alexander: “ogni Pattern rappresenta una soluzione a problemi ricorrenti che siripresentano nell’ambiente di sviluppo, in modo da poter essere riutilizzata milioni di vol-te, evitando di dover ripetere le stesse azioni”. Nell’ambito dell’Ingegneria del Software,un Design Pattern è un concetto che può essere definito "una soluzione di progettazionegenerale ad un problema ricorrente". Nello sviluppo software, i Pattern sono utilizzati inogni fase del ciclo di vita del software: i Desing Pattern sono relativi alla fase di design,ovvero di progettazione. I Pattern sono accomunati da 4 elementi costitutivi principali:

1. Nome - Definisce un vocabolario comune tra i progettisti e per la documentazione.Deve permettere di dare un’idea sul problema di progettazione e la sua soluzione.

2. Problema - Descrive quando applicare il modello, ovvero il problema e il suo con-testo. A volte sono incluse anche specifiche condizioni da soddisfare per poterapplicare il modello.

3. Soluzione - Come il pattern viene applicato, in termini di elementi di design, rela-zioni, responsabilità e collaborazione senza però definire una particolare progetta-zione o implementazione, perchè l’intento è fornire una soluzione generale. Nellaprogrammazione OO si compone di classi, oggetti e interfacce.

4. Conseguenze - Risultati e compromessi dell’applicazione del modello. Sono utiliper definire strategie alternative di progettazione, e valutare costi e benefici dell’ap-plicazione del modello. Poichè uno degli intenti dell’utilizzo dei pattern è la riusa-

5

1.3 Classificazione Patterns Design Patterns

bilità, le conseguenze aiutano a definire il suo impatto sulla flessibilità, estensibilitào portabilità di un sistema.

Al giorno d’oggi i Pattern nello sviluppo software sono ampiamente usati perchè offrononumerosi vantaggi: oltre alla definizione di un vocabolario comune, essi sono un rife-rimento di progettazione, favoriscono la riusabilità dei progetti, incapsulano conoscenzaed esperienza, forniscono una visione di alto livello senza dover prescindere da aspettiimplementativi, riducono i costi e accelerano i tempi di sviluppo.

1.3 Classificazione Patterns

I Pattern sono applicabili in tutte le fasi del ciclo di vita dello sviluppo software, sidifferenziano in:

• Pattern di analisi;

• Pattern architetturali;

• Pattern di progettazione (Design Patterns);

• Pattern di codifica.

I Pattern architetturali operano ad un livello diverso (e più ampio) rispetto ai DesignPattern, forniscono schemi per impostare l’organizzazione strutturale di un sistema soft-ware. In questi schemi si descrivono sottosistemi predefiniti insieme con i ruoli che essiassumono e le relazioni reciproche.

I Design Pattern sono catalogati in base a caratteristiche specifiche allo scopo di facilitareaccessibilità e apprendimento. La classificazione proposta dalla «Gang of Four» organiz-za i Design Pattern secondo due criteri: scopo e ambito. Lo scopo si riferisce a “cosa” ilpattern fa. Si differenziano tre diversi scopi:

1. Creazionale - Forniscono un’astrazione del processo di creazione;

2. Strutturale - Si occupano della composizione di classi e oggetti;

3. Comportamentale - Si occupano del modo in cui oggetti e classi interagiscono e glisono attribuite responsabilità.

L’ambito specifica a quali elementi di progettazione è applicato il Pattern: classi o og-getti. In particolare, i Pattern di classe si occupano delle relazioni tra classi e sottoclassi,attraverso l’ereditarietà, stabilite in fase di compilazione ovvero relazioni statiche. I Pat-tern relativi agli oggetti, stabiliscono relazioni tra oggetti, che possono cambiare in fasedi esecuzione quindi possiedono proprietà dinamiche. In tabella sono presenti i principalidesign pattern in base alla loro classificazione.

6

Design Patterns 1.4 Design Pattern Creazionali

Nei prossimi paragrafi sono descritti i Design Pattern divisi per Scopo: Creazionali (1.4),Strutturali (1.5), Comportamentali (1.6). Dei Pattern Creazionali è descritto l’AbstractFactory; Strutturali Adapter e Composite, Comportamentali l’Observer. È poi presentatoil Pattern Architetturale MVC (Model-View-Controller).Per ogni Pattern sono specificati:

• Scopo - cosa fa il pattern;

• Motivazione - come il pattern risolve il problema;

• Applicabilità - in quali casi utilizziamo il pattern;

• Struttura - di quali elementi si compone;

• Conseguenze - l’impatto nel software dell’applicazione del pattern.

1.4 Design Pattern Creazionali

1.4.1 Abstract Factory

Scopo: Fornire un’interfaccia per creare famiglie di prodotti e oggetti senza definire leloro classi concrete.

Motivazione: Si usa quando i client devono essere indipendenti dalla specifica classeconcreta che utilizzano, quindi si utilizzano classi astratte. Questo meccanismo è utiliz-zato per non accoppiare le istanze di una classe alla propria creazione, per creare oggettitra loro in relazione senza legarsi alla loro specifica forma.

Applicabilità: Viene applicato quando un sistema vuole essere reso indipendente dalmodo in cui i suoi prodotti sono creati e composti; quando un sistema viene organizzato

7

1.5 Design Pattern Strutturali Design Patterns

con all’interno o più famiglie di prodotti; si vuole offrire solo le interfacce di un prodottoper creare una libreria, senza fornire le implementazioni specifiche.

Struttura:

• AbstractFactory - dichiara un’interfaccia per le operazioni che vanno a creare i prodotti.

• ConcreteFactory - implementa le operazioni, si occupa ovvero della creazione di prodotticoncreti.

• AbstractProduct - dichiara un’interfaccia del tipo di prodotto creato.

• ConcreteProduct - l’oggetto prodotto dalla concrete factory; implementa l’interfaccia diAstractProduct.

• Cliente - utilizza solo le interfacce dichiarate da AbstractFactory e AbstractProduct.

Conseguenze: Attua un maggior controllo sulle classi create, promuove la coerenza traoggetti che sono progettati per lavorare insieme, ma supportare nuovi tipi di prodotti èdifficile perchè si deve cambiare l’interfaccia e tutte le concrete factory.

1.5 Design Pattern Strutturali

1.5.1 Adapter

Scopo: Convertire un’interfaccia esistente all’interfaccia che il cliente si aspetta.

Motivazione: Si usa quando abbiamo un modulo che non è possibile riusare a causadell’interfaccia non compatibile.

Applicabilità: L’interfaccia della classe esistente non risponde a necessità specifiche,l’interfaccia di una classe non è compatibile. Un object adapter può adattae l’interfacciadella classe base senza dover adattare quelle singole delle sottoclassi

8

Design Patterns 1.5 Design Pattern Strutturali

Struttura:Class adapter - Usa l’ereditarietà per adattare un’interfaccia a un’altra

Object adapter - Basato su delega/composizione

• Target -Definisce l’interfaccia specifica utilizzata dal client

• Client -Collabora con gli oggetti conformi all’interfaccia Target

• Adaptee - L’interfaccia esistente che deve essere adattata.

• Adapter - Adatta l’interfaccia di Adaptee all’interfaccia Target

Conseguenze: Un Adapter di classe ha il limite di non essere idoneo ad adattare anche lesottoclassi, perchè usa una classe Adaptee concreta. Poichè Adapter è una sottoclasse diAdaptee, permette ad Adapter di ignorare alcuni comportamenti di Adaptee. Un Adapterdi classe invece, consente ad un singolo Adapter di funzionare con tutte le sottoclassidi Adaptee, se ci sono, aggiungendo funzionalità anche contemporaneamente. Inoltre, èdifficile sovrascrivere i comportamenti di Adaptee.

1.5.2 Composite

Scopo: Lo scopo del composite è creare una struttura ad albero, componendo gli oggettiin vere e proprie gerarchie. Usato per consentire ai client di trattare in modo uniforme

9

1.5 Design Pattern Strutturali Design Patterns

composizioni di oggetti, come singoli oggetti.

Motivazione: Quando raggruppiamo oggetti semplici in una struttura per creare compo-nenti più grandi, bisogna distinguere tra oggetti primitivi e oggetti che sono usati comecontenitori di essi. Questa distinzione può essere problematica per i clienti, allora il pat-tern Composite usa la composizione ricorsive per far sì che i clienti possano trattare lasruttura uniformemente.

Applicabilità: Si applica quando si vuole che i client non facciano disstinzione tra com-posizione di oggetti e singoli oggetti e quando si vogliono creare gerarchie di oggetti.

Struttura:

• Component - implementa il comportamento predefinito per l’interfaccia comune, dichia-rando un interfaccia per la gestione e l’accesso ai component figli. Definisce un’interfac-cia per l’accesso al genitore nella struttura ricorsiva.

• Leaf - rappresenta gli oggetti foglia, ovvero quelli che si trovano alla fine della gerarchiae non hanno figli. Descrivono il comportamento degli oggetti primitivi nella gerarchia.

• Composite - definisce il comportamento dei componenti che hanno figli. Tiene tracciadei componenti figli e implementa le operazioni relative ai figli definite nell’interfacciaComponent.

• Cliente - usa gli oggetti accedendovi tramite l’interfaccia Component.

10

Design Patterns 1.6 Design Pattern Comportamentali

Conseguenze: Il modello Composite definisce le gerarchie di classi composte da oggettiprimitivi e composti , create ricorsivamente. Questa struttura rende semplice l’interazio-ne dei client con gli oggetti, i quali non sanno se hanno a che fare con un componentecomposto o con una foglia. Facilita l’aggiunta di nuovi componenti, anche con tipi di-versi, che sono supportati dagli oggetti Composite, inoltre non va modificato il cliente.Lo svantaggio è che si crea troppa generalità ed è difficile limitare i componenti, bisognaaggiungere controlli a run-time.

1.6 Design Pattern Comportamentali

1.6.1 Observer

Scopo: L’obiettivo è creare una dipendenza uno-a-molti tra oggetti, in modo che quandoun oggetto cambia il suo stato tutti gli oggetti dipendenti sono avvisati del cambiamento.

Motivazione: Quando ci sono più oggetti che sono parti di un intero sistema è importan-te mantenere coerenza tra di loro. Se si rende le classi strettamente accoppiate, si riducela riusabilità. Allora il pattern Obserber fornisce un meccanismo diverso per mantenerela correlazione dividendo i componenti in soggetti e osservatori: un soggetto può averequalsiasi numero di oggetti dipendenti osservatori. Questi ultimi ricevono notifiche quan-do lo stato del soggetto cambia, e cambiano a loro volta il loro stato, sincronizzandolocon il soggetto. Il tipo di interazione è noto anche come publish-subscribe. Qualsiasinumero di osservatori può sottoscriversi per ricevere notifiche, e un soggetto non devenecessariamente conoscere i propri osservatori.

Applicabilità: Applicato per riutilizzare in modo indipendente oggetti che presentanodiversi aspetti di un’astrazione, per rendere più efficienti le modifiche a seguito alla mo-difica di un oggetto ulteriore, quando si vuole disaccopiare oggetti che però devono avererelazioni di notifiche tra loro.

Struttura:

11

1.6 Design Pattern Comportamentali Design Patterns

• Subject - conosce i propri observer, un numero arbitrario di observer può osservareun subject

• Observer - definisce una interfaccia per l’aggiornamento degli oggetti che devonoessere notifica dei cambiamenti in un soggetto

• ConcreteSubject - contiene uno stato di interesse per gli oggetti ConcreteObservers;invia notifiche ai propri observer

• ConcreteObserver - mantiene un riferimento a un oggetto ConcreteSubject

Un ConcreteObserver, una volta che è stato informato del cambiamento nel Subject, in-terroga l’oggetto specifico del cambiamento per poter rendere il suo stato consistente conquello del Subject. L’oggetto Observer che avvia la richiesta di modifica, posticipa l’ag-giornamento finchè non riceve la notifica dal Subject. La Notify non è sempre chiamatadal soggetto, può essere chiamata anche da un Observer o da un oggetto interno.

12

Design Patterns 1.7 Architectural Design Patterns

Conseguenze: La conseguenza principale è il disaccoppiamento tra subject e observes.Il meccanismo di comunicazione è di tipo broadcast: il sender invia senza conoscere ireceiver (observers), essi decidono se accettare o meno le notifiche. Può essere difficilegestire eventi che comportano una catena di notifiche negli observer.

1.7 Architectural Design Patterns

1.7.1 MVC (Model - View - Controller)

Il Pattern Model-View-Controller è stato introdotto per creare interfacce utente in Small-talk 80. MVC ha portato l’innovazione di separare in oggetti differenti il modello, ovverol’oggetto della applicazione, la vista ovvero la sua visualizzazione all’utente e il con-troller, il quale stabilisce il modo in cui l’interfaccia va a reagire agli input utente. Laseparazione aumenta flessibilità e riusabilità. MVC disaccoppia le viste e la modalità sta-bilendo un protocollo di sottoscrizione / notifica tra loro. Una vista deve rappresentareadeguatamente uno stato del modello. Al momento di un cambiamento di stato, il mo-dello lo notifica alle viste che lo rappresentano. La vista si aggiorna di conseguenza. Sipossono avere più presentazioni di uno stesso modello e al momento di creazione di unanuova vista, non è necessario modificare il modello. In figura è mostrato un esempio dipiù rappresentazioni di uno stesso dato per dare un’idea del concetto: tabella, grafico atorta e istogramma.

13

1.7 Architectural Design Patterns Design Patterns

Le viste sono disaccopiate dal modello con l’approccio definito dal pattern Observer(notifica-sottoscrizione). Inoltre, le viste possono essere annidate secondo il modellofornito dal pattern Composite.

Il Controller incapsula la logica di business dell’applicazione ovvero trasforma gli inpututente (interazioni con la View) in azioni eseguite dal Model (processi). I controller sonoorganizzati in una gerarchia e una vista utilizza una particolare istanza di Controller perimplementare una particolare strategia, ovvero un oggetto che rappresenta un algoritmo.Questo è un esempio del pattern Strategy.

14

2 Design Pattern nello sviluppomobile

2.1 Introduzione

I dispositivi mobile al giorno d’oggi sono a tutti gli effetti dei dispositivi computazionali.Gli sviluppatori software hanno dovuto adattare i Design Pattern per far fronte alle nuovetecnologie mobili. La nuova esigenza è: soddisfare una vastità di utenti che utilizzanodiversi tipi di dispositivi, i quali sono basati su architetture diverse, ma presentano proble-matiche di progettazione simili. Le applicazioni devono essere sviluppate in tempi brevie far fronte a una vasta competizione. I principi da tenere in considerazione sono evolvi-bilità, riusabilità, efficienza. Definire il nucleo dell’applicazione incoraggia la riusabilità,per ottimizzare la progettazione e l’implementazione di un set di componenti. Costruireil design più accattivante non è l’unico obiettivo dello sviluppo mobile in quanto l’appli-cazione non deve solo attirare gli utenti ma anche raggiungere l’equilibrio in termini difunzionalità, estetica, usabilità e prestazioni. Un buon design non solo elimina l’insod-disfazione degli utenti, ma può prevenire arresti anomali o azioni dannose. Quindi, glisviluppatori devono prendere in considerazione diversi aspetti durante la progettazionedell’applicazione mobile. Le applicazioni mobili devono essere veloci e affidabili al finedi essere competitive nell’ambiente estremamente dinamico del giorno d’oggi. Tutto ciòdeve essere fatto tenendo in considerazione i limiti della tecnologia cellulare, che nonsono presenti nello sviluppo classico. [2]

2.2 Vincoli nello sviluppo Mobile

Sviluppare un’applicazione mobile è una sfida che deve tener conto di vari attributi diqualità. Trovare un approccio unico, che permette di ridurre tempo, sforzi e sviluppareapplicazioni competitive non è facile. Un primo vincolo si può trovare nell’intrinsecadiversità dei dispositivi mobile, in termini di dimensioni, risoluzione del display, sistemaoperativo, dimensioni di memoria, durata della batteria, velocità del processore. Inoltre,essi hanno risorse computazionali limitate, in termini di capacità e risorse, quindi applica-zioni molto dispendiose in termini di CPU e memoria non gireranno bene sui dispositivimobile. Un altro vincolo è la portabilità di applicazioni, non possibile a causa delle di-versità delle tecnologie adottate per lo sviluppo e i dispositivi. Ad esempio applicazionisviluppate per Android non sono portabili su dispositivi Apple, ma con il giosto approccio

15

2.3 Diverse tecnologie Mobile Design Pattern nello sviluppo mobile

si possono sviluppare applicazioni desktop facilmente adattabili. E l’utilizzo dei designpatterns gioca un ruolo fondamentale per migliorare la qualità e l’efficienza. Ad esem-pio, si potrebbe pensare di implementare solo funzionalità leggere sul dispositivo, e fareseguire su un server le applicazioni, permettendo ai client di invocarne le funzionalità

2.3 Diverse tecnologie Mobile

Quando vogliamo sviluppare un’applicazione mobile si devono fare diverse scelte di de-sign, ognuna di questa influenzerà l’efficienza e la portabilità della nostra applicazionesu altre piattaforme. La prima scelta da fare riguarda il tipo di applicazione, infatti sipuò scegliere di sviluppare una applicazione nativa per cellulare, una web app, oppureun’applicazione ibrida. iOS, Android e Windows Phone hanno differenti esigenze per losviluppo di applicazioni. Importanti requisiti sono performance di alto livello e usabilità.Altri aspetti da considerare sono:

• Determinare per quale dispositivo l’applicazione deve essere supportata (risoluzio-ne,CPU,memoria);

• Considerare scenari con banda limitata in termini di velocità e consumo di potenza;

• Progettare opportunamente interfacce UI, tenendo conto di vincoli di piattaforma;

• Portabilità su altri dispositivi;

• Vari standard, protocolli e tecnologie network;

• Necessità specifiche per gli utenti e la loro privacy;

• Sviluppare applicazioni competitive in tempi brevi per il mercato.

I Design pattern sono usati per rispondere a questi bisogni, adattati e usati in praticaper garantire un vocabolario comune e una documentazione del software, nonchè ridurretempi di sviluppo. Alcune ricerche hanno stabilito che i design pattern possono essereusati per le piattaforme mobile in maniera simile all’architettura classica. Stanno inoltreemergendo i pattern per le UI, in quanto l’interfacciamento con l’utente, di facile com-prensione è uno degli aspetti più importanti nello sviluppo delle applicazioni mobile. Ilpattern architetturale MVC è stato usato e riadattato in tutte le tecnologie. Ad esempio,nello sviluppo Android, esso è stato integrato con il pattern Decorator per il Controller econ l’Observer pattern per la View, inoltre è combinato con il Factory Method per creareviste e controller multipli. Questi adattamenti sono stati fatti per supportare proprietà di-namiche e la flessibilità dei software mobile. Così sono utilizzati anche nell’ambiente disviluppo per Mac OS X e iOS, ovvero Cocoa, il sistema operativo per dispositivi mobileApple. Il Command pattern è usato per gestire e distribuire gli oggetti. Anche Cocoariadatta il pattern MVC, inoltre utilizza molti dei pattern catalogati dalla Gang of Four.Non tutti i pattern però, possono essere usati e adattati allo sviluppo mobile, ad esempioil pattern Singleton non è indicato per lo sviluppo di applicazioni leggere. Di seguito unatabella con i design pattern maggiormente usati nello sviluppo mobile, opportunamentecatalogati per piattaforma.

16

Design Pattern nello sviluppo mobile 2.3 Diverse tecnologie Mobile

17

3 Utilizzo e variazioni DesignPatterns classici

3.1 Introduzione

In questo capitolo sono proposti alcuni esempi rappresentavi dei Design Pattern descrittidalla Gang of Four all’interno delle tecnologie mobile. Ovviamente non sono gli unici adessere utilizzati, perchè i design pattern classici restano sempre una soluzione elegante edefficiente a problemi ricorrenti, anche nello sviluppo mobile. Il pattern MVC è presentatofacendo un parallelismo tra le varie tecnologie e fornendo alcuni esempi di utilizzo. Sonopoi proposti due esempi di utilizzo e implementazione di design pattern per la tecnologiaiOS: Composite e Observer e due esempi per la tecnologia Android: Adapter e AbstractFactory.

3.2 MVC: un parallelismo tra le diverse tecnologie

Il Pattern MVC è uno dei pattern architetturali fondamentali. Per la sua importanza edelevata distribuzione nelle applicazioni è stato riutilizzato ed adattato per rifarsi alle esi-genze delle diverse tecnologie mobili. Nei prossimi paragrafi si evidenziano le diverseinterpretazioni e implementazioni rispettivamente per le tre tecnologie mobile dominanti:iOS, Android e Windows Phone.

3.2.1 MVC in iOS

In iOS il Pattern MVC è utilizzato in una versione leggermente diversa rispetto all’origi-nale, che si compone di altri pattern: Strategy e Mediator per il Controller, Command eComposite per la View, e Observer per il Model. In questa versione View e Model noninteragiscono direttamente, non hanno percezione l’uno dell’altro e comunicano attraver-so il Controller, i cui oggetti assumono quindi maggiori responsabilità. Infatti gli oggettiController aumentano in complessità per mediare il flusso di dati fra Model e View inentrambe le direzioni. Per migliorare lo sviluppo di questa nuova funzionalità si introdu-ce il pattern Mediator, il quale funge appunto da “mediatore tra le parti”. Il diagrammarappresenta sinteticamente la struttura del pattern MVC nella concezione adottata in iOS.[3]-[4]

19

3.2 MVC: un parallelismo tra le diverse tecnologieUtilizzo e variazioni Design Patterns classici

Gli oggetti Controller in iOS sono oggetti UIViewController; questa classe è la base perogni applicazione mobile iOS in quanto è composta dai principali metodi per la gestionedi funzionalità associate a comportamenti comuni ad ogni app. Ci possono essere oggettidelegati che ne estendono o modificano alcune caratteristiche. Il Model, relativo al mode-lo dei dati e la View, relativa alle interfacce utente, sono i componenti che generalmentesi riutilizzano nell’architettura. Il design pattern Command è associato in questo modelloagli oggetti View per gestire e coordinare tutti gli eventi prodotti al momento dell’inte-razione dell’utente con l’interfaccia. Essi sono gestiti negli oggetti UIViewController,stabilendo dinamicamente, ovvero a tempo di esecuzione, il destinatario di una specificarichiesta. Questo comportamento è implementato nel meccanismo Target-Action.

Esempio MVC: UIKit

UIKit è un framework che la Apple mette a disposizione,il quale fornisce l’infrastrutturaprincipale per sviluppare app iOS. La maggior parte delle applicazioni iOS sono svilup-pate utilizzando questa struttura. Le funzionalità che racchiude l’UIKit comprendonol’architettura per l’interfaccia, la gestione degli eventi per il Multi-Touch e altri input e ilciclo di esecuzione principale che gestisce interazioni tra utente, sistema e applicazione.Inoltre sono inclusi supporto per animazioni, documenti, disegni e stampa, testo, ricerca,estensione applicazione e gestione delle risorse. Gli oggetti forniti interagiscono con ilsistema, eseguono il ciclo degli eventi principale dell’app e permettono di visualizzare icontenuti sullo schermo. La struttura delle app UIKit si basa sul modello di progettazioneModel-View-Controller (MVC), che divide gli oggetti in base al loro scopo. Gli oggettidel Model gestiscono i dati e la business logic dell’app, Gli oggetti della View fornisco-no la rappresentazione visiva dei dati, mentre gli oggetti Controller si occupano anchedella comunicazione tra oggetti View e Controller, spostando i dati tra di loro quandonecessario.

La figura mostra l’architettura fondamentale di un’app UIKit. Fornisce gli oggetti delmodello, ovvero le strutture dati, la maggior parte degli oggetti vista, ma è possibilecreare anche viste personalizzate. Il coordinamento dello scambio di dati tra gli oggettidati e le viste UIKit sono i Controller di visualizzazione e i loro oggetti delegati. [5]

20

Utilizzo e variazioni Design Patterns classici3.2 MVC: un parallelismo tra le diverse tecnologie

Il Controller contiene l’UIApplication il quale è l’oggetto che si occupa di gestire il ciclodi vita dell’app, nonchè l’event loop ovvero il ciclo di eventi principale per il suo fun-zionamento. UIWindow è la vista principale, alla quale sono aggiunte views e UIObject,gestiti dal ControllerView. Inoltre l’UIKit fornisce un oggetto UIDocument, il quale sioccupa delle strutture dati e della loro organizzazione per i file che si trovano sul disco.

3.2.2 MVC in Android

Il Model ha il compito di gestire e coordinare i dati. In Android, questo meccanismo èincapsulato nel content provider. Il ruolo del content provider è di creare connessione trai dati e le applicazioni, creando quindi una risorsa a cui accedono più applicazioni. Perpoter accedervi, sono richiesti permessi di accesso ai dati, i quali verranno poi restitui-ti. Ogni content provider possiede l’accesso in lettura e scrittura dall’applicazione da cuihanno origine. Oltre ai content provider di sistema, uno sviluppatore Android può deci-dere di crearne uno specifico per contenere i dati della propria applicazione. In un contentprovider i dati sono archiviati in una tabella, ricordando un database relazionale (tipo SQ-Lite). Quindi gli accessi per aggiornare, inserire e eliminare dati in un content providersono simili alle operazioni sui database. Vengono eseguite richiamando metodi specificiin un Content resolver. Ad esempio, l’operazione di aggiornamento avviene così:

getContentResolver (). update (Uri uri, valori ContentValues, String dove, String []selectionArgs);

L’URI (Uniform Resource Identifier), serve a identificare la posizione del content pro-vider. I valori corrispondono ai dati che si vogliono aggiornare, mentre il campo dove èsimile alla funzionalità dell’istruzione SQL WHERE. Nei content provider integrati si tro-

21

3.2 MVC: un parallelismo tra le diverse tecnologieUtilizzo e variazioni Design Patterns classici

va una costante ovvero una colonna ID, requisito di SQLite che si utilizza per visualizzareil contenuto tramite la view ListView.

La View rappresenta tutto ciò che è visualizzato dall’utente. Essa è responsabile per lagestione delle visualizzazioni e nella traduzione degli input utente. Le Activities sonoutilizzare per gestire un set singolo di eventi. Le Activities hanno un ciclo di vita che èlanciato con l’esecuzione di un’applicazione:

1. L’attività è avviata.

2. Viene eseguito il metodo onCreate ().

3. Viene eseguito il metodo onStart ().

4. Viene eseguito il metodo onResume ().

5. Il metodo onPause () viene eseguito quando l’utente lascia l’attività e viene eseguitoonResume () quando l’utente ritorna all’Attività. Questo potrebbe includere finestre didialogo del sistema.

6. Il metodo onStop () viene chiamato quando l’attività non è più visualizzabile dall’u-tente. Se l’utente ritorna, il metodo onRestart () verrà eseguito prima che l’applicazionevenga ripristinata nel ciclo di vita chiamando nuovamente Start ().

7. Il metodo onDestroy () viene chiamato quando l’attività è stata determinata dal sistemaper essere chiuso e ha eventuali risorse riallocate al sistema. Una vista Android conterrài pezzi visibili e intrattabili mostrati all’utente visualizzazione di widget e visualizzazionipersonalizzate.

Infine, il Controller è il centro del sistema, a cui sono passate informazioni dalla Viewtramite listener di eventi come onClick (), onLongClick () e onKey (). Il Controller nonè altro che la logica dei gestori di eventi e servizi. Un servizio è un componente usatoper eseguire operazioni che durano per lunghi periodi di tempo. Un esempio è l’avviodi contenuti multimediali, e una successiva modifica della schermata iniziale o l’avvio diun’altra applicazione mentre il contenuto multimediale è ancora in riproduzione.

La figura mostra il funzionamento di MVC in Android dove il Model è il content provi-der. Essi devono inviare eventi di notifica sui dati che cambiano attraverso ContentResol-ver.notifyChange.

Le notifiche sono consegnate a una View (ad esempio una ListView), tramite oggettiCursor i quali sono associati agli URI del content provider. I messaggi di aggiornamentodel cursore si attivano quindi dal model alla view. Il controller, ovvero l’attività android,ascolta gli eventi e registra automaticamente le modifiche al cursore, inoltre può informarela View di modifiche avvenute per la visualizzazione. [6]-[7]

22

Utilizzo e variazioni Design Patterns classici3.2 MVC: un parallelismo tra le diverse tecnologie

3.2.3 Variazione di MVC: MVVM in Windows Phone

Il pattern Model-View-ViewModel (MVVM) è un’evoluzione del pattern MVC. In Win-dows Phone questo approccio è utilizzato principalmente per separare il design dall’im-plementazione, in una soluzione in cui i progettisti lavorano in un ambiente chiamatoExpression, mentre gli sviluppatori in Visual Studio, fondendo poi insieme i risultatiin un’unica applicazione. Inoltre, i test su questo tipo di modello sono automatizzati eindipendenti, quindi più efficienti. I tre componenti:

P View ovvero l’interfaccia utente, rappresentata da un file XAML, e ad un livellosemplice da mainpage.xaml.

PModello ovvero gli oggetti che forniscono la comunicazione ai dati sottostanti.

P ViewModel che non è altro che l’equivalente del controller in MVC, che media tramodello e vista.

23

3.3 Composite in iOS: Organizzazione VisteUtilizzo e variazioni Design Patterns classici

In genere, DataContext della vista è associato a un’istanza di viewmodel. Il viewmodel,a sua volta, in genere crea un’istanza del modello (o del grafico del modello). WindowsPhone utilizza anche Dipendenza iniezione (DI). Con DI, quando un componente è di-pendente su un altro componente, non codifica in modo rigido questa dipendenza; invece,elenca i servizi che richiede. Il fornitore di servizi può essere iniettato nel componenteda un’entità esterna come una fabbrica o un quadro di dipendenza. In Windows Phone,DI viene utilizzato per fornire la colla tra la vista, il viewmodel e il modello, in modoche l’app non abbia bisogno di codificare direttamente le connessioni. Dato il model-lo UI basato su pagina di app Windows Phone, questo è importante per garantire che èpossibile utilizzare lo stesso viewmodel in più pagine. Per questo motivo, nessuna vista(pagina) è responsabile della creazione di viewmodel. Piuttosto, l’app crea il modello divisualizzazione ed espone è una proprietà, che è quindi accessibile da qualsiasi pagina.[8]

3.3 Composite in iOS: Organizzazione Viste

In iOS, le viste (oggetti UIView) che compongono l’interfaccia grafica hanno una struttu-ra interna che compone una gerarchia di viste. Una vista “padre” contiene una o più viste“figlio”. Questa struttura è realizzata grazie al Composite pattern. Il nodo radice, nonchèil punto di partenza della gerarchia è la UIWindow, la vista principale e la più grande, chesi adatta allo schermo. Ogni nodo presente nella gerarchia è un oggetto di tipo UIView,perchè è utilizzato per rappresentare il contenuto di un’applicazione sullo schermo, ov-vero per visualizzarlo. Utiizzare lo stesso tipo base è necessario per riferirsi alla strutturae ad ogni suo oggetto in particolare con un’unica interfaccia. Le viste aggiunte successi-vamente, diventano subviews della UIWindow. In particolare, ogni subiew (tranne quellaprincipale) può avere una e una sola superview e zero o più sottoviews. Questo tipo diarchitettura è usata sia per l’aspetto visivo, ovvero per la grafica ma anche per gestiregli eventi. Quando il sistema richiede la visualizzazione di una specifica finestra, il mes-

24

Utilizzo e variazioni Design Patterns classici 3.4 Observer in iOS: Sistema di notifiche

saggio percorre la gerarchia arrivando alla specifica sottoview. Così facendo, si possonotrattare rami della gerarchia o elementi specifici come un’unica vista unificata. Questastruttura di views forma una catena di ricevitori (Responder Chain), modellata attraversoun pattern affiancato, per rispondere agli eventi generati dal sistema e dagli utenti. Nel-l’immagine si può visualizzare questa struttura come un contenimento in cui la superviewcontiene le sue sottoview e come una struttura ad albero con nodi “radice” e “foglie”.

3.4 Observer in iOS: Sistema di notifiche

Il meccanismo di notifica di iOS implementa l’invio e la ricezione di messaggi utilizzan-do il pattern observer, con una modalità one-to-many. Le notifiche regolari, ovvero quelletrasmesse dal centro notifiche, sono solo processi. Se si desidera trasmettere le notifichead altri processi, è possibile utilizzare il centro di notifica distribuito e le relative API(Application Programming Interface). Gli oggetti in un programma aggiungono se stessio altri oggetti a un elenco di osservatori di uno o più notifiche, ognuna delle quali è iden-tificata da una stringa globale (il nome della notifica). L’oggetto che desidera notificarealtri oggetti, l’oggetto osservato, crea un oggetto di notifica e lo invia a un centro di noti-

25

3.4 Observer in iOS: Sistema di notifiche Utilizzo e variazioni Design Patterns classici

fica. Il centro di notifica determina gli osservatori di una particolare notifica e invia lorola notifica tramite un messaggio.

Cocoa Touch ha sviluppato nel proprio framework delle classi per realizzare il meccani-smo delle notifiche, le quali utilizzano il pattern Observer, e non deve essere implementatoda zero ogni volta. Gli oggetti NSNotification sono gli “oggetti notifiche” mentre l’og-getto NSNotificationCenter permette di aggiungere osservatori e comunicare le notifiche.Un oggetto che vuole essere informato per un tipo di notifica in particolare, deve essereaggiunto al centro notifica, e la notifica a cui si vuole sottoscrivere è specificata trami-te un identificativo. Quando si riceve una notifica, è implementato un metodo specifico.Una notifica non è altro che un’istanza della classe NSNotification, ovvero un oggettoche contiene un nome per essere identificato e un oggetto generico (NSObject) per co-municare le notifiche agli oggetti che si sono sottoscritti per esse (questi oggetti sono gliosservatori). Dopo aver creato l’oggetto NSNotification, viene inserito nel centro noti-fiche, ovvero NSNotificationCenter. Infine, se non si vuole più essere informati per unadeterminata notifica, si rimuove l’oggetto dal centro notifiche. Questo meccanismo per-mette di inviare in broadcast le notifiche a più ricevitori (osservatori) superando così lanotizione di notifica come evento point-to-point. Utilizzano il pattern observer, l’oggettoche rende disponibile una notifica, non deve avere conoscenza degli osservatori, mentrequesti ultimi dovranno conoscere l’identificativo della notifica per potersi sottoscrivereper riceverla. Per supportare la ricezione in modo asincrono delle notifiche, vi è la strut-tura opzionale della “Coda di Notifiche” che si aggiunge al Centro Notifiche. Essa agiscecome buffer, ordinando le notifiche ricevute in una struttura FIFO, permettendo così diaccumulare notifiche e supportare ritardi temporali. Inoltre, la Coda di Notifiche effettuaun’operazione chiamata “fusione di notifica” per notifiche che sembrano simili tra loroin base a criteri specifici. Questo meccanismo permette la rimozione di notifiche simili

26

Utilizzo e variazioni Design Patterns classici 3.4 Observer in iOS: Sistema di notifiche

ad una già accodata in precedenza, utilizzato quando si verificano eventi di notifica piùdi una volta, permettendo così di ignorare le notifiche duplicate. Le notifiche non sonoaltro che un meccanismo per informare in modo continuo un oggetto di qualcosa che èavvenuto su un altro oggetto qualsiasi sia il loro legame, purchè l’uno sia sottoscritto aricevere le notifiche dell’altro. Molti framework Cocoa utilizzano questo meccanismo dicomunicazione.

Un esempio di utilizzo del Centro di Notifiche in iOS è dato dal lettore musicale, in par-ticolare quando si seleziona un nuovo brano per la riproduzione, ci sono due notifiche dicui si deve tener conto: lo stato del media player, il quale è cambiato, e anche il brano inriproduzione. NSNotificationCenter è utilizzato per sottoscrivere i due tipi di eventi. Do-po che gli Osservatori sono stati aggiunti al NSNotificationCenter è chiamata la funzione“beginGeneratingPlaybackNotifications” per abilitare le notifiche.

27

3.5 Adapter in Android: RecycleView Utilizzo e variazioni Design Patterns classici

3.5 Adapter in Android: RecycleView

In Android, per Vista (View) si intende il blocco principale su cui è organizzato tutto ilframework UI. Una View è un elemento di una UI che ha una specifica funzionalità, adesempio La KeyWordView fornisce la visualizzazione di una tastiera. La RecyclerView èla versione migliorata di ListView, la quale era usata per una raccolta di viste scorrevoliposte verticalmente, posizionate una sotto l’altra in un elenco. Anche RecyclerView vi-sualizza elenchi, consentendo di visualizzare solo una porzione di una finestra con elevataquantità di dati, permettendo così di risparmiare spazio in memoria durante la visualizza-zione. Nel modello RecyclerView,componenti diversi lavorano insieme per visualizzarei dati. Il contenitore generale per la tua interfaccia utente è un RecyclerViewoggetto cheaggiungi al tuo layout. L’elemento principale è l’oggetto RecycleView per l’interfacciautente, al quale si aggiunge un layout. Il gestore di layout posiziona le viste delle vociall’interno di una RecyclerView. Gestori di layout integrati con la RecyclerView:

LinearLayoutManager mostra gli oggetti in una lista a scorrimento verticale o orizzontale.

GridLayoutManager mostra gli oggetti in una griglia.

StaggeredGridLayoutManager mostra gli oggetti in una griglia sfalsata.

L’adapter è utilizzato in questo contesto per associare set di dati specifici alla Recycler-View: l’adattatore converte l’oggetto in una riga di elenco da inserire in una posizione

28

Utilizzo e variazioni Design Patterns classici3.6 Abstract Factory in Android: MediaPlayer

specifica. L’adattatore crea i supporti di visualizzazione secondo necessità.Quando glielementi visualizzati cambiano, è possibile avvisare l’adattatore chiamando il metodo:RecyclerView.Adapter.notify() ,il quale è interno all’adattatore quindi ricollega solo glielementi interessati.

Il codice seguente mostra come creare un oggetto di tipo RecyclerView, come connettereil Layouyt attraverso il LayoutManager e poi come includere i dati attraverso l’adattatorealla RecyclerView:

myRecyclerView = (RecyclerView) findViewById(R.id.my_recycler_view);

myLayoutManager = new LinearLayoutManager(this); myRecyclerView.setLayoutManager(myLayoutManager);

myAdapter = new MyAdapter(myDataset); myRecyclerView.setAdapter(myAdapter);

[9]

3.6 Abstract Factory in Android: MediaPlayer

Nel framework Android ci sono diversi moduli di media player implementati al supportodi strutture multimediali al livello applicazione. L’applicazione MediaPlayerService puòscegliere tra più player nativi (Midi, stagefright o nuplayer) quale adottare al momentodella riproduzione di audio o video. [10]

29

3.6 Abstract Factory in Android: MediaPlayerUtilizzo e variazioni Design Patterns classici

Si usa il design del polimorfismo, perchè tutti i player supportano funzionalità più o me-no simili. MediaPlayerFactory, che è una realizzazione del Pattern Abstract Factory, ècontattato dal MediaPlayerService, immaginato come client, al momento della scelta delplayer specifico. Per la decisione, ci sono regole di punteggio adottate, e ogni factorydeve avere una sua valutazione specifica di punteggio, per questo motivo è necessario ilpattern Factory. La figura mostra il class diagram del MediaPlayerFactory. Ogni factorycrea un player specifico.

MediaPlayerFactory viene richiamato durante l’inizializzazione di MediaPlayerService.

30

Utilizzo e variazioni Design Patterns classici3.6 Abstract Factory in Android: MediaPlayer

Tutte le istanze dell Factory sono gestite da un KeyedVector <>. MediaPlayerServi-ce::Client si occupa di selezionare il player.

Uno sguardo al codice specifico:

MediaPlayerFactory::getPlayerType è una funzione di supporto per determinare il tipo diplayer per i dati multimediali.

In setDataSource_pre, MediaPlayerFacotry crea e restituisce l’istanza del player nativo.

Successivamente, setDataSource_post salva l’istanza in mPlayer.

31

Conclusioni

L’elaborato ha mostrato come i design patterns si dimostrano ancora un’ottima soluzioneper lo sviluppo software, restando un approccio di progettazione moderno ed efficace.Ovviamente, non sono gli unici design pattern ad essere utilizzati nelle tecnologie mobili:ad esempio iOS utilizza il design pattern Façade per visualizzare le immagini, Androidutilizza il Template Method per definire le Activity, e molto altro ancora. I Pattern pre-sentati forniscono gli esempi più rappresentativi. Un altro punto da osservare è che neglismartphone è di essenziale importanza l’interazione con l’utente: infatti, negli ultimi anni,si stanno evolvendo sempre più pattern di UI (User Interface). Le varie tecnologie mobilene mettono a disposizione diversi, ad esempio pattern di autenticazione, scheletri di viste.In particolare ogni elemento relativo alla visualizzazione utente è schematizzato, senzaperò togliere agli sviluppatori la possibilità di crearne dei nuovi. L’intento della proget-tazione mobile è quello di rendere più veloce e semplice l’apprendimento dello sviluppodi applicazioni mobile, incentivando sempre più persone ad approcciarsi a questa nuovatecnologia, specialmente i giovani.

33

Bibliografia

[1] Ralph Johnson, Richard Helm, Erich Gamma, John M. Vlissides, Design Patterns :Elements of Reusable Object-Oriented Software,Addison-Wesley Professional; 1 edizione(31 ottobre 1994)

[2] Fadilah Ezlina Shahbudin and Fang-Fang Chua, Design Patterns for Developing Hi-gh Efficiency Mobile Application, in «Information Technology & Software Engineering»(2013)

[3] Apple Inc., Cocoa Fundamentals Guide; (2010)

[4] Erik M. Buck, Donald A. Yacktman, Cocoa Design Patterns, Addison-Wesley Profes-sional; 1 edition (September 11, 2009)

[5] Apple Inc., https://developer.apple.com

[6] Phil Dutson ,Android Development Patterns.Best Practices for Professional Develo-pers, Addison-Wesley Professional; 1 edition (March 5, 2016)

[7] http://apprize.info/google/programming_3/13.html (2011)

[8] Andrew Whitechapel Sean McKenna, Windows Phone 8 Development Internals, Mi-crosoft Press; 1 edition (June 25, 2013)

[9] https://github.com/h6ah4i/android-advancedrecyclerview, Copyright © 2017 HarukiHasegawa powered by MkDocs e Materiale per MkDocs

[10] https://edwardlu0904.wordpress.com/2015/09/05/the-factory-pattern-in-android-mediaplayerfactory/

35