Embed Size (px)
Citation preview
UNIVERSITÀ POLITECNICA DELLE MARCHE
FACOLTÀ DI INGEGNERIA
Corso di Laurea in Ingegneria Informatica e dell’Automazione
Studio e sviluppo di un’applicazione biomedicale in ambiente Android
Tesi di Laurea di: Relatore: Vlad Stefan Lupu Prof. Aldo Franco Dragoni
Anno Accademico 2011 – 2012
A mia moglie e ai miei genitori, che mi sono sempre stati accanto
- 3 -
INDICE 1. Introduzione .................................................................................................................. - 5 - 2. e-Health ......................................................................................................................... - 6 -
2.1. Definizione ............................................................................................................. - 6 - 2.2. Telemedicina ........................................................................................................... - 7 - 2.3. mHealth .................................................................................................................. - 7 -
3. STMicroelectronics Bodygateway ................................................................................. - 9 - 3.1. STMicroelectronics ................................................................................................. - 9 - 3.2. Panoramica sul device ........................................................................................... - 10 - 3.3. I sensori ................................................................................................................ - 13 -
3.3.1. Elettrocardiogramma ...................................................................................... - 13 -
3.3.2. Bioimpedenza ................................................................................................. - 14 -
3.3.3. Accelerometro ................................................................................................ - 14 -
3.3.4. Altri sensori .................................................................................................... - 14 -
3.4. Elaborazioni indipendenti ...................................................................................... - 16 - 3.4.1. Elaborazione elettrocardiogramma .................................................................. - 16 -
3.4.2. Elaborazione accelerometro ............................................................................ - 20 -
3.4.3. Elaborazione bioimpedenza ............................................................................ - 22 -
3.5. Elaborazioni Comuni ............................................................................................. - 23 - 4. Android ....................................................................................................................... - 25 -
4.1. Cos’è Android ....................................................................................................... - 25 - 4.2. Storia .................................................................................................................... - 26 - 4.3. Dalvik Virtual Machine ......................................................................................... - 28 - 4.4. Architettura ........................................................................................................... - 29 -
4.4.1 Il kernel ........................................................................................................... - 29 -
4.4.2. Android Runtime e le librerie native ............................................................... - 30 -
4.4.3. Application Framework .................................................................................. - 32 -
4.4.4. Application layer ............................................................................................ - 33 -
4.5. Componenti di un’applicazione ............................................................................. - 34 - 4.5.1. Activity........................................................................................................... - 34 -
4.5.2. Intent e Intent Filter ........................................................................................ - 37 -
4.5.3. Service ............................................................................................................ - 37 -
- 4 -
4.5.4. Content Provider ............................................................................................. - 39 -
4.5.5. Broadcast Receiver ......................................................................................... - 39 -
4.6. Strumenti di sviluppo ............................................................................................ - 40 - 4.6.1. Eclipse ............................................................................................................ - 40 -
4.6.2. Android Development Tools ........................................................................... - 41 -
4.6.3. Android SDK .................................................................................................. - 41 -
5. Sviluppo del software .................................................................................................. - 43 - 5.1. Il software per PC ................................................................................................. - 43 - 5.2. Presentazione dell’applicazione ............................................................................. - 44 - 5.3. Miglioramenti e nuove funzionalità ....................................................................... - 48 - 5.4. Dispositivo Android utilizzato ............................................................................... - 67 -
6. Conclusioni e Sviluppi Futuri ...................................................................................... - 70 - 7. Bibliografia ................................................................................................................. - 71 -
- 5 -
1. Introduzione
Nel prossimo futuro è prevista a crescere la richiesta dei servizi connessi alla sanità
in Europa, parzialmente a causa dell’aumento del numero di anziani nella regione europea.
Sempre più richieste saranno per servizi sanitari concentrati sul paziente e basati sulla
prevenzione. Le tecnologie per affrontare queste richieste sono sistemi real-time a basso costo
che monitorano i parametri fisiologici dei pazienti. Una rete wireless è necessaria per poter
trasmettere i dati medicali del paziente ai professionisti medicali direttamente dall’interno
dell’abitazione. In questo modo si evitano l’ospedalizzazioni e si da al paziente una maggiore
mobilità.
Da qualche anni Telemonitoring e Telemedicina sono considerati settori promettenti
per ridurre i costi della salute mediante l’uso di dispositivi biomedicali controllati a distanza.
La miniaturizzazione e la riduzione dei costi dei componenti elettronici facilitano la creazione
di dispositivi indosabili per un monitoraggio a distanza in tempo reale.
Uno strumento di questo tipo è BodyGateWay, progettato e sviluppato da
STMicroelectronics, e in grado di rilevare segnali vitali di un paziente. Tale apparecchio verrà
preso in esame in questa tesi e il suo funzionamento approfondito nel capitolo 3. Il device si
trova nella zona di intersezione dei settori mHealth (mobile Health) e Telemedicina, nozioni
accennate nel secondo capitolo.
Nel quarto capitolo verrà presentato il sistema operativo Android con la sua
architettura e gli strumenti di sviluppo. Creata da Google in collaborazione con l’Open
Handset Alliance, Android è la prima piattaforma completa e gratuita per lo sviluppo di
applicazioni mobile. Attualmente è la più diffusa al mondo e il suo negozio online Google
Play Store conta più di 600.000 applicazioni.
Lo scopo di questa tesi è di aggiustare e migliorare un’applicazione per i dispositivi
Android capace di collegarsi tramite protocollo Bluetooth al dispositivo BodyGateWay.
L’applicazione dovrà essere in grado di tracciare grafici per segnali come l’ECG e
bioimpedenza e mostrare anche altri parametri, tutto in tempo reale.
- 6 -
2. e-Health
2.1. Definizione
L’evoluzione delle tecnologie dell’informazione e della comunicazione (ICT) in
ambito sanitario ha introdotto un modello innovativo di sanità “elettronica”, chiamato e-
Health. L’e-Health rappresenta un vero paradigma di innovazione, al cui servizio si
raggruppano diverse discipline, tra cui l’informatica clinica, la medicina e anche l’economia
aziendale.
Ci sono opinioni che mettono l’e-Health intercambiabile con il termine health care
informatics, altre invece lo utilizzano in un senso più stretto, ovvero la pratica delle cure
sanitarie mediante l’uso di internet.
Il termine include una vasta gamma di servizi o sistemi:
Cartella clinica elettronica - permette una comunicazione semplice dei dati
del paziente tra le diverse figure professionali (medici di medicina generale,
specialisti);
Telemedicina - include tutti i tipi di cure mediche o psicologiche che non
richiedono al paziente la presenza fisica dal medico curante;
Medicina basata sulle evidenze - sistema in grado di fornire informazioni
circa l’appropriato trattamento di una malattia;
Consumer health informatics - branca dell’informazione medica che si
occupa di analizzare i bisogni dei consumatori e rendere accessibili gli studi e
gli sviluppi nel campo della medicina;
Virtual healthcare team - composto da professionisti della salute che
collaborano fra loro e condividono le informazioni sui pazienti attraverso
l’utilizzo di apparecchiature digitali;
mHealth – l’uso di dispositivi mobili per colletare dati sulla salute del
paziente, monitoraggio in tempo reale dei segnali vitali del paziente;
Sistemi informatici healthcare – soluzioni software per prenotare le visite,
gestire i dati del paziente o gestire l’orario di lavoro del personale.
- 7 -
2.2. Telemedicina
Quando si parla dell’applicazione dell’e-Health, spesso ci si pensa ad una disciplina
conosciuta sotto il nome di Telemedicina.
La Telemedicina comprende l’applicazione delle tecnologie informatiche e delle
telecomunicazioni alla medicina e consente di rendere disponibili le risorse mediche sia di
base, sia specialistiche a pazienti che non possono accedere direttamente ai servizi sanitari per
difficoltà di varia natura. Questa disciplina è in grado di migliorare la qualità dell’assistenza
sanitaria e consentire la disponibilità di cure, servizi di diagnosi e consulenza medica a
distanza, oltre al costante monitoraggio di parametri vitali, al fine di ridurre il rischio
d’insorgenza di complicazioni in pazienti affetti da patologie gravi.
Negli ultimi decenni l’andamento demografico, soprattutto nei paesi più sviluppati,
ha evidenziato un costante aumento della vita media, con conseguente incremento delle fasce
di età più elevata. La diminuzione della natalità e dei decessi hanno modificato
completamente la composizione della società, con conseguenze sociali e sanitarie complesse
che si manifesteranno in modo sempre più evidente. L’invecchiamento della popolazione
determina l’incremento percentuale delle fasce adulte ed anziane con la necessità di ripensare
le strategie sanitarie e affrontare controlli periodici più frequenti. La Telemedicina potrà
essere uno degli strumenti per rendere più efficace l’azione di prevenzione e di monitoraggio
necessarie per mantenere in salute la popolazione anziana.
La Telemedicina include numerosi campi di applicazione: Teleassistenza,
Telecardiologia, Teleconsulto, Teledialisi, Telemonitoraggio, Teleradiologia, Telesoccorso,
Telespirometria, Telechirurgia e Telerobotica chirurgica.
In conclusione, la Telemedicina porta l’assistenza a casa del paziente, permette la
consultazione a distanza tra specialisti e mette a disposizione dell’intera struttura ospedaliera
informazioni in tempo reale, in questo modo evitando lo spreco di tempo e di risorse.
2.3. mHealth
mHealth (o m-Health) è un termine usato per la pratica della medicina con il
supporto dei dispositivi mobili. Mobile health è un campo giovane e dinamico che potrebbe
migliorare il benessere delle persone da tutto il mondo.
- 8 -
I dispositivi mobili e servizi associati possono svolgere delle funzioni di primo piano
per migliorare il livello delle cure sanitarie, sia nel mondo sviluppato che nei paesi emergenti.
Le applicazioni mobili possono abbassare i costi e consolidare la prevenzione, tutto questo
migliorando i risultati della sanità a lungo termine.
Le tecnologie mobili non possono trasmettere farmaci, dottori o apparecchiatura tra
diversi luoghi, ma possono in cambio trasmettere ed elaborare più tipi di informazioni: dati
criptati, testo, immagini, audio e video. Le principale tecnologie che possono trasmettere
informazioni m-Health sono le reti di telefonia mobile GSM, GPRS, 3G e 4G-LTE, le
tecnologie Wi-Fi e WiMax e il Bluetooth per le comunicazioni a corto raggio. Queste
tecnologie funzionano su reti hardware che comprendono telefoni cellulari, computer portatili
(che includono netbook, tablet e PDA), camere digitali e sensori remoti.
mHealth è un settore in piena crescita guidato dal successo delle applicazioni per
smartphone e tablet, dalla forte penetrazione di questi device mobili. Attualmente ci sono
circa 250 milioni gli utenti di applicazioni mHealth nel mondo, nel 2011 erano 125 milioni.
Figura 2.1 Applicazioni mHealth1
1 Fonte: healthinformatics [Online] http://healthinformatics.wikispaces.com/mHealth
- 9 -
3. STMicroelectronics Bodygateway
In questo capitolo si farà una presentazione del device in studio in questa tesi e per il
quale è stato sviluppato il software per dispositivi mobili Android. È un dispositivo progettato
e creato da STMicroelectronics.
3.1. STMicroelectronics
STMicroelectronics è una azienda italo-francese con sede a Ginevra (Svizzera), per
la produzione di componenti elettronici a semiconduttore. È uno dei più grandi produttori
mondiali di componenti elettronici, usati soprattutto nell'elettronica di consumo, nell'auto,
nelle periferiche per computer, nella telefonia cellulare e nel settore cosiddetto "industriale".
Figura 3.1 STMicroelectronics - Settori di attività2
2 Fonte: STMicroelectronics [Online]
http://www.st.com/internet/com/about_st/st_company_information.jsp?WT.svl=about_st_header
- 10 -
I top 10 Clienti OEM per il 2011 sono stati: Apple, Bosch, Cisco, Continental, HP,
Nokia, Research In Motion, Samsung, Seagate, Sony/Sony Ericsson.
3.2. Panoramica sul device
Il Bodygateway (BGW) (Fig. 3.2) è un dispositivo biomedico indossabile e non
invasivo in grado di monitorare i parametri vitali dell’uomo.
(a)
(b)
Figure 3.2 (a) e (b) Immagini del dispositivo3
3 Fonte: Andrea Vitali, Marco Pessione, STMicroelectronics. Detection, Processing And Wireless Transmission Of Biologic Signal: The Electronic Patch "BodyGateWay". efytimes.com. [Online]
http://www.efytimes.com/e1/creativenews.asp?edid=63194
- 11 -
È dotato di sensori in silicio miniaturizzati e circuiti per il rilevamento di segnali
biologici (accelerometro a tre assi e filtri/amplificatori per l’elettrocardiografia), un modulo
Bluetooth per la trasmissione dei dati e un microcontrollore a bassa potenza per la gestione
locale e in tempo reale dei dati.
L’elaborazione dell’elettrocardiogramma include rimozione di rumori e artefatti,
stima della frequenza cardiaca, stima della frequenza respiratoria e classificazione e
valutazione del battito cardiaco. Il trattamento dei dati dell’accelerometro comprende filtri
digitali per la rimozione di rumore e stima del livello di attività fisica.
I segnali vengono trattati sia singolarmente che insieme, per esempio si va a
verificare la corrispondenza di battito cardiaco e attività fisica.
I sensori miniaturizzati permettono al dispositivo di essere piccolo e leggero per
poter essere indossato in maniera confortevole e nello stesso momento permettono un
rilevamento continuo e preciso dei segnali biologici. Infatti questo è un fattore importante
nella creazione di un apparecchio di questo genere. Inoltre, deve essere robusto allo stress
mentre è indossato.
Un altro fattore importante è il consumo di energia. Il dispositivo deve essere a bassa
potenza per permettere la rilevazione dei segnali biologici per un lungo periodo di tempo.
È necessaria la presenza di un unità di elaborazione per pulire i segnali, per
comprimerli (per ridurre i consumi durante la trasmissione) e per elaborarli (per estrarre i
parametri significativi). L’apparecchio deve includere anche un modulo per trasmettere i dati
individuati ad una memoria remota per permettere ulteriori processazioni.
Attualmente nel prototipo del Bodygateway sono presenti rilevatori di tensione per
l’elettrocardiogramma, misuratori di impedenza (iniezione di una corrente con successivo
calcolo della tensione), accelerometro a tre assi e due LED bicolori. I futuri prototipi
includeranno fotodiodi per la fotopletismografia, un microfono per i suoni interni (suoni
cardiaci e respiratori) e suoni esterni (voce) e due sensori di temperatura (uno per la pelle e
uno per l’ambiente).
La gestione del rilevamento dei segnali e della loro elaborazione, delle memorie
locali/remote, della trasmissione/ricezione via Bluetooth è realizzata mediante un
microcontrollore a bassa potenza.
Il sistema integrato è a basso costo e permette ad uno strato più ampio della
popolazione di essere monitorato con la stessa quantità di spese. Questo è un punto
importante dato che la popolazione diventa più anziana. Questo approccio aumenta
l’efficienza di ogni protocollo sanitario.
- 12 -
Il dispositivo è estremamente pratico da usare, senza compromettere alcun
movimento all’utente. Si applica al torace tramite un cerotto adesivo monouso che contiene
dei elettrodi. Le dimensioni ridotte e la facilità d’uso li permettono di essere usato in diversi
campi: home care, riabilitazione, allenamento sportivo, ricerca, wellness. Tutto il sistema
viene alimentato da una batteria ricaricabile interna ed è munito di un’unità di ricarica con
connettore AC/DC. I due led posizionati sul fronte del dispositivo consentono di controllare
l’accensione e lo spegnimento e di verificare la connessione con un dispositivo esterno o la
trassmissione dei dati.
Per ingrandire il raggio di parametri medicali, il dispositivo può essere accoppiato
con sensori esterni come bilance e misuratori di pressione sanguigna.
Figura 3.3 Sistema completo rappresentando il Bodygateway accanto a sensori off-body. Il dispositivo è
progettato per rilevare segnali biologici, elaborarli e trasmeterli via Bluetooth ad un telefono mobile, che in
seguito li trasmette ad un server remote di una struttura sanitaria, dove i dati possono essere verificati da
personale specializzato4
I segnali biologici raccolti dai sensori interni ed esterni collegati wireless sono
elaborati e ritrasmessi su dispositivi locali (smartphone o PC). Una connessione internet è
4 Fonte: Vanni Saviotti, STMicroelectronics. The Body Gateway: mHealth Platform for Wearable Devices. MEDS – Medical Electronic Device Solutions [Online] http://medsmagazine.com/2012/01/the-body-gateway-mhealth-platform-for-wearable-devices/
- 13 -
usata dal dispositivo ricevente per trasferire i dati dalla locazione del paziente ai dispositivi
remoti (server) e viceversa. Il dispositivo locale può ospitare una GUI (graphical user
interface) con lo scopo della consultazione dal paziente.
Infine, la memorizzazione sul server e l’architettura dei servizi rappresentano l’unità
remota di elaborazione hardware e software responsabile di costituire connessioni securizzate
e autenticare l’utente, per raccogliere i dati ricevuti dal BGW nonché per fornire le funzioni
per monitorare ed emettere allarmi o messaggi all’utente. Questi server rappresentano i centri
per la fornitura dei servizi.
3.3. I sensori
Il dispositivo fa uso di due tipologie di sensori: uno per il rilevamento della tensione
per l’elettrocardiogramma e la bio-impedenza, l’altro dedicato all’acquisizione dei movimenti
mediante un accelerometro triassiale.
3.3.1. Elettrocardiogramma
L’elettrocardiogramma viene calcolato amplificando la differenza di potenziale tra
due elettrodi posizionati sul petto, per mezzo del cerotto, 8-10 cm l’uno dall’altro. Il circuito
elettronico annulla la tensione di modo comune mediante filtri passa-banda (banda di
interesse da 0.05-2 Hz a 100 Hz).
(a) (b)
Figura 3.4 Testing del ECG dalla STMicroelectronics. ECG corretta (a) e con un elettrodo scollegato (b)5
5 Fonte: Andrea Vitali, STMicroelectronics. Dispositivi bio-elettronici: sensori per la salute e il benessere. [Online]
http://www.arti.puglia.it/fileadmin/user_files/download/Andrea_Vitali__STM.pdf
- 14 -
Il campionamento è eseguito a 500 Hz, però tale frequenza può essere programmata e posta
da 100 Hz sino ad 4 kHz mentre la quantizzazione viene fatta con 12 bit di precisione.
3.3.2. Bioimpedenza
L’acquisizione dell’impedenza avviene per mezzo degli stessi elettrodi usati per
l’elettrocardiogramma. Facendo scorrere una corrente continua o alternata sul corpo, si misura
la tensione, dal loro rapporto risultando l’impedenza. Occorrono alcuni secondi per passare
dalla rilevazione dell’elettrocardiogramma a quella della bio-impedenza al fine di permettere
di completare i transitori nei filtri analogici.
3.3.3. Accelerometro
Il movimento viene rilevato per mezzo di un accelerometro a 3-assi. Il segnale è
campionato a 25 Hz con una risoluzione a 8 bit. La stima della velocità istantanea del corpo e
la distanza percorsa sono realizzate tramite un algoritmo proprietario. L’algoritmo è
progettato per funzionare con un accelerometro posizionato sul petto (come avviene con il
BGW), sul braccio o sulla vita.
3.3.4. Altri sensori
Come detto prima, il dispositivo prevede di includere nel futuro altri sensori come un
fotodiodo CMOS che rileva la luce riflessa dai tessuti sotto la pelle. Due LED emettono luce
nella banda rossa e infrarossa. Questa rilevazione verrà usata per il fotopletismogramma
(stima della saturazione dell’ossigeno). Si prevede anche un microfono per catturare i suoni
cardiaci (fonocardiogramma) e respiratori. Il segnale sarà campionato a 4 kHz con 16 bit di
risoluzione.
- 15 -
(a) (b) (c)
Figura 3.5 Testing del fotodiodo dalla STMicroelectronics. Immagini con il fotodiodo posizionato sul dito (a),
polso (b) e petto (c) con relativi grafici sotto, rappresentando i led della banda rossa (colore rosso) e infrarossa
(colore blu) e l’ECG(colore nero).6
(a) (b) (c)
Figura 3.6 Testing del microfono dalla STMicroelectronics. Grafici per il microfono posizionato sul polso (a),
braccio (b) e petto (c).7
6 Fonte: Andrea Vitali, STMicroelectronics. Dispositivi bio-elettronici: sensori per la salute e il benessere. [Online] http://www.arti.puglia.it/fileadmin/user_files/download/Andrea_Vitali__STM.pdf 7 Ibidem
- 16 -
3.4. Elaborazioni indipendenti
Sul microcontrollore è stato precaricato un software che si occupa del filtraggio dei
segnali generati da ogni sensore. Il primo passo della catena di processo comprende filtri
indipendenti per ogni segnale, con l’obiettivo di rimuovere il rumore e trovare artefatti. Il
rumore fuori banda è eliminabile grazie ad un filtro passa-banda. I segnali puliti vengono
utilizzati per stimare i parametri significativi (frequenza cardiaca, frequenza respiratoria, etc).
Anche gli artefatti (falsi segnali generati dal movimento) e le condizioni anomale
(disconnessione dell’elettrodo) sono rilevate, ovviamente in questo caso i parametri non sono
disponibili.
L’estrazione dei parametri è soggetta a falsi negativi (il campione è presente ma non
rilevato) e falsi positivi (viene trovato un campione anche se non presente). Una sensibilità
elevata permetterebbe maggiore correttezza nella rilevazione ma permetterebbe inoltre anche
una maggiore frequenza di casi di falsi positivi.
Nel settore per il quale questo dispositivo è progettato, ovvero applicazioni
biomediche, è preferibile avere un’alta precisione, per essere sicuri che, quando il campione
viene dichiarato rilevato, è veramente presente nel segnale. Purtroppo questo porta ad un più
alto tasso di falsi negativi.
3.4.1. Elaborazione elettrocardiogramma
Per il calcolo del segnale dell’elettrocardiogramma sono implementati e valutati due
differenti processi a catena. Il primo è quello di Hamilton-Tompkins, usato nel ben noto
algoritmo per il calcolo della frequenza cardiaca (OSEA).
La catena è composta dai seguenti blocchi:
filtro passa-basso con frequenza di taglio a 16 Hz che elimina i rumori alle
alte frequenze (rumore muscolare e interferenza a 50-60 Hz
dell’alimentazione);
filtro passa-alto con frequenza di taglio a 8 Hz il quale rimuove il
funzionamento alla linea di base;
blocco che calcola la derivata del primo ordine (con i picchi corrispondenti al
battito cardiaco che presentano generalmente considerevoli pendenze);
filtro media mobile a 80 ms che evidenzia i picchi;
- 17 -
soglia adattiva di rilevamento logico.
Il secondo processo, e quello scelto per il Bodygateway, è basato sul algoritmo di
Pan-Tompkins. La catena è esenzialmente uguale, con la differenza che la pendenza è
quadrata e non presa nel valore assoluto, e la media mobile è svolta a 150ms invece di 80ms.
Questo spinge ad una rilevazione del picco più efficace, anche in casi di bassa ampiezza degli
stessi, però con un maggior sforzo di calcolo.
Figura 3.7 Risultati di un elaborazione ECG usando l’algoritmo di Pan-Tompkins e la semplice logica soglia-
adattiva per il rilevamento del picco relativo al battito. In rosso: falsi positivi (eventi rilevati, ma non presenti).
Verde: falsi negativi (eventi non rilevati, che dovevano essere presenti). Nero: Classificazione corretta ma nella
parte sbagliata della forma dell’onda.8
Due situazioni critiche sono state rivelate dai primi risultati sperimentali: la
disconnessione degli elettrodi e la sovrapposizione del rumore sulla larghezza di banda
spettrale del segnale di interesse. Entrambe portavano ad una errata rilevazione dei picchi R,
con una conseguente valutazione sbagliata della frequenza cardiaca (Fig. 3.7). L’algoritmo è
stato ottimizzato in tre modi. Il primo dice che una valutazione della varianza del segnale
permette di individuare eventi critici (es. disconnessione degli elettrodi, rumore ad alta
frequenza), perché questi eventi hanno alti valori di varianza. Il calcolo di somiglianze
(corrispondenze) con un’onda di riferimento rappresenta il secondo miglioramento
dell’algoritmo. Le corrispondenze sono valutate trovando il minimo locale della SAD (Sum of
8 Fonte: Andrea Vitali, Marco Pessione, STMicroelectronics. Detection, Processing And Wireless Transmission Of Biologic Signal: The Electronic Patch "BodyGateWay". efytimes.com. [Online] http://www.efytimes.com/e1/creativenews.asp?edid=63194
- 18 -
Absolute Differences – somma delle differenze assolute) tra la porzione di segnale corrente e
il riferimento. Infine, il prototipo deve funzionare qualunque sia il posizionamento degli
elettrodi. Perciò, è necessaria una base di dati dei modelli per rendere l’algoritmo
indipendente dall’onda acquisita (Fig. 3.9).
(a)
(b)
Figura 3.8 Catena de elaborazione (a) e algoritmo del rilevamento (b) dei battiti cardiaci (picchi d’onda R)9
L’adattamento all’onda ECG specifica del paziente si garantisce aggiornando i
modelli in maniera adeguata ai campioni riconosciuti.
9 Ibidem
- 19 -
Figura 3.9 Database dei modelli usati per la classificazione dei picchi d’onda R10
Figura 3.10 Confronto tra i due algoritmi. Nel grafico in alto l’algoritmo standard (OSEA) che conta 10 falsi
positivi, 24 falsi negativi e una classificazione corretta di 25/49 battiti; nel grafico in basso l’algoritmo
modificato di Pan-Tompkins, che conta 0 falsi positivi, 10 falsi negativi e una classificazione corretta di 39/49
battiti11
10 Ibidem 11 Ibidem
- 20 -
3.4.2. Elaborazione accelerometro
Mediante filtraggio e elaborazioni, dal segnale dell’accelerometro si estrae un
parametro corrispondente all’attività totale, contando i passi e quindi misurando il livello di
attività fisica. La rilevazione è effettuata identificando ripidi passaggi sugli assi
dell’accelerometro (Fig. 3.11 (a)). Durante l’attività fisica, il segnale di ECG è affetto da
rumore (dovuto al movimento dei muscoli pettorali). Una elaborazione più sofisticata
permette la stima della postura (inclinato, disteso, in piedi), delle azioni (camminare, correre)
e situazioni anomale (cadute).
Con l’aiuto dell’accelerometro può essere stimata anche frequenza cardiaca e
respiratoria (Fig. 3.11 (b) e (c)). Sfortunatamente queste rilevazioni sono possibili solo
quando il paziente è fermo. Infatti, questo sensore permette di rilevare deboli segnali con una
frequenza inferiore di 150 Hz, permettendo un buon meccanomiogramma (MMG) e un
soddisfacente fonocardiogramma. Tramite un processo di inviluppo dei picchi d’onda R, la
frequenza respiratoria può essere ricavata anche dal segnale dell’ECG (Fig 3.11 (c)).
Un maggior processo di elaborazione potrebbe permettere inoltre la stima della
pressione sanguigna dal segnale acustico/accelerometro.
- 21 -
(a)
(b)
- 22 -
(c)
Figura 3.11 Rilevazioni sincronizzate di elettrocardiogramma (onda in alto) e di accelerazione su i tre assi (x, y,
z). Il paziente sta camminando (ECG con disturbi) (a); paziente fermo (ritmo cardiaco presente anche nei segnali
xyz) (b); paziente fermo ma con difficoltà respiratoria (ritmo respiratorio anche sull’ECG e sul XYZ) (c).12
3.4.3. Elaborazione bioimpedenza
Il segnale dell’impedenza acquisito utilizzando una corrente DC permette una stima
della qualità del contatto elettrico. Utilizzando correnti ad alta frequenza (30-50 KHz) è
possibile ricavare invece la frequenza respiratoria (tuttavia la posizione ottimale in questo
caso degli elettrodi è differente rispetto al caso dell’ECG).
12 Ibidem
- 23 -
3.5. Elaborazioni Comuni
Dopo aver elaborato in maniera indipendente i segnali, il dispositivo provvede ad
effettuare una elaborazione comune.
Lo stesso parametro può essere stimato da segnali acquisiti da sensori differenti.
Combinando i segnali da diversi canali può essere ottenuta una stima più affidabile del
parametro. Per esempio, l’elettrocardiogramma è il principale metodo usato per calcolare la
frequenza cardiaca. Però lo stesso parametro può essere ricavato dai risultati di una
elaborazione di fotopletismografia o del segnale acustico. Se il paziente è fermo, anche il
segnale dell’accelerometro permette una stima attendibile. Nella stessa maniera, la frequenza
respiratoria è rilevata principalmente dal segnale di fotopletismografia e dal segnale di
impedenza. Lo stesso parametro può essere verificato con il microfono e, durante
l’immobilità, con l’accelerometro.
Per incrementare l’affidabilità dell’informazione o addirittura per creare una nuova, è
possibile combinare più parametri. Per esempio, il segnale di fotopletismografia è affetto da
rumore che può essere corretto mediante la stima con l’accelerometro. Il software integrato
realizza una cancellazione in tempo reale di questi artefatti, mettendo a disposizione dati più
affidabili. In modo simile, la frequenza cardiaca calcolata dall’elettrocardiogramma è
confrontata con il valore stimato dell’attività fisica calcolato usando l’accelerometro,
distinguendo tra anomalie (immobilità combinata a tachicardia) e normali situazioni (corsa
con frequenza cardiaca elevata).
- 24 -
Figura 3.12 Diagramma a blocchi hardware (a) e elaborazioni indipendenti e comuni dei segnali (b)13
13 Fonte: Vanni Saviotti, STMicroelectronics. The Body Gateway: mHealth Platform for Wearable Devices. MEDS – Medical Electronic Device Solutions [Online] http://medsmagazine.com/2012/01/the-body-gateway-mhealth-platform-for-wearable-devices/
- 25 -
4. Android
4.1. Cos’è Android
Android è un sistema operativo open source per dispositivi mobili costituito da uno
stack software che include un sistema operativo, un middleware e applicazioni di base.
Nel corso degli anni, Android è arrivato ad essere la piattaforma mobile più diffusa al
mondo. Infatti nel secondo trimestre del 2012, Android domina il mercato con una quota di
68,1%, rispetto all’iOS di Apple che ha solo 16,9% (Fig.4.1). Tramite il negozio online
Google Play Store si ha accesso a più di 600.000 applicazioni, milioni di libri e brani audio e
migliaia di film.
Figura 4.1 Quote di mercato approssimate per i sistemi operativi degli smartphone per il secondo trimestre del
201214
14 Fonte dati: Android and iOS Surge to New Smartphone OS Record in Second Quarter, According to IDC.
IDC [Online] http://www.idc.com/getdoc.jsp?containerId=prUS23638712
68,1%
16,9%
4,8% 4,4% 3,5%
2,3% 0,1%
Android
iOS
BlackBerry OS
Symbian
Windows Phone/Windows Mobile
Linux
Altri
- 26 -
4.2. Storia
Il sistema operativo ha origini nell’acquisizione di Android, Inc. da parte di Google
nel 2005. L’azienda è stata fondata nel 2003 da Andy Rubin (co-fondatore di Danger) e Nick
Sears (ex-vicepresidente di T-Mobile). Nel 2007, prende vita la Open Handset Alliance
(OHA), un consorzio formato da 84 aziende di cui Google è capofila. I membri includono
operatori mobili, costruttori di telefoni, aziende di semiconduttori, aziende software e aziende
di commercializzazione. Nel 5 novembre dello stesso anno OHA presentò publicamente
Android. Dopo una settimana è stato rilasciato il Software Development Kit (SDK) che
include: gli strumenti di sviluppo, le librerie, un emulatore del dispositivo, la documentazione
e alcuni progetti di esempio e tutorial.
Nel 2008 è uscita la versione 1.0 di Android insieme al primo dispositivo reale,
ovvero HTC Dream, conosciuto anche come T-Mobile G1 in alcuni mercati (Fig. 4.2). A
febbraio 2009 esce la versione 1.1 che porta piccole correzioni e alcuni bugfix. Però le più
importanti versioni lanciate nel 2009 sono 1.5 Cupcake e 1.6 Donut. La prima introduce una
maggior integrazione con i servizi Google e aggiunge il pieno supporto ai widget, mentre la
seconda integra funzionalità a voce come la ricerca e la sintesi vocale, supporto alle reti
CDMA, diverse risoluzioni di schermo insieme ad altre piccole novità generali. Dalla 1.5 in
poi, ogni versione avrà un nome di dolce che rispetterà un ordine alfabetico.
Figura 4.2 HTC Dream – il primo dispositivo Android15
15 Fonte: Android Caotic http://android.caotic.it/2012/05/la-storia-di-android-capitolo-2-la-prima-generazione-android/
- 27 -
A poche settimane del rilascio della versione 1.6, Google ha lanciato Android 2.0
Eclair, che porta alcune novità come il supporto per il Bluetooth 2.1, supporto all’HTML 5,
migliorie alla fotocamera e sincronizzazione con account multipli. Nel gennaio 2010 è stato
rilasciato l'Android SDK 2.1 che corregge piccoli bug di sistema.
Il 20 maggio 2010 al Google I/O conference è stato rilasciato l'Android SDK 2.2
Froyo. Questa versione contiene importanti aggiornamenti: nuovo kernel linux 2.6.32, nuovo
compilatore JIT 16 , V8 Engine per il javascript, tethering Wi-fi nativo per utilizzare il
terminale come Hotspot Wireless, nuove icone per la Home, Adobe Flash Player 10.1 e
Adobe AIR integrato, possibilità di installare le apps sulla memoria SD, aggiornamento
automatico Over-the-Air delle applicazioni e nuove API 17
Il primo smartphone al mondo a ricevere Froyo è stato Google Nexus One prodotto
da HTC, il primo smartphone Android della serie Nexus by Google.
per gli sviluppatori, tra cui le
OpenGL ES 2.0. Questa versione è caratterizzata da una velocità maggiore, performance e
fluidità rispetto alla precedente versione 2.1 Eclair.
La versione Android 2.3 Gingerbread ha avuto il suo lancio nel dicembre 2010 con
grande successo, e oggi è la versione più diffusa e utilizzata tra tutti i terminali Android. La
versione del kernel Linux su cui si basa Gingerbread è la 2.6.35. Il JIT compiler è stato
ulteriormente ottimizzato, i driver OpenGL ES sono stati aggiornati ed è stato aggiunto il
supporto alle API audio Khronos OpenSL ES. La novità più grande è però il supporto alla
tecnologia Near Field Communication (NFC), che consentirà ai possessori di terminali con
chip NFC di poter usare il terminale come strumento per effettuare pagamenti. A seguire, nei
mesi del 2011, sono state rilasciate alcune nuove versioni al fine di correggere i vari bug del
software: sono uscite 5 versioni correttive di Gingerbread numerate dalla 2.3.3 alla 2.3.7.
Nel febbraio del 2011 viene rilasciato il sistema 3.0 (Honeycomb) dedicato ai soli
tablet. Honeycomb ha messo delle basi solide per il mondo tablet Android, ma ha
rappresentato anche un sistema operativo poco ottimizzato. Durante il resto del 2011 sono
usciti alcuni update che però hanno introdotto poche novità.
Il 19 ottobre 2011 Android 4.0 Ice Cream Sandwich fa il suo debutto
contemporaneamente alla presentazione del nuovo Samsung Galaxy Nexus. Questa versione è
destinata sia per smartphone, sia per tablet, e intende di risolvere i problemi della
16 Just-In-Time compiler: compilatore che permette un tipo di compilazione, conosciuta anche come traduzione dinamica 17 Application Programming Interface: Interfaccia di Programmazione di un’Applicazione - insieme di procedure e strumenti disponibili al programmatore per l'espletamento di un determinato compito all'interno di un programma
- 28 -
Honeycomb. Le principali novità sono l’aumento delle prestazioni, il Face Unlock, ovvero il
sistema che permette di sbloccare lo smartphone tramite riconoscimento facciale, la rimozione
del ritardo negli scatti della fotocamera e la nuova interfaccia utente completamente
riprogettata chiamata “Holo UI“.
L’ultima versione del sistema operativo Android è la 4.1 Jelly Bean, che è stata
lanciata nel giugno 2012. Tra i cambiamenti si notano: riconoscimento del tocco migliorato,
ottimizzato l'utilizzo della CPU, miglioramenti notevoli nella fluidità grazie a Project Butter,
importanti miglioramenti nell'applicazione fotocamera, nuove funzionalità per la condivisione
di foto e video tramite NFC e Google Play aggiornato.
Figura 4.3 Statistiche della distribuzione delle varie versioni sul totale dei dispositivi Android, aggiornate al
01/09/201218
4.3. Dalvik Virtual Machine
Per lo sviluppo delle applicazioni, Google ha scelto come linguaggio quello di Java,
invece di creare uno nuovo. Questa scelta tuttavia va in parte in contrasto con la filosofia open
di Android. I dispositivi che vorranno adottare la Virtual Machine (VM) associata
all’ambiente J2ME devono pagare una royalty, quindi in totale disaccordo con la licenza
Apache adottata.
Per evitare le royalty che doveva pagare a Sun Microsystems (poi acquistata da
Oracle), Google ha deciso di creare una propria macchina virtuale, progettata da Dan
Bornstein. Essa prende il nome di Dalvik Virtual Machine (DVM), nome che deriva dal
villaggio di cui la famiglia di Bornstein è originaria. Si tratta di un Virtual Machine 18 Fonte: http://developer.android.com/about/dashboards/index.html
- 29 -
ottimizzata per sfruttare la poca memoria presente nei dispositivi mobili. Prima di essere
installati su un dispositivo, i file .class con bytecode Java sono convertiti in file .dex (Dalvik
Executable) che sono poi eseguiti dalla DVM. Utilizzando questa macchina virtuale
alternativa comporta anche una sensibile riduzione della memoria richiesta dall’esecuzione
delle applicazioni. Un file .dex non compresso è tipicamente con qualche percentuale più
piccolo del file .jar compresso derivato dallo stesso file .class.
Dalla versione 2.2 è stato incluso un compilatore Just-In-Time per migliorare le
prestazione della macchina virtuale. Si tratta di un meccanismo attraverso il quale la VM
riconosce determinati pattern di codice Java traducendoli in frammenti di codice nativo (C e
C++) per una loro esecuzione più efficiente.
Una differenza importante con la JVM tradizionale è il meccanismo di generazione
del codice che viene detto register based (orientato all’utilizzo di registri) a differenza di
quello della JVM detto stack based (orientato all’uso di stack). Attraverso questa architettura
è possibile di ridurre con 30% il numero di operazioni da eseguire, a parità di codice Java.
Un’altra caratteristica esenziale della DVM è quella di permettere una efficace esecuzione di
multiple istanze della VM e quindi più processi contemporaneamente. Ogni applicazione è
eseguita all’interno del proprio processo Linux e ciò porta dei vantaggi dal punto di vista delle
performance.
4.4. Architettura
Android ha un’architettura di tipo gerarchico, strutturata a layer a complessità
crescente dal basso verso l’alto (Fig. 4.4). I layer comprendono un sistema operativo, un
insieme di librerie native per le funzionalità core della piattaforma, una implementazione della
VM e un insieme di librerie Java.
4.4.1 Il kernel
Il livello più basso è rappresentato dal kernel Linux nella versione 2.6 e 3.x (da
Android 4.0 in poi) che costituisce il livello di astrazione di tutto l’hardware sottostante. Si
noti la presenza di driver per la gestione delle periferiche multimediali, del display, delle
connessione Wi-Fi e Bluetooth, dell’alimentazione, del GPS, della fotocamera. I produttori di
telefoni possono quindi intervenire già a questo livello per personalizzare i driver di
- 30 -
comunicazione con i propri dispositivi. Grazie all’astrazione dell’hardware, infatti, i livelli
soprastanti non si accorgono dei cambiamenti hardware, permettendo una programmazione ad
alto livello omogenea ed una user experience indipendente dal device.
La scelta verso l’utilizzo di un kernel Linux si spiega attraverso la necessità di avere
un’alta affidabilità. L’affidabilità è la più importante delle prestazioni in un dispositivo
mobile che deve principalmente garantire il servizio di telefonia: gli utenti si aspettano quindi
tale affidabiltà, ma allo stesso tempo hanno bisogno di un dispositivo che possa garantire
servizi più evoluti: Linux permette di raggiungere entrambi gli scopi.
Figura 4.4 Architettura Android19
4.4.2. Android Runtime e le librerie native
Salendo nella gerarchia troviamo un insieme di librerie native realizzate in C e C++ e
l’Android Runtime. L’ambiente di runtime è costituito dalle librerie core Java e dalla
19 Fonte: Android Wiki http://androidwiki.wikidot.com/introduzione
- 31 -
macchina virtuale Dalvik (DVM): insieme costituiscono la piattaforma di sviluppo per
Android.
Le librerie invece fanno riferimento a un insieme di progetti Open Source e sono
descritte di seguito:
Surface Manager (SM), componente fondamentale in quanto ha la
responsabilità di gestire le View, ovvero i componenti dell’interfaccia grafica. Il
suo compito è coordinare e impostare i diversi layer delle finestre, utilizzando il
double buffering. Il Surface Manager permette l’accesso alle funzionalità del
display e la visualizzazione contemporanea di grafica 2D e 3D delle diverse
applicazioni.
OpenGL ES (for Embedded Systems), una versione ridotta di OpenGL per
sistemi embedded. Essa comprende un insieme di API multipiattaforma che
forniscono l’accesso a funzionalità 2D e 3D nei dispositivi mobili.
SGL (Scalable Graphics Library), libreria in C++ che costituisce il motore
grafico di Android insieme alle OpenGL. Se per la grafica 3D ci si appoggia
all’OpenGL, per quella 2D viene utilizzato invece un motore ottimizzato
chiamato SGL. È una libreria utilizzata principalmente dal Window Manager e
dal Surface Manager all’interno del processo di renderizzazione grafica.
Media Framework, API in grado di gestire i diversi codec per i vari formati di
acquisizione e riproduzione audio e video. Si basa su una libreria open source
OpenCore di PacketVideo, uno dei membri fondatori dell’OHA. I codec gestiti
dal Media Framework permettono la gestione dei formati più importanti tra cui
MPEG4, H.264, MP3, AAC, AMR oltre quelli per la gestione delle immagini
come JPG e PNG.
FreeType, libreria di piccole dimensioni, molto efficiente e altamente
personalizzabile per il rendering dei font. Una caratteristica importante è quella
di fornire un insieme di API semplici per ciascun tipo di font in modo
indipendente dal formato del corrispondente file.
SSL (Secure Socket Layer), libreria per la sicurezza della comunicazione su
internet.
- 32 -
SQLite, libreria scritta in C che implementa un DBMS 20
WebKit, framework per la navigazione web utilizzato già da diversi browser
come Safari e Chrome. Si tratta di un browser engine open-source basato sulle
tecnologie HTML, CSS, JavaScript e DOM. Un aspetto da sottolineare è che
WebKit occupa un’aspetto di browser engine quindi può essere integrato in
diversi tipi di applicazioni.
relazionale
caratterizzato dal fatto di essere compatto, diretto, di non necessitare alcuna
configurazione e soprattutto essere transazionale. Permette di creare una base di
dati incorporata in un unico file ed è diretto in quanto non utilizza un processo
standalone, ma può essere incorporato all’interno dell’applicazione che lo usa.
LibC, implementazione della libreria standard C ottimizzata per dispositivi
basati su Linux embedded.
4.4.3. Application Framework
Al prossimo livello si trova l’Application Framework (AF), costituito da un insieme
di componenti che utilizzano le librerie native. Si tratta di un insieme di API e componenti per
l’esecuzione di funzionalità di base del sistema Android.
I componenti dell’AF sono:
Activity Manager - lo strumento fondamentale che gestisce il ciclo di vita
delle activity di un’applicazione. L’activity è una singola schermata che
permette la visualizzazione, la raccolta di informazioni e l’interazione con
l’utente. Questo componente ha la responsabilità di organizzare le varie
schermate di un’applicazione in un unico stack a seconda dell’ordine di
visualizzazione delle stesse sullo schermo.
Package Manager - gestisce il ciclo di vita delle applicazioni nei dispositivi
analogamente a quanto avviene in J2ME da parte del Java Application
Manager (JAM).
Window Manager - componente molto importante che permette di gestire le
finestre delle diverse applicazioni, gestite da processi diversi, sullo schermo
dispositivo
20 Database Management System: sistema software progettato per consentire la creazione, la manipolazione e l'interrogazione efficiente di basi di dati
- 33 -
Telephony Manager - gestore delle funzionalità caratteristiche di un telefono
come la semplice possibilità di iniziare una chiamata o di verificare lo stato
della chiamata stessa
Content Provider - componente che gestisce la condivisione di informazioni
tra i vari processi.
Resource Manager - componente che ha la responsabilità di gestire le risorse
che oltre il codice compongono una applicazione (immagini, file di
configurazione, file di definizione del layout, ecc). Per le risorse, come avviene
già per il codice, esiste un processo di trasformazione delle stesse in contenuti
binari, ottimizzati per il loro utilizzo all’interno di un dispositivo.
View System - gestore del rendering dei componenti dell’interfaccia grafica
nonché della gestione degli eventi associati.
Location Manager - componente che mette a disposizione le API necessarie
per creare applicazioni che gestiscono la localizzazione del dispositivo.
Notification Manager - componente che fornisce diversi strumenti che
un’applicazione può utilizzare per inviare notifiche al dispositivo, il quale le
dovrà presentare all’utente.
XMPP Service (Extensible Messaging and Presence Protocol) - insieme di
protocolli open di messaggistica istantanea basato su XML (Extensible Markup
Language).
4.4.4. Application layer
Al livello più alto si trova il layer delle applicazioni native come telefono, contatti,
browser e di terze parti. Le funzionalità base del sistema, come per esempio il telefono, non
sono altro che applicazioni utente scritte in Java e che girano ognuna nella sua VM. A questo
livello verrano installate le app create dall’utente o scaricate dal Play Store.
- 34 -
4.5. Componenti di un’applicazione
Ci sono cinque blocchi esenziali che costituiscono un’applicazione Android:
Activity
Intent e Intent Filter
Service
Content Provider
Broadcast Receiver
4.5.1. Activity
Una parte fondamentale dell’applicazione è rappresentata dalla gestione
dell’interfaccia grafica. Essa viene realizzata attraverso la definizione di activity descritte
tramite la classe Activity del package android.app. Un’Activity è un componente
dell’applicazione che fornisce una schermata con cui gli utenti possono interagire. Una
normale applicazione consisterà in una sequenza di activity. Quindi, abbiamo diverse
schermate che si alternano sul display comunicando eventualmente tra di loro e scambiandosi
delle informazioni.
Tipicamente, una tra le activity di un’applicazione è un’activity “main”, cioè sarà
visualizzata per prima all’avvio dell’applicazione. Ogni activity può iniziare una nuova
activity per eseguire diverse azioni. A tale scopo la piattaforma organizza le attività secondo
una struttura a pila (il “back stack”) dove l’attività in cima è sempre quella attiva. La
visualizzazione di una nuova schermata, che corrisponde all’avvio di una nuova Activity, la
porterà in cima allo stack mettendo in pausa quelle precedenti. Lo stack funziona secondo il
principio “Last In, First Out” (LIFO) e quindi quando l’utente preme il bottone Back, l’attività
corrente è rimossa dallo stack e eliminata e l’activity precedente viene ripristinata.
Nel momento in cui un’attività è chiusa, il cambio di stato è notificato tramite le
callback methods (metodi di richiamata) del ciclo di vita dell’activity (Fig. 4.5). Ci sono
alcuni metodi callback che un’attività può ricevere al cambiamento del suo stato e ognuna di
loro permette di implementare dati opportuni per quel cambio di stato. L’implementazione di
questi metodi rimane il compito dello sviluppatore. Per esempio, si possono inizializzare degli
oggetti alla creazione dell’attività oppure di rilasciare degli oggetti alla chiusura della stessa.
- 35 -
Figura 4.5 Diagramma con i cicli di vita di un’Activity21
21 Fonte: Android Developers http://developer.android.com/guide/components/activities.html
- 36 -
La figura 4.5 illustra la sequenza di chiamate ai metodi di Activity eseguite durante i
passaggi di stato dell’attività:
protected void onCreate(Bundle savedIstanceState)
Metodo che deve essere implementato obbligatoriamente. È chiamato non appena l’attività
viene creata. L’argomento savedInstanceState serve per riportare un eventuale stato
dell’attività salvato prima di essere eliminata dal sistema. L’argomento è null nel caso in cui
l’attività non abbia uno stato salvato.
protected void onStart()
Chiamato per segnalare che l’attività sta per arrivare in cima allo stack per potere essere
visualizzata sul display.
protected void onResume()
Chiamato per segnalare che l’attività è in primo piano e può interagire con l’utente. Sempre
seguita da onPause().
protected void onPause()
Chiamato quando il sistema è sul punto di riprendere un’altra attività e l’attività corrente non
sta più interagendo con l’utente. Seguito da onResume()se l’attività ritorna in primo piano,
oppure da onStop() se diventa invisibile per l’utente.
protected void onStop()
Chiamato per segnalare che l’attività non è più visibile sullo schermo. Seguita da
onRestart() se l’attività arriva di nuovo in primo piano, oppure da onDestroy() se
l’activity viene distrutta.
protected void onRestart()
Chiamato prima di essere riavviata l’attività, dopo un precedente arresto. Sempre seguita da
onStart().
- 37 -
protected void onDestroy()
Metodo chiamato prima che l’activity viene distrutta.
La procedura standard richiede che, come prima riga di codice di ciascuno di questi metodi,
dev’essere richiamata l’implementazione di base del metodo che si sta ridefinendo:
@Override
protected void onStart() {
super.onStart();
// qui viene inserito il proprio codice
}
4.5.2. Intent e Intent Filter
L’Intent è un meccanismo di messagi che può attivare tre dei componenti di base di
un’applicazione: activity, service e broadcast receiver. L’oggetto Intent è una struttura dati
passiva che contiene una descrizione astratta dell’operazione da eseguire. L’intent contiene
informazioni per il componente che riceve l’intent (come l’azione da eseguire e i dati su cui
agire) e per il sistema Android (come la categoria dei componenti che dovrà maneggiare
l’intent e instruzioni riguardo il lancio dell’attività prevista).
Gli intents sono di due tipi:
Explicit (espliciti): indicano il componente obiettivo con il suo nome. I nomi
dei componenti di altre applicazioni non sono conosciuti e per questo motivo
gli intents espliciti sono usati tipicamente per messagi interni.
Implicit (impliciti): non indicano nessun componente. Sono di solito usati per
attivare componenti in altre applicazioni.
L’IntentFilter invece è una descrizione dell’insieme di intent impliciti che un
componente dell’applicazione può gestire. Esso, in prattica, filtra gli intent di un certo tipo.
4.5.3. Service
Un Service (servizio) è un componente dell’applicazione atto ad eseguire operazioni
a lungo termine in background, senza fornire alcuna interfaccia utente. Se un componente
applicativo attiva un Service, quest’ultimo inizia la sua esecuzione in background,
- 38 -
continuandola anche se l'utente passa ad un’altra applicazione. In aggiunta, un componente
puo collegarsi ad un servizio con cui vuole interagire e quindi attuare una comunicazione
inter-processo (IPC): per esempio, un servizio può fornire funzionalità di gestione di
connessioni di rete, riprodurre musica, fare I/O di file su memoria di massa o interagire con
un Content Provider, tutto questo dal background.
Un Service può essere di due tipi:
Started: un servizio è “started” quando un componente dell’applicazione
(come un’Activity) lo fa partire chiamando il metodo startService().
Una volta partito, un Service può girare in background per un tempo indefinito
e può continuare anche se il componente che l’ha messo in esecuzione e stato
distrutto. Di solito un servizio lanciato esegue una singola operazione e non
ritorna alcun valore al chiamante. Per esempio, può scaricare o caricare un file
su internet: quando l'operazione e conclusa, il servizio si ferma in modo
autonomo.
Bound: un servizio si dice “bound” quando un componente dell’applicazione si
connette ad esso chiamando il metodo bindService(). Un Service di tipo
“bound” offre un’interfaccia client-server che permette ai componenti di
interagire con esso, inviare richieste, ottenere risultati, e addirittura fare tutto
questo tra i processi attraverso l’utilizzo della comunicazione inter-processo
(IPC). Un servizio “bound“ esegue fino a quando un componente rimane legato
ad esso. È possibile legare nello stesso tempo più componenti ad un solo
servizio e solo quando tutti si disconnettono, il Service viene distrutto.
Le due tipologie di servizi possono entrare in esecuzione in entrambe le modalità:
possono essere “started” (per eseguire in un tempo indefinito) e nello stesso tempo permettere
anche il binding da parte di altri componenti. Il tutto dipende da quale metodo di callback
viene implementato all’interno del componente: onStartCommand() permette al
componente di avviare il servizio, mentre onBind() permette il binding. Senza considerare
il modo con cui il Service e stato avviato (“started”, “bound” o entrambi), qualsiasi
componente dell’applicazione può utilizzarlo (anche da un’applicazione separata) nella stessa
maniera in cui ogni componente può usare un’activity: avviarlo con un Intent. Tuttavia, per
ragioni di sicurezza, è possibile dichiarare il Service come privato (nel file Manifest) e
bloccare le richieste di accesso da parte di altre applicazioni.
- 39 -
4.5.4. Content Provider
I Content Provider gestiscono l’accesso ad un set di dati strutturati. Android viene
rilasciato con una varietà di Content Provider per tipi di dati comuni (audio, video, immagini,
informazioni di contatto personali, ecc.). Per rendere pubblici i propri dati ci sono due
possibilità: creare un Content Provider personalizzato (sottoclasse di ContentProvider)
oppure aggiungere i dati ad un Content Provider esistente (se ne esiste uno che riesce a
controllare gli stessi dati di riferimento e se si possiedono i permessi di scrittura). Ogni
applicazione può definire una o più tipologie di dati e rendere poi disponibili tali informazioni
esponendo uno o più Content Provider. Nell’ordine inverso, invece, qualunque applicazione
può richiedere l’accesso ad un particolare tipo di dato: il sistema la metterà in contatto con il
corrispondente Content Provider precedentemente installato nel sistema.
4.5.5. Broadcast Receiver
Il Broadcast Receiver è un componente che gestisce eventi di broadcast lanciati dal
sistema. Il sistema genera molti messaggi di broadcast (per esempio un messaggio che
annuncia che lo schermo è stato spento, che la carica della batteria è bassa o che è stata
appena scattata una foto) e tale funzionalità è svolta anche dalle applicazioni (per esempio per
notificare al resto del sistema che dei dati sono stati scaricati e sono disponibili per l’uso). I
Broadcast Receiver (come i Service) non mostrano un’interfaccia utente, ma possono creare
una notificazione sulla status bar per avvertire l’utente che un determinato evento è avvenuto.
Più comunemente può essere assimilabile ad un “gateway” per gli altri componenti, utilizzato
per eseguire una quantità minima di lavoro.
- 40 -
4.6. Strumenti di sviluppo
4.6.1. Eclipse
Come è stato già accenato, il linguaggio per lo sviluppo delle applicazioni è Java.
L’ambiente di sviluppo consigliato da Google è Eclipse.
Eclipse è uno degli IDE (Integrated Development Environment) più utilizzati al
mondo per la programmazione in Java. Esso è stato ideato da un consorzio di grandi società
quali Ericsson, HP, IBM, Intel, MontaVista Software, QNX, SAP e Serena Software,
chiamato Eclipse Foundation sul modello open-source. È un ambiente multi-linguaggio e
multi-piattaforma, essendo disponibile sia per Linux, che per Mac OS e Windows.
Figura 4.6 Immagine con l’ambiente di sviluppo Eclipse22
22 Fonte: Caffeine Dependency Injection http://www.caffeinedi.com/2010/07/03/beginning-google-android-development-for-net-developers-part-1/
- 41 -
4.6.2. Android Development Tools
Android Development Tools (ADT) è un plugin per Eclipse che fornisce un ambiente
di sviluppo professionale per creare applicazioni Android. ADT estende le capabilità di
Eclipse e integra gli strumenti dall’Android SDK, permettendo all’utente di cominciare un
nuovo progetto Android, creare l’interfaccia utente di un’applicazione, editare i file XML,
fare il debug ed esportare il file .apk per la distribuzione dell’applicazione.
4.6.3. Android SDK
L’Android SDK (Software Development Kit) fornisce tutti gli strumenti e le librerie
necessari allo sviluppo delle applicazioni per la piattaforma Android. Gli strumenti sono
classificati in due gruppi: strumenti SDK (SDK Tools) e strumenti di piattaforma (Platform
Tools). I tool SDK sono indipendenti dalla piattaforma, mentre i tool di piattaforma sono
personalizzati per ogni piattaforma Android.
Tra gli strumenti SDK più importanti si trovano:
android – permette di gestire gli AVD (Android Virtual Devices), i progetti e i
componenti SDK.
DDMS (Dalvik Debug Monitor Server) – tool che permette di fare il debug
dell’applicazione e la cattura schermo del dispositivo.
Draw 9-patch – offre la possibilità di creare grafica NinePatch usando un
editor. Usato per la creazione dei bottoni o icone cliccabili.
Android Emulator – dispositivo mobile virtuale che gira sul computer e può
essere usato per il testing di un applicazione senza aver bisogno di un
dispositivo fisico (Fig. 4.7).
Hierarchy Viewer – permette di fare il debug e di ottimizzare l’interfaccia
utente. Fornisce una rappresentazione visuale della gerarchia del layout.
Monkey – programma che gira sull’emulatore o sul dispositivo e genera flussi
di eventi utente a caso come clicchi o tocchi, e un numero di eventi di sistema.
Può essere usato per testare l’applicazione agli eventi di vario tipo.
ProGuard – strumento per la sicurezza del codice. Restringe, ottimizza e
offusca il codice rimovendo codice non usato e rinominando le classi, i campi e
- 42 -
i metodi con nomi vaghi. Il risultato sarà un file .apk più piccolo e più difficile
da decompilare (reverse engineer).
sqlite3 – permette di accessare e gestire i file SQLite creati e usati dalle
applicazioni Android.
Gli strumenti di piattaforma sono tipicamente aggiornati ogni volta che si installa una
nuova piattaforma SDK. Ogni aggiornamento è compatibile con le versioni precedenti. Di
solito, l’Android Debug Bridge (adb) è l’unico strumento di piattaforma usato.
Android Debug Bridge è uno strumento che permette all’utente di gestire lo stato di
un emulatore o di un dispositivo Android connesso. È usato anche per installare
un’applicazione Android su un device.
Figura 4.7 Modello di emulatore Android23
23 Fonte: Android Developers http://developer.android.com/tools/devices/emulator.html
- 43 -
5. Sviluppo del software
5.1. Il software per PC
Come modello per l’applicazione Android è stato usato il software per PC
provveduto insieme al dispositivo BGW dall’azienda STMicroelectronics.
Per poter eseguire la connessione con il BodyGateWay, il PC deve essere dotato di
un modulo Bluetooth. Dopo aver connesso il computer al dispositivo è possibile avviare il
programma. La finestra è divisa tra due diagrammi, uno in alto ed uno in basso. Nel primo
diagramma vengono visualizzati i grafici relativi all’elettrocardiogramma (ECG),
bioimpedenza (Z0 e dZ) e accelerometro per le tre assi (X, Y, Z). Nel secondo i grafici che
rappresentano la posizione del corpo (BodyPos), la frequenza cardiaca (HR), la frequenza
respiratoria (BR), il livello di attività fisica (AL), l’affidabilità del segnale (Reliab). Tutti i
grafici sono visualizzabili in tempo reale.
Figura 5.1 Cattura schermo dell’applicazione per il PC
- 44 -
5.2. Presentazione dell’applicazione
In questo sottocapitolo si farà una presentazione dell’applicazione BodyGateWay
nello stato in cui si trovava prima dell’inizio del lavoro di questa tesi.
All’accensione, il programma prima verifica la connettività Bluetooth (Fig. 5.2). Se
l’interfaccia è spenta provvede ad accenderla, poi entra nella schermata principale. Se si
sceglie di non attivare il Bluetooth oppure se non è possibile attivarlo, si esce
dall’applicazione. Questo è il motivo per cui non è possibile eseguire l’applicazione
sull’emulatore, poiché esso non supporta il Bluetooth.
Figura 5.2 Schermata all’avvio dell’applicazione nel caso in cui il Bluetooth non è già attivo
La schermata principale si compone di un’interfaccia grafica piuttosto semplice
composta dal logo ST in alto e due bottoni grandi in basso su un sfondo bianco (Fig. 5.3(a)).
Tutto questo rappresenta la main activity BodyGateWayActivity.
Toccando il pulsante “Scansione” si accede all’activity ListaDispActivity. Essa
contiene la lista dei dispositivi già accoppiati e dà la possibilità di fare una nuova scansione.
In seguito è possibile collegarsi ad uno dei dispositivi premendo semplicemente sullo schermo
sul rispettivo nome visualizzato (Fig. 5.3(b)). Ogni operazione compiuta verrà descritta sul
titolo della Dialog che mostra questa lista.
- 45 -
(a) (b)
Figura 5.3 Schermata principale (a) e il dialog che compare dopo aver premuto il buttone Scansione (b).
Scegliendo “BGW_DEMO” dalla lista si crea la connessione Bluetooth tra il
Bodygateway e il telefono. Sulla barra del titolo in destra compare il messaggio “in
connessione...” e poi alla connessione “connesso:BGW_DEMO” (Fig. 5.4 (a) e (b)).
(a) (b)
Figure 5.4 (a) e (b) Schermata con i messaggi sulla barra del titolo
- 46 -
Il fatto che la connessione è riuscita verrà segnalato anche tramite un messaggio
(Toast), che scomparirà dopo qualche secondo, ma anche mediante i due led del dispositivo
che emmetteranno luce ad intermittenza sincrona.
Il secondo bottone apre la schermata dei grafici che partono direttamente solo se la
connessione con il BGW è stabilita. Altrimenti compare in un Toast il messaggio “Non sei
collegato con nessun dispositivo”.
Per poter iniziare a inviare pacchetti verso il dispositivo Android, il Bodygateway
deve entrare in una particolare modalità chiamata Test Mode. Per fare questo si è dovuto
mandare un pacchetto costruito grazie alle informazioni relative nella documentazione
consegnata dalla STMicrolectronics.
L’applicazione dispone di un parser che estrae i dati significativi dal flusso di byte e
individua i pacchetti di vario tipo (ECG, Bioimpedenza, Acc, ecc.). Per effettuare la
schermata dei grafici si è scelto di utilizzare una libreria open-source chiamata AndroidPlot
versione 0.4.4. Utilizzando i valori catturati dal parser ai metodi della libreria si ottiene la
schermata che mostra i vari grafici in tempo reale.
Figura 5.5 Schermata dei grafici
Purtroppo, poiché si trova ai suoi albori, la libreria ha delle limitazioni. A causa
dell’approccio sbagliato e a tanti valori da elaborare, l’applicazione si blocca solo dopo pochi
- 47 -
secondi. Si è tentata una versione semplificata solo con l’ECG e la frequenza cardiaca, ma
purtroppo anche questa si blocca dopo alcuni minuti.
(a) (b) Figura 5.6 Cattura schermo che mostra il lavoro della CPU durante il blocco dell’applicazione (a) e versione
solo con l’ECG e la frequenza cardiaca (b)
- 48 -
5.3. Miglioramenti e nuove funzionalità
Il codice dell’applicazione non può essere interamente riprodotto poiché certi dettagli
tecnici del dispositivo sono informazioni considerate segreti industriali.
Il software è stato compilato usando le API dell’SDK di Android versione 2.3.3
Gingerbread e sviluppato con l’IDE Eclipse.
Per prima cosa è stato apportato un cambiamento al layout della schermata
principale: nuovo logo e sfondo grigio.
(a) (b)
Figura 5.7 Layout schermata principale prima (a) e dopo (b)
Utilizzando i metodi della libreria AndroidPlot sono stati fatti alcuni miglioramenti al
layout del grafico come forma della finestra, colori dei grafici, legenda, labels, domini. La
finestra è stata allargata per massimizzare l’area disponibile ai grafici. Per migliorare la
visibilità, i colori dei grafici e del loro sfondo sono stati cambiati. Come si osserva nella
Fig.5.8(a) gli elementi della legenda erano sovrapposti e il titolo, i labels e i domini non erano
allineati correttamente.
//metti solo numeri interi al range label
bgwLevels2Plot.getGraphWidget().setRangeValueFormat(new DecimalFormat("0"));
//metti solo numeri interi al domain label
- 49 -
bgwLevels2Plot.getGraphWidget().setDomainValueFormat(new DecimalFormat("0"));
bgwLevels2Plot.getGraphWidget().setPadding(5, 5, 0, 5);
bgwLevels2Plot.getGraphWidget().getGridBackgroundPaint().setColor(Color.BLACK);
bgwLevels2Plot.setDomainStepValue(5);
bgwLevels2Plot.setTicksPerRangeLabel(2);
bgwLevels2Plot.setRangeStepValue(9);
//cambia posizione del domain label
bgwLevels2Plot.position(bgwLevels2Plot.getDomainLabelWidget(),
10,
XLayoutStyle.ABSOLUTE_FROM_LEFT,
0,
YLayoutStyle.ABSOLUTE_FROM_BOTTOM,
AnchorPosition.LEFT_BOTTOM);
//cambia posizione del range label
bgwLevels2Plot.position(bgwLevels2Plot.getRangeLabelWidget(),
2,
XLayoutStyle.ABSOLUTE_FROM_LEFT,
0,
YLayoutStyle.RELATIVE_TO_CENTER,
AnchorPosition.LEFT_MIDDLE);
//modifiche border e margin
bgwLevels2Plot.setBorderStyle(Plot.BorderStyle.SQUARE, null, null);
bgwLevels2Plot.setPlotMargins(0, 0, 0, 0);
//modifiche legenda – grandezza e posizione
bgwLevels2Plot.getLegendWidget().setSize(new SizeMetrics(15,
SizeLayoutType.ABSOLUTE, 150, SizeLayoutType.ABSOLUTE));
bgwLevels2Plot.position(
bgwLevels2Plot.getLegendWidget(),
5,
XLayoutStyle.ABSOLUTE_FROM_RIGHT,
0,
YLayoutStyle.ABSOLUTE_FROM_BOTTOM,
AnchorPosition.RIGHT_BOTTOM);
//modifiche dimensioni icone legenda
bgwLevels2Plot.getLegendWidget().setIconSizeMetrics(new SizeMetrics(8,
SizeLayoutType.ABSOLUTE, 8, SizeLayoutType.ABSOLUTE));
bgwLevels2Plot.getLegendWidget().setDrawIconBorderEnabled(true);
bgwLevels2Plot.setPlotPadding(2, 2, 2, 2);
- 50 -
bgwLevels2Plot.setGridPadding(0, 10, 7, 0);
Inoltre sono stati corretti ai grafici e dappertutto nel codice i nomi sbagliati D0 e Dz
con dZ (deltaZ) e Z0 che rappresentano i parametri della bioimpedenza.
(a) (b)
Figura 5.8 Layout schermata grafici prima (a) e dopo (b)
Nella versione iniziale, la schermata dei grafici non era in un’activity separata, ma
nell’attività main. L’accesso si faceva nascondendo nel layout gli elementi relativi alla
schermata principale e rendendo visibili quelli relativi ai grafici. In questo modo, invece di
ritornare alla schermata principale quando si premeva il pulsante Back del telefono, si usciva
direttamente dall’applicazione. Questo è stato il prossimo obiettivo, di spostare tutto ciò che
riguarda i grafici in una nuova activity (BGWGraphActivity) con un nuovo layout
(graph.xml).
Sono stati individuati e risolti due bug. Il primo consisteva nel fatto che il testo sulla
barra del titolo (title bar) rimaneva bloccato su “in connessione” quando si tentava la
connessione con il BGW ed esso non era acceso. Ora compare “non connesso” fino alla
prossima scansione.
Il secondo bug era simile al primo nel fatto che, se il bluetooth si disattivava quando
si era connessi con il dispositivo, appariva il toast “La connessione è andata persa”, ma il
- 51 -
titolo rimaneva bloccato su “connesso:BGW_DEMO”. Ora compare “non connesso” fino alla
prossima connessione (Fig. 5.9).
(a) (b) Figura 5.9 Schermata con titolo bloccato su “connesso:BGW_DEMO” quando il Bluetooth è disattivato (a) e
schermata con il problema risolto (b)
Figura 5.10 Schermata della versione funzionante dell’applicazione
- 52 -
Nonostante l’aggiornamento della libreria AndroidPlot alla versione 0.5.0,
l’applicazione continuava a bloccarsi. Per risolvere questo problema è stato adottato un
approccio diverso nella stampa dei grafici. Inoltre, i grafici dell’accelerometro (X,Y,Z) e della
batteria sono stati rimossi per alleggerire l’applicazione (Fig. 5.10).
Per aumentare le funzionalità di questa applicazione sono state implementate le
opzioni di fermare e ripartire il trasferimento dati e di fare lo zoom sui grafici. Queste nuove
funzionalità sono molto importanti dato che i grafici possono essere fermati e analizzati da
personale medico.
Per fermare il trasferimento dati e implicitamente i grafici, si deve inviare al
Bodygateway un certo pacchetto specificato nella documentazione. Per lanciare questo evento
si deve tener premuto il bottone Menu del telefono per qualche secondo. Al momento
dell’arresto il telefono vibrera per un attimo per avvisare il paziente dell’evento.
@Override
public boolean onKeyLongPress(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_MENU) {
final Vibrator vibrator=(Vibrator)getSystemService(VIBRATOR_SERVICE);
vibrator.vibrate(100);
if(flag==1) {
disattivaTest();
flag=2;
}
else {
attivaTest();
flag=1;
}
return true;
}
return super.onKeyLongPress(keyCode, event);
}
Per lo zoom e lo scroll è stata creata una nuova classe chiamata MultitouchPlot che
estende XYPlot (classe della libreria AndroidPlot) e implementa OnTouchListener. Questa
classe sarà usata d’ora in poi per creare i grafici. Per fare lo zoom si usa la tecnica multi-touch
pinch-to-zoom che permette di allargare o rimpicciolire con due dita un oggetto. È possibile
anche scorrere in tutte le direzioni il grafico.
- 53 -
Figura 5.11 Cattura schermo con zoom sui grafici
Una nuova funzionalità è stata aggiunta: una lista di parametri che si aggiornano ogni
volta che arrivano nuovi pacchetti dal Bodygateway.
La prima cosa da fare è stata trovare e modificare un’icona per il nuovo bottone. Per
la modifica è stato usato il strumento Android chiamato Draw9patch. Attraverso le ninepatch
si possono definire quali parti di un’immagine hanno dimensioni variabili. Si tratta di
suddividere l’immagine in nove parti. L’interfaccia dello strumento è composta da due parti,
quella sinistra dove viene caricata l’immagine e dove si modifica, mentre in quella destra vi è
la visualizzazione delle tre possibili situazioni in cui il contenuto fosse più alto, più largo o
lasciato inalterato. La parte destra rappresenta quindi un preview del risultato che si vuole
ottenere. L’icona è stata modificata in modo che il testo scorra sotto l’imagine (Fig. 5.12).
- 54 -
Figura 5.12 L’immagine modificata con Draw9patch
Dopo sono state fatte delle modifiche come il layout della schermata principale e la
grandezza del font in modo che il nuovo bottone „Signals Monitor” è allineato con gli altri
(Fig. 5.13).
Figura 5.13 Layout della schermata principale con il nuovo bottone
- 55 -
A questo punto si inizializza il bottone con un listener per l’evento click e si crea una
nuova Activity chiamata ListaSignActivity collegata al buttone e alla quale si associa un
layout di tipo lista. Per mettere i dati in una lista si usa un adapter (adattatore). Poiché
l’adattatore predefinito permette di mettere su ogni riga solo un oggetto, esso è stato
modificato per accettare tre: un ImageView e due TextView.
private class CustomAdapter extends BaseAdapter {
private LayoutInflater inflater;
String [] arr1;
Integer [] arr2;
public CustomAdapter(String[] arr1, Integer[] arr2){
inflater = (LayoutInflater)
ListaSignActivity.this.getSystemService(Context.LAYOUT_INFLATER_SERVI
CE);
this.arr1 = arr1;
this.arr2 = arr2;
}
@Override
public int getCount() {
return arr1.length;
}
@Override
public Object getItem(int position) {
return null;
}
@Override
public long getItemId(int position) {
return 0;
}
private class ViewHolder {
ImageView img;
TextView tv1;
TextView tv2;
}
@Override
- 56 -
public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder holder;
if (convertView == null){
convertView = inflater.inflate(R.layout.signal_list_item, null);
holder = new ViewHolder();
holder.tv1 = (TextView)
convertView.findViewById(R.id.signal_name);
holder.tv2 = (TextView)
convertView.findViewById(R.id.signal_value);
holder.img = (ImageView) convertView.findViewById(R.id.icon);
convertView.setTag(holder);
} else {
holder = (ViewHolder)convertView.getTag();
}
String s = arr1[position];
if (s.startsWith("Heart")){
holder.img.setImageResource(R.drawable.heart);
holder.img.setPadding(6,0,7,0);
}
else if (s.startsWith("Breath"))
holder.img.setImageResource(R.drawable.lungs);
else if (s.startsWith("Activity")) {
holder.img.setImageResource(R.drawable.activity);
holder.img.setPadding(2,0,0,0);
}
else if (s.startsWith("Battery"))
holder.img.setImageResource(R.drawable.battery);
holder.tv1.setText(s);
holder.tv2.setText(String.valueOf(arr2[position]));
return convertView;
}
}
- 57 -
Figura 5.14 Cattura schermo della nuova Activity
Identico come per il Test Mode, sono stati implementati messaggi nel caso in cui non
si è collegati con il Bodygateway oppure se c’è perdita di connessione.
Nelle activity dei grafici e della lista è stato implementato un menu contenente due
bottoni: Informazioni e Cattura schermo (Fig. 5.15 (a)).
(a) (b)
Figura 5.15 Il menu di BGWGraphActivity (a) e il dialog informativo che compare quando si preme il bottone
Informazioni (b)
- 58 -
Il primo bottone apre un dialog informativo che contiene il logo ST, BodyGateWay
come titolo, e il Patient Id, cioè il numero identificativo del dispositivo in possesso. Se il
device non è connesso al telefono, sarà scritto “not connected” al posto dell’id (Fig. 5.15 (b)).
Il menu è stato creato usando il metodo predefinito onCreateOptionsMenu, al
quale vienne aggiunto un nuovo layout.
@Override
public boolean onCreateOptionsMenu(Menu menu) {
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.act_menu, menu);
return true;
}
Il layout act_menu è formato da due item corrispondenti ai due bottoni, che contengono un
id, un’icona, e un nome. Per aggiungere un’altro bottone si deve semplicemente aggiungere
un nuovo item.
<?xml version="1.0" encoding="utf-8"?> <menu xmlns:android="http://schemas.android.com/apk/res/android"> <item android:id="@+id/info" android:icon="@drawable/ic_menu_info_details" android:title="@string/info" /> <item android:id="@+id/screen" android:icon="@drawable/ic_menu_camera" android:title="@string/screen" /> </menu>
Ai bottoni del menu si devono associare delle azioni per provocare degli eventi. Ciò
è stato realizzato tramite il metodo onOptionsItemSelected(MenuItem item). Per
verificare quale bottone è stato premuto si usa il switch(item.getItemId()). Nel
caso dell’id del primo bottone si crea la dialog, come si osserva dal codice:
case R.id.info:
AlertDialog.Builder dialog = new
AlertDialog.Builder(this).setIcon(R.drawable.logo_1).setTitle(R.string.info_title)
.setCancelable(true).setNeutralButton("Ok", new DialogInterface.OnClickListener(){
public void onClick(DialogInterface dialog, int id) {
dialog.cancel();
- 59 -
}
});
if(BGWparser.patient_id != 0)
dialog.setMessage("Patient id: " + BGWparser.patient_id);
else dialog.setMessage(R.string.info_msg);
dialog.show();
return true;
Il secondo bottone invece esegue la cattura dello schermo e la salva in formato
immagine .png sulla memory card. Anche questa funzionalità è importante perché il paziente
può fare la cattura schermo e mandare l’immagine via e-mail ad un dottore.
Il nome del file è creato utilizzando la data e l’ora della cattura per avere un nome
unico ed evitare di sovrapporsi ad un altro file. Prima dell’operazione si fa una verifica dello
stato della memory card, nei casi di problemi con essa stampando dei messaggi di
avvertimento.
case R.id.screen:
if(statoMemCard.equals(Environment.MEDIA_MOUNTED)) {
try{
DateFormat df = new SimpleDateFormat("yyyy-MM-dd_HHmmss");
String path = Environment.getExternalStorageDirectory() +
"/graph_"+df.format(new Date())+".png";
shoot(av,path);
Toast.makeText(getApplicationContext(), "Cattura schermo
salvata in "+path, Toast.LENGTH_LONG).show();
}
catch (Exception e) {
Toast.makeText(getApplicationContext(), "C'è stata un problema
con la cattura schermo", Toast.LENGTH_SHORT).show();
System.out.println(e);
}
}
else if(statoMemCard.equals(Environment.MEDIA_REMOVED))
Toast.makeText(getApplicationContext(), "Memory Card non
presente", Toast.LENGTH_SHORT).show();
else if(statoMemCard.equals(Environment.MEDIA_MOUNTED_READ_ONLY))
Toast.makeText(getApplicationContext(), "Memory Card inserita
in modalità solo lettura", Toast.LENGTH_SHORT).show();
- 60 -
else Toast.makeText(getApplicationContext(), "C'è un problema con la
Memory Card", Toast.LENGTH_SHORT).show();
return true;
La cattura effettiva dello schermo è fatta nel metodo shoot(), che però non verrà
presentato.
Al menu si accede mediante lo stesso tasto che si usa per la sospensione della
trasmissione dei dati. Per differenziare tra le due azioni è stato usato l’inseguimento (tracking)
del tasto Menu nei metodi onKeyDown e onKeyUp.
@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
if (keyCode == KeyEvent.KEYCODE_MENU) {
event.startTracking();
return true;
}
return super.onKeyDown(keyCode, event);
}
@Override
public boolean onKeyUp(int keyCode, KeyEvent event){
if (keyCode == KeyEvent.KEYCODE_MENU && event.isTracking() &&
!event.isCanceled())
this.openOptionsMenu();
return super.onKeyUp(keyCode,event);
}
Un’altra cosa che è stata migliorata è l’icona del launcher dell’applicazione. Essa è
stata aggiustata, come consigliato nelle linee guida Android, per le tre versioni di risoluzione
di schermo. Inoltre, gli angoli dell’icona sono stati arrotondati per un aspetto migliore.
Come si osserva dalla Fig. 5.17, la cartella res (resources) contiene tre cartelle
drawable per diverse risoluzioni di schermo (hdpi, mdpi, ldpi). Qui sono state messe le
diverse icone usate nel launcher, nel menu e nel dialog Informazioni.
- 61 -
Figura 5.16 Icona del launcher prima e dopo la modifica
Invece nell’altra cartella drawable sono rimaste le immagini usate nell’applicazione
che non sono divise per misura.
Figura 5.17 Contenuto della cartella res
- 62 -
La cartella res contiene anche altre risorse divise in tre cartelle: layout, menu e
values. Le prime due contengono una serie di file xml che descrivono il layout delle activity e
del menu. La cartella values contiene il file strings.xml che e costituito da una serie di stringhe
utilizzate nell’applicazione (Fig. 5.18).
Figura 5.18 Contenuto delle cartelle layout, menu e values
Come ogni applicazione Android, anche l’applicazione BodyGateWay ha la stessa
struttura base (Fig. 5.19). Una delle più importanti cartelle è la src (source) e contiene i file
con il codice sorgente dell’applicazione. La directory gen (generated) contiene il file R.java
creato in automatico in fase di compilazione e costituito dai riferimenti alle risorse. Questo
file non deve essere mai modificato. Android 2.3.3 costituisce la versione Android utilizzata
contenente tutte le classi disponibili per lo sviluppo dell’applicazione. Nella cartella lib si
trovano le librerie usate che sono referenziate in Referenced Libraries. La cartella bin
contiene il file .apk di installazione dell’applicazione.
Infine c’è il file AndroidManifest.xml, che contiene in questo caso, oltre a varie
configurazioni, anche i permessi di usare il Bluetooth, la vibrazione e la memoria esterna.
- 63 -
Figura 5.19 Struttura finale progetto
In parallelo a questa applicazione è stata sviluppata anche la versione con solo l’ECG
e la frequenza cardiaca, la quale è stata rinominata BodyGateWay HB (Heart Beat). Tutte le
funzionalità della versione di base sono state implementate anche qui, l’unica cosa differente
è l’activity dei grafici.
All’inizio sono stati aggiunti i parametri Affidabilità Ecg e Livello batteria,
aggiornabili come Heart Rate ogni volta che arriva un rispettivo pacchetto.
In seguito sono stati inclusi un’animazione e un bottone. Inizialmente l’animazione
era del tipo FrameAnimation, cioè costituita in questo caso da due immagini di diversa
grandezza che si succedono ad intervalli stabiliti. Dopo è stata cambiata per motivi di estetica
e prestazioni con una ScaleAnimation, costituita da una sola immagine del cuore che viene
ingrandito e rimpicciolito ad intervalli regolari in modo di imitare il battito cardiaco.
- 64 -
Il bottone Start-Stop è destinato a sostituire l’azionamento del bottone Menu per
l’arresto della trasmissione dati dell’altra versione dell’app. Quando viene premuto, il bottone
cambia colore da rosso a verde e testo da “Stop” a “Start”. Ulteriormente gli angoli del
bottone sono stati arrotondati ed è stato dato un effetto gradient al colore.
(a) (b)
(c) (d)
Figura 5.20 Evoluzione dell’applicazione BodyGateWay HB
- 65 -
(a) (b)
(c) (d)
Figura 5.21 Schermate con il menu (a), il dialog Informazioni (b), il messaggio che compare dopo la cattura
schermo (c) e i file .png salvati nella memory card (d)
L’ultima aggiunta che è stata apportata ad entrambe le versioni dell’applicazione è
stata un dialog di conferma all’uscita dell’applicazione (Fig. 5.22). La funzionalità è stata
implementata mediante il metodo onBackPressed() nell’activity principale
BodyGateWayActivity.
- 66 -
@Override
public void onBackPressed() {
AlertDialog.Builder builder = new AlertDialog.Builder(this);
builder.setIcon(android.R.drawable.ic_dialog_alert)
.setTitle(R.string.titolo_esci)
.setMessage(R.string.esci)
.setCancelable(false)
.setPositiveButton("Si", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
finish();
}
})
.setNegativeButton("No", new DialogInterface.OnClickListener() {
public void onClick(DialogInterface dialog, int id) {
dialog.cancel();
}
});
AlertDialog alert = builder.create();
alert.show();
}
Figura 5.22 Dialog conferma uscita
- 67 -
5.4. Dispositivo Android utilizzato
Per il testing del software è stato utilizzato il telefono low-cost Samsung Galaxy
Next. L’utilizzo di un modello di smartphone low-cost dimostra l’efficienza dell’applicazione
e la possibilità di girare su dispositivi con potenza limitata di elaborazione. Questo permette la
distribuzione ad uno strato più ampio della popolazione.
Di seguito si trovano le specifiche più importanti del device.
Figura 5.24 Samsung Galaxy Next
MARCA E MODELLO
Marca Samsung
Modello S5570 Galaxy Next
MISURE E DIMENSIONI
Peso 109 g
Altezza 110,4 mm
Larghezza 60,6 mm
Profondità 12,1 mm
DISPLAY
Tecnologia display TFT
Risoluzione 240x320 QVGA
- 68 -
Diagonale 3,14 pollici
Densità display 127 dpi
Tipo Display Multi touch capacitivo
Touchscreen Si
Display 3D No
AUTONOMIA
Batteria Li-Ion 1200 mAh
Standby 180 ore
Conversazione 4 ore
HARDWARE E SO
S.O. Android OS
Versione originale 2.2.1 Froyo con UI TouchWiz 3.0
Versione aggiornata 2.3.4 Gingerbread con UI LaucherPro 0.8.6
Processore 600 MHz
Dual Core No
GPU Si
Modello GPU Adreno 200
RAM 278 MB
ROM 160 MB
Memoria espandibile Si (microSD/SDHC fino a 32 GB)
DATI E CONNETTIVITA'
USB Si (2.0)
Mini-USB Si
Bluetooth Si (2.1)
Irda No
Wifi Si (802.11 b/g/n)
NFC No
Uscita HDMI No
SENSORI
Sensore di prossimità Si
Accelerometro Si
Bussola digitale Si
Giroscopio No
- 69 -
Barometro No
GPS Si (A-GPS)
SUPPORTO RETI
GSM Quad Band (850/900/1800/1900)
Rete HSDPA 7.2Mbps
Wap Si (2.0.0)
GPRS Si (Classe 10, 48 kbps)
Modulo UMTS Si
Edge Si
MULTIMEDIA
Lettore Mp3 Si (Player)
Lettore Mpeg4 Si (Player)
Radio FM Si
Jack audio Si (3,5mm)
FORMATI AUDIO E VIDEO
Audio MP3, AAC, AAC+, eAAC+, MIDI, WAV
Video 3GP, MPEG4, WMV, H.263, H.264
FOTOCAMERA
Risoluzione fotocamera 3,15 Mpx (2048x1536)
Flash No
Autofocus Si
Fotocamera secondaria No
Zoom Digitale 3x
Risoluzione Video 320x240 px QVGA a 15 fps
Videochiamata No
- 70 -
6. Conclusioni e Sviluppi Futuri
Con il presente lavoro si è cercato di migliorare l’applicazione Android per
comunicazione con il dispositivo BodyGateWay. Gli obbiettivi di questo progetto sono stati
raggiunti: l’applicazione è funzionante, senza blocchi, e mostra i dati e i grafici in tempo reale
pronti per essere consultati da paziente o personale medico. Oltre a questo sono apportate
delle nuove funzionalità molto importanti.
Per questo lavoro è stato necessario apprendere i concetti e l’utilizzo di strumenti per
la programmazione destinata alla piattaforma Android, ma anche studiare e capire la
documentazione inviata da STMicroelectronics.
Vorrei ringraziare il prof. Dragoni per avermi consigliato questo progetto e per la
fiducia accordata.
L’applicazione può essere migliorata sia dal punto di vista del design, ma anche
aggiungendo delle nuove funzionalità. Consiglio l’implementazione della possibilità di
controllare anche i grafici dell’accellerometro oppure di altri parametri che verranno inclusi in
future versioni del device BodyGateWay.
Inoltre è possibile fare il porting del software verso altre piattaforme come Windows
Phone e iOS, che necessitano i linguaggi di programmazione C# e rispettivamente Objective-
C. Questo implica l’individuazione per ogni piattaforma di librerie adatte per creare i grafici.
- 71 -
7. Bibliografia
1. Andrea Vitali, Marco Pessione, STMicroelectronics. Detection, Processing And
Wireless Transmission Of Biologic Signal: The Electronic Patch "BodyGateWay".
efytimes.com. [Online] http://www.efytimes.com/e1/creativenews.asp?edid=63194
2. Vanni Saviotti, STMicroelectronics. The Body Gateway: mHealth Platform for
Wearable Devices. MEDS – Medical Electronic Device Solutions [Online]
http://medsmagazine.com/2012/01/the-body-gateway-mhealth-platform-for-wearable-
devices/
3. STMicroelectronics [Online] http://www.st.com/
4. Andrea Vitali, STMicroelectronics.
Dispositivi bio-elettronici: sensori per la salute e il benessere. [Online]
http://www.arti.puglia.it/fileadmin/user_files/download/Andrea_Vitali__STM.pdf
5. Android and iOS Surge to New Smartphone OS Record in Second Quarter, According
to IDC. IDC [Online] http://www.idc.com/getdoc.jsp?containerId=prUS23638712
6. Android [Online] http://www.android.com/about/
7. Android developers [Online] http://developer.android.com
8. Mobile Platforms: The clash of ecosystems, Vision Mobile [Online]
http://www.visionmobile.com/blog/2011/11/new-report-mobile-platforms-the-clash-
of-ecosystems
9. La storia di Android. Android Caotic [Online] http://android.caotic.it/2012/05/la-
storia-di-android-capitolo-1-le-origini/
10. L’architettura di Android. DevAPP [Online] http://android.devapp.it/larchitettura-di-
android
11. Android Architecture - The Key Concepts of Android OS. [Online]
http://www.android-app-market.com/android-architecture.html
12. Carlo Pellicia, Lezioni di Programmazione su Android. [Online]
http://www.sauronsoftware.it/teaching/uniroma2/android/
13. Massimo Carli, Android 3: Guida per lo sviluppatore. Google Libri [Online]
http://books.google.it/books?id=wDUSkilIBaQC&printsec=frontcover&hl=it&source
=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
14. Struttura di un’applicazione Android. Simplesoft [Online]
http://www.simplesoft.it/android/struttura_di_un_applicazione_android.html
- 72 -
15. AndroidPlot [Online] http://androidplot.com/wiki/Docs
16. Luca Buccoliero, E-Health – Tecnologie per il patient empowerment [Online]
http://www.mondodigitale.net/Rivista/10_numero_4/Buccoliero_p_3_17.pdf
17. Maria Dell’Osso, Tutta la verità sull’e-Health. Pubblica Amministrazione [Online]
http://www.pubblicaamministrazione.net/governance/articoli/465/p1/tutta-la-verita-
sulle-health.html
18. Telemedicina. Ministero della Salute [Online]
http://www.salute.gov.it/eHealth/paginaInternaEHealth.jsp?id=2515&lingua=italiano
&menu=telemedicina
19. La telemedicina. e-health [Online] http://unifihealth.blogspot.it/
20. mHealth app market trends and figures 2011-2016. Key4biz [Online]
http://www.key4biz.it/Analisi_e_Dati/Reports/2012/03/mHealt_Mobile_Applicazioni
_Mercato_Smartphone_Tablet_Research2Guidance_Rapporto.html
21. Giampiero Papi, Fabrizio L. Ricci, La Telemedicina [Online]
http://www.uniroma2.it/didattica/fam/deposito/Telemedicina.pdf
22. Christine Zhenwei Qiang, Masatake Yamamichi, Vicky Hausman, Daniel
Altman, Mobile Applications for the Health Sector. [Online]
http://www.thinkinnovation.org/it/blog/2012/09/mobile-applications-for-the-health-
sector/
23. Jens Kargaard Madsen, Henrik Karstoft, Finn Overgaard Hansen, Thomas
Skjødeberg Toftegaard, ASE-BAN, a Wireless Body Area Network Testbed
24. Wikipedia – L’enciclopedia libera. [Online] http://it.wikipedia.org
25. Wikipedia – The free encyclopedia. [Online] http://en.wikipedia.org
