Alma Mater Studiorum · Universit`
a di Bologna
SCUOLA DI SCIENZE
Corso di Laurea in Informatica Triennale
Un’applicazione mobile per il monitoraggio
della qualit`
a del servizio
di trasporto ferroviario
Tesi di Laurea in Architettura degli elaboratori
Relatore:
Chiar.mo Prof.
Vittorio Ghini
Presentata da:
Luca Rinaldi
Sessione II
Anno Accademico 2012/2013
Introduzione
La scarsa qualit`a del servizio di trasporto ferroviario, in Italia, `e sotto gli occhi di tutti i viaggiatori. Sono state fondate vere e proprie associa-zioni di pendolari per protestare contro il servizio offerto ai cittadini. Que-ste lamentele riguardano soprattutto i continui ritardi (e soppressioni), il sovraffollamento e la scarsa pulizia dei treni regionali.
Sono un viaggiatore pendolare da qualche anno e ho un’esperienza diretta sull’argomento. Mi `e capitato spesso di vedere treni semi-vuoti alternati a treni sovraffollati, in cui era difficile persino salire. Mi `e anche capitato di assistere a ritardi annunciati solo all’ultimo minuto, costringendo i viaggia-tori a rimanere in attesa sulla banchina. Questi disagi possono convincere i viaggiatori ad utilizzare altri mezzi, spesso meno economici e pi`u inquinanti. In questa tesi cerco di utilizzare l’informatica per realizzare uno strumento di supporto al viaggiatore ferroviario.
Il progetto che illustro in queste pagine `e una applicazione mobile per Android, della quale descrivo: gli obiettivi che cerca di soddisfare (cap. 1), gli strumenti utilizzati per realizzarla (cap. 2), la sua progettazione (cap. 3), la sua implementazione (cap. 4), la guida per utilizzarla e le prove sperimentali effettuate (cap. 5).
Indice
Introduzione i
1 Scenario e obiettivi 1
2 Strumenti di sviluppo 5
2.1 Sviluppo lato client . . . 6
2.1.1 Android . . . 6
2.2 Sviluppo lato server . . . 8
3 Progettazione 11 3.1 Idea iniziale . . . 11 3.2 Caratteristiche . . . 13 3.3 Funzionamento . . . 14 3.4 Scelte progettuali . . . 17 3.5 Algoritmi utilizzati . . . 19 4 Implementazione 21 4.1 Programmazione server . . . 21 4.1.1 Database . . . 21 4.1.2 PHP . . . 23 4.2 Programmazione client . . . 26 4.2.1 Metadati . . . 27 4.2.2 Service . . . 29 4.2.3 Activity . . . 35 iii
iv INDICE
5 Valutazione 39
5.1 Guida all’uso . . . 39 5.2 Prove sperimentali . . . 45
Conclusioni e sviluppi futuri 47
Elenco delle figure
1.1 Trenitalia: qualit`a del viaggio . . . 1
2.1 Vendite smartphone in Italia . . . 6
2.2 Diagramma del server . . . 9
3.1 Schema della rete globale . . . 11
3.2 Sistema delle coordinate nelle API Android . . . 19
5.1 Guida - menu iniziale . . . 39
5.2 Guida - informazioni dispositivo . . . 40
5.3 Guida - lista dei viaggi . . . 41
5.4 Guida - visualizzazione dati automatici . . . 42
5.5 Guida - visualizzazione dati manuali . . . 43
5.6 Guida - valutazione manuale . . . 44
5.7 Monitoraggio - posizione seduta . . . 46
5.8 Monitoraggio - posizione in piedi . . . 46
Capitolo 1
Scenario e obiettivi
Scenario
Figura 1.1: Sondaggi Trenitalia sulla qualit`a della permanenza a bordo
Analizzando il sondaggio1 in figura 1.1 si pu`o notare come la
soddisfa-zione dei viaggiatori ferroviari verso il servizio offerto sia piuttosto scadente, soprattutto per quanto riguarda il trasporto regionale (e quindi i treni che utilizzano prevalentemente i pendolari ). Questo si pu`o anche osservare dalla presenza di numerosi comitati locali e associazioni di pendolari (i pendolari in Italia sono circa 2 milioni), nati per protestare contro la scarsa qualit`a del servizio ferroviario italiano (bib. [2]).
1Vedi bibliografia [1].
2 1. Scenario e obiettivi
Questa tesi `e stata fatta per cercare di migliorare la qualit`a del servi-zio ricevuto, offrendo ai viaggiatori dei dati in tempo reale sulla situaservi-zione del treno che vorrebbero utilizzare. Prima di avanzare `e meglio offrire una panoramica sui principali problemi riscontrati dai viaggiatori ferroviari:
• I treni sono spesso in ritardo e questo, nella maggior parte dei casi, viene segnalato solo pochi minuti prima dell’orario ufficiale di arrivo del treno. Un treno pu`o essere in ritardo per i seguenti motivi:
– Scarsa organizzazione del personale;
– Condizioni meteorologiche particolari (neve, freddo, grandine, . . . ); – Presenza di altri treni in ritardo sulla linea;
– Incidente sulla linea;
– Malfunzionamento del treno;
– Attesa eccessiva dovuta alla discesa e alla salita dei viaggiatori sul treno.
In alcuni casi, un eccessivo ritardo del treno pu`o causare la sua sop-pressione. Naturalmente il ritardo improvviso del treno causa non po-chi disagi ai pendolari, che sono costretti ad arrivare in ritardo ad appuntamenti o esami.
• La scarsa pulizia della carrozza e dei bagni, oltre che al fattore igienico, pu`o dare fastidio a molti viaggiatori (soprattutto quelli occasionali) e far preferire l’utilizzo di altri mezzi (come l’automobile) per arrivare a destinazione.
• Il sovraffollamento dei treni `e molto frequente in certe fasce orarie, so-prattutto nel fine ed inizio settimana. Non solo il viaggiatore non trova il posto a sedere, ma in certi casi pu`o fare addirittura fatica ad entrare nel treno (una delle cause del ritardo del treno) per via dell’eccessivo numero di persone presenti a bordo. Viaggiare in queste condizioni non `e solo poco gradevole, ma `e anche pericoloso. Il sovraffollamento
3
`e dovuto soprattutto alla chiusura di certe carrozze del treno e ad un numero non previsto di passeggeri.
Obiettivo principale
L’obiettivo principale di questa tesi `e creare una applicazione mobile per Android che, attraverso l’utilizzo dei sensori presenti nel dispositivo, valuti automaticamente la qualit`a del servizio offerto al viaggiatore ferroviario.
Obiettivo secondario
L’obiettivo secondario `e offrire agli utenti la possibilit`a di valutare per-sonalmente e manualmente la qualit`a il viaggio. Attraverso questa funzio-nalit`a `e possibile offrire agli utenti un rapporto sulle qualit`a non valutabili automaticamente, come ad esempio la pulizia del treno.
Utilit`
a
La qualit`a del servizio viene trattata sotto diversi punti di vista:
Comfort del viaggiatore Durante la sua permanenza sul treno, special-mente per quanto riguarda i viaggi di lunga percorrenza, il viaggiatore si dovrebbe sentire a proprio agio. Il comfort del cliente `e pi`u alto se trova un posto a sedere e se l’ambiente `e pulito.
Puntualit`a Il viaggiatore preferisce scegliere un treno puntuale per il suo viaggio. Per quanto riguarda i treni regionali, i ritardi vengono spesso segnalati all’ultimo minuto e il pendolare non ha alcun modo di saperlo in anticipo, se non mettendosi in contatto telefonico con chi `e gi`a sul treno. Se un treno rimane fermo a lungo o ha una velocit`a media infe-riore al solito, allora `e probabile che questo sia la causa di un eventuale ritardo del treno o che sia la conseguenza di un suo malfunzionamento.
4 1. Scenario e obiettivi
Numero di persone a bordo Un grande problema del viaggiatore pendo-lare `e il sovraffollamento dei treni. Pu`o essere utile alla societ`a ferrovia-ria capire in dettaglio in quali giorni il numero delle persone a bordo del treno supera notevolmente la sua effettiva capacit`a. In questo modo la societ`a pu`o decidere eventualmente di aumentare il numero di carrozze del treno o di sostituirlo con un altro solo in quegli orari.
I dati ottenuti dal monitoraggio hanno un duplice scopo:
1. Permettere al viaggiatore di essere informato sulla qualit`a dei treni disponibili per effettuare un determinato viaggio, in modo da poter scegliere quello che offre un servizio di qualit`a maggiore.
2. Incentivare la societ`a ferroviaria all’aumento della qualit`a del servizio offerto, tenendo anche conto dei giudizi espressi dai propri clienti. Aumentare la qualit`a del servizio di trasporto ferroviario potrebbe inoltre spingere il cittadino all’utilizzo dei mezzi pubblici, riducendo di conseguenza il traffico e l’inquinamento dovuti all’utilizzo di automobili.
Capitolo 2
Strumenti di sviluppo
In questo capitolo vengono trattati in dettaglio gli strumenti software utilizzati per lo sviluppo dell’applicazione.
Per la realizzazione dell’applicazione ho utilizzato: • Eclipse Juno (versione 4.2);
• Plugin ADT (versione 22.0.5) per Eclipse;
• Apache HTTP Server (versione 2.22).
• Modulo PHP5 per Apache, con estensione PDO. • MySQL (Oracle).
La tesi `e si pu`o dividere in due principali sezioni. La prima sezione `e la parte client, che `e quella relativa all’applicazione per Android (vedi par. 2.1); la seconda sezione `e quella relativa al server, ovvero la gestione del database (vedi par. 2.2). La rete creata `e composta da un server centrale e da numerosi client (smartphone, tablet, . . . ), che comunicano con esso.
6 2. Strumenti di sviluppo
2.1
Sviluppo lato client
In questo paragrafo vengono analizzati i principali strumenti di sviluppo utilizzati a lato client.
2.1.1
Android
Android `e un sistema operativo di Google per dispositivi mobili. Si di-stingue dagli altri per il fatto di essere open source (Licenza Apache1) e di
basarsi sul kernel 2.6 di Linux (kernel 3.x da Android 4.0 in poi).
Ho scelto di sviluppare l’applicazione su Android per puntare ad una fetta di utenti pi`u alta: infatti, come si pu`o notare dalla figura 2.1, in Italia (e anche nella maggior parte degli altri Paesi) le vendite di smartphone Android sono in continua crescita, mentre la concorrenza subisce dei rallentamenti.
Figura 2.1: Vendite degli smartphone in Italia nel mese di giugno (bib. [4])
Programmare in Android
Lo strumento principale che si utilizza `e Eclipse , un ambiente di sviluppo integrato (IDE2) utilizzato per lo sviluppo di software con diversi linguaggi di programmazione.
1La Licenza Apache consente agli utenti di distribuire e modificare il software,
utilizzandolo per ogni possibile scopo.
2.1 Sviluppo lato client 7
Eclipse `e incentrato sull’utilizzo di plugin . Quello relativo ad Android si chiama ADT (Android Developer Tools, bib. [3]) e offre funzionalit`a in pi`u rispetto a quelle normalmente offerte da Eclipse, che permettono il test e lo sviluppo di applicazioni Android. Tra queste troviamo:
• IDE Java completo, che comprende:
– Template di base per creare progetti e componenti Android; – Editor XML migliorato e navigazione integrata tra JAVA e le
risorse XML;
• Possibilit`a di modificare l’interfaccia grafica attraverso il semplice “drag and drop”;
• Possibilit`a di emulare un dispositivo virtuale (personalizzabile) per eseguire il test dell’applicazione;
• Possibilit`a di eseguire il test dell’applicazione su un dispositivo reale, attraverso un cavo USB.
Oltre al plugin ADT `e necessario installare anche Android SDK , ovvero le librerie API e gli strumenti necessari per lo sviluppo di applicazioni Android. Per iniziare a scrivere una applicazione Android `e necessario conoscere le basi di Java e XML. Una applicazione Android `e infatti formata principal-mente da due elementi: il codice e le risorse. Il codice `e scritto in Java e le risorse3 sono composte nella maggior parte dei casi da file XML.
La divisione tra codice e risorse `e presente per tre motivi: il primo motivo `e separare il come dal cosa, ovvero separare la presentazione dei dati (layout) dalla loro effettiva gestione.
Il secondo motivo `e sicuramente pi`u funzionale: dare la possibilit`a di sce-gliere tra diverse risorse in base alle configurazioni del dispositivo in cui `e installata l’applicazione. Nell’applicazione che ho sviluppato, ad esempio,
8 2. Strumenti di sviluppo
sono presenti due file string.xml, uno contenente le stringhe in inglese e l’al-tro contenente le stringhe in italiano; verr`a selezionato automaticamente (a runtime) il file giusto in base alla lingua impostata nel dispositivo (in caso di altre lingue selezionate verr`a selezionata di default quella inglese).
Il terzo e ultimo motivo della divisione tra codice e sorgente `e il fatto che la ricompilazione del codice viene fatta solo quando questa risulta stretta-mente necessaria. Se per esempio volessi aggiungere una terza lingua alla mia applicazione, potrei creare un nuovo file string.xml e metterlo nel percorso /res/values-xx/ dell’apk 4 , dove xx `e il codice di due lettere corrispondente
al linguaggio.
Altri esempi di risorse della la mia applicazione sono i dati relativi agli orari dei treni e i dati relativi alle coordinate delle tratte ferroviare, dei quali parleremo nel capitolo 4.2.1.
2.2
Sviluppo lato server
In questo paragrafo vengono analizzati i principali strumenti di sviluppo utilizzati per il lato server.
Per gestire e memorizzare i dati che ogni client invia al server, faccio uso di MySQL . Oracle MySQL `e un RDBMS (Relational Database Management System) che comprende un client con interfaccia a riga di comando e un ser-ver, che permette l’interrogazione del database da parte di altre applicazioni. Nel paragrafo 4.1.1 `e spiegato in dettaglio l’utilizzo di MySQL nello sviluppo del mio progetto.
Un altro strumento che utilizzo `e Apache HTTP Server con il modulo PHP5 . Apache `e un web server in grado di gestire le richieste HTTP pro-venienti dalla rete ed in particolare la mia tesi gestisce le richieste POST tra applicazione e server. Al modulo PHP ho aggiunto inoltre l’estensione PDO (PHP Data Objects) che mi offre un’unica interfaccia per l’accesso alle basi di dati. In questo modo non sono comunque vincolato all’utilizzo di MySQL
2.2 Sviluppo lato server 9
per la gestione del database, potrei infatti decidere di cambiare DBMS senza comunque modificare gli script PHP.
Grazie alla combinazione di questi strumenti riesco a creare la rete in figura 2.2, dove il senso delle frecce corrisponde al senso delle richieste.
Figura 2.2: Diagramma del server
L’accesso diretto al DBMS diventa dunque disponibile solo agli script PHP sul server Apache, nei quali sono presenti i controlli per evitare eventuali SQL Injection.
Capitolo 3
Progettazione
In questo capitolo `e illustrata la fase di progettazione dell’applicazione. Si parte dunque dall’idea iniziale fino ad arrivare ai dettagli pi`u tecnici.
3.1
Idea iniziale
Figura 3.1: Schema della rete globale
Analizziamo la figura 3.1: a sinistra `e presente un server (PC) che si occupa della gestione dei dati; a destra sono presenti i client, ovvero smart-phone, tablet e altri dispositivi mobili con il sistema operativo Android; sul treno possono esserci anche altri dispositivi Bluetooth, comunque utili per il nostro scopo. Il verso delle frecce indica chi pu`o mandare e chi pu`o ricevere
12 3. Progettazione
i dati rilevati automaticamente. Come si pu`o notare tutti i dispositivi mobili possono ricevere dati, ma solo quelli sul treno possono monitorarli e inviarli al server.
Ecco le prime domande che mi sono posto: 1. Quali strumenti ho a disposizione?
2. Quali tra questi possono essere utili al mio scopo? 3. Quali dati riesco effettivamente a monitorare? 4. Come capisco se un dispositivo `e su un treno?
La risposta alla domanda numero 1 pu`o essere riassunta con “non si sa”. Non so su quale dispositivo l’utente installer`a l’applicazione e ogni dispo-sitivo mobile pu`o anche non avere un determinato strumento utile al mio scopo. Devo dunque costruire un’applicazione che si adatti al dispositivo sul quale `e installata, utilizzando di conseguenza solo gli strumenti effettiva-mente disponibili. Quindi mi devo chiedere: “quali strumenti posso avere a disposizione?”.
Per rispondere a questa domanda ho realizzato una applicazione di prova che visualizza sullo schermo una lista di tutti i possibili strumenti e sensori disponibili all’interno del dispositivo. Provando l’applicazione su pi`u dispo-sitivi di recente uscita ho rilevato i seguenti strumenti: Bluetooth, GPS, sensore di gravit`a, giroscopio, accelerometro, sensore di rotazione, sensore di luminosit`a, sensore di prossimit`a e sensore di orientamento.
Passo dunque a rispondere alle domande numero 2 e 3: uno strumento che certamente mi pu`o essere utile `e il Bluetooth, che mi consente di scansionare l’ambiente circostante in cerca di altri dispositivi e fare dunque una stima sul numero di persone presenti nella carrozza. Tra i sensori disponibili posso invece utilizzare il sensore di prossimit`a e l’accelerometro: combinandoli si ottiene una stima sulla posizione del viaggiatore (in piedi o seduto).
Un altro strumento particolarmente utile `e il ricevitore GPS , che mi calcola la velocit`a del treno e la posizione in coordinate. Utilizzando il GPS
3.2 Caratteristiche 13
riesco a rispondere anche alla domanda numero 4. Considerando il fatto che non posso inviare dati al server se non sono sicuro che questi dati siano stati presi sul treno, allora il GPS diventa un prerequisito per avere la possibilit`a di monitorare automaticamente l’ambiente circostante.
I dettagli pi`u approfonditi sull’utilizzo degli strumenti del dispositivo all’interno dell’applicazione sono al paragrafo 3.3.
3.2
Caratteristiche
Requisiti e caratteristiche dell’applicazione:
• Il livello di API minimo richiesto dall’applicazione `e il 16, che corri-sponde ad Android 4.1 Jelly Bean.
• L’applicazione utilizza solamente i sensori effettivamente disponibili nel dispositivo. Nel caso questi sensori non dovessero essere disponibili, l’applicazione pu`o essere comunque utilizzata per consultare i dati degli altri utenti.
• L’applicazione supporta sia la lingua inglese (di default) che la lingua italiana.
Permessi richiesti:
L’applicazione, prima di essere installata nel dispositivo, richiede i se-guenti permessi:
• Accesso alla rete internet; • Accesso al Bluetooth;
• Accesso alla lettura dei dati proveniente dai sensori all’interno del dispositivo;
• Accesso alla lettura dello stato del dispositivo;
14 3. Progettazione
3.3
Funzionamento
L’applicazione si basa sul rapporto tra i client (applicazioni Android) e il server (database). I dati devono essere raccolti in modo automatico, senza l’intervento dell’utente e per fare questo l’applicazione si divide in 2 parti: ci`o che l’utente vede (foreground o activity) e ci`o che l’utente non vede (background o service). Nei paragrafi successivi sono elencati i compiti delle due parti.
Funzionamento del service
Il service `e la parte dell’applicazione che opera “all’insaputa” dell’utente e si occupa di eseguire un monitoraggio in automatico ogni 20 minuti (ma pu`o comunque essere disattivato manualmente dall’utente). La rilevazione dei dati deve essere effettuata anche quando l’utente ha chiuso l’applicazione (o non l’ha aperta), in modo che il processo di monitoraggio venga avviato anche in assenza di un esplicito consenso da parte dell’utente. Il service viene attivato automaticamente all’accensione del dispositivo, senza richiedere ogni volta il permesso dell’utente (il permesso per avviare il service al termine del processo di boot viene richiesto una sola volta, prima dell’installazione). Una volta che il service `e stato attivato, avvia la procedura di monitoraggio e inizia a verificare la disponibilit`a di una connessione internet (sia WiFi che 3G). Nel caso la rete non sia disponibile, il service termina il monitoraggio.
Se la rete `e disponibile, il service controlla lo stato del ricevitore GPS (o di un dispositivo di geolocalizzazione equivalente). Se il GPS non `e attivo, il service interrompe il monitoraggio. Se il GPS `e attivo, il service esegue 3 geolocalizzazioni a distanza di 2 secondi l’una dall’altra. Se tutte e 3 le scansioni rilevano delle coordinate all’interno di una tratta ferroviaria (vedi paragrafo 4.2.1) , allora il service invia la velocit`a massima rilevata al server e controlla lo stato degli altri strumenti da utilizzare (Bluetooth, sensore di prossimit`a e accelerometro).
3.3 Funzionamento 15
• Se il Bluetooth `e presente ed `e attivo, allora il service effettua in modo asincrono una scansione Bluetooth (tempo medio di 12 secondi). Al termine della scansione, per ogni dispositivo rilevato, invia la coppia <MAC dispositivo utente, MAC dispositivo rilevato> al server.
• Se il sensore di prossimit`a e l’accelerometro sono presenti ed attivi, allora il service calcola se il dispositivo `e in tasca e se l’utente `e seduto o in piedi. Lo stato dell’utente viene inviato al server. Questa rilevazione viene effettuata solamente nel caso che il treno sia in movimento (quindi con velocit`a maggiore di zero).
Al termine del monitoraggio il service mostra all’utente, tramite notifica, quali dati sono stati raccolti e inviati al server. Nel paragrafo 4.2.2 ci sono maggiori dettagli sull’implementazione del service.
Funzionamento dell’activity
L’activity `e quella parte dell’applicazione con cui l’utente pu`o interagire in modo diretto. A differenza del service, l’activity si avvia solo quando l’uten-te apre l’applicazione e si inl’uten-terrompe quando l’ul’uten-tenl’uten-te esce dall’applicazione. In realt`a l’applicazione `e composta da pi`u di una activity: ogni scherma-ta dell’applicazione `e una activity a parte; l’applicazione ha un totale di 5 schermate e quindi di 5 activity.
La prima schermata, quella che compare subito dopo avere avviato l’ap-plicazione, `e il menu iniziale. In questa activity l’utente pu`o attivare o di-sattivare il service (attivo di default), ovvero scegliere di non voler avviare il monitoraggio automatico ogni 20 minuti. Sempre in questa activity l’utente pu`o visualizzare le statistiche relative al dispositivo in uso (ad esempio da quanti treni sono stati raccolti i dati o quanti giudizi manuali sono stati in-seriti). Per accedere all’activity successiva (quella relativa ai viaggi) l’utente deve selezionare il codice del treno sul quale vuole ricevere informazioni. `E possibile anche scegliere una data (nel caso si volessero osservare i dati pas-sati), di default `e comunque selezionata la data attuale. Se `e presente una
16 3. Progettazione
connessione internet, vengono richiesti al server i dati relativi a quel treno e viene visualizzata la schermata successiva.
La seconda schermata contiene una lista dei viaggi relativi al treno se-lezionato. Per ogni viaggio sono indicati: stazione di partenza, stazione di arrivo, orario del viaggio e numero totale di dati raccolti dalla rete. Da questa activity `e possibile passare all’activity di valutazione per valutare un viaggio sulla lista (solo nel caso che siano stati raccolti dati relativi a quel viaggio). Per ogni viaggio `e possibile passare anche all’activity di visualizzazione dei dati.
La terza schermata, quella della valutazione, consente all’utente di dare una propria valutazione manuale ad certo viaggio. In questa schermata `e possibile inviare al server una valutazione (di massimo 3 stelle) su pulizia del treno, disponibilit`a di posti a sedere e puntualit`a del treno. `E inoltre possibile lasciare un commento sul viaggio. Confermando la valutazione, i dati vengono inviati al server e l’applicazione torna all’activity iniziale (menu principale).
La quarta schermata e la quinta schermata sono dedicate alla visualizza-zione dei dati. `E possibile passare da una schermata all’altra semplicemente trascinando l’activity a destra o a sinistra. Nell’activity di sinistra `e presente una lista con i dati monitorati automaticamente:
• Velocit`a media: media delle velocit`a giornaliere per quel viaggio rice-vute dal server, in chilometri all’ora.
• Numero di persone presenti sul treno: numero delle persone rilevate attraverso il Bluetooth, contando solo gli indirizzi MAC distinti dalle coppie <MAC1, MAC2> presenti sul server. Se il numero degli indirizzi MAC rilevati `e inferiore al numero dei dispositivi che hanno inviato i dati al server, allora viene visualizzato quest’ultimo dato.
• Numero di persone in piedi. • Numero di persone sedute.
3.4 Scelte progettuali 17
Nell’activity di destra `e possibile visualizzare la media delle valutazioni glo-bali relative a quel viaggio, compresi gli eventuali commenti rilasciati dagli utenti.
Nel paragrafo 4.2.3 sono presenti i dettagli dell’implementazione delle activity.
3.4
Scelte progettuali
Avvio automatico del service
Per scegliere l’intervallo di tempo che passa tra un monitoraggio e quello successivo si deve tenere conto di alcuni requisiti:
• Meglio non scegliere un intervallo di tempo troppo basso (da 1 a 10 minuti):
Utente sul treno Nella maggior parte dei casi la situazione sul treno non cambia in pochi minuti e risulta inutile inviare al server dei dati simili a quelli inviati pochi minuti prima.
Utente non sul treno Un monitoraggio continuo causerebbe un inu-tile spreco di risorse. Inoltre `e improbabile che un viaggio duri solo pochi minuti, quindi un’eventuale salita su un treno si potrebbe rilevare anche con un intervallo di tempo non troppo basso. • Meglio non scegliere un intervallo di tempo troppo alto (40 o pi`u
minuti):
Utente sul treno La situazione del treno (ad esempio il numero di persone) spesso cambia tra una fermata e l’altra. Scegliendo un intervallo di tempo troppo alto si rischia di non monitorare alcuni cambiamenti essenziali. Per esempio, supponiamo di avere 4 sta-zioni in successione: A,B,C e D. Il tragitto AB dura 30 minuti e il tragitto BC dura 20 minuti. Prendiamo 40 minuti come intervallo di tempo tra un monitoraggio e l’altro. Supponiamo che l’utente
18 3. Progettazione
voglia partire dalla stazione A per arrivare alla stazione D e che il primo monitoraggio si avvii dopo 20 minuti dalla partenza (quin-di al server vengono inviati i dati del tragitto AB). Il successivo monitoraggio avviene dopo 40 minuti e il successivo tragitto non viene considerato: 10 minuti per arrivare a B, 5 minuti di attesa nella stazione B e 20 minuti per arrivare a C. Notiamo come in questo caso il monitoraggio non sia avvenuto nel tratto BC e che quindi gli utenti nella stazione C abbiano ricevuto dei dati pro-babilmente sbagliati (ad esempio non viene calcolato il numero di viaggiatori salito in B, che pu`o essere elevato).
Utente non sul treno Un gran numero di pendolari fa dei viaggi in treno piuttosto brevi; tenendo l’intervallo troppo alto si rischia quindi di non monitorare interi viaggi. Riprendendo l’esempio precedente: supponiamo che l’utente voglia andare dalla stazione A alla stazione B e che primo monitoraggio parta 10 minuti prima della partenza (rilevando l’utente non sul treno). Il successivo monitoraggio avviene dopo 40 minuti, ma la durata del viaggio `
e di soli 30 minuti, quindi il viaggio fatto dall’utente non viene monitorato.
Tenendo presenti i fattori appena elencati ho tenuto come intervallo il tem-po medio di un viaggio (su un treno regionale) tra una stazione e quella successiva: 20 minuti.
Accensione automatica dei sensori
Nelle applicazioni Android, richiedendo i relativi permessi, `e possibile abilitare in modo automatico gli strumenti presenti nel dispositivo (GPS, Bluetooth, . . . ) e la rete internet (connessione dati o WiFi). Ho scelto di non seguire questa strada per due principali motivi:
1. Abilitare in modo automatico tutti i sensori ogni 20 minuti causa un calo significativo del livello di batteria. Questo pu`o essere fastidioso
3.5 Algoritmi utilizzati 19
per l’utente e pu`o portarlo a disinstallare l’applicazione;
2. Anche se l’applicazione viene eseguita in background, deve essere co-munque l’utente ad avere un controllo globale su di essa. Se per esempio l’utente non ha attivato la connessione dati perch´e non vuole spendere soldi, l’applicazione non pu`o attivarla senza il suo consenso.
Per questi motivi lascio che l’applicazione si adatti al dispositivo sul quale `e installata, utilizzando solamente gli strumenti effettivamente a disposizione.
3.5
Algoritmi utilizzati
Per calcolare l’intensit`a delle vibrazioni ricevute dal treno utilizzo i dati ricavati dalle rilevazioni dell’accelerometro.
Figura 3.2: Sistema delle coordinate nelle API Android
Un accelerometro misura le accelerazioni applicate al dispositivo sugli assi (indicati in figuta 3.2), inclusa quella di gravit`a. Quando, per esempio, il dispositivo `e appoggiato su un tavolo, l’accelerometro rileva una accelerazione verso il basso di 9.81 m/s2 (accelerazione gravitazionale). Quando invece il
dispositivo `e in caduta libera, l’accelerazione verso il basso diventa quindi di 0 m/s2. Per questo motivo, per calcolare la reale accelerazione subita
dal dispositivo, devo sottrarre l’accelerazione gravitazionale alle accelerazioni rilevate.
20 3. Progettazione
Il mio obiettivo `e calcolare l’intensit`a delle vibrazioni del treno rilevate dal dispositivo, ovvero la differenza di accelerazione tra un rilevamento e quello successivo. Chiamo xt, yt e zt le tre accelerazioni in figura 3.2 rilevate
all’istante t. Il valore assoluto dell’accelerazione del dispositivo all’istante 0 e all’istante t sar`a data da
a0 = |g| ≈ 9.81m/s2
at=
q
x2
t + y2t + zt2
Nelle accelerazioni at`e sempre inclusa l’accelerazione gravitazionale. Calcolo
ora la differenza tra l’accelerazione all’istante t e l’accelerazione all’istante t − 1:
∆t= at− at−1
Si pu`o notare come ∆1 = a01 sia la reale accelerazione del dispositivo nel
primo istante, dopo aver sottratto l’accelerazione gravitazionale a0. Per le
accelerazioni successive utilizzo la tecnica del high-pass filter , ovvero: a0t= ∆t+ a0t−1∗ α con 0 ≤ α ≤ 1
dove α `e la costante del high-pass filter (il suo valore `e circa 0.9) che d`a pi`u importanza agli improvvisi cambiamenti di accelerazione, utile per individua-re scossoni e/o vibrazioni del tindividua-reno. Le prove sperimentali sull’accelerometro sono riportate nel paragrafo 5.2.
Capitolo 4
Implementazione
Questo capitolo contiene i dettagli dell’implementazione della tesi e le scelte implementative. Nel paragrafo 4.1 ci si concentra sulla parte relativa al server, ovvero quella parte che riguarda la memorizzazione dei dati e la gestione delle richieste provenienti dai client. Nel paragrafo 4.2 ci si concentra invece sull’implementazione dell’applicazione Android e sulla gestione delle risposte del server.
4.1
Programmazione server
La programmazione del server comprende l’implementazione del database (MySQL) e la scrittura degli script PHP che gestiscono le richieste provenienti dai client.
4.1.1
Database
Nel database devo memorizzare solo i dati effettivamente importanti, sen-za occupare spazio per dati inutili e sensen-za rischiare di perdere dati utili a fini statistici.
1 CREATE TABLE VELOCITA ( T r a i n VARCHAR( 1 5 ) , 2 T r a v e l VARCHAR( 1 0 ) ,
3 D e v i c e VARCHAR( 1 0 0 ) ,
22 4. Implementazione
4 TodayDate VARCHAR( 1 5 ) ,
5 Speed VARCHAR( 1 0 0 ) NOT NULL,
6 PRIMARY KEY( Train , T r a v e l , Device , TodayDate ) ) ;
La tabella VELOCITA deve contenere la velocit`a (Speed) rilevata dal di-spositivo (Device) durante il viaggio (Travel) di oggi (TodayDate) sul treno (Train). Se un utente in un giorno rileva pi`u di una velocit`a durante lo stes-so viaggio, allora devo tenere la velocit`a pi`u recente, sovrascrivendo quella precedente.
1 CREATE TABLE BLUETOOTH( T r a i n VARCHAR( 1 5 ) , 2 T r a v e l VARCHAR( 1 0 ) ,
3 Mac1 VARCHAR( 2 0 ) , 4 Mac2 VARCHAR( 2 0 ) , 5 TodayDate VARCHAR( 1 5 ) ,
6 PRIMARY KEY( Train , T r a v e l , Mac1 , Mac2 , TodayDate ) ) ;
La tabella BLUETOOTH contiene gli indirizzi (Mac2) di tutti i dispositivi rilevati dal dispositivo dell’utente (Mac1) sul treno (Train). La scansione `e relativa ad un determinato viaggio (Travel), perch´e tra un viaggio e l’altro il numero di passeggeri pu`o cambiare. Se un dispositivo effettua pi`u scansioni durante lo stesso viaggio, allora devo tenere memorizzati gli indirizzi delle scansioni precedenti e aggiungere eventuali indirizzi nuovi rilevati dall’ultima scansione.
1 CREATE TABLE STATO( T r a i n VARCHAR( 1 5 ) , 2 T r a v e l VARCHAR( 1 0 ) ,
3 D e v i c e VARCHAR( 1 0 0 ) , 4 TodayDate VARCHAR( 1 5 ) ,
5 S t a t u s VARCHAR( 3 0 ) NOT NULL,
6 PRIMARY KEY( Train , T r a v e l , Name , TodayDate ) ) ;
La tabella STATO `e costruita per contenere la posizione (Status) del viag-giatore (Device) durante un viaggio (Travel) sul treno (Train). Se sono state effettuate pi`u rilevazioni in un giorno (TodayDate) sullo stesso viaggio, allora si tiene la rilevazione pi`u recente, sovrascrivendo quelle passate.
4.1 Programmazione server 23
1 CREATE TABLE VALUTAZIONE( T r a i n VARCHAR( 1 5 ) , 2 T r a v e l VARCHAR( 1 0 ) ,
3 D e v i c e VARCHAR( 1 0 0 ) ,
4 S e a t i n g VARCHAR( 5 ) NOT NULL, 5 C l e a n i n g VARCHAR( 5 ) NOT NULL, 6 P u n c t u a l i t y VARCHAR( 5 ) NOT NULL, 7 Comment VARCHAR( 3 0 0 ) ,
8 PRIMARY KEY( Train , T r a v e l , D e v i c e ) ) ;
La tabella VALUTAZIONE si occupa di mantenere i dati immessi manual-mente dall’utente (Device). Un utente pu`o inserire i dati su un viaggio (Tra-vel) solo se ha raccolto precedentemente altri dati relativi a quel viaggio. L’utente pu`o valutare la qualit`a del treno (Train) in base alla pulizia (Clea-ning), ai posti a sedere (Seating) e alla puntualit`a (Punctuality). Inoltre pu`o anche aggiungere un commento (Comment) per evidenziare eventuali lati po-sitivi o negativi del viaggio. Ogni utente pu`o inserire una sola valutazione per ogni viaggio (indipendentemente dalla data), ma pu`o sempre modificare le valutazioni fatte (ad esempio togliendo il commento).
4.1.2
PHP
Gli script PHP gestiscono le richieste dei client e, prelevando i dati dal database, inviano una risposta in formato JSON. Per il collegamento con il DBMS si utilizza l’estensione PDO .
Il collegamento con il DBMS viene fatto nel seguente modo:
1 h e a d e r ( ” c o n t e n t −t y p e : a p p l i c a t i o n / j s o n ; c h a r s e t=UTF− 8 ” ) ; 2 $ r e s p o n s e = array ( ) ; //preparo l a r i s p o s t a
3 $db = new PDO( ” h o s t ; nome d a t a b a s e ; username ; password ” ) ; 4 $db−>s e t A t t r i b u t e (PDO : : ATTR ERRMODE,
5 PDO : : ERRMODE EXCEPTION ) ;
6 $db−>s e t A t t r i b u t e (PDO : : ATTR EMULATE PREPARES, f a l s e ) ;
Come si pu`o notare, utilizzando PDO il codice dello script viene scritto indipendentemente dal DBMS utilizzato.
24 4. Implementazione
Inserimento di dati nel database
1 //Controllo l a correttezza d e l l a r i c h i e s t a del c l i e n t
2 i f ( i s s e t ( $ POST [ ” devname ” ] ) 3 and i s s e t ( $ POST [ ” s p e e d ” ] ) 4 and . . . ) ) {
5 //Prelevo i dati d a l l a r i c h i e s t a POST
6 $devname = $ POST [ ” devname ” ] ; 7 $ t r a v e l i d = $ POST [ ” t r a v e l i d ” ] ; 8 $ c o d e = $ POST [ ” t r a i n c o d e ” ] ; 9 . . . 10 t r y { 11 $ s t a t e m e n t = $db−>p r e p a r e ( ”REPLACE INTO 12 t a b e l l a VALUES ( ? , ? , . . . ) ” ) ;
13 $ s t a t e m e n t −>e x e c u t e ( array ( $code , $ t r a v e l i d , . . . ) ) ; 14 $ r e s p o n s e [ ” s u c c e s s ”]=” t r u e ” ;
15 }
16 /∗In caso di errore i n v i o l a sua d e s c r i z i o n e
17 con $response [ ” success”]=” f a l s e ” ∗/
18 . . .
19 echo j s o n e n c o d e ( $ r e s p o n s e ) ;
I dati da inserire vengono passati al server attraverso la richiesta POST di HTTP. Lo script utilizza PDO per inserire questi dati nel database e risponde al client con un file JSON cos`ı formato:
1 {
2 ”success” : <”true” o ” f a l s e ”>
3 }
Richiesta di dati al database
1 i f ( i s s e t ( $ POST [ ” t r a i n ” ] ) 2 and i s s e t ( $ POST [ ” d a t e ” ] ) ) { 3 t r y {
4.1 Programmazione server 25
5 $ d a t e = $ POST [ ” d a t e ” ] ;
6 $stmSpeed = $db−>p r e p a r e ( ”SELECT ∗ FROM VELOCITA
7 WHERE T r a i n=? AND Date = ? ” ) ;
8 $stmSpeed−>e x e c u t e ( array ( $ t r a i n , $ d a t e ) ) ;
9 $rowsSpeed = $stmSpeed−>f e t c h A l l (PDO : : FETCH ASSOC ) ; 10 $ r e s p o n s e [ ” s p e e d t a b l e ” ] = $rowsSpeed ;
11 //SELECT da a l t r e t a b e l l e
12 . . .
13 $ r e s p o n s e [ ” s u c c e s s ”]=” t r u e ” ;
14 //Controllo s u g l i e r r o r i e stampa del r i s u l t a t o
15 . . .
Il client invia al server il codice del treno e la relativa data in una richiesta POST. Il server deve rispondere con un file JSON cos`ı formato:
1 {
2 ”speed table” : [
3 {
4 ”Train” : <codice del treno>, 5 ”Device” : <id del device>,
6 ”TodayDate” : <data d e l l a r i l e v a z i o n e>,
7 . . . 8 } , . . . 9 ] , 10 ” s t a t u s t a b l e ” : [ . . . ] , 11 ”b t t a b l e ” : [ . . . ] , 12 ”v a l u a t i o n t a b l e” : [ . . . ] , 13 ”success” : ”true” 14 }
Nella risposta del server sono contenuti tutti i dati relativi al codice del treno e alla data passati come parametri.
26 4. Implementazione
4.2
Programmazione client
La programmazione del lato client (applicazione) comprende la gestione dei metadati (orari dei treni e coordinate delle linee ferroviarie), l’implemen-tazione del service (per gestire il monitoraggio) e la struttura delle activity (parte grafica).
Struttura dell’applicazione
Elenco di seguito le principali classi realizzate per l’implementazione del-l’applicazione:
• Activity:
MenuActivity Activity iniziale, adibita all’attivazione manuale del service e alla richiesta dei dati al server;
TravelListActivity Activity che visualizza la lista dei viaggi del treno selezionato;
InfoListActivity FragmentActivity composta da due activity: la pri-ma activity visualizza le inforpri-mazioni rilevate autopri-maticamente relative al viaggio selezionato, la seconda activity visualizza quelle inserite manualmente dagli utenti;
ValuationActivity Activity che consente all’utente di inserire una propria valutazione manuale.
• Service:
MyService Service che si occupa del monitoraggio automatico esegui-to in background.
• Altro:
BluetoothReceiver Receiver che gestisce la scansione Bluetooth e invia i dati al server;
4.2 Programmazione client 27
JSONParser Classe che si occupa del parsing dei file JSON presenti nelle risorse o ricevuti come risposta dal server;
MySensorListener Listener che si occupa della gestione dei sensori (prossimit`a e accelerometro) e invia i dati al server;
InsertXX e GetXX AsyncTask utilizzate per interfacciarsi con il ser-ver;
Travel Classe che contiene i dati relativi ad un viaggio;
Train Classe che contiene i dati relativi ad un treno (compresi i viaggi); TravelInformation Classe che contiene le informazioni monitorate
relative al viaggio selezionato dall’utente.
4.2.1
Metadati
I dati riguardanti le coordinate delle linee ferroviarie e i dettagli di ogni treno sono inseriti nell’apk come risorse e sono divisi in due file JSON : map-pa.json e treni.json. Il primo file contiene le coordinate dei percorsi tra ogni 2 stazioni. Per la struttura di questo file mi sono ispirato ai dati offerti dalle API di Google Maps (bib. [5]), dove per ogni percorso tra due punti vengono presi in considerazione tutti i segmenti che compongono quel percorso. Il file ha quindi la seguente struttura:
1 {
2 ”routes” : [
3 {
4 ”id” : <id route>,
5 ”end location” : {
6 ”name” : <nome stazione di arrivo>,
7 ” l a t ” : <l a t i t u d i n e stazione arrivo>,
8 ”lng” : <longitudine stazione di arrivo>
9 } ,
10 ” s t a r t l o c a t i o n ” : {
28 4. Implementazione
12 ” l a t ” : <l a t i t u d i n e stazione partenza>,
13 ”lng” : <longitudine stazione di partenza>
14 } ,
15 ”steps” : [
16 {
17 ”end location” : {
18 ” l a t ” : <l a t i t u d i n e punto di arrivo>,
19 ”lng” : <longitudine punto di arrivo>
20 } ,
21 ” s t a r t l o c a t i o n ” : {
22 ” l a t ” : <l a t i t u d i n e punto di partenza>,
23 ”lng” : <longitudine punto di partenza>
24 }
25 } , . . .
26 ] } , . . .
27 ] }
La struttura `e una lista di route. Ogni route `e descritta da una stazione di partenza e una stazione di arrivo. Il percorso relativo ad un route `e formato da una lista di step, cio`e dai segmenti che lo compongono. Ogni step `e descritto dalle coordinate dei due punti estremi del segmento che rappresenta. Ad esempio, se un route va da una stazione nel punto A ad una stazione nel punto D, allora gli steps che lo compongono saranno: AB, BC e CD, dove B e C sono i punti dove il percorso cambia direzione (ad esempio nei pressi di una curva).
Il secondo file (treni.json) contiene le informazioni su ogni treno ed ha la seguente struttura:
1 {
2 ” t r a i n s ” : [
3 {
4 ”code” : <codice treno>, 5 ” t r a v e l s ” : [ {
4.2 Programmazione client 29
7 ”min hour” : <ora di partenza>,
8 ”max hour” : <ora di arrivo>,
9 ”route” : <t r a t t a f e r r o v i a r i a percorsa>
10 } , . . .
11 ] } , . . . 12 ] }
La struttura `e una lista di train. Ogni train `e descritto da un proprio codice univoco e da una lista di viaggi travel che quel treno effettua rego-larmente. Ogni travel `e descritto da un orario di partenza, da un orario di arrivo, da un id univoco e dall’id del route corrispondente nel file mappa.json.
4.2.2
Service
Come `e stato illustrato nel capitolo 3.3, il compito del service `e utilizzare i sensori presenti nel dispositivo per effettuare il monitoraggio dei dati da inviare al server. Il service viene chiamato in automatico ogni 20 minuti e deve essere avviato al termine del boot del dispositivo. Per fare questo devo inserire il seguente codice nel AndroidManifest.xml1:
1 < r e c e i v e r 2 a n d r o i d : n a m e=” . B o o t R e c e i v e r ” 3 a n d r o i d : e n a b l e d=” t r u e ” 4 a n d r o i d : e x p o r t e d=” f a l s e ” > 5 <i n t e n t − f i l t e r > 6 <a c t i o n a n d r o i d : n a m e= 7 ” a n d r o i d . i n t e n t . a c t i o n .BOOT COMPLETED” /> 8 </ i n t e n t − f i l t e r > 9 </ r e c e i v e r>
In questo modo viene registrato un receiver che ha il compito di gestire gli intent di tipo BOOT COMPLETED (inviati al termine del processo di boot). Una volta che il receiver ha ricevuto questo intent deve avviare il
30 4. Implementazione
service e programmare l’avvio del monitoraggio ogni 20 minuti a partire da quell’istante.
Considerando che un service pu`o essere automaticamente arrestato da Android in caso di mancanza di risorse e che il service che devo costruire si deve attivare anche con l’applicazione chiusa, mi `e risultato impossibile utilizzare un TimerTask per programmare l’avvio del monitoraggio ogni 20 minuti. Ho optato dunque per l’utilizzo della classe AlarmManager , che offre uno scheduling degli eventi utilizzando i service del sistema, in questo modo il service diventa indipendente dall’applicazione stessa (che pu`o anche essere chiusa).
Per quanto riguarda l’implementazione del monitoraggio, la prima cosa da fare `e assicurarsi che il dispositivo possa connettersi alla rete:
1 public s t a t i c boolean c h e c k C o n n e c t i o n ( Context c t x ) { 2 C o n n e c t i v i t y M a n a g e r cm = ( C o n n e c t i v i t y M a n a g e r ) 3 c t x . g e t S y s t e m S e r v i c e ( Context . CONNECTIVITY SERVICE ) ; 4 N e t w o r k I n f o n i = cm . g e t A c t i v e N e t w o r k I n f o ( ) ; 5 i f ( ( n i != n u l l ) && ( n i . i s C o n n e c t e d ( ) ) ) 6 return true ; 7 e l s e 8 return f a l s e ; 9 }
Se il metodo checkConnection restituisce true, allora il service pu`o inviare i dati al server e pu`o iniziare dunque il processo di monitoraggio.
Il prossimo passo `e trovare il miglior strumento di geolocalizzazione pre-sente nel dispositivo. Se ad esempio il GPS non `e presente o non `e attiva-to, allora posso fare uso del WiFi o di uno strumento meno accurato. Per scegliere lo strumento migliore scrivo queste righe:
1 //LM = Location Manager
2 C r i t e r i a c r i t = new C r i t e r i a ( ) ;
3 c r i t . s e t A c c u r a c y ( C r i t e r i a . ACCURACY FINE ) ;
4 //Prendo un provider a t t i v o con l a migliore accuratezza
4.2 Programmazione client 31
6 i f (LM. i s P r o v i d e r E n a b l e d ( b e s t P r o v ) ) {
7 LM. r e q u e s t L o c a t i o n U p d a t e s ( b e s t P r o v , 2 0 0 0 , 0 , 8 new L o c a t i o n L i s t e n e r ( ) { . . .
Se il provider (GPS) esiste ed `e attivo, allora inizio a monitorare, in modo asincrono, l’aggiornamento dei suoi valori (quando cambiano le coordinate) con un intervallo minimo di 2 secondi tra una scansione e l’altra.
Prelevando le coordinate dagli step del file mappa.json, il service verifica che le coordinate rilevate dal GPS facciano parte di uno degli step. In caso negativo interrompo la scansione del GPS e aspetto la prossima chiamata del service, mentre nel caso positivo attendo la prossima scansione del GPS. Alla terza scansione, se le coordinate rilevate dal GPS fanno ancora parte di uno step, devo inviare la velocit`a rilevata al server. Come `e stato detto nel paragrafo 4.1.1, il database (oltre che alla velocit`a) ha bisogno di: un id univoco del dispositivo, il codice del treno, l’id del viaggio e la data di rilevazione.
1 Calendar a c t u a l d a t e = Calendar . g e t I n s t a n c e ( ) ; 2 //Prendo l a data di oggi n e l l a forma gg/mm/aaaa
3 String d a t e S t r i n g = DateFormat . f o r m a t ( ” dd /MM/ y y y y ” , 4 a c t u a l d a t e ) . t o S t r i n g ( ) ;
5 //Prendo l ’ ora attuale n e l l a forma hh :mm
6 String h o u r S t r i n g = DateFormat . f o r m a t ( ” k k :mm” , 7 a c t u a l d a t e ) . t o S t r i n g ( ) ;
8 //ID univoco del device (TM = TelephonyManager)
9 String d e v i d = TM. g e t D e v i c e I d ( ) ;
Successivamente calcolo l’id del route sapendo in quale step mi trovo. Cono-scendo l’orario e l’id del route riesco a trovare i relativi codice del treno e id del viaggio nel file treni.json.
Se il Bluetooth `e disponibile ed attivo, avvio in modo asincrono il rela-tivo processo di scansione. Il processo di scansione invia in broadcast degli intent di tipo “ACTION FOUND” per ogni altro dispositivo rilevato. Al termine della scansione, mediamente della durata di 12 secondi, il processo
32 4. Implementazione
invia in broadcast un intent di tipo “ACTION DISCOVERY FINISHED” e ferma l’utilizzo del Bluetooth. Per ricevere gli intent devo costruire un BroadcastReceiver che in caso di “ACTION FOUND” mi aggiunga il MAC del dispositivo rilevato in una lista e in caso di “ACTION DISCOVERY FINI-SHED” invii le coppie <MAC dispositivo utente, MAC dispositivo rilevato> al server.
Se la velocit`a rilevata `e maggiore di zero e i sensori sono disponibili e attivi, registro un Listener (handler asincrono) in ascolto sul cambiamento dei valori del sensore di prossimit`a. Il sensore di prossimit`a pu`o assumere due valori: 0 (prossimit`a vicina) e 5 (prossimit`a lontana). Appena ci si mette in ascolto sul sensore, il valore restituito di default `e sempre 5, anche se il dispositivo `e in tasca (quindi con prossimit`a vicina). Il valore 0 pu`o essere restituito solo come secondo valore, nel caso che il dispositivo sia in tasca. Per risolvere questo problema creo un TimerTask della durata di 2 secondi (entro cui sicuramente pu`o arrivare il valore 0): se entro tale tempo il valore 0 `e arrivato, allora il dispositivo `e in tasca, altrimenti non `e in tasca.
1 i s n e a r = f a l s e ; 2 . . .
3 Timer t = new Timer ( ) ;
4 Calendar now = Calendar . g e t I n s t a n c e ( ) ; 5 now . add ( Calendar .SECOND, 2 ) ;
6 t . s c h e d u l e (new TimerTask ( ) {
7 @Override
8 public void run ( ) {
9 i f ( ! i s n e a r )
10 // Dispositivo non in tasca , termino qui
11 }
12 } , now . getTime ( ) ) ;
13 i f ( e v e n t . v a l u e s [ 0 ] != 5 ) 14 i s n e a r = true ;
15 // Dispositivo in tasca , r e g i s t r o un Listener
4.2 Programmazione client 33
Se il dispositivo viene rilevato come “in tasca”, registro un Listener in ascolto sui cambiamenti dei valori dell’accelerometro e faccio un totale di 20 rilevamenti. Considerando l’algoritmo illustrato nel paragrafo 3.5 e le prove sperimentali presentate nel paragrafo 5.2, posso supporre che se l’intensit`a dell’accelerazione rilevata in ognuno dei 20 rilevamenti `e inferiore ad 1, allora l’utente `e in piedi, altrimenti `e seduto.
1 f l o a t a c c e l = 0 . 0 0 f ;
2 f l o a t a c c e l C u r r e n t = SensorManager .GRAVITY EARTH; 3 f l o a t a c c e l L a s t = SensorManager .GRAVITY EARTH; 4 i n t i = 0 ;
5 . . .
6 public void onSensorChanged ( S e n s o r E v e n t e v e n t ) {
7 i ++; 8 a c c e l L a s t = a c c e l C u r r e n t ; 9 f l o a t x = e v e n t . v a l u e s [ 0 ] ; 10 f l o a t y = e v e n t . v a l u e s [ 1 ] ; 11 f l o a t z = e v e n t . v a l u e s [ 2 ] ; 12 a c c e l C u r r e n t = ( f l o a t ) Math . s q r t ( x∗x + y∗y + z ∗ z ) ; 13 f l o a t d e l t a = a c c e l C u r r e n t − a c c e l L a s t ; 14 a c c e l = a c c e l ∗ 0 . 9 f + d e l t a ; 15 i f ( a c c e l >1)
16 //Invio a l server l a posizione ‘ ‘ seduto ’ ’
17 //e termino
18 e l s e i f ( i >= 2 0 )
19 //Invio a l server l a posizione ‘ ‘ in p i e d i ’ ’
20 //e termino
21 }
Dove 0.9 `e la costante del high-pass filter.
Rapporti con il server
Per interagire con il server faccio uso della classe AsyncTask, che mi permette di eseguire una parte di codice in modo asincrono. Come `e stato
34 4. Implementazione
detto nel paragrafo 4.1.2, il server si aspetta dal client delle richieste HTTP di tipo POST. Queste richieste devono contenere i parametri di ricerca o di inserimento, utilizzati poi dal server per eseguire le relative query sul database.
1 List<NameValuePair> v a l u e s =
2 new ArrayList<NameValuePair > ( ) ; 3 v a l u e s . add (
4 new BasicNameValuePair ( ” devname ” , p a r a m e t r o 1 ) ) ; 5 . . .
6 DefaultHttpClient h t t p C l i e n t = new DefaultHttpClient ( ) ; 7 HttpPost h t t p P o s t = new HttpPost ( u r l ) ;
8 h t t p P o s t . s e t E n t i t y (new UrlEncodedFormEntity ( v a l u e s ) ) ; 9 HttpResponse h t t p R e s p o n s e =
10 h t t p C l i e n t . e x e c u t e ( h t t p P o s t ) ;
Nell’ultima riga il client si mette in attesa (sincrona) della risposta del server, per questo motivo le parti relative all’interazione con il server devono essere eseguite in modo asincrono, a differenza del resto del codice.
Parsing dei file JSON
Le risposte del server arrivano al client in formato JSON e inoltre, come illustrato nel paragrafo 4.2.1, il client deve essere in grado di leggere le risorse in formato JSON presenti nell’apk. Per fare il parsing dei file JSON utilizzo le classi JSONArray (JA) e JSONObject (JO). Ad esempio, prendiamo il seguente file JSON:
1 {
2 ”array” : [ . . . ]
3 }
Il file intero `e un JO che comprende un JA chiamato “array”.
Il file mappa.json `e un JO che contiene un JA chiamato “routes” , che contiene a sua volta una serie di JO (i route). Ognuno di questi JO
con-4.2 Programmazione client 35
tiene: una stringa “id”, due JO (“end location” e “start location”) e un JA chiamato “steps”.
Una risposta del server `e un JO che contiene una stringa “success” e tanti JA quante sono le tabelle nel database. Ogni JA contiene un JO per ogni riga di quella tabella restituita dalla query.
4.2.3
Activity
L’implementazione delle activity si divide principalmente in due parti: la parte del layout e la parte della gestione degli eventi. Il layout di una applicazione Android viene scritto in XML ed `e formato da widget . Per esempio, per inserire un bottone in una activity devo inserire nel relativo layout il seguente codice:
1 <Button 2 a n d r o i d : i d=”@+i d / b t n S h o w I n f o ” 3 s t y l e=” @ s t y l e / m y B t n S t y l e ” 4 a n d r o i d : l a y o u t w i d t h=” w r a p c o n t e n t ” 5 a n d r o i d : l a y o u t h e i g h t=” w r a p c o n t e n t ” 6 a n d r o i d : l a y o u t a l i g n P a r e n t B o t t o m=” t r u e ” 7 a n d r o i d : l a y o u t c e n t e r H o r i z o n t a l=” t r u e ” 8 a n d r o i d : l a y o u t m a r g i n B o t t o m=” 38 dp ” 9 a n d r o i d : t e x t=” @ s t r i n g / s h o w I n f o ” />
In questo caso, per inserire il bottone nell’interfaccia grafica ho specificato: id Ogni widget ha un id univoco (“btnShowInfo”) che mi consente di
rife-rirmi a lui in ogni parte dell’applicazione.
style In questo caso ho voluto cambiare lo stile standard del bottone, crean-done uno rosso. “myBtnStyle” `e l’id dello stile corrispondente, creato in un’altra risorsa XML, di nome “style”.
layout I parametri di layout servono per definire la dimensione e la posizione del bottone nell’interfaccia grafica.
36 4. Implementazione
text Il testo contenuto dal bottone `e contenuto nella risorsa string.xml ed ha id “showInfo”.
Per collegare l’activity (MenuActivity.java) al layout corrispondente (activi-ty menu.xml ) devo inserire la seguente riga nell’activi(activi-ty:
1 s e t C o n t e n t V i e w (R . l a y o u t . a c t i v i t y m e n u ) ;
In questo modo riesco a gestire il bottone ricercandolo tramite il suo id:
1 Button btnShowInfo =
2 ( Button ) f i n d V i e w B y I d (R . i d . btnShowInfo ) ;
L’activity chiamata all’avvio dell’applicazione `e definita nel file AndroidMa-nifest.xml con il seguente codice:
1 < a c t i v i t y
2 a n d r o i d : n a m e=”com . p r o j e c t . M e n u A c t i v i t y ” 3 a n d r o i d : l a b e l=” @ s t r i n g / app name ” > 4 <i n t e n t − f i l t e r >
5 <a c t i o n a n d r o i d : n a m e=” a n d r o i d . i n t e n t . a c t i o n .MAIN” /> 6 <c a t e g o r y
7 a n d r o i d : n a m e=” a n d r o i d . i n t e n t . c a t e g o r y .LAUNCHER” /> 8 </ i n t e n t − f i l t e r >
9 </ a c t i v i t y>
Dopo aver definito il layout, posso procedere con la gestione degli eventi. Come `e stato detto nel paragrafo 3.3, il service pu`o essere interrotto ma-nualmente dall’utente. Per fare questo devo creare una relazione tra activity e service, in modo che l’activity possa sapere in qualsiasi momento quando il service `e attivo. Tra i possibili modi per realizzare questo legame, ho scelto di utilizzare la classe SharedPreferences, che consente di memorizzare in modo persistente (e condiviso tra activity e service) delle coppie <chiave,valore> formate da dati primitivi. Durante la creazione del service (metodo “Crea-te”), prima dell’avvio del monitoraggio, memorizzo una SharedPreference <“service attivo”,true>. Nel metodo “Destroy”, invocato subito prima della
4.2 Programmazione client 37
chiusura del service (sia volontaria che involontaria), modifico la SharedPre-ference in <“service attivo”,false>. La persistenza della SharedPreSharedPre-ference garantisce all’activity la possibilit`a di leggere in qualsiasi momento il valore corrispondente alla chiave “service attivo” e, quindi, di verificare quando il service `e attivo.
Per la gestione dei dati provenienti dalle risorse o dalle risposte del server, ho creato le classi Travel, Train e TravelInformation. La creazione di queste classi mi permette di ricavare i dati una sola volta e passarli tra una activity e l’altra, attraverso l’utilizzo degli intent. La classe Travel contiene le infor-mazioni relative ad un singolo viaggio: l’id del viaggio, gli orari, l’id della route corrispondente e le stazioni di partenza e di arrivo. La classe Train contiene le informazioni relative ad un treno: il codice del treno e la lista di Travel che pu`o effettuare. La classe TravelInformation contiene le informa-zioni monitorate durante un viaggio: tutte le velocit`a effettuate, gli indirizzi MAC dei dispositivi Bluetooth rilevati, la posizione degli utenti rilevata dai sensori e le valutazioni manuali fornite dagli utenti. Il codice che segue si riferisce alla richiesta fatta dal client appena l’utente conferma il codice del treno e la data inseriti.
1 //Chiamata asincrona a l server
2 new A s y n c G e t I n f o ( ) {
3 //La chiamata mi r e s t i t u i s c e un oggetto
4 // di tipo TravelInformation
5 protected void
6 o n P o s t E x e c u t e ( T r a v e l I n f o r m a t i o n r e s u l t ) { 7 i f ( r e s u l t != n u l l ) {
8 //Costruisco l ’ intent per chiamare l ’ a c t i v i t y
9 //che contiene l a l i s t a dei v i a g g i
10 Intent i n t e n t =
11 new Intent ( t h i s , T r a v e l L i s t A c t i v i t y ) ;
12 //Aggiungo g l i o g g e t t i di tipo TravelInformation
13 //e Train a g l i extra d e l l ’ intent
38 4. Implementazione 15 i n t e n t . p u t E x t r a ( ” Train ” , s e l e c t e d t r a i n ) ; 16 //Avvio l ’ a c t i v i t y corrispondente 17 s t a r t A c t i v i t y ( i n t e n t ) ; 18 } 19 }
20 //Al server passo i l codice del treno e l a data
21 } . e x e c u t e ( t r a i n c o d e , s e l e c t e d d a t e ) ;
Nella classe AsyncGetInfo invio al server il codice del treno e la data, inseren-do i dati della risposta in un oggetto di tipo TravelInformation. Nelle activity successive non ho pi`u bisogno di richiedere i dati al server, basta passare gli oggetti di tipo Train e TravelInformation da una activity all’altra, attraverso gli intent.
L’elaborazione dei dati ricevuti dal server avviene nell’activity adibita alla visualizzazione dei dati, subito dopo aver selezionato il relativo viaggio.
Capitolo 5
Valutazione
5.1
Guida all’uso
Attivare il service
Figura 5.1: Guida - menu iniziale
Per attivare o disattivare il service `e sufficiente cliccare o trascinare il bot-tone illustrato nella figura 5.1 (2). Quando si attiva manualmente il service,
40 5. Valutazione
parte subito un primo processo di monitoraggio, utile nel caso l’utente voglia rilevare “manualmente” i dati. Quando un monitoraggio `e terminato con successo, viene visualizzata una notifica con indicati i relativi dati rilevati.
Leggere le informazioni del dispositivo
Per leggere le informazioni del dispositivo si deve selezionare la voce “In-formazioni sul dispositivo” dal menu, come illustrato in figura 5.1 (1). Per fare questo il dispositivo deve essere connesso alla rete internet. Una vol-ta selezionavol-ta l’opzione nel menu, verr`a visualizzata una schermata come in figura 5.2.
Figura 5.2: Guida - informazioni dispositivo
Leggere le informazioni relative ad un viaggio
Per leggere le informazioni relative ad un viaggio il dispositivo deve essere connesso alla rete internet. Si devono scegliere il codice del treno (3) e la data (4), come illustrato in figura 5.1. Una volta selezionati i filtri di ricerca, premere sul bottone “Mostra informazioni”.
5.1 Guida all’uso 41
Figura 5.3: Guida - lista dei viaggi
La schermata che appare (figura 5.3) si presenta con una lista dei viaggi che quel treno pu`o effettuare. Il titolo della schermata (1) indica il numero del treno scelto e selezionandolo si torna alla schermata precedente. Un viaggio si presenta nella forma “Partenza - Arrivo (Ora partenza - Ora arrivo)” e per ogni viaggio sono anche indicati quanti dati, sia automatici che manuali, sono stati raccolti per quel viaggio nella data selezionata. Quando il viaggio `e scritto in corsivo vuol dire che l’utente non hai mai monitorato dati per quel viaggio, altrimenti viene scritto in grassetto (2).
Selezionando un viaggio appare la schermata in figura 5.4. Questa scher-mata contiene le informazioni relative al viaggio e alla data selezionati in precedenza. Nel campo “Velocit`a media” (1) `e indicata la media (in km/h) delle velocit`a rilevate da tutti gli utenti che hanno monitorato quel viaggio in quella data. Nel campo “Numero di passeggeri rilevati” (2) `e indicata una stima dei passeggeri rilevati a bordo. Questo numero `e il massimo tra il numero di dispositivi che hanno effettuato il monitoraggio e il numero di dispositivi rilevato attraverso il monitoraggio Bluetooth. I campi “Persone in piedi” (3) e “Persone sedute” (4) si riferiscono ai dati rilevati attraverso
42 5. Valutazione
Figura 5.4: Guida - visualizzazione dati automatici
il sensore di prossimit`a e l’accelerometro. La percentuale visualizzata a lato del numero si riferisce al numero di passeggeri dati dalla somma delle persone sedute e le persone in piedi, non al numero di passeggeri rilevati dal Blue-tooth (che pu`o anche essere diverso). Selezionando uno dei campi precedenti compaiono delle informazioni relative al campo scelto, come ad esempio il metodo di rilevazione del dato.
Per passare alla schermata dei “risultati manuali” (figura 5.5) basta far scorrere il dito da destra a sinistra. In questa schermata (a scorrimento ver-ticale) sono presenti la media delle valutazioni e tutti i commenti rilasciati dagli utenti relativi a quel viaggio, indipendentemente dalla data scelta (le valutazioni manuali riguardano il viaggio in generale, non solo quello gior-naliero). Le valutazioni di “Pulizia”, “Posti a sedere” e “Puntualit`a” sono espresse con 3 stelle e il punteggio di ciascuna valutazione assume un valore da 0 a 6 (si pu`o dare anche un punteggio di mezza stella). Per visualizzare la lista dei commenti degli utenti riguardanti il viaggio si deve premere il bot-tone “Visualizza commenti”. Per tornare alla schermata precedente si deve far scorrere il dito da sinistra a destra.
5.1 Guida all’uso 43
Figura 5.5: Guida - visualizzazione dati manuali
Valutare un viaggio
Per valutare un viaggio il dispositivo deve essere connesso alla rete e si deve tornare alla schermata in figura 5.3. I viaggi visualizzati in verde e grassetto sono da valutare, quelli in corsivo invece non si possono valutare, dato che l’utente non ha effettuato il viaggio (o non l’ha monitorato). Nella figura 5.6 sono rappresentati i vari passaggi per valutare un viaggio in treno. Dalla lista dei viaggi, tenendo premuto su un viaggio in grassetto, compare l’opzione “Valuta”. Selezionando questa opzione compare una schermata a scorrimento verticale dove `e possibile dare un punteggio da 0 a 6 (in 3 stelle) ad ognuna delle 3 voci viste precedentemente. Inoltre `e possibile inserire un commento relativo al viaggio, con massimo 300 caratteri (il commento pu`o anche non essere inserito, semplicemente lasciando vuoto il relativo box). Terminate le modifiche, per confermare la valutazione premere sul bottone “Valuta”. Ogni viaggio che `e stato valutato correttamente viene segnato in azzurro e grassetto nella lista dei viaggi e sar`a possibile modificare in qualsiasi momento la valutazione data.
44 5. Valutazione
5.2 Prove sperimentali 45
5.2
Prove sperimentali
Per calibrare il rilevamento automatico della posizione dell’utente (seduto o in piedi) ho dovuto fare alcune prove sperimentali. Ho realizzato dunque una applicazione Android con lo scopo di memorizzare in un database locale (in SQLite) i rilevamenti dell’accelerometro presente nel dispositivo. L’ap-plicazione effettua un monitoraggio ogni 5 minuti e ogni monitoraggio rileva 20 variazioni di accelerazione. Provando l’applicazione in un reale viaggio in treno (con lo smartphone in tasca), ho effettuato un totale di 20 monitoraggi (10 mentre ero seduto e 10 mentre ero in piedi) e le vibrazioni ricevute dal treno in movimento avevano intensit`a diverse a seconda della mia posizione. L’accelerometro rileva un’intensit`a di accelerazione maggiore quando l’uten-te `e seduto sul treno, mentre quando `e in piedi, l’accelerazione rilevata ha un’intensit`a inferiore. Questo pu`o essere dovuto al fatto che quando l’utente `e seduto, tutto il corpo `e a contatto con il treno; invece, quando l’utente `e in piedi, la maggior parte delle vibrazioni viene assorbita dal corpo (a partire dai piedi) prima di arrivare alla posizione del dispositivo (tasca, zaino, . . . ). Per fare un confronto accurato dei due possibili casi ho scelto e realizzato due grafici che rappresentano rispettivamente un monitoraggio con la pi`u bassa intensit`a di accelerazione rilevata da seduto (figura 5.7) e un monitoraggio con la pi`u alta intensit`a di accelerazione rilevata in piedi (figura 5.8). Quello che si pu`o subito notare `e che la differenza tra le due diverse situazioni rima-ne accentuata anche cercando di scegliere due monitoraggi (un monitoraggio per situazione) con risultati molto vicini tra di loro.
Non avendo a disposizione i reali dati delle coordinate delle tratte ferro-viarie, ho provato l’applicazione completa sia in automobile che in autobus, inserendo manualmente i dati delle relative coordinate. I dati ottenuti hanno rispettato le mie aspettative, trovando circa 5 viaggiatori in meno rispetto ai viaggiatori reali.
46 5. Valutazione
Figura 5.7: Monitoraggio da seduto con i valori pi`u bassi
Conclusioni e sviluppi futuri
Il progetto che `e stato presentato soddisfa gli obiettivi che mi sono posto nel capitolo 1 e le prove sperimentali effettuate sono state soddisfacenti, anche se l’applicazione realizzata, per essere effettivamente utile al suo scopo, deve essere utilizzata da un gran numero di viaggiatori. Rendere l’applicazione pi`u user-friendly pu`o essere un modo per incentivare l’utilizzo dell’applicazione anche da parte degli utenti con poca esperienza nell’utilizzo dei dispositivi mobili. Il progetto che `e stato presentato in questa tesi pu`o essere visto come uno scheletro per lo sviluppo di altri progetti e, ad esempio, pu`o essere ampliato nei seguenti modi:
• Sviluppare un Social Network tra gli utenti che utilizzano l’applicazio-ne. Ecco alcune caratteristiche che potrebbe avere:
– Registrazione degli account;
– Classifica degli utenti, ognuno con un relativo punteggio (in base al numero di monitoraggi effettuati);
– Sistema di amicizie basato sul Bluetooth o sul NFC1.
• Progettare un servizio automatico per la gestione degli orari e del-le tratte ferroviarie, offrendo aldel-le societ`a ferroviarie l’opportunit`a di collaborare attraverso la condivisione delle informazioni.
1Near Field Communication
48 CONCLUSIONI
• Rendere l’applicazione compatibile anche con altri sistemi operativi per dispositivi mobili, come iOS e Windows Phone, in modo che il tipo di dati monitorati sia indipendente dal sistema utilizzato.
• Fare uno studio approfondito sui dati raccolti da un campione ab-bastanza grande di utenti, in modo da poter fornire una valutazione statistica sulla qualit`a del servizio di trasporto ferroviario italiano.
Bibliografia
[1] Sondaggi trenitalia del 2011: http://www.trenitalia.com/cms-file/allegati/trenitalia/area clienti/Relazionesullaqualitadelservizio.pdf [2]
http://www.legambiente.it/contenuti/articoli/i-principali-comitati-dei-pendolari-italiani
[3] http://developer.android.com/tools/sdk/eclipse-adt.html
[4] Statistiche mensili di Kantar: http://www.kantarworldpanel.com/ [5] https://developers.google.com/maps/documentation/geocoding/
![Figura 2.1: Vendite degli smartphone in Italia nel mese di giugno (bib. [4])](https://thumb-eu.123doks.com/thumbv2/123dokorg/7472242.102482/13.892.206.654.580.788/figura-vendite-smartphone-italia-mese-giugno-bib.webp)
