Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamento al sistema di controllo TANGO, tramite l'ausilio del framework Apache Cordova

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria dell’Informazione
Sviluppo di un’applicazione ibrida su
dispositivo mobile per l’interfacciamento al
sistema di controllo TANGO
Tesi di Laurea Triennale
Laureando:
Mattia DE BERNARDI
Relatore:
prof. Enzo MUMOLO
Correlatore:
dott. Lucio ZAMBON
_____________________________________
ANNO ACCADEMICO 2015-2016

2. 2
Indice
1. Introduzione
1.1. Sistema di controllo TANGO
1.2. La differenza tra Web app, Hybrid app e Native app
2. Il framework Cordova
2.1. Funzionalità di Apache Cordova
2.2. Struttura fondamentale di un progetto
2.3. Plugin – accedere alle funzionalità del dispositivo
3. Sistema realizzato
3.1. Bootstrap
3.2. jQuery
3.3. Single Page Application
3.4. Interazione tra utente e sistema
3.5. Interazione tra sistema e server
3.6. Elaborazione dell’informazione ricevuta dal server
4. Risultati sperimentali
4.1. Output del framework
4.2. Prove effettuate sul sistema
5. Manuale d’uso del framework
5.1. Requisiti
5.2. Cordova Comand-Line Interface
6. Conclusione

3. 3
1. Introduzione
La seguente tesi è stata svolta presso Elettra-Sincrotrone Trieste S.C.p.A. che si trova
al km 163,5 della S.S. 14 in AREA Science Park Basovizza, Trieste.
Lo scopo di questo lavoro è stato quello di rendere fruibili su dispositivo mobile delle
funzionalità interessanti per il personale dell’azienda, quali:
 Monitoraggio in tempo reale dello stato della macchina FERMI inclusi grafici
caratteristici di Intensità e sua RMS (Root Mean Square) percentuale
 Implementazione di alcune funzionalità proprie dell’applicativo desktop Astor,
come la sua forma ad albero
 Implementazione di una modalità inedita che visualizzasse a partire dalle
informazioni contenute nell’albero di Astor i soli device server in stato di allarme
 Possibilità di avviare o fermare un device server dalla lista o dall’albero, previa
autenticazione dell’utente
 Possibilità di visualizzare la lista degli attributi di ogni device server e di
impostare una soglia di allarme oltre la quale ricevere notifiche (suono e/o
vibrazione) sul proprio dispositivo mobile
 Visualizzazione dei turni operatori, turni fisici della macchina FERMI, resoconti
di fine turno della macchina FERMI (End Of Shift), monitoraggio in tempo reale
dello stato della macchina ELETTRA.
Le richieste facenti parte dell’ultimo punto non sono state sviluppate a dovere poiché
implementate verso la fine del progetto. Tuttavia, una loro parte o la loro totalità,
costituirà probabilmente la base da cui partire per sviluppi futuri. La loro aggiunta ha in
primis lo scopo di dimostrare come il sistema possa essere ampliato con ulteriori
funzionalità. Viceversa, le altre sono state soddisfatte ed in gran parte ottimizzate per i
dispositivi mobili. Tutto ciò è stato perseguito tramite l’ausilio di un framework per lo
sviluppo di applicazioni ibride denominato Apache Cordova.

4. 4
Nelle fasi iniziali di contatto con l’azienda si sono delineate due proposte di tesi presso
Elettra-Sincrotrone: lo sviluppo di un’applicazione ibrida contro quello di
un’applicazione nativa. Prima di argomentare le motivazioni nella scelta della prima
opzione, si presenta brevemente TANGO e la sua parte qui implementata: Astor.
1.1 Sistema di Controllo TANGO
Il Sistema di Controllo TANGO è un software libero ed open source, costituito da un
insieme di strumenti che possono essere utilizzati per controllare hardware, software o
per costruire sistemi di controllo supervisionato e acquisizione dati (SCADA). Esso viene
mantenuto e sviluppato da un consorzio composto alcuni dei principali acceleratori di
particelle dell’Europa Continentale, di cui fanno parte una sorgente di neutroni ed otto
sorgenti di luce di sincrotrone, tra cui Elettra-Sincrotrone Trieste.
Tra gli utilizzatori si possono annoverare non solamente i membri del consorzio, ma
anche altri progetti come ad esempio SKA (Square Kilometre Array), un vasto insieme di
radiotelescopi in costruzione in Australia e Sud Africa, la cui dimensione consentirebbe
una sensitività molto maggiore alla massima attuale.
Grazie ad una struttura gerarchica ad albero, il sistema è in grado di connettere tra di
loro complessi sottosistemi. All’interno di questi, ogni dispositivo fisico o virtuale è
rappresentato da un device server: esso è un processo utilizzato per regolare l’accesso
all’hardware o per fornire un servizio. Ogni device server possiede, a patto che controlli
un dispositivo fisico, comandi utilizzati per eseguire azioni fisiche su di esso e attributi
usati per visualizzarne lo stato fisico.
Astor è il supervisore del sistema di controllo TANGO. Esso implementa diverse
funzionalità quali: fornire a colpo d’occhio informazioni tali da capire se vi siano
problemi o meno nel sistema di controllo e in caso contrario; mettere a disposizione
strumenti utili alla diagnostica e alla soluzione dei problemi; configurare il sistema di
controllo e le sue componenti…

5. 5
Il principio di funzionamento di Astor è incentrato attorno al concetto di Starter, un
device server che ha il compito di controllare tutti gli altri device server in esecuzione sul
calcolatore. La lista dei server controllati viene letta dal database TANGO e visualizzata
attraverso un’interfaccia grafica. Essa è connessa con tutti gli starter server e consente: la
visualizzazione dello stato del sistema di controllo e delle sue componenti attraverso dei
led colorati; eseguire diagnosi ed azioni su questi componenti, come avvio, arresto, test,
configurazione, visualizzazione informazioni…
1.2 La differenza tra Web app, Hybrid app e Native app
Le applicazioni native vengono installate tramite store quali Google Play Store o
Apple App Store, ed eseguite sul dispositivo tramite il tap sull’icona corrispondente.
Vengono sviluppate specificamente per una piattaforma e per questo possono accedere a
tutte le funzionalità del dispositivo come fotocamera, GPS, accelerometro, giroscopio,
contatti ed altre. Possono inoltre funzionare anche offline, usare il sistema di notifiche di
sistema e usufruire delle gesture, combinazioni di input tattili definite dal sistema
operativo o dall’utente stesso.
Le applicazioni web non sono realmente delle applicazioni, sono piuttosto dei siti web
che danno la sensazione di esserlo ma non sono implementate allo stesso modo di una
nativa. Vengono “eseguite” all’interno di un browser e il loro primo accesso avviene
attraverso la navigazione su di una pagina web vera e propria. Su di essa l’utente può
trovare un’opzione per “installare” l’applicazione, che altro non fa che aggiungere un
segnalibro di quella pagina alla propria schermata iniziale. In molti casi è difficile
distinguere tra web e nativo: ad esempio in gran parte delle web app, non vengono
visualizzati bottoni o barra del browser e grazie alla cache, è possibile visualizzare il loro
contenuto o parte di esso anche offline. Rimangono comunque inaccessibili alcune
funzionalità proprie del dispositivo, che non possono essere utilizzate dal browser.
Qualcuno potrebbe dire che non tutte le applicazioni native usufruiscono di queste
funzionalità, ma se fosse veramente necessario usarle, si avrebbe la necessità di
svilupparne una di questo tipo oppure una ibrida.

6. 6
Le applicazioni ibride sono in parte native e in parte web, e per questo motivo da molti
vengono erroneamente chiamate web app. Esse sono popolari poiché possono fungere da
semplice involucro per una web app, ma anche perché lo stesso codice HTML, JavaScript
e CSS può essere utilizzato per lo sviluppo su più piattaforme diverse, abbattendo i costi
di sviluppo. Come le applicazioni native, sono distribuite attraverso gli store delle
rispettive piattaforme e possono usufruire di quelle funzionalità del dispositivo a cui le
web app non hanno accesso. In maniera simile a queste ultime, le app ibride sono basate
su codice visualizzato attraverso un browser integrato nell’applicazione, ma a loro
differenza esso non è esterno.
La scelta è ricaduta sullo sviluppo di un’applicazione ibrida per i seguenti motivi:
 L’assenza di necessità prestazionali elevate che giustificassero lo sviluppo di
un’applicazione nativa;
 La capacità delle applicazioni ibride di usufruire delle funzionalità del device
attraverso l’implementazione di plugin;
 La possibilità del riutilizzo di gran parte dello stesso codice per diverse
piattaforme mobili (e anche per web), anziché la limitazione, per esempio, al solo
Android;
 La presenza in rete di numerosissime librerie e framework UI che aiutano la
creazione di interfacce utenti adatte a dispositivi mobili e, cosa ancor più
importante, responsive rispetto alle dimensioni dei loro schermi;
 La possibilità di poter aggiornare il contenuto dell’applicazione senza eccessivi
sforzi: un’applicazione nativa può avere differenti versioni a seconda delle
piattaforme e della versione del sistema operativo. Le modifiche che vi si
apportano devono essere opportunamente impacchettate e caricate sui relativi
store (e a volte anche approvate dallo store stesso prima di essere pubblicate). Per
un’applicazione ibrida aggiornarsi significa modificare il proprio codice HTML,
JavaScript o CSS. Se parte di questo codice viene ottenuto da un server remoto,
la sua modifica non comporta la necessità di dover aggiornare la versione
dell’applicazione presente sullo store.

7. 7
2. Il framework Cordova
Apache Cordova è un framework open source che permette ai propri utilizzatori di
convertire codice HTML (HyperText Markup Language), JavaScript e CSS (Cascading
Style Sheets) in un’applicazione nativa che può essere eseguita su iOS, Android e altre
piattaforme mobili come ad esempio Windows 10 Mobile. Per fare ciò, Cordova usa un
browser integrato nell’applicazione stessa, la quale viene denominata applicazione ibrida.
Diversamente da un semplice sito web ottimizzato per dispositivi mobili, Cordova
garantisce accesso a funzionalità proprie del dispositivo mobile, come ad esempio
fotocamera, accelerometro, giroscopio od informazioni sulla connettività. Oltre a questo
il framework permette all’applicazione di essere distribuita e venduta sugli store delle
rispettive piattaforme mobili, esattamente come un’applicazione nativa.
2.1 Funzionalità di Apache Cordova
Il principale strumento utilizzato per rapportarsi con Cordova è l’interfaccia a riga di
comando.
Attraverso di essa è possibile creare nuovi progetti, compilare codice per una specifica
piattaforma mobile, aggiungere e rimuovere dall’applicazione l’accesso a varie
funzionalità del dispositivo mobile ed infine, installare ed eseguire il codice compilato su
un dispositivo virtuale o fisico.
Attraverso i plugin Cordova estende quello che lo sviluppatore può fare in JavaScript
dando l’accesso ad aggiuntive API (Application Programming Interface). Oltre a
funzionalità proprie dei dispositivi mobili già esistenti, questo framework permette di
supportare funzionalità future, a patto di scrivere il codice nativo ad hoc ed accoppiarlo
con una libreria JavaScript corrispondente, in modo da renderlo disponibile all’utilizzo
proprio e di altri sviluppatori.
Un ulteriore, e generalmente non riportato, vantaggio di Cordova è quello di poter
usare le migliaia di librerie HTML, JavaScript e CSS preesistenti sul web. D’altra parte,
ciò che il framework non fornisce sono degli strumenti atti ad ottimizzare l’interfaccia
utente delle applicazioni specificamente per dispositivi mobili.

8. 8
Cordova semplicemente visualizza il codice HTML, JavaScript e CSS così com’è senza
adattare, per esempio, le dimensioni di testi, bottoni, tabelle od immagini allo schermo
del dispositivo mobile. Fortunatamente, esistono sul web diverse soluzioni al problema,
consistenti in framework UI che possono facilmente essere incluse ed utilizzate nel
proprio codice, per rendere l’applicazione “mobile-friendly”.
2.2 Struttura fondamentale di un progetto
Un progetto di Apache Cordova è composto da diversi file e cartelle:
 config.xml viene usato per configurare opzioni relative a come il progetto è
costruito.
Ad esempio il nome e la descrizione dell’app, il suo id, informazioni sull’autore,
icone personalizzate per piattaforma e densità di pixel dello schermo del
dispositivo mobile, URL ai quali è possibile accedere attraverso il codice HTML
e JavaScript ed altre;
 hooks è una cartella inizialmente vuota, che può essere riempita con sottocartelle
corrispondenti ai “ganci”, ovvero codice in linguaggio JavaScript che utilizza
Node.js , di cui si parlerà in seguito, per modificare il comportamento della CLI
di Cordova (e.g. dopo aver aggiunto una piattaforma, in maniera automatica
aggiungere una lista di plugins);
 platforms è una cartella contenente il codice nativo dell’applicazione per ogni
piattaforma, una volta che Cordova l’ha costruito a partire dal codice HTML,
JavaScript e CSS;
 www è la cartella che durante lo sviluppo subisce il maggior numero di modifiche,
poiché essa contiene i file HTML e una serie di sottocartelle contenenti file
JavaScript e CSS che andranno a caratterizzare l’applicazione ibrida.

9. 9
2.3 Plugin - accedere alle funzionalità del dispositivo
In Apache Cordova, accedere a funzionalità proprie del dispositivo mobile è reso
possibile grazie ai cosiddetti “plugins”, il cui compito è garantire una comunicazione tra
il codice JavaScript e il dispositivo. Essi vengono scritti in ogni codice nativo (Java,
Objective-C…) a seconda della piattaforma per la quale si vuole aggiungere il supporto
alla funzionalità. Una volta fatto questo, una sola API JavaScript consente
l’interfacciamento per tutte le piattaforme, indipendentemente da quali esse siano, tranne
rare occasioni.
Anche se ognuno può scrivere i plugin che gli interessano di proprio pugno,
recentemente, per la loro ricerca e l’accesso alla loro documentazione, essi sono stati
raccolti online nel sito web “https://www.npmjs.com/”.
In questo modo, per il progetto sviluppato, sono stati individuati plugin utili a
supportare alcune funzionalità come le informazioni sulla connettività (cordova-plugin-
network-information), le finestre di dialogo e i suoni di notifica (cordova-plugin-dialogs),
la vibrazione (cordova-plugin-vibration) ed il controllo della cache memorizzata sul
dispositivo (cordova-plugin-cache).
Da notare che al momento dell’aggiunta di una nuova funzionalità, Cordova ricerca
quali piattaforme sono state aggiunte al progetto e per ognuna di esse inserisce il codice
nativo del plugin nella corrispondente cartella contenuta in platforms. Se si aggiunge una
piattaforma dopo aver installato diversi plugins, per ognuno di questi ultimi, Cordova si
preoccupa di inserire il loro codice nativo nella cartella della piattaforma appena aggiunta.
Per poter utilizzare effettivamente un plugin, è necessario aspettare che Cordova
instauri una linea di comunicazione tra il proprio codice JavaScript e il dispositivo.
Questo processo avviene in maniera automatica ed è seguito dall’attivazione di un evento
denominato deviceready. Tutto quello che uno sviluppatore deve fare è aggiungere al suo
codice JavaScript un “event listener” che attenda l’attivazione di questo evento, dopo la
quale eseguirà una funzione passatagli come argomento. Il cuore dell’applicazione ibrida
è costituito da questa funzione, in cui si possono definire tutte le operazioni che si
vogliono eseguire per rendere dinamico il codice HTML ed utilizzare i plugin secondo la
loro documentazione.

10. 10
I componenti aggiuntivi sono stati scelti per le seguenti motivazioni:
1. cordova-plugin-dialogs garantisce l’accesso a 4 funzioni JavaScript attraverso un
oggetto globale denominato navigator.notification. Una di queste (beep) genera
una o più notifiche sonore da parte dell’applicazione in base a un parametro. Le
altre visualizzano messaggi di allarme (alert), di conferma (confirm) e di richiesta
di input (prompt). Tutte queste ultime utilizzano un’interfaccia utente dipendente
dal sistema operativo e dalla sua versione in uso sul dispositivo mobile;
2. cordova-plugin-vibration fornisce una funzione per controllare la vibrazione del
dispositivo. Ad essa è possibile passare due tipologie diverse di parametri: un
numero in millisecondi indicante la durata della vibrazione, oppure un array di
numeri della stessa tipologia del precedente, al fine di definire una sequenza di
vibrazioni e pause.
3. cordova-plugin-cache viene utilizzato all’interno dell’applicazione per eliminare
la cache del browser integrato, in modo che esso non riempia diversi iframe
facenti parte dell’app con informazioni obsolete derivanti da interazioni
precedenti col server. Tutto ciò è reso possibile attraverso due funzioni chiamate
all’avvio dell’applicazione.
4. cordova-plugin-network-information consente grazie ad una proprietà chiamata
type dell’oggetto navigator.connection, di accedere alle informazioni circa la
connessione wireless e mobile del dispositivo. Il plugin fornisce anche l’accesso
a due nuovi eventi, offline ed online, che vengono attivati al passaggio da uno
stato all’altro della connessione. Attraverso la definizione di un gestore di evento
per ognuno di essi è possibile eseguire operazioni sulla propria applicazione in
caso non fosse rilevata alcuna connessione di rete, oppure essa tornasse attiva
dopo essere stata assente. Nel sistema sviluppato, nel caso in cui si perda la
connessione, si è fatto in modo che il contenuto della pagina visualizzata scompaia
e al suo posto venga mostrata una scritta rossa di allarme. Nel momento in cui la
connessione torna attiva, viene effettuata la procedura contraria. Entrambe le
modifiche sono precedute da un messaggio di allarme creato con il plugin dialogs.

11. 11
3. Sistema realizzato
L’applicazione ibrida sviluppata tramite Cordova è stata fondamentalmente testata su
Android, a causa della facilità nel reperire emulatore e strumenti di debug della relativa
piattaforma. Installando Android SDK infatti, è possibile ottenere Android Virtual
Device Manager tramite cui è stato possibile creare ed utilizzare un emulatore di un
dispositivo mobile con sistema operativo Android, previa installazione da SDK
Manager, sempre incluso in Android SDK, di immagini di sistema fornite da Google.
Un problema riscontrato in fase di sviluppo è stato quello delle prestazioni
dell’emulatore: selezionando, in fase di creazione del dispositivo virtuale, una CPU
basata su ARM, l’accensione e in generale l’esecuzione di qualsivoglia operazione è
risultata lenta rispetto alla controparte fisica. Questo problema è stato risolto con il
download attraverso SDK Manager del pacchetto di installazione di Intel® Hardware
Accelerated Execution Manager (Intel® HAXM). Dopo aver installato questo prodotto,
è stato possibile creare un nuovo dispositivo virtuale la cui CPU è stata basata su Intel®
x86_64 ed abilitare l’emulazione GPU per gestire la parte grafica. Al termine di questo
ulteriore passaggio, le prestazioni dell’emulatore sono state praticamente identiche a
quelle del dispositivo fisico corrispondente, a patto di avere come nel caso affrontato un
calcolatore con sufficiente RAM.
3.1 Bootstrap
Per rendere l’applicazione responsiva e adatta a dispositivi mobili, una soluzione non
molto pratica sarebbe stata quella di scrivere a mano tutto il codice CSS. Esistono tuttavia
sul web diverse librerie che permettono di migliorare l’interfaccia utente della propria
applicazione semplicemente inserendo un foglio di stile all’interno della propria
applicazione. Alcune di queste applicano poi in maniera del tutto automatica lo stile da
esse definito, altre necessitano invece l’aggiunta di attributi di tipo classe ai propri tag
HTML in modo da poter applicare lo stile. Usando una di queste librerie è possibile
realizzare facilmente un’applicazione dall’aspetto professionale in poco tempo,
specialmente se chi commissiona l’applicazione non ha espresso specifiche in materia di
interfaccia utente.

12. 12
Bootsprap è il framework più popolare tra quelli appena descritti. Libero ed open
source, ovvero che può essere usato, modificato, ridistribuito e migliorato a piacimento
come enunciano le quattro libertà fondamentali della Free Software Foundation, esso è
stato utilizzato nello sviluppo del sistema in questione per migliorarne la resa visiva e
rendere responsivi e mobile-first gli elementi HTML che costituiscono l’interfaccia
utente. Tramite il sito www.getbootstrap.com è stato possibile scaricare i file CSS e JS ed
includerli nell’applicazione, in modo da beneficiare dello stile definito nella libreria.
3.2 jQuery
Un altro componente che è stato utilizzato nello sviluppo del sistema è jQuery: una
libreria JavaScript capace di migliorare le funzionalità del proprio codice notevolmente.
Essa è capace di rendere molto più facile navigare e manipolare il DOM (Document
Object Model) di un documento HTML, nonché di gestire eventi, animazioni e chiamate
AJAX (Asynchronous JavaScript and XML) attraverso delle API versatili e compatibili
con quasi ogni browser odierno. Recandosi sul sito www.jquery.com si è potuto scaricare
il file JS di cui consta la libreria e successivamente includerlo nell’applicazione ibrida.
3.3 Single-page application
Solitamente un sito web è composto da più pagine web che vengono esplorate a partire
dalla home page via via addentrandosi all’interno dell’ideale albero del sito.
Generalmente, il layout del sito rimane lo stesso, ma il contenuto cambia di volta in volta.
Tuttavia procedendo in questa maniera il browser è costretto a fare una richiesta al web
server su cui sono presenti i file costituenti il sito, ogni volta che l’utente in questione
vuole visitare una nuova pagina. Vi sono certamente metodi come il meccanismo dei
cookies o quello delle sessioni, che consentono di facilitare il processo, ma non ne
cambiano l’essenza.
Una soluzione migliore, soprattutto per quanto riguarda lo sviluppo di applicazioni
ibride, è quello della SPA, Single-Page Application. La prima parte della navigazione è
sostanzialmente uguale a quella tradizionale, in cui si approda su una pagina iniziale che
racchiude il layout del sito. La successiva navigazione nel sito web avviene, invece,

13. 13
utilizzando il meccanismo delle chiamate AJAX, che rende il tutto più fluido per l’utente.
In questo modo, in seguito alla richiesta viene caricata solamente la minima quantità di
dati necessari, senza modificare il design della pagina e senza doverne ricaricare
interamente un’altra. AJAX è il meccanismo più comune per una pagina web di
aggiornare il proprio contenuto in maniera asincrona: si tratta sostanzialmente di
utilizzare JavaScript per eseguire HTTP request a delle risorse remote.
Un beneficio fondamentale di costruire la propria applicazione come una SPA è la
persistenza dei dati. Infatti al caricamento di una nuova pagina web tutte le variabili
JavaScript e i loro relativi valori vengono persi. Questo è anche il motivo dell’invenzione
delle sessioni lato server: tenere traccia di determinati valori per un utente, anche se
quell’utente naviga tradizionalmente all’interno del sito, caricando nuove pagine
continuamente. Viceversa, poiché grazie ad AJAX viene caricato del contenuto in una
pagina preesistente, i dati possono essere mantenuti anche da lato client non venendo
cancellati ad ogni chiamata. Poiché un’applicazione ibrida generalmente non si appoggia
su alcun server, ma utilizza i file HTML, JS e CSS trovati nella memoria di massa locale
del dispositivo, è fondamentale progettare una SPA in modo da non perdere i dati
dell’utente nel passaggio da una schermata ad un’altra.
Un ulteriore beneficio è legato ai plugin e al loro funzionamento: generalmente, una
volta caricata una pagina, per poter utilizzare le funzionalità del dispositivo è necessario
aspettare che l’evento deviceready venga attivato. Se si caricasse di volta in volta una
pagina nuova, questo significherebbe aspettare che questo evento venga lanciato ogni
volta per poter usare, ad esempio, le notifiche sonore o la vibrazione. Inoltre, un maggior
numero di eventi da aspettare corrisponde a un maggior numero di gestori da definire,
che inevitabilmente può portare a errori dovuti a dimenticanze nel codice. Implementando
invece una SPA, l’unica pagina da caricare diventa quella iniziale, dunque un solo evento
da attendere, meno possibilità di errore e più compattezza nel codice.
A causa della diversità tra la struttura di un’applicazione e quella di un sito web e a
causa delle differenti interazioni tra utente e applicazione e tra utente e sito, la forma di
una SPA meglio si adatta all’ambito mobile, consentendo una maggior organizzazione
nell’applicazione sia dal punto di vista dell’utilizzatore sia dal punto di vista del
progettista e/o sviluppatore.

14. 14
3.4 Interazione tra utente e sistema
All’apertura dell’applicazione ibrida viene visualizzata la pagina iniziale, in cui è
possibile selezionare la modalità alla quale si è interessati semplicemente facendo un tap
sul bottone corrispondente. In fondo al gruppo dei bottoni è presente una checkbox, la cui
spunta viene utilizzata dal codice per discernere tra il caso in cui l’utente voglia impostare
come predefinita la prossima modalità selezionata o meno. L’operazione di scelta iniziale
può risultare infatti tediosa a lungo andare. Inoltre viene notificata una funzionalità
presente in ogni sottopagina: clickando sul logo di Elettra-Sincrotrone Trieste in alto a
sinistra si viene riportati alla home page dell’applicazione e vengono resettate tutte le
preferenze impostate in precedenza.
Le modalità che è possibile selezionare sono:
 ELETTRA Status
Vengono visualizzati i dati relativi alla macchina Elettra: questa pagina non è
stata ottimizzata per dispositivi mobili a causa della concentrazione delle attività
su altri obiettivi. Vi sono quindi grandi margini di miglioramento, fino a
raggiungere risultati simili a quanto fatto con FERMI Status.
 Turni Operatori
Una tabella ottimizzata per la presentazione su dispositivi mobili che si adatta
alle dimensioni dello schermo del relativo dispositivo: suddivisa in 4 colonne
denominate Data, Morning, Late e Night, contiene per ogni giornata gli operatori
sia della macchina ELETTRA che di quella FERMI.
 Turni Fisici
Analogamente a sopra, questa tabella possiede 3 colonne: la prima indica il
giorno della settimana, la seconda la data, la terza è suddivisa il 3 sottorighe a tre
campi. Ogni sottoriga corrisponde a un periodo del giorno quale Morning, Late e
Night, in cui vengono indicati codice e identificativo delle risorse della macchina
FERMI

15. 15
 End of Shift
Anche questa modalità non è stata ottimizzata per dispositivi mobili a causa
del perseguimento di altre funzionalità di maggior complessità e importanza. Essa
dovrebbe fornire una lista consultabile di report di fine turno operatori: possibilità
di miglioramento sono presenti e saranno sicuramente prese in considerazione in
futuro.
 FERMI Status
La pagina dell’applicazione visualizza i dati relativi alla macchina FERMI: nella
parte superiore sono presenti due grafici responsivi rappresentanti due parametri
fondamentali per chi utilizza FERMI: Intensità e sua RMS (Root Mean Square)
percentuale di I0-Monitor. Su ognuno di essi l’utente può fare tap in modo da
aprire nel proprio browser predefinito una pagina contenente ulteriori strumenti
per l’analisi di questi ultimi. Scorrendo l’applicazione verso il basso si possono
trovare 4 pannelli a scomparsa contenenti informazioni che si aggiornano grazie
a richieste AJAX al server fcsproxy.elettra.eu. Questi pannelli sono chiusi di
default ma è possibile aprirli con un semplice tap; inoltre su dispositivi con uno
schermo largo più di 768 pixel i 4 pannelli vengono affiancati ed aperti
automaticamente.
 Astor
Questa modalità consiste in realtà di 3 sottopagine idealmente sullo stesso
piano che è possibile alternare in maniera ciclica attraverso un’icona nell’angolo
in alto a destra di ogni relativa pagina: la prima contiene una struttura ad albero
simile a quella della rispettiva applicazione desktop Astor, la seconda è una lista
dei device server che al momento sono in stato di allarme, la terza una lista degli
allarmi impostati dall’utente sugli attributi di uno specifico device server.
Nella modalità standard di “Astor” ogni elemento della struttura ad albero è
costituito da un led di vario colore e da un nome, ed ogni ramo è inizialmente
nascosto e visualizzabile attraverso tap sul padre del ramo stesso. Il primo livello
dell’albero contiene tutti i nodi il cui nome è un gruppo di starter e i cui figli sono
gli starter appartenenti a quel gruppo.

16. 16
Il led affianco al nome cambia colore a seconda dello stato dello starter
corrispondente, e tale cambiamento si propaga anche al livello superiore:
o Verde, se tutti i server controllati sono in esecuzione;
o Blu, se lo starter sta avviando almeno uno dei server;
o Arancione, se almeno uno dei server controllati non è in esecuzione;
o Rosso, se lo starter non è in esecuzione sul dispositivo.
L’utente può navigare l’albero liberamente e facendo tap sul nome di uno
starter aprire un menu a comparsa contenente diverse opzioni.
In futuro sarà possibile aggiungere ulteriori funzionalità presenti nella versione
desktop di Astor, ma allo stato attuale dell’applicazione solo l’opzione “Open
control panel” è supportata. Clickando su di essa si accede a un’ulteriore pagina
specifica per ogni starter, in cui viene visualizzata un’altra struttura ad albero,
idealmente connessa a quella precedente. Per tornare alla pagina precedente è
presente un pulsante a forma di freccia nell’angolo in alto a sinistra, che sostituisce
il logo di Elettra-Sincrotrone utilizzato nelle altre pagine per tornare alla home
page.
Gli elementi di questo nuovo albero sono analoghi nella forma a quelli descritti
nel paragrafo soprastante, tuttavia i nodi rappresentano i device server controllati
dallo starter selezionato in precedenza e sono raggruppati anch’essi in 5 gruppi
denominati “livelli” più un gruppo per i server non controllati. Anche qui il nome
è affiancato da un led, il cui colore assume significati diversi da quelli descritti
sopra:
o Verde, se il server è in esecuzione;
o Blu, se il server è in esecuzione ma non risponde (molto probabilmente in
avvio);
o Rosso, se il server non è in esecuzione;

17. 17
Anche in questo caso, facendo tap su uno dei server controllati, per ognuno di
essi appare un menu consistente in due opzioni: “Start/Stop server” e “Show
attribute list”.
La prima opzione ha una dicitura dinamica e consente, previa autenticazione,
di avviare o fermare un server a seconda del suo stato. Una volta selezionata, viene
mostrato un prompt di richiesta username che, dopo essere stato completato,
memorizza il nome utente per usi futuri e manda il dato inserito a una pagina
specifica per l’autenticazione. Quest’ultima avviene attraverso l’uso del
protocollo LDAP (Lightweight Directory Access Protocol) da parte della pagina.
Essa viene mostrata nell’applicazione attraverso un iframe a comparsa in cui si
può inserire la password e procedere all’esecuzione del comando ed inoltre,
richiede l’utilizzo del protocollo HTTPS in modo da garantire i principi di
sicurezza informatica di segretezza, integrità ed autenticazione. L’utilizzo di
questo espediente è necessario per fare in modo che le password non vengano
inserite direttamente nell’applicazione e che quindi esse non possano essere
memorizzate da codice JavaScript malevolo. In seguito all’autenticazione
dell’utente, l’iframe invia un messaggio alla pagina web che lo contiene, la quale
lo intercetta grazie a un gestore dell’evento “message” definito durante
l’inizializzazione dell’applicazione: esso definisce il comportamento alla
ricezione della conferma di avvenuta autenticazione ed esecuzione del comando.
In caso di fallimento della procedura di login viene visualizzato invece un
messaggio d’errore ed un invito a riprovare.
La seconda opzione sostituisce il menù con una lista di attributi del device
server controllato: facendo tap su uno di questi è possibile creare una soglia di
allarme, attraverso l’inserimento tramite prompt dell’operatore di confronto
(minore < o maggiore >) e di un valore numerico decimale o intero.

18. 18
La sottopagina “Astor alarm mode” costituisce una funzionalità innovativa di
Astor, non implementata nella sua controparte desktop. Come il nome suggerisce
in essa viene visualizzata una lista dei soli device server il cui led è di colore rosso,
ovvero che non sono in esecuzione. Analogamente a quanto visto sopra,
selezionando uno di essi compare un menù con le due opzioni “Start server” e
“Show attribute list”, le quali consentono di svolgere le azioni appena descritte.
L’ultima modalità ha il titolo “Active alarms” ed è una raccolta di tutti gli
allarmi fino a quel momento definiti dall’utente. Al momento gli unici allarmi
supportati sono quelli di tipo soglia, anche se in futuro potrebbero esserne
implementati di altri tipi, come per esempio il passaggio di stato di uno specifico
device server. Nell’unico caso fino ad ora disponibile viene visualizzato il nome
dell’attributo su cui è attivo l’allarme, l’operatore di confronto e il valore di soglia.
Selezionando un elemento nella lista compare un menù con tre opzioni: “Delete
threshold”, “Modify threshold” e “Modify Notifications”.
La prima voce di questa lista consente semplicemente di eliminare la soglia di
allarme, bloccando la chiamata ricorsiva al metodo che ha il compito di
monitorare il valore dell’attributo.
La seconda chiede nuovamente in input tramite prompt l’operatore e il valore
per cui si vuole impostare la soglia.
La terza opzione invece consente di personalizzare, allarme per allarme, il
numero di notifiche sonore e la durata della vibrazione del dispositivo mobile in
conseguenza al singolo superamento della soglia impostata.

19. 19
3.5 Interazione tra sistema e server
A seconda della modalità selezionata nella schermata iniziale dell’applicazione vi è
una diversa comunicazione tra di essa e il server del caso in questione. Dove richiesto
inoltre, a risposta ricevuta viene avviato un timer al termine del quale la chiamata al server
viene ripetuta, in maniera tale da visualizzare sempre dei dati aggiornati. In caso di
cambio da una pagina all’altra le chiamate pendenti vengono concluse senza portare alcun
riscontro visivo ed i loro timer vengono eliminati per non caricare eccessivamente e senza
alcuna utilità sia i server corrispondenti sia il dispositivo mobile stesso.
 ELETTRA Status, Turni operatori, Turni Fisici, End of Shift
Allo stato attuale tutte queste pagine constano, al di là dello header contenente
titolo e logo di Elettra-Sincrotrone Trieste, di un iframe che riempie tutta la
larghezza dello schermo e la sua rimanente altezza. L’unica interazione che
avviene è dunque la richiesta al server della pagina contenuta in esso. A seconda
della pagina il documento richiesto è differente, ma il server fa sempre parte della
rete interna ad Elettra-Sincrotrone Trieste:
Modalità URL
ELETTRA
Status
http://elog.elettra.eu/informationsystem/web.asp
Turni Operatori http://fcsproxy.elettra.eu/docs/fermi/app/turni_operatori.php
Turni Fisici http://fcsproxy.elettra.eu/docs/fermi/app/turni_fisici.php
End of Shift http://felog.elettra.eu/forum.asp?FORUM_ID=66

20. 20
 FERMI Status
In seguito alla selezione di questa modalità, le prime due richieste che vengono
fatte al server padresproxy.elettra.eu sono dovute ai due iframe contenenti i grafici
di Intensità e RMS, i quali inoltre vengono aggiornati con un’ulteriore interazione
ogni 60 secondi. Immediatamente dopo queste due, l’applicazione esegue nove
richieste HTTP asincrone al server fcsproxy.elettra.eu utilizzando la funzione
AJAX jQuery.get(url), per ottenere i parametri principali riguardanti lo stato della
macchina FERMI.
Una volta ottenuti questi dati, averli opportunamente elaborati e visualizzati
all’interno dei 4 pannelli, l’applicazione interroga sempre lo stesso server circa i
dati di funzionamento corrispondenti al laser in funzione, in base al valore di una
delle variabili ricavate in precedenza, la quale indica se e quale FEL(Free Electron
Laser) sia attivo. A seconda che sia attivo l’uno o l’altro FEL varia il numero di
chiamate che vengono effettuate ogni 2 secondi per aggiornare queste variabili:
Laser ad Elettroni Liberi attivo Numero di chiamate
FEL-1 12
FEL-2 17
 Astor
All’apertura della sottopagina in cui è presente la struttura ad albero, viene
effettuata un’unica chiamata AJAX al server fcsproxy.elettra.eu che verrà ripetuta
ogni 120 secondi, poiché i dati che vengono ottenuti dal server non variano con
una velocità tale da essere necessario un aggiornamento più frequente. La risposta
contiene una lista in formato CSV (Comma Separated Value) degli starter della
macchina FERMI, contenente tutte le informazioni di interesse.

21. 21
Dopo aver aperto un menù e aver selezionato la voce “Open Control Panel”, il
titolo del menù stesso, corrispondente allo starter su cui si era fatto tap, viene
utilizzato come parametro di una chiamata HTTP per ottenere un file di testo in
cui è racchiusa una collezione delle informazioni relative a tutti i device server
controllati. Il caricamento della pagina contenente il secondo albero avviene in
seguito a questa richiesta al server fcsproxy.elettra.eu, la quale viene ripetuta con
una cadenza di 5 secondi per non caricare eccessivamente server e dispositivo
mobile, sebbene possa essere effettuata più di frequente.
Su questa nuova pagina o nella modalità denominata “Astor alarm mode”,
selezionando l’opzione “Start/Stop server” dal menù contestuale l’applicazione
contatta il server www.elettra.eu utilizzando come query-string della richiesta
HTTP lo username appena inserito ed un token costruito ad hoc per informare il
server di quale azione si vuole intraprendere sul device server controllato. La
risposta consiste nella pagina di autenticazione utente visualizzata nell’iframe.
La scelta della seconda opzione “Show attribute list” scatena invece dapprima
una richiesta al server fcsproxy.elettra.eu usando il titolo del menù come
parametro della sua query-string, al cui completamento l’applicazione esegue per
ognuna dei valori presenti nel file CSV ricevuto una richiesta HTTP usandoli per
ottenere l’effettiva lista degli attributi del device server controllato.
Creare una soglia per uno di questi attributi porta all’instaurazione di una
chiamata al server fcsproxy.elettra.eu ogni 3 secondi la cui risposta contiene il
valore dell’attributo usato per il confronto. Il tutto si ripete fino a che l’allarme
non viene eliminato nella relativa pagina.

22. 22
3.6 Elaborazione dell’informazione ricevuta dal server
Le risposte ottenute dai vari server interrogati sono di tipo testuale e si concludono
sempre con un timestamp relativo alla data in cui vengono mandate. Questo valore
numerico di fine messaggio viene sempre eliminato prima dell’elaborazione vera e
propria.
Durante lo sviluppo dell’applicazione è stato quindi necessario definire diversi parser
che estrapolassero l’informazione contenuta nei file di testo al fine di poterla visualizzare
in modo comprensibile all’utente. Inoltre, per alcune delle risposte è stato necessario
utilizzare un codice, dato che esse risultavano di tipo numerico, in modo tale da trasporre
il valore comunicato dal server in linguaggio naturale. Nel caso in cui la risposta fosse un
numero che non dovesse essere manipolato esso è stato arrotondato alla terza cifra
decimale.
La prima forma di elaborazione della risposta è quella incontrata quando si è connessi
ad una qualsiasi rete che non sia quella interna di Elettra-Sincrotrone: in questo caso i
server interrogati restituiscono un codice di errore che viene catturato dal codice, il quale
risponde a questo avvenimento caricando una pagina che avvisa l’utente sulla necessita
del cambio di rete per poter utilizzare l’applicazione.
 ELETTRA Status, Turni operatori, Turni fisici, End Of Shift
Per tutte e 4 queste modalità non è stato necessario effettuare alcuna
elaborazione: la risposta ricevuta è un’intera pagina web che è stata visualizzata
nell’iframe.
 FERMI Status
Per quasi tutte le variabili contenute nei 4 pannelli di questa modalità viene
effettuato parsing o viene applicato un codice. Di seguito si analizza la
trasformazione della risposta per ognuna di esse.

23. 23
All’interno del primo pannello, il primo campo, identificato come Beam To,
viene riempito con una delle due parti del testo ritornato dal server separate dal
segno meno poiché solo una di esser risulta interessante per l’utente. La seconda
variabile Fel active viene estrapolata da un testo in formato CSV composto da 15
campi che possono assumere valore True o False: se il sesto di essi assume valore
True, allora è FEL-1 ad essere attivo; se invece è il settimo ad assumere questo
valore, è FEL-2 ad essere attivo. In caso entrambi siano uguali a False, nessuno
dei due FEL è attivo. Ciò può essere anche dedotto dai grafici in cima alla pagina
i quali appaiono vuoti o dal quarto pannello con cui non si può avere alcuna
interazione.
Il primo, secondo e l’ultimo elemento del secondo pannello denominati
rispettivamente RF Plants, E-beam Energy e Bunch Charge vengono riempiti
direttamente col valore tornato dal server. I due campi rimanenti meritano invece
un approfondimento: le loro nomenclature BC-1/Energy e BC-2/Energy risultano
molto simili e stanno chiaramente ad indicare un collegamento tra le due. Il valore
visualizzato in essi è in realtà una combinazione di due chiamate al server, una
contenente lo stato del BC, l’altra corrispondente all’energia espressa in GeV. Se
lo stato è FAULT, l’intero campo viene riempito con OFF e null’altro; viceversa
se lo stato risulta essere ON la risposta alla seconda richiesta viene inserita e divisa
dalla prima parte con uno slash.
Aprendo il terzo pannello si possono trovare in totale cinque voci, di cui le
ultime quattro sono riempite coi valori presi così come sono dalla risposta HTTP
del server, senza che venga effettuato alcun parsing. Al contrario, il testo ricevuto
relativo alla prima variabile è un valore numerico che attraverso un’opportuna
codifica viene tradotto nella sua controparte testuale e inserito all’interno del
campo. Di seguito si riporta la tabella esplicativa del codice.
Numero 0 1 2 3 4 5 6 7
Significato ---- ATTENUATING OPEN ---- OPEN CLOSED OPEN ----

24. 24
Il contenuto del quarto pannello varia in base al valore della variabile Fel
active descritta sopra, ma in ogni caso si possono distinguere tre sezioni: la prima
contenente le variabili Harmonic, Wavelength e Polarization, la seconda
denominata Fel-x I0 Monitor contenente altri due campi Intensity e RMS, ed infine
la terza sezione relativa allo Spectrometer in cui saranno visibili Wavelength e
Bandwidth di quest’ultimo.
Il cambiamento tra il caso in cui sia attivo FEL-1 ed il caso in cui lo sia FEL-2
è lo sdoppiamento delle variabili nella prima e nella seconda sezione, dal
momento che si devono differenziare uno Stage 1 ed uno Stage 2. In entrambi i
casi le uniche risposte testuali del server che subiscono un’elaborazione sono
quelle relative alla Polarization, poiché anche in questo caso l’informazione viene
trasmessa in valore numerico, il quale attraverso il codice qui sotto riportato viene
tradotto in linguaggio naturale.
Numero 0 1 2 3 4
Significato N.A.
Linear
Vertical
Linear
Horizontal
Right
Circular
Left
Circular
 Astor
Nella pagina principale di questa modalità l’albero viene inizializzato
staticamente coi nodi corrispondenti ai gruppi di starter della macchina FERMI.
La risposta del server contiene un testo in formato CSV in cui ogni valore è
separato dal successivo da un carattere di nuova riga “n” ed ha una struttura di
questo tipo, dove l’ultimo campo è solitamente assente: identificatore_starter,
stato, identificatore_gruppo_appartenenza, nome_starter.
1. identificatore_starter insieme a nome_starter, se presente, viene usato
come contenuto di un tag <span> rappresentante il nome del nodo. Inoltre
identificatore_starter viene assegnato anche come id del tag <li>
costituente l’intero nodo, in modo tale da poter eseguire con maggior
facilità operazioni su di esso in futuro;

25. 25
2. stato, espresso in forma numerica, viene convertito in un colore che viene
utilizzato per modificare l’attributo “src” di un tag <img> e dare un
riscontro visivo della situazione in cui versa lo starter;
3. identificatore_gruppo_appartenenza indica il nodo padre a cui deve essere
appeso lo starter nell’albero.
Di seguito si riportano due tabelle che esplicano il codice usato nella
descrizione degli stati:
Numero 0 1 2 3 4 5 6
Significato ON OFF CLOSE OPEN INSERT EXTRACT MOVING
Colore green red red red red red blue
Numero 7 8 9 10 11 12 13
Significato STANDBY FAULT INIT RUNNING ALARM DISABLE UNKNOWN
Colore red red red red orange red red
In seguito all’inserimento di ogni starter, lo stato del nodo padre viene aggiornato in
modo da essere in linea con l’insieme degli stati dei propri figli. I colori in questo senso
hanno un ordine di importanza che parte dal rosso e passando per arancione e blu arriva
al verde. Così alla presenza anche di un solo starter rosso, il led del gruppo diviene
anch’esso rosso, senza badare se e quanti nodi con stato di differente colore ci siano. In
questo senso domina sul colore del gruppo sempre quello con importanza maggiore.
L’applicazione si comporta in maniera del tutto analoga a quanto appena visto nella
pagina che contiene l’albero coi device server controllati da uno specifico starter e i livelli
in cui sono suddivisi. La risposta in questo caso contiene un testo racchiuso tra parentesi
tonde in formato CSV il cui il carattere separatore è la virgola.

26. 26
Una volta suddivisi, i campi di questo testo si presentano come quattro variabili
intervallate da tabulazioni “t”.
1. La prima rappresenta il nome del device server che analogamente a quanto visto
sopra viene utilizzata sia come contenuto del tag <span> per la visualizzazione
del nodo sia, insieme al nome dello starter seguito da un doppio slash, come id del
tag <li>;
2. Il secondo campo contiene lo stato del device server che contrariamente a quanto
avveniva per gli starter questa volta viene espresso in forma testuale nei valori
visti in precedenza. Sempre con lo stesso codice, esso viene utilizzato per
determinare un colore, il quale viene poi inserito come parametro nell’attributo
“src” del tag <img> per la rappresentazione visiva dello stato;
3. La terza variabile non è di interesse;
4. Il quarto ed ultimo valore corrisponde al numero del livello a cui il device server
appartiene. I nodi corrispondenti a questi livelli sono definiti staticamente nel file
HTML della pagina ed al termine dell’inserimento di tutti i nodi figli, i livelli che
non hanno alcun discendente vengono rimossi dal DOM per evitare problemi di
visualizzazione. Ugualmente a quanto avviene per i gruppi di starter, anche il led
dei livelli viene aggiornato ed il suo colore segue le medesime regole applicate in
precedenza.
Nella pagina denominata “Astor alert mode” inizialmente viene effettuata una
chiamata identica a quella della modalità principale ad albero. Una volta estrapolati i dati
ed in particolare lo stato degli starter, esso viene utilizzato per discernere tra il fare una
richiesta per la lista dei device server controllati dallo starter considerato o meno. In caso
questa seconda interazione col server avvenga, i dati ricevuti vengono elaborati
similmente a quanto visto fino ad ora, con la sola differenza che vengono aggiunti alla
lista visualizzata solamente i device server il cui colore del led risulta rosso. L’etichetta
dell’elemento contiene sia il nome dello starter sia quello del device server separati da
uno slash per garantire la massima chiarezza possibile. A seguito delle successive
interazioni col server, lo stato viene aggiornato e se corrisponde a un colore diverso dal
rosso, il device server in questione viene rimosso dalla lista.

27. 27
4. Risultati sperimentali
Prima di entrare nel merito dell’applicazione e dei test che si sono effettuati durante il
suo sviluppo per arrivare ad un risultato ottimale, soprattutto per quanto riguarda la
frequenza di aggiornamento dei dati, è bene focalizzarsi sul framework Apache Cordova
per capire cosa esso produce e con quali tempistiche lo fa.
4.1 Output del framework
L’iniziale output prodotto da Apache Cordova si trova nella cartella platforms del
proprio progetto: in essa è possibile individuare una cartella per ogni piattaforma che è
stata aggiunta. Il framework copia in ciascuna di esse i file contenuti nella cartella www
del progetto e crea il rimanente necessario affinché si possa avere un’istanza di
applicazione che funzioni a dovere. Tutto ciò avviene dando per scontato che i requisiti
specifici per ogni piattaforma siano soddisfatti. In caso contrario Cordova genera nella
sua interfaccia a riga di comando un WARNING, avvisando lo sviluppatore che non è
stato possibile procedere e se ne è in grado, cerca di spiegargli quale sia il problema.
Per fare un esempio, al fine di sviluppare un’applicazione ibrida che funzioni sulla
piattaforma iOS è necessario installare il framework Apache Cordova su un calcolatore
con sistema operativo OS X. Anche il solo aggiungere la piattaforma iOS al proprio
progetto su un calcolatore su cui è in esecuzione un sistema operativo diverso, genera un
chiaro messaggio di allarme. Esso notifica all’utente che applicazioni per iOS non
possono essere compilate sul computer in questione, ma ugualmente crea la cartella ios
all’interno di quella platforms e vi aggiunge i file necessari al funzionamento
dell’applicazione, compresi i plugin che erano stati aggiunti al progetto. Nel caso si
tentasse di compilare il codice per la piattaforma di Apple, verrebbe visualizzato un
messaggio d’errore di colore rosso dovuto all’impossibilità di trovare xcodebuild,
programma necessario per questa operazione.
Al fine di eseguire l’installazione del sistema sviluppato su un qualsiasi dispositivo
mobile, non è in realtà necessario eseguire complesse operazioni di impacchettamento e
caricamento sui relativi store delle piattaforme.

28. 28
Grazie ad alcuni comandi di Apache Cordova, infatti, è possibile installare l’applicazione
funzionante in tutto e per tutto sul dispositivo, previa preparazione di esso su alcune
piattaforme. Per esempio, su Android è necessario dapprima sbloccare le “Opzioni
sviluppatore” dove abilitare il “Debug USB”. In seguito a ciò è sufficiente collegare via
cavo il dispositivo in questione al calcolatore su cui si trova il progetto di Cordova, ed
eseguire un comando adeguato.
Tuttavia, per la distribuzione della propria app al pubblico, piccolo o grande che sia,
una scelta più funzionale e soprattutto più abituale per l’utilizzatore, sarebbe quella di
inviarla opportunamente impacchettata al gestore dello store delle piattaforme di
sviluppo.
Si consideri l’eventualità che si sia scelto Android come uno tra i sistemi operativi di
destinazione del proprio sistema. Quello che viene caricato su Google Play Store è un
unico file standard con estensione apk (Android Application Package) che corrisponde
alla versione release della propria applicazione.
Per costruire questo pacchetto è necessario, oltre che effettuare un debug completo e
minuzioso, firmare la propria app attraverso l’utilizzo di una chiave crittografica. In
seguito alla registrazione sul sito
http://developer.android.com/distribute/googleplay/index.html e al pagamento della
quota una tantum di 25 $, è possibile caricare il proprio file apk ma non ancora pubblicare
l’applicazione. Per fare questo bisogna inserire su di essa ulteriori informazioni come ad
esempio una categoria, degli screenshots, una descrizione, un paese di distribuzione e
deciderne il prezzo.
4.2 Prove effettuate sul sistema
Nelle prime fasi di sviluppo dell’applicazione, ci si è concentrati sullo sviluppo della
modalità denominata FERMI Status. Durante la scrittura del codice ad essa relativo si è
provato a variare il numero, la tipologia e la precedenza delle chiamate al server
fcsproxy.elettra.eu, in maniera tale da raggiungere la massima frequenza di
aggiornamento dei dati visualizzati.

29. 29
Inizialmente si era costruita la pagina attorno a una chiamata singola che restituisse
tutti i dati utili in una singola risposta e, in seguito all’elaborazione, li visualizzasse
adeguatamente. Acausa della necessità di ogni valore di essere collezionato sul lato server
per poi essere unito a tutti gli altri in una sola stringa di testo, al crescere del numero di
campi che venivano inseriti, il tempo di risposta del server aumentava in maniera più che
lineare. Per questo motivo si è deciso di spezzare la chiamata monolitica in più richieste,
le quali venivano gestite in maniera asincrona sia sul lato client che su quello server. In
questo modo le tempistiche si sono ridotte notevolmente, grazie all’introduzione di un
certo parallelismo tra le interazioni con fcsproxy.elettra.eu.
Dato che si è principalmente lavorato su sistema operativo Android, un successivo
passo di questa evoluzione è stato compiuto utilizzando gli strumenti di debug facenti
parte di Google Chrome. Digitando come URL chrome://inspect/#devices viene infatti
visualizzata una lista delle applicazioni in esecuzione su dispositivi mobili o emulatori
connessi con Debug USB attivo.
Dopo averne selezionato una, un’altra finestra del browser viene aperta ed usata sia
per l’interazione col dispositivo stesso attraverso interfaccia grafica, sia per la
visualizzazione di diverse schede utili tra cui:
 Elements, contenente il file HTML aggiornato in tempo reale relativo
all’applicazione;
 Console, in cui è possibile attraverso il codice JavaScript stampare dei log, per
monitorare lo stato di alcune variabili, oppure in cui vengono visualizzati i
messaggi di errore;
 Source, una lista di tutti i file usati dall’applicazione per il suo funzionamento;
 Network, una linea temporale in cui è possibile osservare tutte le richieste HTTP
eseguite dal codice, corredate con loro dettagli quali istante di avvio, durata
dell’attesa, istante di ricezione della risposta, tipologia della richiesta, URL
richiesta ecc ecc.

30. 30
Grazie a quest’ultimo strumento è stato possibile monitorare quali tra le chiamate fatte
hanno un tempo medio di risposta più lungo. Inoltre sono state poste in questo gruppo
anche le richieste restituenti un valore che non varia così spesso nel tempo, in modo da
non sovraccaricare il server di troppe richieste, velocizzando nel contempo le altre. Si è
proceduto quindi per tentativi, diminuendo via via il periodo di aggiornamento fino a
raggiungere il limite al di sotto del quale si trovano in attesa di risposta due richieste allo
stesso URL.
Tutte le prove eseguite per raggiungere questo risultato finale hanno avuto lo scopo di
ottenere un’applicazione la cui modalità relativa allo stato della macchina FERMI
aggiornasse praticamente in tempo reale i dati di interesse, in modo da intervenire in
maniera tempestiva in caso di problematiche. Esiste già, infatti, una pagina web non
ottimizzata per dispositivi mobili, ma consultabile solo da desktop, che visualizza questi
dati. Tuttavia essa riceve valori aggiornati ogni 120 secondi e visualizza al posto dei
grafici interattivi presenti, immagini statiche con scale non esattamente utili al personale.
Di seguito si riportano i tempi di risposta delle varie prove, per i gruppi di variabili.
Variabili
Lente
Variabili
Veloci
Tutte le
variabili
Richiesta monolitica ---- ---- 15000 ms
Richieste singole 10000 ms 7000 ms ----
Gruppi di richieste
separate
60000 ms 2000 ms ----

31. 31
5. Manuale d’uso del framework
Prima di poter effettuare qualsiasi operazione utilizzando Apache Cordova è
necessario soddisfare alcuni prerequisiti per la sua corretta installazione.
5.1 Requisiti software
Per poter funzionare Cordova ha bisogno di tre componenti fondamentali:
 Node.js
 Git
 Mobile SDK(s)
Node.js è un framework utilizzato per realizzare applicazioni Web in JavaScript, che
permette di utilizzare questo linguaggio, tipicamente utilizzato nello sviluppo “client-
side”, anche per la scrittura di applicazioni “server-side”. La piattaforma è basata sul
JavaScript Engine V8, che è il runtime di Google utilizzato anche da Chrome e disponibile
sulle principali piattaforme, anche se maggiormente performante su sistemi operativi
UNIX-like. Esso è popolare poiché include lo strumento, denominato npm (Node Package
Manager), utilizzato per la gestione del più grande ecosistema di librerie software open
source e delle loro dipendenze. npm verrà usato per scaricare e installareApache Cordova.
Recandosi, attraverso il proprio browser, sulla pagina web https://nodejs.org è
possibile eseguire il download del pacchetto di installazione di Node.js clickando
sull’enorme bottone verde, ma non prima di aver verificato che il sistema operativo
rilevato dal sito sia corretto. Durante questo processo è consigliabile utilizzare tutte le
impostazioni predefinite e verificare che sia spuntata l’opzione relativa alla modifica della
variabile d’ambiente PATH.
Git è un sistema di controllo versione distribuito open source utilizzabile da riga di
comando. Esso viene usato per tenere traccia delle modifiche apportate al codice sorgente
di un software, senza la necessità di utilizzare un server centrale.

32. 32
In questo modo gli sviluppatori possono collaborare individualmente e parallelamente da
offline su di un proprio ramo (branch) di sviluppo, registrare le proprie modifiche
(commit) ed in seguito condividerle con altri o unirle (merge) a quelle di altri, il tutto
senza bisogno del supporto di un server, proprio perché il server è soltanto un mero
strumento d'appoggio. Questo strumento verrà usato da Cordova automaticamente.
Il programma di installazione relativo alla propria piattaforma può essere trovato sul
sito https://git-scm.com/downloads. Come per node.js è bene lasciare tutti i valori
predefiniti durante la procedura e verificare che esso modifichi la variabile d’ambiente
PATH.
Infine, è necessaria l’installazione del Mobile SDK (Software Development Kit)
corrispondente alla piattaforma mobile per cui si intende rilasciare l’applicazione. Nel
caso affrontato, al fine di sviluppare un’applicazione ibrida per la piattaforma Android è
stato necessario installare JDK (Java Development Kit) ed Apache Ant, una libreria
utilizzata in maniera automatica da Cordova. Successivamente si è potuto effettivamente
installare Android SDK ed attraverso il relativo SDK Manager ottenere le diverse
versioni di Android, complete di documentazione.
Su http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-
2133151.html è stato possibile scaricare e installare JDK per il sistema operativo in
esecuzione sul proprio calcolatore, semplicemente seguendo le istruzioni a schermo. Ci
si è poi recati sul sito https://developer.android.com/studio/index.html dove a fondo
pagina si trova il link per il download del solo Android SDK, escluso Android Studio. La
procedura di installazione del SDK si concluderebbe con un errore in caso non fosse
presente JDK sul proprio computer. Una volta che essa è terminata con esito positivo, è
bene spuntare l’opzione “Start SDK Manager”, programma grazie al quale è possibile
scaricare l’ultima versione di Android includendo immagini di sistema utili alla creazione
di un emulatore. Infine, nella sezione Download del menù laterale del sito
http://ant.apache.org/ si può trovare il link “Binary Distribution”, che conduce a una
pagina in cui è possibile effettuare il download del file zip, all’interno del quale si trovano
i file binari della libreria Apache Ant.

33. 33
Dopo aver installato tutti i componenti necessari, la prima cosa da fare è assicurarsi
che determinate cartelle siano state aggiunte alla variabile d’ambiente PATH. Essa è
una lista di directory in cui il sistema operativo ricerca un comando nel caso in cui esso
non sia presente nella cartella in cui si è aperto il prompt dei comandi su Windows o il
terminale su Linux o OS X.
Nel nostro caso, le cartelle da aggiungere al PATH sono state:
 Android SDK platform-tools
 Android SDK tools
 Apache Ant bin
 Java JDK bin
 Git bin
 Node bin
Per assicurarsi che tutti i componenti fossero installati, ed aggiunti al PATH, si sono
eseguiti i seguenti comandi:
 adb (per Android SDK)
 ant (per Apache Ant)
 javac (per JDK)
 git (per Git)
 npm (per Node.js)

34. 34
A questo punto, per installare finalmente Cordova si esegue il comando:
𝑛𝑝𝑚 𝑖𝑛𝑠𝑡𝑎𝑙𝑙 − 𝑔 𝑐𝑜𝑟𝑑𝑜𝑣𝑎
oppure
𝑠𝑢𝑑𝑜 𝑛𝑝𝑚 𝑖𝑛𝑠𝑡𝑎𝑙𝑙 − 𝑔 𝑐𝑜𝑟𝑑𝑜𝑣𝑎
su OS X.
Per verificare la corretta installazione, si digita 𝑐𝑜𝑟𝑑𝑜𝑣𝑎: se tutto è andato a buon fine,
come risposta si ottengono informazioni utili all’utilizzo del framework.
5.2 Cordova Command-Line-Interface
Per la creazione del primo progetto Cordova, si utilizza il comando
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑐𝑟𝑒𝑎𝑡𝑒 𝑖𝑑_𝑝𝑟𝑜𝑔𝑒𝑡𝑡𝑜 𝑛𝑜𝑚𝑒_𝑝𝑟𝑜𝑔𝑒𝑡𝑡𝑜
 id_progetto identifica in maniera univoca l’applicazione negli store delle
piattaforme scelte ed è in formato “nome di dominio invertito”
(e.g. com.companyname.sectionname.appname)
 nome_progetto è il nome dell’applicazione che compare nel dispositivo una volta
che essa sia stata installata (e.g. ElettrApp)
Di default un progetto di Cordova non supporta alcuna piattaforma; per visualizzare
le piattaforme che è possibile aggiungervi si usa il comando
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑝𝑙𝑎𝑡𝑓𝑜𝑟𝑚𝑠
, mentre per effettivamente aggiungerne una
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑝𝑙𝑎𝑡𝑓𝑜𝑟𝑚𝑠 𝑎𝑑𝑑 𝑛𝑜𝑚𝑒_𝑝𝑖𝑎𝑡𝑡𝑎𝑓𝑜𝑟𝑚𝑎
e per eliminarne una
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑝𝑙𝑎𝑡𝑓𝑜𝑟𝑚𝑠 𝑟𝑒𝑚𝑜𝑣𝑒 𝑛𝑜𝑚𝑒_𝑝𝑖𝑎𝑡𝑡𝑎𝑓𝑜𝑟𝑚𝑎
Un progetto di Cordova nasce avendo installato un solo plugin chiamato cordova-
plugin-whitelist. Esso viene utilizzato per mantenere una lista degli URL accessibili dal
codice HTML e JavaScript, in modo da evitare l’accesso da parte dell’applicazione di siti
web maligni.

35. 35
Dopo aver aperto un terminale o prompt dei comandi nella cartella principale del
progetto, si possono visualizzare i plugins che sono al momento installati digitando il
comando 𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑝𝑙𝑢𝑔𝑖𝑛𝑠.
Una volta individuato l’ID di un plugin sul sito https://www.npmjs.com/ di interesse
lo si può aggiungere al progetto tramite
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑝𝑙𝑢𝑔𝑖𝑛𝑠 𝑎𝑑𝑑 𝑖𝑑_𝑝𝑙𝑢𝑔𝑖𝑛
Analogamente, se si vuole eliminarne uno si usa il comando
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑝𝑙𝑢𝑔𝑖𝑛𝑠 𝑟𝑒𝑚𝑜𝑣𝑒 𝑖𝑑_𝑝𝑙𝑢𝑔𝑖𝑛
Dopo aver modificato secondo le proprie esigenze il codice HTML, JavaScript e CSS
si può procedere a caricare sul dispositivo fisico o virtuale la propria applicazione ibrida:
 𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑝𝑟𝑒𝑝𝑎𝑟𝑒 𝑛𝑜𝑚𝑒_𝑝𝑖𝑎𝑡𝑡𝑎𝑓𝑜𝑟𝑚𝑎 copia i file contenuti nella cartella www
nella cartella della piattaforma corrispondente;
 𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑐𝑜𝑚𝑝𝑖𝑙𝑒 𝑛𝑜𝑚𝑒_𝑝𝑖𝑎𝑡𝑡𝑎𝑓𝑜𝑟𝑚𝑎 compila i file della piattaforma in codice
binario che è possibile eseguire su un dispositivo;
 𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑏𝑢𝑖𝑙𝑑 𝑛𝑜𝑚𝑒_𝑝𝑖𝑎𝑡𝑡𝑎𝑓𝑜𝑟𝑚𝑎 combina le due operazioni precedenti;
 𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑒𝑚𝑢𝑙𝑎𝑡𝑒 𝑛𝑜𝑚𝑒_𝑝𝑖𝑎𝑡𝑡𝑎𝑓𝑜𝑟𝑚𝑎 include l’operazione precedente e
manda il codice binario al dispositivo virtuale;
 𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑟𝑢𝑛 𝑛𝑜𝑚𝑒_𝑝𝑖𝑎𝑡𝑡𝑎𝑓𝑜𝑟𝑚𝑎 è analoga alla versione emulate, ma sua
differenza invia il codice a un dispositivo fisico connesso.
Si è già visto che nel caso in cui si volesse distribuire l’applicazione creata su Google
Play Store, è necessario firmarla attraverso l’utilizzo di una chiave. Supponendo che lo
sviluppatore non ne possieda già uno, è possibile creare un gruppo di chiavi ed una chiave
contemporaneamente grazie a una chiamata a riga di comando:
𝑘𝑒𝑦𝑡𝑜𝑜𝑙 − 𝑔𝑒𝑛𝑘𝑒𝑦 − 𝑣 − 𝑘𝑒𝑦𝑠𝑡𝑜𝑟𝑒 𝑐𝑜𝑚𝑝𝑎𝑛𝑦_𝑛𝑎𝑚𝑒. 𝑘𝑒𝑦𝑠𝑡𝑜𝑟𝑒
−𝑎𝑙𝑖𝑎𝑠 𝑎𝑙𝑖𝑎𝑠_𝑘𝑒𝑦𝑠𝑡𝑜𝑟𝑒 − 𝑘𝑒𝑦𝑎𝑙𝑔 𝑅𝑆𝐴 − 𝑘𝑒𝑦𝑠𝑖𝑧𝑒 2048 − 𝑣𝑎𝑙𝑖𝑑𝑖𝑡𝑦 10000

36. 36
Dove 𝑐𝑜𝑚𝑝𝑎𝑛𝑦_𝑛𝑎𝑚𝑒. 𝑘𝑒𝑦𝑠𝑡𝑜𝑟𝑒 è il nome del keystore mentre 𝑎𝑙𝑖𝑎𝑠_𝑘𝑒𝑦𝑠𝑡𝑜𝑟𝑒 è il
suo alias. Dopo aver inserito una nuova password e risposto a delle domande su di sé e
sulla propria organizzazione, è necessario creare un file denominato ant.properties nella
cartella android all’interno di platforms.
Editandolo si devono aggiungere due righe ad esso, che vengono utilizzate da
Cordova per la firma:
𝑘𝑒𝑦. 𝑠𝑡𝑜𝑟𝑒 = 𝑝𝑎𝑡ℎ/𝑐𝑜𝑚𝑝𝑎𝑛𝑦_𝑛𝑎𝑚𝑒. 𝑘𝑒𝑦𝑠𝑡𝑜𝑟𝑒
𝑘𝑒𝑦. 𝑎𝑙𝑖𝑎𝑠 = 𝑎𝑙𝑖𝑎𝑠_𝑘𝑒𝑦𝑠𝑡𝑜𝑟𝑒
A questo punto è possibile digitare il seguente comando per creare una versione di
rilascio dell’applicazione, che nel caso Android consiste di un file apk:
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 𝑏𝑢𝑖𝑙𝑑 − 𝑟𝑒𝑙𝑒𝑎𝑠𝑒
In caso sia necessario un aiuto generico per quanto riguarda il framework è
sufficiente usare
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 ℎ𝑒𝑙𝑝
per visualizzare a schermo tutti i comandi supportati da Cordova insieme ad una breve
descrizione. Se servissero ulteriori informazioni circa la sinossi di un comando si può
digitare
𝑐𝑜𝑟𝑑𝑜𝑣𝑎 ℎ𝑒𝑙𝑝 𝑛𝑜𝑚𝑒_𝑐𝑜𝑚𝑎𝑛𝑑𝑜

37. 37
6. Conclusione
Come i capitoli precedenti descrivono in maniera esaustiva, gran parte delle
funzionalità richieste dal sistema sono state soddisfatte.
Grazie al meccanismo delle chiamate AJAX nessun dato dell’utente viene perso nel
passaggio da una modalità all’altra. Inoltre i dati utili a sessioni future, come l’ultima
modalità selezionata, gli allarmi impostati o lo username inserito vengono salvati usando
un nuovo strumento fornito da HTML5 denominato localStorage.
L’utente dovrebbe essere capace di usare l’applicazione in maniera semplice dato che
essa è stata sviluppata basandosi su modalità di interazione consolidate nell’uso comune
di piattaforme mobili, come ad esempio bottoni, scorrimenti verticali, logo dell’azienda
come link alla pagina principale dell’applicazione eccetera.
Il numero e la frequenza di richieste ai server è stato per quanto possibile ottimizzato,
in modo da non sovraccaricarli di lavoro e contemporaneamente avere un periodo di
aggiornamento delle informazioni migliore di quello preesistente sugli applicativi web
(FERMI Status) e non (Astor).
Per chi continuerà auspicabilmente questo lavoro, una panoramica generale sul
framework è stata fornita, insieme ad un breve excursus sui comandi maggiormente
utilizzati e ritenuti fondamentali per lo sviluppo di un’applicazione. Sono inoltre state
fornite istruzioni su come risolvere il problema prestazionale dell’emulatore Android
incluso nel SDK relativo e riferimenti utili al reperimento dei software richiesti da
Cordova per il suo corretto funzionamento.
In conclusione, si può dire che attraverso l’utilizzo di strumenti software quali Apache
Cordova, Bootstrap e jQuery è stato possibile creare un’applicazione ibrida che allo stato
attuale svolge egregiamente il proprio compito, ma che in un futuro non troppo lontano
potrà essere migliorata ed ampliata, senza dimenticare la possibilità di pubblicarla sugli
store delle piattaforme mobili di sviluppo.

38. 38
Fonti bibliografiche e sitografia
RAYMOND K. CAMDEN (2016) – Apache Cordova in action. Manning
Pubblications Co. , New York, 230 pp, ISBN: 9781633430068
Astor (TANGO Manager) User’s Guide -
http://www.esrf.eu/computing/cs/tango/tango_doc/tools_doc/astor_doc/index.html
(Ultimo accesso: 24 novembre 2016)
Apache Ant - http://ant.apache.org/ (Ultimo accesso: 26 ottobre 2016)
Bootstrap - http://getbootstrap.com/ (Ultimo accesso: 23 novembre 2016)
Apache Cordova Plugin - https://cordova.apache.org/plugins/ (Ultimo accesso: 25
novembre 2016)
Git - https://git-scm.com/ (Ultimo accesso: 23 novembre 2016)
jQuery - https://jquery.com/ (Ultimo accesso: 15 novembre 2016)
Node.js - https://nodejs.org/it/ (Ultimo accesso: 23 novembre 2016)
Stack Overflow - http://stackoverflow.com/ (Ultimo accesso: 15 novembre 2016)
TANGO Controls - http://www.tango-controls.org/ (Ultimo accesso: 24 novembre
2016)
Wikipedia (TANGO) - https://en.wikipedia.org/wiki/TANGO (Ultimo accesso:29
novembre 2016)
W3Schools Online Web Tutorial - http://www.w3schools.com/ (Ultimo accesso: 15
novembre 2016)