3.3 Modello dell’applicazione Valtellina
4.1.1 Interfaccia Grafica
In questa sezione riportiamo l’analisi dettagliata di tutti gli elementi del metamodello implementativo che compongono l’interfaccia grafica, definibili grazie alle relazioni sull’oggetto ViewController che sono state presentate in precedenza.
Button
Tra i diversi widget che l’utente pu`o utilizzare in fase di sviluppo di un’ap-
Metamodello implementativo
scatenarsi di determinati eventi e il conseguente verificarsi di certe azioni, come la navigazione verso un nuovo ViewController, attivata in genere dal- l’elemento ClickListener, che rileva il click del bottone da parte dell’utente.
Quest’ultimo pu`o infatti essere usato per definire una Navigation che condu-
ce a un nuovo ViewController. Ogni Button presenta un codice identificativo univoco, cos`ı come la maggior parte dei componenti grafici, e un titolo, che sono stati quindi introdotti tra gli attributi di Button.
Per poter modellare correttamente il Listener che rileva il click sul bottone abbiamo aggiunto una relazione che lega Button all’elemento ClickListener. Gli attributi di Button sono:
• Id: `e l’identificativo del bottone.
• Title: `e il titolo che compare sopra il bottone. Le relazioni di Button sono:
• ClickListener: rende il bottone selezionabile e quindi in grado di scate- nare un’azione al momento del click da parte dell’utente. La sua car-
dinalit`a va da zero a uno poich´e `e consentita la definizione di bottoni
non cliccabili.
• ViewController: `e la relazione inversa di buttons su ViewController. ImageView e VideoView
L’elemento ImageView permette di inserire foto o immagini all’interno dei ViewController, mentre VideoView consente di caricare un video. Le imma- gini e i video possono corrispondere a file salvati all’interno dell’applicazione, file remoti scaricati da Internet, oppure file che provengono direttamente dal gestore della fotocamera o videocamera del dispositivo sul quale l’applica-
zione `e installata. Si rende quindi necessario aggiungere un attributo per
indicare la provenienza del file che si intende mostrare e un altro per identifi- carlo, utilizzato solo nel caso in cui il file non abbia come fonte la fotocamera o videocamera del dispositivo.
Gli attributi di ImageView e VideoView sono:
• Id: `e l’identificativo dell’ImageView o della VideoView.
• FileUri: `e l’attributo che permette al programmatore di inserire il no- me del file da utilizzare nel caso in cui sourceType fosse impostato a localFile, oppure l’URL a cui accedere per scaricare la foto o il vi- deo nel caso in cui il valore di sourceType fosse remoteFile. Per i file che provengono dalla fotocamera o videocamera del dispositivo questo attributo deve essere ignorato.
Le relazioni di ImageView e VideoView sono:
• SourceType: `e la relazione con l’attributo enumerativo sourceType, che permette di stabilire la provenienza dell’immagine o del video da mostrare a schermo.
• ViewController: `e la relazione inversa di imageViews o videoView su ViewController.
TextView
Una TextView rappresenta un’area di testo il cui contenuto non pu`o essere
modificato da parte dell’utente finale. Gli attributi di TextView sono:
• Id: `e l’identificativo dell’oggetto TextView.
• Content: ´e il contenuto della TextView. Il contenuto corrisponde a una
stringa e pu`o essere molto lungo.
L’unica relazione di TextView `e:
• ViewController: `e la relazione inversa di textViews su ViewController. EditText
L’elemento EditText rappresenta un’area di testo il cui contenuto pu`o essere
modificato dall’utente finale e corrisponde in genere ad un campo di una
form. Le sue propriet`a sono molto simili a quelle definite per l’elemento
TextView.
Gli attributi di EditText sono:
• Id: `e l’identificativo della EditText.
• InitialContent: `e il contenuto iniziale mostrato in modo predefinito al-
l’apertura del ViewController e in quanto opzionale pu`o essere lasciato
vuoto.
L’unica relazione di EditText `e:
Metamodello implementativo
ListView e GridView
ListView e GridView sono concetti simili, utilizzati per mostrare un elenco di elementi all’interno di uno stesso ViewController. La differenza risiede nel fatto che le ListView sono delle liste scorrevoli, mentre le GridView sono tabelle con scorrimento bidimensionale. Entrambe sono costituite al loro in-
terno da celle, ciascuna delle quali pu`o avere contenuti di vario tipo, anche
se in genere si tratta di testi e/o immagini. Solitamente la selezione di una determinata cella conduce all’apertura di un nuovo ViewController con lo scopo di mostrare all’utente maggiori dettagli riguardo all’elemento cliccato.
Ci`o `e possibile grazie ad un ClickListener, che corrisponde al metodo invo-
cato al momento del click di una cella. In base alla logica implementativa definita all’interno del metodo viene scatenata una determinata azione, co- me l’apertura del nuovo ViewController configurato sulla base dell’elemento selezionato.
L’unico attributo di ListView e GridView `e:
• Id: `e l’identificativo della ListView o GridView. Le relazioni di ListView e GridView sono:
• ListViewCells o GridViewCells: consentono al programmatore di inse- rire un numero qualsiasi di celle nella ListView o GridView. La cardi-
nalit`a di queste relazioni varia da zero a molti, in quanto l’utente pu`o
decidere di inserire manualmente le celle successivamente. Nel caso in cui l’utente intendesse rendere i contenuti della lista o della tabella di- namici, per esempio sulla base di dati salvati in un database locale, l’utente deve lasciare la View priva di celle e gestire successivamente via codice la logica applicativa necessaria per inserire i contenuti nelle varie celle.
• ClickListener: consente alla lista o alla tabella di rendere le proprie celle selezionabili e quindi in grado di scatenare un’azione al momento
del click da parte dell’utente. La sua cardinalit`a va da zero a uno poich´e
la lista o la tabella pu`o presentare celle non selezionabili.
• ViewController: `e la relazione inversa di listViews o gridViews su ViewController.
ListViewCell e GridViewCell
ListViewCell e GridViewCell sono le celle che possono essere aggiunte a List- View e GridView rispettivamente. Questi elementi non sono presenti nel metamodello astratto proprio per la natura di tale metamodello di modellare
ad alto livello la struttura delle applicazioni. Abbiamo anticipato che il con-
tenuto delle celle delle GridView e delle ListView pu`o essere personalizzato
e, nel caso pi`u semplice, il contenuto `e rappresentato da una stringa. Per
questo abbiamo scelto di dare all’utente la possibilit`a di definire nel modello
dell’applicazione esclusivamente un titolo per ciascuna cella: modificando po-
che righe di codice pu`o sempre decidere di personalizzarla successivamente.
In base a quanto detto l’unico attributo necessario per l’elemento ListView-
Cell o GridViewCell `e pertanto title, che permette di definire il titolo da
inserire nella specifica cella. Non si tratta di un attributo il cui valore deve
essere inserito obbligatoriamente dallo sviluppatore, il quale pu`o decidere di
settare il titolo in un secondo momento via codice. WebView
Una WebView `e una View usata per mostrare una pagina Web, il cui conte-
nuto e il layout sono definiti attraverso file HTML e CSS, che appartengono
alle risorse dell’applicazione. L’elemento WebView `e particolarmente indica-
to nello sviluppo di applicazioni mobili per chi intendesse definire in maniera semplice i contenuti e lo stile di una View, sfruttando gli strumenti della programmazione web.
Gli attributi di WebView sono:
• Id: `e l’identificativo della WebView.
• HTMLFileName: `e l’attributo che rappresenta il nome del file HTML che si intende utilizzare per definire il contenuto della WebView. Que-
sto campo pu`o essere lasciato vuoto ed in tal caso il sistema genera il
codice per il corretto settaggio della WebView, senza specificare alcun
riferimento al file HTML, che dovr`a essere inserito manualmente dal
programmatore. Nel caso in cui si intendesse definire il layout della
pagina attraverso un file CSS, `e necessario definire il riferimento al file
nell’header del file HTML.
L’unica relazione di WebView `e:
• ViewController: `e la relazione inversa di webViews su ViewController. AlertDialog
L’elemento AlertDialog consente di visualizzare un messaggio con titolo e contenuto in sovrimpressione sullo schermo del dispositivo. Quindi, si rende necessario avere all’interno dell’elemento due attributi per inserire titolo e contenuto del messaggio. In quanto la comparsa di un messaggio di questo
Metamodello implementativo
tipo blocca l’interfaccia grafica, vengono automaticamente mostrati anche due bottoni di conferma e annullamento.
Gli attributi di AlertDialog sono:
• Id: `e l’identificativo dell’AlertDialog. • Title: `e il titolo dell’AlertDialog. Le relazioni di AlertDialog sono:
• Message: rappresenta il contenuto del messaggio.
• ViewController: `e la relazione inversa di alertDialogs su ViewControl- ler.
ProgressDialog
L’elemento ProgressDialog `e, come l’AlertDialog, un messaggio che pu`o avere
un titolo e un contenuto, ma con due differenze sostanziali: non ha bottoni di conferma o annullamento e presenta uno spinner oppure una barra oriz- zontale, che indica lo stato di avanzamento dell’operazione in corso.
Gli attributi di ProgressDialog sono:
• Id: `e l’identificativo del ProgressDialog. • Title: `e il titolo del ProgressDialog.
• Message: rappresenta il contenuto del messaggio.
• Spinner: `e un attributo booleano utilizzato per scegliere se l’avanza- re dell’operazione deve essere mostrato attraverso uno spinner oppure attraverso una semplice barra orizzontale.
L’unica relazione di ProgressDialog `e:
• ViewController: `e la relazione inversa di progressDialogs su ViewCon- troller.
4.1.2 Hardware
Di seguito riportiamo una descrizione dei principali elementi di una generica applicazione che gestiscono l’interfacciamento con l’hardware del dispositivo.
Ricordiamo che lo scopo del metamodello implementativo `e quello di consen-
tire la definizione di un modello dell’applicazione sufficientemente espressivo da permettere la generazione dei sorgenti nativi corrispondenti. Per i Con-
troller dei componenti hardware questa fase si concretizzer`a nella produzione
dei pezzi di codice che implementano la logica applicativa di interfacciamento con il componente modellato.
Ogni ViewController pu`o presentare al suo interno diversi metodi per l’in-
terazione con l’hardware, tuttavia di tutti i metodi implementabili abbiamo
deciso di modellarne solo alcuni, quelli utilizzati pi`u di frequente nelle ap-
plicazioni. Tali elementi sono stati modellati come figli del concetto HWRe- sourceController, presentato nel metamodello astratto, e sono presentati di
seguito. E’ bene tenere presente che quando `e necessario interfacciarsi con un
qualsiasi componente hardware dall’interno di un ViewController i concetti del metamodello astratto coinvolti sono sempre due: quello di HWResource e quello di HWResourceController.
LocationManager
L’elemento LocationManager `e un HWResourceController che sfrutta il sen-
sore GPS del dispositivo per determinare la posizione geografica dell’utente. Questo elemento non necessita di particolari attributi nel metamodello im-
plementativo, perch´e quando l’utente decide di fare in modo che un certo
ViewController possa recuperare la posizione dell’utente non deve settare alcun parametro, quanto piuttosto decidere come implementare la logica del-
l’utilizzo della posizione ottenuta, che purtroppo non pu`o essere modellata.
Perci`o, quando il programmatore definisce nel modello un oggetto di tipo
LocationManager, nel codice generato automaticamente verranno inseriti i metodi di interfacciamento con il sensore GPS, la cui implementazione deve essere ultimata dallo sviluppatore.
L’unica relazione che presenta l’elemento `e viewController, ossia la relazione
inversa di locationManager su ViewController. AudioPlayer
AudioPlayer `e un HWResourceController che sfrutta la risorsa hardware
Speaker per la riproduzione di file musicali provenienti da file locali, da remoto o per la riproduzione di registrazioni effettuate col microfono del dispositivo. Quando lo sviluppatore decide di inserire nel modello questo ele- mento, al momento della generazione dei sorgenti vengono automaticamente inseriti i pezzi di codice che definiscono la logica applicativa di gestione della
riproduzione musicale (play, pause, stop). Le funzionalit`a offerte dall’Audio-
Player riguardano in particolare il recupero di uno specifico file audio e la sua riproduzione, oltre alla messa in pausa e all’arresto della riproduzione stessa.
Gli attributi di AudioPlayer sono:
Metamodello implementativo
• FileUri: `e l’attributo che permette al programmatore di inserire il nome del file locale da utilizzare come sorgente, oppure l’url da cui scaricare il file musicale nel caso fosse remoto. Laddove il file audio da riprodurre corrisponda a una registrazione col microfono del dispositivo l’attributo fileUri deve essere ignorato.
Le relazioni di AudioPlayer sono:
• SourceType: `e la relazione con l’attributo enumerativo sourceType, che permette di stabilire la provenienza del file musicale che si intende riprodurre.
• ViewController: `e la relazione inversa di audioPlayer su ViewControl- ler.
PhotocameraController, VideocameraController e AudioRecorder PhotocameraController, VideocameraController e AudioRecorder vengono utilizzati rispettivamente per scattare una foto con la fotocamera, registrare un video con la videocamera ed effettuare una registrazione audio attraverso il microfono del dispositivo.
PhotocameraController e VideocameraController, una volta implementati, si presentano graficamente con un bottone all’interno della Window del View- Controller in cui vengono inseriti. Tale bottone, una volta cliccato, permette all’utilizzatore di aprire sul dispositivo l’applicazione predefinita per la cat- tura di foto o di video. I file generati vengono automaticamente salvati in
memoria e ritornati all’applicazione chiamante, dove lo sviluppatore dovr`a
ultimare l’implementazione definendo via codice la logica di gestione dei fi-
le ricevuti. L’unico attributo di PhotocameraController `e imageViewId, che
permette di associare al PhotocameraController una ImageView con HWRe-
source come sourceType. Tale attributo dovr`a essere settato dal programma-
tore nel caso in cui decidesse di visualizzare direttamente nella Window del ViewController l’ultima foto scattata. Considerazioni analoghe valgono per VideocameraController, che presenta l’attributo videoViewId, da utilizzare per indicare l’id della VideoView dove riprodurre l’ultimo video registrato. AudioRecorder si presenta anch’esso con un bottone con titolo “Rec” nella Window del ViewController in cui viene inserito. Una volta cliccato il bot- tone non viene mostrata nessuna schermata particolare, al contrario l’utente
continuer`a a visualizzare la stessa View con il titolo del bottone mutato in
“Stop”, ad indicare che la registrazione dal microfono `e in corso e pu`o essere
interrotta cliccando nuovamente sul bottone. E’ possibile riprodurre diretta- mente l’ultimo file audio registrato attraverso un elemento AudioPlayer con
HWResource come SourceType: come per PhotocameraController e Video- cameraController, l’elemento AudioRecorder presenta un apposito attributo,
chiamato audioPlayerId, che lo sviluppatore pu`o utilizzare per indicare l’id
dell’AudioPlayer dove intende riprodurre l’ultimo file audio registrato. Gli elementi PhotocameraController, VideocameraController e AudioRecor- der presentano un attributo e una relazione:
• ImageViewId, VideoViewId o AudioPlayerId: `e l’attributo che permet- te di indicare l’id dell’oggetto oggetto dove mostrare o riprodurre il file generato utilizzando l’hardware del dispositivo. Nel caso in cui lo sviluppatore preferisca o necessiti di definire via codice la logica applica- tiva di gestione del file ricevuto deve ignorare il settaggio dell’attributo al momento della modellazione dell’applicazione.
• ViewController: `e la relazione inversa di photocameraController, vi- deocameraController o audioRecorder su ViewController.