Università degli Studi di Padova - Dipartimento di Matematica "Tullio - SIAGAS
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio
Levi-Civita"
Corso di Laurea in Informatica
Sviluppo di applicazione Android con
framework Ionic
Tesi di laurea triennale
Relatore
Prof.Gilberto Filè
Laureando
Cristian Pirlog
Anno Accademico 2017-2018
Cristian Pirlog: Sviluppo di applicazione Android con framework Ionic , Tesi di laurea triennale, c Settembre 2018.
Quando la tempesta sarà finita, probabilmente non saprai neanche tu come hai
fatto ad attraversarla e a uscirne vivo. Anzi, non sarai neanche sicuro se sia finita
per davvero. Ma su un punto non c’è dubbio. Ed è che tu, uscito da quel vento,
non sarai lo stesso che vi è entrato.
— Haruki Murakami
Sommario
Il presente documento descrive il lavoro da me svolto durante il periodo di stage,
della durata di 312 ore, presso l’azienda Digital Lighting S.r.l nella sua sede a Padova.
Inizialmente, mi erano stati proposti una serie di progetti diversi in ambito sviluppo
web ed un progetto invece che corrispondeva alla creazione di un’applicazione
per Android, attraverso l’utilizzo del framework Ionic. Non avendo mai avuto
l’occasione di affrontare lo sviluppo di un’ applicazione, colsi al volo l’opportunità,
nella speranza di riuscire ad assimilare una quantità più alta possibile di conoscenze
durante i due mesi successivi di lavoro.
L’obiettivo dello stage era quindi la realizzazione di un’applicazione Android tramite
l’utilizzo del framework Ionic, per la configurazione delle installazioni dei dispositivi
prodotti da Digital Lighting. Maggiori dettagli riguardanti il progetto si possono
trovare all’interno del capitolo 2.
v
Indice
1 Contesto aziendale 1
1.1 Descrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Prodotto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Missione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Gestione delle configurazioni . . . . . . . . . . . . . . . . . . . . . . 2
1.5 Collaborazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Contesto stage 5
2.1 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Smart Cities . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Il sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 nanoConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 Utilizzo tipico dell’applicazione . . . . . . . . . . . . . . . . 9
2.3 Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Ticketing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Analisi preventiva dei rischi . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Aspettative personali . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.7 Aspettative aziendali . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 nanoConfig: primi passi 19
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Perché un PoC ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.4 Approccio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.5 Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.6 Ionic Native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7 Sicurezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.7.1 AES-JS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.8 Salvataggio dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.8.1 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.9 Geolocalizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.9.1 Test sul campo . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 nanoConfig: sviluppo avanzato 27
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Autenticazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
viiviii INDICE
4.2.1 Auth0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Ritorno alle origini . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Algoritmo per la geolocalizzazione . . . . . . . . . . . . . . . . . . . 29
4.3.1 "Dove mi trovo?" . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.1 CSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.4.2 Native Storage . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Sessione, Master e Nano . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.1 Sessione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.2 Master . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6 Nano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5 Conclusioni 37
5.1 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . 37
5.2 Resoconto dell’analisi dei rischi . . . . . . . . . . . . . . . . . . . . 38
5.3 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.1 Crescita lato tecnico . . . . . . . . . . . . . . . . . . . . . . 39
5.3.2 Crescita personale . . . . . . . . . . . . . . . . . . . . . . . 39
5.4 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Glossario 43Elenco delle figure
1.1 Logo Digital Lighting . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Logo GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Pacchetto G Suite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Illustrazione sull’illuminazione intelligente su strada . . . . . . . . . 6
2.2 Esempio di dimmerazione giornaliera . . . . . . . . . . . . . . . . . 8
2.3 Logo Ionic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Funzionamento di Angular . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Esempio di utilizzo delle boards di GitHub . . . . . . . . . . . . . . 15
3.1 Illustrazione di Proof of Concept . . . . . . . . . . . . . . . . . . . 20
3.2 Pagina di visualizzazione dei dispositivi trovati . . . . . . . . . . . . 22
3.3 Pagina dove la connessione è avvenuta con successo al dispositivo
(risultato finale) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Funzionamento di un servizio in Ionic . . . . . . . . . . . . . . . . . 25
4.1 Pagina con form di autenticazione . . . . . . . . . . . . . . . . . . . 28
4.2 Pagina di creazione di un calendario . . . . . . . . . . . . . . . . . . 30
4.3 Pagina relativa alla sessione in corso . . . . . . . . . . . . . . . . . 33
4.4 Pagina relativa ad uno specifico master . . . . . . . . . . . . . . . . 34
4.5 Pagina impostazioni di uno specifico master . . . . . . . . . . . . . 35
4.6 Pagina relativa ad uno specifico slave . . . . . . . . . . . . . . . . . 36
Elenco delle tabelle
2.1 Tabella degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Tabella analisi dei rischi . . . . . . . . . . . . . . . . . . . . . . . . 17
ixx ELENCO DELLE TABELLE
5.1 Tabella raggiungimento obiettivi . . . . . . . . . . . . . . . . . . . . 38
5.2 Tabella di resoconto dell’analisi dei rischi . . . . . . . . . . . . . . . 38Capitolo 1
Contesto aziendale
1.1 Descrizione
Figura 1.1: Logo Digital Lighting
Digital Lighting Srl (unipersonale) è stata costituita ad agosto 2014 ed è iscritta
allo speciale registro delle start-up innovative. Essa offre dei prodotti per rendere
le città più intelligenti. La costituzione è avvenuta per "conferimento" di una ditta
individuale, denominata INWENTA. Digital Lighting è un marchio registrato
e la società ha presentanto domanda di registrazione di brevetto inerente alle
caratteristiche del prodotto che ha sviluppato.
1.2 Prodotto
La ricerca e lo sviluppo sono parte integrante dell’azienda, ed hanno permesso di
creare un unico dispositivo che può essere personalizzato per incorporare diverse
applicazioni, a seconda delle esigenze del cliente. Questo dispositivo si chiama
Ulysset. Sono state brevettate le sue funzionalità in Italia, ma non le componenti
hardware: questo significa che altre aziende potranno progettare prodotti con le
stesse componenti ma non potranno avere le stesse funzioni tutte assieme.
Le funzionalità offerte per l’integrazione sono:
• Controllo intelligente dell’illuminazione;
• Misurazione intelligente;
• Smart Parking;
12 CAPITOLO 1. CONTESTO AZIENDALE
• Videosorveglianza ed analisi del traffico;
• Copertura hotspot WiFi Internet;
• Tracciamento di oggetti e persone;
• Bike sharing.
Digital Lighting permette di gestire qualunque tipo di illuminazione sia presente,
garantendo compatibilità con quanto già installato e con le più moderne tecnologie
LED. La regolazione dell’intensità luminosa permette di ottenere il massimo dei
risultati in termini di risparmio energetico e riduzione dell’inquinamento luminoso.
Il monitoraggio dei consumi e del tempo di lavoro permette di verificare il corretto
funzionamento dei corpi illuminanti e di prevedere ed organizzare le manutenzioni
sugli stessi.
1.3 Missione
La missione di Digital Lighting è di avere un impatto positivo e duraturo sulle
città in cui viviamo e sulle città del futuro fornendo un dispositivo che creerà un
ambiente più efficiente, intelligente e sicuro.
Risparmiare energia, rispettare l’ambiente, ridurre i costi di gestione, aumentare
l’efficienza e la qualità dei servizi sono quindi i principali obiettivi a cui tutte le
città ai giorni nostri dovrebbero aspirare, assieme a Digital Lighting.
1.4 Gestione delle configurazioni
L’azienda utilizza il software di controllo di versione distribuito Git, attraverso la
sue implementazioni GitHub e GitBucket, per salvare il proprio codice sorgente
nelle repository gestite sotto un profilo aziendale.
Per l’attività da me svolta è stato creato un repository privato specifico per il
progetto, nominato nanoConfig. All’interno di questo è stato aggiunto il codice
iniziale per il Proof of Concept, poi riutilizzato per la vera e propria applicazione.
Figura 1.2: Logo GitHub
1.5 Collaborazione
L’azienda utilizza come strumento di collaborazione interna G Suite, una suite di
software e strumenti di produttività offerta da Google.1.5. COLLABORAZIONE 3
Il motivo principale per cui viene utilizzato G Suite dalle aziende è per l’hosting
email. Tuttavia, moltre altre funzionalità che possono tornare molto utili vengono
offerte. Alcune di esse sono:
• Google Calendar: molto utile per tenere i propri impegni ben organizzati;
• Google Drive: permette di archiviare, accedere e condividere i propri files
in un unico posto sicuro;
• Google Docs e Google Sheets: questi strumenti danno la possibilità di
creare e modificare documenti di testo e spreadsheets;
• Google Keep: l’alternativa a Evernote per salvare le proprie note.
Figura 1.3: Pacchetto G SuiteCapitolo 2
Contesto stage
All’interno di questo capitolo verrà prima di tutto descritto dettagliamente il progetto.
Successivamente verranno definiti i rischi possibili introdotti ad esempio dalle tecnologie
utilizzate oppure dalla mia mancanza di esperienza. In ultima fase, verranno elencati gli
obiettivi prefissati, che verranno analizzati a posteriori all’interno dell’ultimo capitolo
del documento, assieme alle considerazioni finali sullo stage.
2.1 Introduzione al progetto
Prima di descrivere cosa effettivamente dovrebbe fare l’applicazione, è doveroso
descriverne il contesto applicativo.
2.1.1 Smart Cities
Gli obiettivi a cui Digital Lighting aspira sono fornire prodotti e servizi per rendere
le città più smart. Ma come si dovrebbe rendere una città più smart?
Rispettando l’ambiente, risparmiando energia, riducendo i costi di gestione, aumen-
tando la qualità e l’efficienza dei servizi da essa offerti.
Per raggiungere tali obiettivi, una delle soluzioni proposte da Digital Lighting
consiste nell’implementazione di un sistema che fornisce un’ illuminazione intel-
ligente.
Smart Lighting
Quando si parla di Smart Lighting ci si riferisce alla possibilità di variare l’intensità
della luce in modo ottimale, potendola quindi ad esempio adeguare a particolari
condizioni sulla strada (un incidente o molto traffico), sulla base della presenza o as-
senza delle persone o determinati oggetti (ad esempio monumenti) o ai cambiamenti
stagionali.
Per capirne meglio le potenzialità bisognerà andare più in dettaglio:
• se la strada è vuota, non è necessario che ci sia un’illuminazione eccessiva, e di
conseguenza l’intensità dovrà essere abbassata automaticamente, producendo
così un risparmio energetico e una riduzione delle emissioni di CO2;
56 CAPITOLO 2. CONTESTO STAGE
• sempre qualora le strade fossero vuote, l’illuminazione all’interno delle città
risulta comunque essere essenziale per la sicurezza, ed è per questo motivo
che i lampioni dovranno emettere sempre un leggero bagliore, ed aumentare
di intensità solamente quando qualcuno si avvicinerà;
• data la possibilità di integrare diversi sensori, possiamo rendere questi lampioni
come delle piattaforme disponibili per altri servizi, come ad esempio il
monitoraggio ambientale, o come Hotspot per il Wi-Fi pubblico;
• in caso di calamità naturali è necessario avvertire i cittadini il più presto
possibile, ed in questi casi i lampioni intelligenti diventano gli strumenti adatti
per gli annunci di pubblica sicurezza;
• anche in condizioni meno gravi in una città c’è la necessità di informare i
cittadini sulle condizioni del traffico locale, sui parcheggi, sulle condizioni del
meteo o sul trasporto pubblico. Anche in questi casi i lampioni intelligenti
sono d’aiuto, trasformandosi in ottimi strumenti per la segnaletica digitale.
Figura 2.1: Illustrazione sull’illuminazione intelligente su strada
Queste e molte altre, sono le potenzialità offerte da un lampione intelligente.
Digital Lighting cerca di raggiungere questi obiettivi integrando una serie di
sensori di luminosità, telecamere, radar, wi-fi, bluetooth, RFID e meteo all’interno
dei suoi dispositivi, permettendo così anche la riduzione dell’inquinamento
luminoso e garantendo un risparmio di energia elettrica.
2.1.2 Il sistema
Ora che ne è stato descritto il contesto applicativo, si può andare avanti a descri-
verne il sistema.
Digital Lighting offre due dispositivi principali, entrambi modulari, che offrono
quindi la possibilità di personalizzare il prodotto in base alle necessità. Se ad
esempio non ci si trova in un parco, non è necessario installare un modulo per la2.1. INTRODUZIONE AL PROGETTO 7
segnaletica stradale, ma potrebbe tornare invece molto utile installare quello che
possa permettere alle persone di connettersi al Wi-Fi tramite Hotspot.
I due dispositivi in questione sono:
• ULYSSET ONE: il dispositivo principale offerto dall’azienda, sul quale si
potranno attivare praticamente tutte le funzionalità sopra citate, incluso il
modulo per la videosorveglianza come standard;
• ULYSSET LITE: il dispositivo che viene dall’azienda definito come smart
street light controller, ovvero controller intelligente per l’illuminazione
stradale. Questo viene offerto nella sua versione base, senza modulo di
videosorveglianza incluso, però resta comunque altamente personalizzabile
grazie alla modularità.
L’ULYSSET LITE è il dispositivo utilizzato all’interno del progetto da me
portato avanti.
Architettura master-slave
All’interno del sistema, l’ULYSSET LITE viene definito come master in quanto,
similmente a quel che succede nell’architettura master-slave 1 all’interno di un cal-
colatore, esso gestisce l’intero sistema, composto da una molteplicità di periferiche,
ovvero slave. Questi ultimi dispositivi sono denominati nodi, oppure - come è
d’uso all’interno dell’azienda - nano, da cui deriva anche il nome dell’applicazione,
nanoConfig.
Master in dettaglio
Una volta che l’area dove il dispositivo dovrà agire sarà identificata, una rete
wireless mesh viene sviluppata. Essa consisterà di una serie di sensori richiesti
per coprire la specifica area.
Una volta che la rete sarà stata creata, i dispositivi nano sono messi al lavoro in
modo da trasmettere i dati da un nodo all’altro per poter alla fine trasmetterli ad
un server cloud. Qui i dati sono processati e mostrati o forniti agli utenti sotto
forma di un’API. La rete viene inoltre utilizzata dal cliente per inviare comandi ai
singoli dispositivi, potendo interagire con i diversi servizi offerti.
La rete mesh, per poter essere efficiente nel fornire i servizi, dispone delle seguenti
caratteristiche:
• Banda larga da 300 Mbit/s;
• Standard Wi-Fi 802.11s;
1
https://it.wikipedia.org/wiki/Architettura_master-slave8 CAPITOLO 2. CONTESTO STAGE
• Alta affidabilità attraverso l’utilizzo di 4 livelli di sicurezza;
• Alta capacità, sfruttando il multi-gateway;
• Alta scalabilità, permette di avere un numero di nodi slave variabile, in base
alle necessità. E’ potenzialmente estensibile all’infinito.
Slave in dettaglio
I dispositivi slave, come già accennato, possono essere presenti all’interno della rete,
in un quantitativo che varia in base alla situazione d’utilizzo.
Una volta posizionati sui pali della luce, i dispositivi potranno successivamente
essere configurati, utilizzando l’app nanoConfig. Questa fase verrà da ora chiamata
configurazione, mentre quella precedente di posizionamento sui pali si chiamerà
di installazione.
Il calendario Questi dispositivi si illuminano automaticamente, attraverso una
configurazione di dimmerazione standard giornaliera.
Figura 2.2: Esempio di dimmerazione giornaliera
Tuttavia, una configurazione standard non basta, per diversi motivi:
• alba e tramonto non avvengono sempre alla stessa ora;
• alba e tramonto variano in base alla posizione geografica;
• un parco ha necessità diverse di illuminazione rispetto ad un centro commer-
ciale o ad una semplice strada;
• certi giorni dell’anno necessiteranno di un’illuminazione diversa, in concomi-
tanza con eventi particolari.
La soluzione a tutto questo è la creazione di un calendario, o anche chiamato
profilo, per ciascun dispositivo nano che copra l’intero arco di 365 giorni. Il cliente
avrà due possibilità:2.2. NANOCONFIG 9
1. organizzare in anticipo, ancora prima dell’installazione dei dispositivi, un
calendario completo. Assieme al calendario sarà loro dovere catalogare i
dispositivi, dando loro un identificativo, ma anche possibilmente una posizione
geografica ben precisa;
2. creare il calendario durante la fase di configurazione sfruttando l’applica-
zione nanoConfig. Sarà possibile configurare una dimmerazione giornaliera,
per ciascun giorno dell’anno, ma anche scegliere dei periodi separati e lasciare
dei valori standard per i giorni non coperti.
2.2 nanoConfig
Come già accennato precedentemente, l’applicazione da me sviluppata permette di
configurare dei dispositivi già installati.
I clienti a cui Digital Lighting vorrebbe vendere il prodotto sono di vario tipo:
• Amministrazioni Pubbliche;
• Energy Service Company (ESCO);
• aree residenziali;
• centri commerciali;
• in generale grandi spazi.
Risulta quindi importante capire che l’applicazione nanoConfig non sarà quindi
pubblicata sul Play Store di Google, in quanto l’utenza è molto ristretta,
riducendosi solamente ad alcuni dipendenti dei clienti sopra elencati.
Premessa Bisogna comunque tenere conto del fatto che diverse funzionalità sono
state pianificate durante l’attività di stage, per uno sviluppo successivo. La descri-
zione di seguito darà una panoramica di un’applicazione completa, obiettivo non
raggiungibile durante lo stage.
2.2.1 Utilizzo tipico dell’applicazione
Per spiegare in dettaglio nanoConfig, verranno di seguito descritti i passaggi che
solitamente dovrà fare l’utente per configurare un sistema master-slave.
Fase di autenticazione L’utente, prima di cominciare il suo lavoro, dovrà ese-
guire l’autenticazione. Le credenziali per accedere gli saranno precedentemente
fornite dall’azienda per cui sta lavorando. Quando l’utente cercherà di autenticarsi,
una richiesta HTTP verrà fatta all’API che l’azienda ha messo a disposizione. I
controlli necessari verranno fatti sul database contenente gli utenti registrati che
avranno tutti i permessi per operare attraverso l’applicazione.
Bisogna tenere conto del fatto che a nessun utente sarà possibile registrarsi
autonomamente.10 CAPITOLO 2. CONTESTO STAGE Creazione di una nuova sessione Una volta che l’utente avrà inserito le cre- denziali corrette egli si troverà davanti la pagina Dashboard. All’interno di questa schermata egli potrà visualizzare - se presenti - le vecchie sessioni di configurazione, che possono essere concluse o ancora in corso. Inoltre, gli sarà data la possibilità di cominciare una nuova sessione. Quando si parla di nuova sessione ci si riferisce alla configurazione di un sistema master-slave, composto da un master e da un certo numero di slaves, ovvero dispositivi nano. Premendo sulla sessione appena creata gli verrà mostrata la pagina di Ricerca dispositivi. Alla ricerca di dispositivi Ora che l’utente avrà creato una nuova sessione, potrà andare in cerca dei dispositivi da testare e configurare. Prima di tutto dovrà accertarsi di avere la connessione Bluetooth accesa. Una volta attivato il modulo Bluetooth, i dispositivi vicini verranno mostrati su schermo, ordinati in base alla potenza del segnale ricevuta. Telefoni cellulari o altri dispositivi diversi dai dispositivi nano non verranno elencati. Premendo su uno dei dispositivi in lista verrà effettuato un tentativo di pairing. Connessione sicura Se il tentativo di pairing è andato a buon fine, un ulteriore passaggio per portare a termine con successo la connessione dovrà essere fatto; rendere la connessione sicura attraverso l’utilizzo di un algoritmo di crittografia assimmetrica. Questi passaggi saranno eseguiti dall’applicazione in automatico, senza l’intervento dell’utente. Ora che la connessione al dispositivo è stata eseguita, all’utente sarà finalmente concessa la possibilità di testare il dispositivo. Test nano Una volta connesso, l’utente non può sapere immediatamente di quale dispositivo si tratti. Si immagini di essere all’interno di un parcheggio con venti pali della luce molto vicini; un livello di segnale alto potrebbe essere indicativo della vicinanza di un dispositivo, ma se i pali sono posti a pochi metri l’uno dall’altro la situazione diventa più complicata. A questo scopo esiste una funzionalità molto basilare, che risolve però il problema: l’accensione e lo spegnimento della luce. Una volta che l’utente avrà trovato il palo su cui è installato il dispositivo, si posiziona nella sua prossimità per proseguire con la configurazione. L’applicazione avrà accesso tramite un API ai dati relativi a tutti i dispositivi posi- zionati sui pali durante la fase di installazione. Tra questi dati ci saranno un nome identificativo del dispositivo, le coordinate geografiche (latitudine e longitudine) ed una serie di altri dati. Sfruttando questi dati, l’applicazione potrà fare l’associazione tra il dispositivo a cui si è connessi e uno presente all’interno del database. Scelta di un calendario Tra le varie informazioni presenti nel database dell’a- zienda per il dispositivo associato, c’è anche un calendario. Questo, se presente, verrà associato direttamente anch’esso come dato relativo al dispositivo, altrimenti,
2.3. TECNOLOGIE E STRUMENTI 11 l’utente potrà sceglierne uno tra quelli che lui ha già creato attraverso l’applicazione. Se non lo ha ancora fatto, potrà farlo in una fase successiva oppure sul momento. Creazione di un nuovo calendario All’interno di questa schermata l’utente potrà personalizzare un calendario per uno o più dispositivi. Esso sarà composto da una serie di intervalli di date, ciascuno contenente una configurazione giornaliera per quel periodo. Ciascuna configurazione giornaliera sarà poi suddivisa in fasce orarie, a partire dal tramonto per finire con l’alba. Per ogni fascia oraria sarà possibile definire ora di inizio, ora di fine ed il livello di dimmerazione. Una volta che avrà completato la configurazione del calendario, potrà andare ad assegnarlo al dispositivo desiderato. Salvataggio dei dati Ora che ha finito di configurare il dispositivo, l’utente potrà salvare i dati all’interno di un database locale interno al telefono premendo sul pulsante specifico. L’utente dovrà quindi proseguire nella ricerca degli altri dispositivi ed eseguire la stessa procedura per tutti quanti gli altri. Caricamento dei dati Una volta che avrà finito il giro di tutti quanti i disposi- tivi, l’utente potrà finalmente andare a connettersi al dispositivo master, ovvero l’ULYSSET LITE, seguendo la stessa procedura di connessione eseguita anche per i dispositivi nano. Qui troverà la lista di tutti quanti i dispositivi configurati e potrà associare a ciascuno di essi (o anche selezionandone molteplici) un calendario preesistente. Qualora volesse, potrà anche assegnare un calendario al dispositivo master stesso; in tal caso tutti i dispositivi slave erediteranno lo stesso calendario. Nel caso non ce ne fossero e ci fosse la necessità, potrà crearne di nuovi e assegnarli in un secondo momento. Quando avrà finito, dovrà caricare i dati raccolti e terminare la sessione in corso. 2.3 Tecnologie e strumenti Di seguito viene data una panoramica delle tecnologie e strumenti utilizzati. Framework Ionic Ionic è un framework per lo sviluppo di applicazioni mobile in HTML5 utilizzato per la creazione di applicazioni mobile ibride. Le applicazioni ibride non sono altro che piccoli siti web che vengono eseguiti all’interno dello shell di un browser dentro ad un’applicazione che ha accesso allo strato nativo della piattaforma specifica. Le applicazioni ibride hanno molti benefit rispetto alle applicazioni native, tra le quali: • supporto multipiattaforma; • velocità di sviluppo; • accesso a librerie di terze parti.
12 CAPITOLO 2. CONTESTO STAGE
Bisogna pensare ad Ionic come ad un framework dell’interfaccia front-end che
gestisce l’aspetto e le interazioni dell’interfaccia che l’applicazione necessita per
essere al passo con le ultime innovazioni in questo campo.
Dato che Ionic è un framework HTML5, esso necessita di un wrapper nativo come
Cordova o PhoneGap, per essere eseguito come un’applicazione nativa.
Figura 2.3: Logo Ionic
Ionic 3.0 Si è scelto di utilizzare la versione più recente di questo framework, per
le seguenti motivazioni:
• utilizza Angular 4.0.0;
• è compatibile con TypeScript v2.1 e v2.2;
• introduce la possibilità di utilizzare il Lazy Loading, ovvero un design pattern
che permette di rinviare l’inizializzazione di un oggetto fino al punto in
cui non viene effettivamente utilizzato. Nel caso di Ionic viene rinviata
l’inizializzazione delle componenti oppure dei services (come ad esempio un
database);
• il supporto è sempre crescente e la comunità sempre più grande.
Ionic vs React Native Analizzando bene questo framework si possono scoprire
alcuni aspetti interessanti.
Prima di tutto, le applicazioni Cordova hanno almeno un grande benefit, ovvero la
possibilità di utilizzare lo stesso codice anche per applicazioni web, modificando in
genere solamente lo stile.
Inoltre, rispetto a React Native, Chrome Developer Tools dà la possibilità di
fare debug sia per le componenti visive sia per il codice JavaScript. Risulta quindi
facile ispezionare ciascun elemento UI a run time e provare instantaneamente
diverse modifiche. Questo può essere fatto sia simulando diverse risoluzioni di
device, sia connettendo un vero dispositivo fisico (sia iOS che Android).
La connessione al dispositivo fisico è stata di vitale importanza durante lo sviluppo,
in quanto ha permesso di testare le funzionalità del Bluetooth e del GPS, altrimenti
non possibili all’interno del browser web.2.3. TECNOLOGIE E STRUMENTI 13
Angular
Angular è una piattaforma ed un framework per la creazione di applicazioni client
in HTML e TypeScript. Angular stesso è scritto in TypeScript. Esso implementa il
suo core e le funzionalità opzionali come un set di librerie TypeScript che vengono
importate all’interno delle applicazioni.
I principali blocchi di costruzione di un’applicazione Angular sono gli NgModules,
che forniscono un contesto di compilazione per le componenti. Un’applicazione ha
almeno un modulo radice che abilita il bootstrapping e tipicamente ha anche molti
altri moduli che forniscono diverse features.
• Le componenti definiscono interfacce, le quali sono set di elementi a schermo
che Angular può scegliere da un insieme e modificarli appositamente sulla
base della logica e dei dati del programma;
• Le componenti utilizzano servizi, che forniscono specifiche funzionalità non
direttamente correlate alle interfacce. I fornitori di servizi possono essere
iniettati nelle componenti come dipendenze, facendo sì che il codice diventi
modulare, riutilizzabile ed efficiente.
Figura 2.4: Funzionamento di Angular
TypeScript
TypeScript è un linguaggio di programmazione libero che ha due obiettivi princi-
pali:
• Fornire un sistema tipizzato opzionale per JavaScript;
• Fornire funzionalità programmate per le future versioni di JavaScript all’engine
JavaScript corrente.
I tipi, introdotti per l’appunto anche da TypeScript, hanno dimostrato di aumentare
la qualità del codice e la sua chiarezza. Nello specifico:14 CAPITOLO 2. CONTESTO STAGE
• I tipi aumentano l’agilità in una fase di refactoring. E’ meglio per il compilatore
catturare gli errori piuttosto che avere fallimenti a fase di runtime;
• I tipi sono una delle forme migliori di documentazione che si possa avere. La
firma della funzione è un teorema, mentre il suo corpo ne è la dimostrazione.
Cordova
Apache Cordova permette di creare applicazioni per dispositivi mobili usando
CSS3, HTML5 e JavaScript invece che basarsi sulle API specifiche per le piattaforme
quali Android, iOS o Windows Phone.
Abilita lo wrapping del codice CSS, HTML e JavaScript in base alla piattaforma
del device in utilizzo, estendendo le funzionalità di HTML e JavaScript in modo
che possano lavorare con il device. Le risultanti applicazioni saranno ibride, ovvero
non sono né vere applicazioni native (perché il rendering del layout viene fatto
tramite le interfacce Web invece che dal framework nativo della piattaforma), né
vere applicazioni Web-based (perché non sono solo delle applicazioni Web, ma sono
impacchettati come applicazioni pronte per la distribuzione che hanno accesso alle
API del device nativo).
Visual Studio Code
Visual Studio Code (VS Code) è un editor di codice sorgente. Supporta un vasto
numero di linguaggi di programmazione e una serie di funzionalità che non sono
esposte attraverso i menu o l’interfaccia utente, ma sono invece accessibili tramite
la palette dei comandi o tramite un file .json (ad esempio, le preferenze dell’utente).
Perché VS Code? Le ragioni principali per cui ho deciso di utilizzare questo
editor piuttosto che altri sono state:
• è un editor leggero ma allo stesso tempo molto veloce;
• la feature Extensions permette di aggiungere una molteplicità di estensioni
che migliorano l’esperienza e la produttività durante la fase di sviluppo. La
possibilità di attivare e disattivare queste estensioni a piacere, permette di
trasformare l’editor in un vero e proprio IDE;
• una volta installato si ha già il supporto necessario per diversi linguaggi come
ad esempio HTML5, TypeScript, CSS, fornendo features quali ad esempio
autocompletamento del codice, controllo di sintassi, debug, source control
(GitHub), etc.2.3. TECNOLOGIE E STRUMENTI 15
Figura 2.5: Visual Studio Code
2.3.1 Ticketing
Figura 2.6: Esempio di utilizzo delle boards di GitHub
Per tenere traccia dei compiti svolti e pianificare quelli successivi, ho utilizzato il
sistema di ticketing offerto da GitHub stesso, GitHub Projects Boards. Questo
tool permette di rappresentare il lavoro ed il suo percorso verso il completamento.
A questo scopo, le tasks sono state suddivise in tre colonne:
• Backlog: upcoming tasks, ovvero compiti in arrivo che dovranno essere svolti
prossimamente;16 CAPITOLO 2. CONTESTO STAGE
• In progress: tasks in progress, ovvero compiti che vengono svolti in questo
momento;
• Done: finished tasks, ovvero compiti già completati in passato.
2.4 Obiettivi
Gli obiettivi definiti per l’attività di stage all’interno del Piano di Lavoro non sono
poi stati quelli realmente pianificati durante il tirocinio. Data la natura molto
dinamica del progetto e della continua esplorazione e scoperta di nuovi requisiti,
alla fine dei conti la maggior parte di essi sono stati cambiati. Di seguito quindi
ci sarà una lista di obiettivi definiti nel tempo, tra i quali ci saranno anche alcuni
inizialmente definiti, principalmente obbligatori.
Agli obiettivi si farà riferimento secondo le seguenti notazioni:
• O: requisiti obbligatori, vincolanti in quanto obiettivo primario richiesto dal
committente;
• D: requisiti desiderabili, non vincolanti o strettamente necessari, ma che
possono portare un valore aggiunto al prodotto;
• F: requisiti facoltativi, che portano un valore aggiunto al prodotto che non è
strettamente competitivo.
Le sigle indicate sopra saranno seguite da una coppia sequenziale di numeri, assieme
ai quali indicheranno il requisito. Si prevede quindi lo svolgimento dei seguenti
obiettivi:
ID Descrizione
Obbligatori
O01 Collegamento sicuro tramite bluetooth al dispositivo nano
O02 Comunicazione bidirezionale tramite bluetooth con il dispositivo
nano
O03 Salvataggio dei dati su DB locale sul dispositivo
O04 Creazione del calendario manuale
O05 Creazione servizio per l’autenticazione degli utenti
O06 Creazione servizio di connessione per il caricamento dei dati tramite
Wi-Fi
Desiderabili
D01 Possibilità di mostrare la posizione su mappa del dispositivo
D02 Possibilità di spostare il pin sulla mappa
D03 Suddivisione dei dispositivi Nano in gruppi
Facoltativi
O01 Supporto multi-lingua
O02 Porting su iOS
Tabella 2.1: Tabella degli obiettivi2.5. ANALISI PREVENTIVA DEI RISCHI 17
2.5 Analisi preventiva dei rischi
Durante la fase di analisi iniziale sono stati individuati alcuni possibili rischi a cui
si potrà andare incontro. Si è quindi proceduto a elaborare delle possibili soluzioni
per far fronte a tali rischi.
Descrizione Piano di emergenza Rischio
Difficoltà nell’appren- Grazie anche all’aiuto del Occorrenza:
dere le tecnologie: è tutor aziendale Massimo Alta
presente il rischio che il Fagotto, verranno analiz- Pericolosità:
tempo speso ad apprendere zate le soluzioni e verran- Media
le nuove tecnologie diventi no prese le decisioni nella
troppo oneroso. I motivi seguente maniera:
principali possono essere
sia la mia scarsa esperien- • se è troppo comples-
za, sia la complessità del so da realizzare, pen-
progetto stesso. sare ad una soluzio-
ne alternativa che sia
efficace allo stesso
modo;
• se non è possibile
raggiungere l’efficien-
za desiderata, dare
priorità all’efficacia.
Framework Ionic non Questo rischio può essere Occorrenza:
utilizzabile : è presen- molto pericoloso e di grave Bassa
te il rischio che le funzio-impatto sul progetto. Per Pericolositàs:
nalità principali richieste prevenire la presenza di un Molto alta
non possano essere imple- rischio simile, si è inizial-
mentabili attraverso il fra-mente accordato per prova-
mework Ionic in quanto non re attraverso un Proof of
ha la possibilità di accede-
Concept le funzionalità es-
re alle funzionalità native senziali ed in caso di esito
obbligatorie. negativo discuterne con il
tutor aziendale ed il resto
del team.
Tabella 2.2: Tabella analisi dei rischi
2.6 Aspettative personali
Prima di questa esperienza non ero ancora venuto a contatto con il mondo dello
sviluppo mobile. L’idea di poter imparare un framework come Ionic ha attirato sin
da subito la mia attenzione, sicchè, tra le diverse opzioni a me proposte dall’azienda
scelsi proprio questa senza battere ciglio.
Il progetto, mi era stato detto, sarebbe stato tuttavia abbastanza complesso e di18 CAPITOLO 2. CONTESTO STAGE difficoltosa implementazione per innumerevoli aspetti. Non nascondo il fatto che mi impauriva anche dover sviluppare alcuni plugin per sopperire alla mancanza di certe funzionalità native di Ionic. Nonostante queste paure, non vedevo l’ora di incominciare ed affrontare questa nuova avventura. Mi era già stato anticipato che avrei dovuto collaborare e confrontarmi con diversi colleghi ingegneri esperti in questo campo, e questo ha alimentato la mia voglia di impare ancor di più, sia lato conoscitivo che collaborativo. Mi aspettavo inoltre che all’interno di un’azienda come Digital Lighting ci fosse un way of working ed un insieme di processi e metologie atte ad aumentare la produttività. In fine, essendo anche la mia prima esperienza lavorativa, una delle mie aspettative era anche quella di riuscire ad imparare a gestire meglio il carico di lavoro sotto scadenze ben definite. 2.7 Aspettative aziendali Digital Lighting è un’azienda giovane ed i loro prodotti sono nati da poco. Il sistema che si basa sulle reti mesh che stanno cercando di mettere in piedi non è ancora stato del tutto implementato e mancano alcuni elementi importanti per il completamento del prodotto e la chiusura del cerchio. Uno di questi elementi è proprio l’applicazione di configurazione da realizzare durante la mia attività di stage. Sin da subito mi era stata accennata la difficoltà di realizzazione di questo progetto. Per questo motivo la loro aspettativa era quella di realizzare un prodotto non neces- sariamente completo, ma piuttosto che potesse permettere di testare i dispositivi in possesso, capire le potenzialità della connessione bluetooth ad essi e di riuscire a configurarli adeguatamente. In fine, per l’azienda è anche un’opportunità per conoscere lo stagista il quale, una volta introdotto al progetto, possa essere preso in considerazione come nuovo dipendente.
Capitolo 3
nanoConfig: primi passi
All’interno di questo capitolo verrà descritto il lavoro da me svolto durante le prime
quattro settimane di stage, corrispondenti allo sviluppo di un Proof of Concept affiancato
dall’implementazione di alcune funzionalità principali.
3.1 Introduzione
Per la prima settimana, il lavoro pianificato era quello di studio delle tecnologie che
poi avrei dovuto utilizzare per realizzare l’applicazione. Dopo i primi due giorni
di studio dei documenti ufficiali, libri e visione di videotutorial, ho capito che il
passo successivo sarebbe stato quello di realizzare un Proof of Concept, attraverso
il quale avrei potuto provare ad implementare le funzionalità essenziali per il lancio
dell’applicazione.
3.2 Perché un PoC ?
Le conoscenze acquisite durante lo svolgimento del progetto di Software Engineering,
mi hanno permesso di analizzare per bene la situazione e prendere una decisione
in questa direzione. Di fatti, per quello specifico progetto, ci era stata richiesta la
costruzione di un PoC, che poi avremmo dovuto mostrare attraverso un colloquio
agile. Quest’esperienza, mi ha fatto capire due questioni molto importanti:
• si tratta di un processo che permette di verificare se certe idee o metodi sono
attuabili o meno. Nel caso di nanoConfig, era inizialmente di vitale importanza
capire se le tecnologie utilizzate, potevano permettermi di implementare le
funzionalità principali;
• di solito viene mantenuto incompleto e di piccole dimensioni per obiettivi che
puntano all’efficienza nell’utilizzo delle risorse, economiche e di tempo. Data
la durata dello stage e la necessità dell’azienda nel fornire nanoConfig ai suoi
clienti, era importante capire subito se ci fosse o meno la presenza di blocchi
tecnologici, per poter agire al più presto e cambiare direzione, qualora fosse
necessario.
1920 CAPITOLO 3. NANOCONFIG: PRIMI PASSI
Figura 3.1: Illustrazione di Proof of Concept
3.3 Obiettivi
A questo punto non restava che parlare con il mio tutor aziendale, il quale mi diede
qualche spunto per quanto riguarda le feature da implementare per il PoC :
• connessione e comunicazione con il dispositivo Nano attraverso bluetooth;
• salvataggio dei dati all’interno di un database locale;
• prova GPS.
3.4 Approccio
Il mio approccio per la realizzazione del Proof of Concept, non è tuttavia stato
quello classico. Invece di ricercare in modo approfondito le tecnologie da utilizzare
e solo poi passare alla realizzazione vera e propria, ho cercato di trovare una via di
mezzo. Questa esigenza è partita dal fatto che i miei colleghi stavano sviluppando
proprio nel frattempo il firmware del dispositivo ed anche loro necessitavano di
alcuni feedback. Questo ha fatto sì che io sviluppassi ad esempio la feature relativa
alla connessione bluetooth (anche se in modo grezzo) subito dopo aver ricercato la
tecnologia richiesta, in modo da aiutare anche i colleghi a capire in quale direzione
andare con lo sviluppo del firmware.3.5. BLUETOOTH LOW ENERGY 21
3.5 Bluetooth Low Energy
Il Bluetooth Low Energy (BLE) è una tecnologia che viene nativamente supportata
da praticamente tutti i sistemi operativi mobili e non. Rispetto al Bluetooth Classico
offre un consumo ridotto mantenendo un range di comunicazione simile. Il BLE
permetterà a nanoConfig di connettersi al dispositivo Nano e comunicare con esso,
mandando e ricevendo messaggi.
Per poter accedere alle funzionalità native offerte dal dispositivo, bisogna sfrut-
tare Cordova. L’applicazione verrà eseguita all’interno di wrappers che mirano a
determinate piattaforme (come ad esempio Android o iOS) e che permetteranno di
accedere a ciascuna funzionalità del dispositivo come ad esempio bluetooth, local
storage e geolocalizzazione.
3.6 Ionic Native
Ionic Native è il wrapper TypeScript per i plugin di Cordova che viene utilizzato
da Ionic. Esso è un grande insieme di plugin mantenuti dalla comunità e, nono-
stante questa sia molto veloce nel trovare e correggere i problemi riscontrati, alcuni
plugin non funzionano correttamente, fatto che fa perdere diverso tempo durante
lo sviluppo.
Il plugin che ho utilizzato per comunicare con il dispositivo Nano è stato BLE1 .
3.7 Sicurezza
Una volta implementata la feature di scanning dei dispositivi nelle vicinanze, stando
attento a mostrare solamente i dispositivi Nano, io ed il mio collega che si occupava
della parte firmware, ci siamo posti la domanda se la connessione fosse realmente
sicura.
Durante questa analisi, insieme anche al collega esperto in sicurezza, alcuni punti
sono emmersi:
1. un attacco di tipo sniffing può essere concluso con successo dopo un paio di
ore, in base anche alla strumentazione utilizzata;
2. la connessione ad un dispositivo Nano non durerà più di qualche minuto, in
quanto la configurazione dovrà essere molto veloce;
3. perché possa fare sniffing, il malintenzionato dovrà essere posto nelle vicinanze
e dovrà seguire l’utente, fatto che potrebbe renderlo più visibile e quindi
vulnerabile;
4. i dati che potrà raccogliere saranno di non troppa rilevanza, in quanto al
massimo riuscirà a raccogliere informazioni sul calendario configurato.
1
https://github.com/don/cordova-plugin-ble-central22 CAPITOLO 3. NANOCONFIG: PRIMI PASSI
Detto ciò, siamo arrivati alla conclusione che un livello di sicurezza maggiore non
sarebbe strettamente necessario, in quanto, anche se un malintenzionato riuscisse
a sniffare i dati, questi non sarebbero tanto sensibili. Tuttavia, è anche vero che
questi dispositivi sono modulari ed in futuro non è detto che non possano essere
implementate funzionalità (ad esempio videosorveglianza) che si nutrono di dati
sensibili. Per tale motivo è stato deciso che sarebbe comunque stato necessario
implementare un ulteriore stratto di sicurezza (oltre quello già presente nella
tecnologia stessa).
Figura 3.2: Pagina di visualizzazione dei dispositivi trovati
3.7.1 AES-JS
Dopo alcune ricerche mi sono imbattuto nella libreria AES-JS2 scritta in JavaScript
puro, la quale implementa l’algoritmo AES Block Cipher e tutte le sue modalità
di operazione più comuni, tra le quali anche CBC (Cipher-Block Chaining)3 .
La procedura per la connessione sicura viene effettuata nella seguente maniera:
1. Prima di tutto verrà eseguito il pairing;
2. Avviene poi la connessione automatica tra i due dispositivi, della quale si
occuperà il plugin BLE;
3. In questo momento, il dispositivo Nano rifiuterà qualsiasi tipo di comando
inviato dall’applicazione. Bisognerà quindi effettuare la connessione sicura;
2
https://github.com/ricmoo/aes-js
3
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation3.8. SALVATAGGIO DATI 23
4. Il dispositivo Nano invierà all’applicazione una chiave in chiaro valida so-
lamente per la sessione in corso. Non ci interessa che il malintenzionato
ottenga la chiave, in quanto gli mancherà sempre un pezzo del puzzle, ovvero
il vettore di inizializzazione (predefinito);
5. L’applicazione cripterà un messaggio (predefinito) utilizzando la chiave for-
nitagli assieme al vettore d’inizializzazione, e la stringa risultante verrà
spedita indietro al dispositivo Nano;
6. Il dispositivo controllerà che la stringa ricevuta sia identica a quella che lui
stesso ha calcolato. Se il controllo va a buon fine, allora la connessione viene
effettuata e l’applicazione potrà quindi inviare qualsiasi comando. In caso
contrario, avviene una disconnessione.
Figura 3.3: Pagina dove la connessione è avvenuta con successo al dispositivo (risultato
finale)
3.8 Salvataggio dati
Una volta che il dispositivo mobile è connesso al Nano, l’utente dovrà cercare di
ricavare le informazioni necessarie e salvarle all’interno del dispositivo fin quando
non avrà finito il giro di configurazione.
Per fare ciò, Ionic Native offre due principali scelte:
1. SQLite4 ;
4
https://github.com/litehelpers/Cordova-sqlite-storage24 CAPITOLO 3. NANOCONFIG: PRIMI PASSI
2. Native Storage5 .
Prima di andare a scegliere quale plugin utilizzare, ho cercato di capire per bene il
contesto applicativo ed alcuni interessanti spunti sono sorti:
• Una volta che l’utente avrà finito il giro ed avrà caricato i dati, questi ultimi
non serviranno più all’interno dello storage locale, e quindi potranno essere
eliminati. Ciò significa che lo spazio a disposizione per salvare i dati della
sessione corrente, non dovrà essere troppo ampio e basteranno probabilmente
poche centinaia di Kilobyte;
• I dati che verranno poi salvati saranno degli oggetti, i quali avranno un
determinato model. Tornerebbe quindi molto utile usuffruire di un plugin
che permetta semplicemente di salvare l’oggetto così com’è, e recuperarlo allo
stesso modo.
Analizzando bene i due plugin sopra citati all’interno della documentazione ufficiale
e l’articolo scientifico Assessment of Data Storage Strategies Using the
Mobile Cross-Platform Tool Cordova 6 sono arrivato alla conclusione che
Native Storage sarebbe stata la scelta migliore da adottare. All’interno del
capitolo successivo si potrà vedere come questa scelta sia stata la più azzeccata.
3.8.1 Test
Per testare il plugin in questione, ho deciso di realizzate un service Provider 7 ,
chiamato Storage. Aggiungendolo globalmente alla componente root, viene creata
un’unica istanza condivisa tra tutte le componenti. Se invece questo provider
viene fornito ad una componente individuale, allora una nuova istanza verrebbe
creata, specifica per quella componente.
5
https://github.com/TheCocoaProject/cordova-plugin-nativestorage
6
https://thinkmind.org/download.php?articleid=mobility_2017_2_10_90007
7
https://angular.io/guide/providers3.9. GEOLOCALIZZAZIONE 25
Figura 3.4: Funzionamento di un servizio in Ionic
All’interno di questo storage salvavo semplicemente i dati relativi al dispositivo
connesso, sotto forma di oggetto, che poi facevo visualizzare all’interno di una
componente pagina chiamata Laboratory, utilizzata poi anche per altri scopi.
E’ stata molto importante come prova in quanto mi ha fatto capire che stavo
andando nella direzione giusta per quanto riguarda la scelta del plugin. Chiudendo
l’applicazione, o anche solo cambiando pagina, i dati erano persistenti. Solamente
dopo una disinstallazione il Local Storage viene svuotato, insieme a tutti i dati.
3.9 Geolocalizzazione
Per ricavare le coordinate geografiche del dispositivo e salvarle all’interno del local
storage, ho utilizzato il plugin Geolocation8 , inserito all’interno di un service
provider, come per lo storage. Tuttavia, nonostante poi i risultati siano arrivati,
ho riscontrato molti problemi nella configurazione e nell’utilizzo di questo plugin.
Uno fra questi è l’impossibilità di fare debug nella modalità livereload, che mi avreb-
be permesso di cambiare il codice e vedere i risultati in real time sul dispositivo,
senza dover attendere che l’applicazione venisse rebuildata. Questo problema è
dato dal fatto che la modalità livereload funziona in modalità HTTP (HyperText
Transfer Protocol) e non HTTPS (HyperText Transfer Protocol over Se-
8
https://github.com/apache/cordova-plugin-geolocation26 CAPITOLO 3. NANOCONFIG: PRIMI PASSI
cure Socket Layer), che è invece l’unica modalità accettata per poter accedere
alla posizione del dispositivo, per motivi di privacy.
3.9.1 Test sul campo
All’interno del Laboratory, ho inserito una mappa, usando il plugin Google
Maps9 , dove viene mostrato il pin corrispondente alla posizione attuale. Tuttavia,
dopo numerosi test, mi sono accorto che la posizione registrata non era molto
precisa, nonostante l’applicazione fosse configurata con un valore per la precisione
impostato al massimo possibile. Nemmeno testando con altri dispositivi mobili la
situazione migliorò. Ho notato poi che l’edificio era principalmente costituito di
metallo, fatto che molto probabilmente incideva sulle prestazioni della geolocalizza-
zione. Ho deciso quindi di fare dei test outdoor.
All’esterno, tuttavia, la situazione non migliorò molto. Di fatti, dopo numerosi
test, l’errore riscontrato si aggirava intorno ai 20 metri, tranne in alcuni rari
casi nei quali il risultato era molto vicino alla posizione reale. Per risolvere questo
problema, si è quindi pensato di far sistemare manualmente la situazione all’utente.
Quest’ultimo, potendosi orientare in base ai punti di riferimento attorno, potrà
spostare attraverso l’azione DRAG il pin nella posizione desiderata.
9
https://github.com/ionic-team/ionic-native-google-maps/blob/master/
documents/README.mdCapitolo 4
nanoConfig: sviluppo avanzato
All’interno di questo capitolo verrà descritto il lavoro da me svolto durante le ultime
4 settimane di stage, corrispondenti al perfezionamento delle feature sviluppate nella
prima fase e alla realizzazione di quelle restanti.
4.1 Introduzione
Dopo aver compreso che le principali funzionalità potevano essere implementate,
il passo successivo sarebbe stato quello di riprendere in mano quanto realizzato
nella prima fase e ottimizzare il codice scritto. Questo lavoro è stato fatto durante
la prima settimana di questa fase, assieme alla creazione del service riguardante
l’autenticazione e all’aggiunta di un algoritmo per il recupero delle coordinate
precise di un dispositivo da un database. Le due settimane successive le ho invece
impiegate per la creazione del calendario, componente tanto importante quanto
difficile da implementare. L’ultima settimana è stata invece dedicata alla creazione
delle pagine relative alla sessione, al master, al dispositivo Nano e ad alcune altre
modifiche.
4.2 Autenticazione
L’API relativa a questa funzionalità verrà sviluppata dal mio tutor aziendale nella
fase finale dell’applicazione, successiva al mio periodo di stage. In attesa di questa
implementazione, tuttavia, mi era stato anche chiesto di trovare un’alternativa alla
realizzazione di un’API standard, analizzando per bene Auth01 .
4.2.1 Auth0
L’unico modo per analizzare per bene la situazione in questi casi è quello di provare
ad implementare la funzionalità all’interno della propria applicazione. Mezz’ora
dopo, l’applicazione avrebbe avuto un sistema di autenticazione molto sicuro con
1
https://auth0.com/
2728 CAPITOLO 4. NANOCONFIG: SVILUPPO AVANZATO
un database facilmente gestibile all’interno della piattaforma Auth0, lasciando sia
me che il mio tutor aziendale colpiti. La semplicità di configurazione e di gestione
non vengono tuttavia gratuitamente, in quanto Auth0 offre un piano gratuito
solamente per quanto riguarda l’autenticazione (entro certi limiti); se si volesse far
gestire il database di utenti al cliente, come in questo caso, bisognerebbe sborsare
un certo ammontare di soldi, proporzionato alla quantità di utenti.
I costi per sviluppare e manutenere invece una propria API sono molto bassi e
discutendone con il tutor abbiamo deciso che non ne vale la pena di lasciare la
strada principale, e di continuare invece a sviluppare un’autenticazione standard.
4.2.2 Ritorno alle origini
Dopo questa analisi, ho codificato quindi la pagina relativa all’autenticazione ed
aggiunto un nuovo service il cui compito è quello di connettersi all’API (che il tutor
andrà a sviluppare successivamente) ed inviare richieste riguardanti l’autenticazione.
Figura 4.1: Pagina con form di autenticazione4.3. ALGORITMO PER LA GEOLOCALIZZAZIONE 29
4.3 Algoritmo per la geolocalizzazione
L’applicazione avrà accesso tramite un API ai dati relativi a tutti i dispositivi posi-
zionati sui pali durante la fase di installazione. Tra questi dati ci saranno un nome
identificativo del dispositivo, le coordinate geografiche (latitudine e longitudine) ed
una serie di altri dati.
L’utente non può conoscere però il nome identificativo del dispositivo a
cui è connesso al momento, in quanto è stato scelto in una fase di progettazione,
successiva a quella di costruzione del dispositivo. Di fatto, questo è uno degli scopi
dell’applicazione; fare l’associazione del dispositivo a cui si è connessi con
uno presente all’interno del database dell’azienda.
Ma come viene risolto il problema? Come si può associare il dispositivo ad
uno presente nel database senza saperne il nome?
4.3.1 "Dove mi trovo?"
Per risolvere il problema, l’utente dovrà prima di tutto abilitare la geolocalizzazione
nelle impostazioni del telefono cellulare. Successivamente potrà premere un pulsante
che recupererà latitudine e longitudine della sua posizione attuale. Trovandosi in
prossimità del palo, significa che le coordinate della sua posizione saranno molto
simili alle coordinate del dispositivo installato su quel palo. Se così non fosse, egli
avrà la possibilità di spostare manualmente il pin all’interno della mappa per far
coincidere le coordinate con la vera posizione.
Verrà poi fatto un confronto con le coordinate dei vari dispositivi presenti nel
database ed associare a quello a cui si è connesso, il dispositivo con le coordinate
prossime a quelle della sua posizione, utilizzando una soluzione trovata online2
adattata all’esigenza.
4.4 Calendario
Il passo importante successivo è stato la creazione del calendario, il cuore pulsante
dell’applicazione. Durante lo sviluppo di questa funzionalità ho riscontrato la
maggior quantità di problemi con il framework Ionic in generale.
Andiamo prima a vedere in dettaglio la schermata visualizzata:
2
https://gist.github.com/Thibaut-B/56071bcc8207fa11be90Puoi anche leggere
