Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamento al sistema di...

38
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

Transcript of Sviluppo di un'applicazione ibrida su dispositivo mobile per l'interfacciamento al sistema di...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. A causa 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

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

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 installare Apache 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

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

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

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

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

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

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

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)