WattsUP: monitoraggio energetico su Android - POLITECNICO DI TORINO
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
POLITECNICO DI TORINO
III Facoltà di Ingegneria
Corso di Laurea Specialistica in Ingegneria Informatica
Tesi di Laurea Specialistica
wattsUP: monitoraggio
energetico su Android
Relatori: Candidato:
Prof. Fulvio Corno Daniele Antoci
Dott. Luigi De Russis Matr. 162882
Dicembre 2012
Ringraziamenti
Desidero innanzitutto ringraziare i miei relatori, il Prof. Fulvio Corno e il
Dott. Luigi De Russis, per la disponibilità dimostratami e per avermi accom-
pagnato durante il lavoro di tesi con preziosi ed efficaci consigli.
Il ringraziamento più grande va a tutta la mia famiglia, per avermi sem-
pre incoraggiato e sostenuto in questo lungo percorso universitario. Grazie
ai miei genitori, punto di riferimento e maestri di vita. Grazie a Dario,
fratello maggiore come pochi, sempre presente nei momenti più difficili, ma
soprattutto in quelli più belli.
Infine non posso dimenticare di ringraziare gli amici per aver condiviso sia
momenti di serietà e studio, che momenti di divertimento. Grazie a quelli
nuovi, che quest’esperienza da studente fuori sede ha deciso di regalarmi, e
a quelli di sempre, per essere costantemente presenti nonostante la distanza
e il trascorrere degli anni.
i
Indice
1 Introduzione 1
1.1 Contesto generale . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 La Domotica e la Building Automation . . . . . . . . . . . . . 2
1.2.1 Differenze tra impianti tradizionali ed impianti domotici 2
1.2.2 Vantaggi e campi di applicazione . . . . . . . . . . . . 4
1.2.3 Protocolli di comunicazione standard vs. protocolli
proprietari . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Obiettivi 8
3 Tecnologia utilizzata 17
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Ambiente domotico utilizzato . . . . . . . . . . . . . . . . . . 17
3.2.1 Dog . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2 DogOnt . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3.1 Risorse per gli sviluppatori . . . . . . . . . . . . . . . . 25
3.3.2 Android SDK . . . . . . . . . . . . . . . . . . . . . . . 28
3.4 XML-RPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4 Design 33
4.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Scelte progettuali e funzionalità . . . . . . . . . . . . . . . . . 35
4.2.1 Le stanze . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.2 Informazioni sui device più energivori . . . . . . . . . . 39
4.2.3 Impostazioni . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.4 Gestione della colorazione . . . . . . . . . . . . . . . . 41
4.2.5 Visualizzazione allarme . . . . . . . . . . . . . . . . . . 43
4.3 Realizzazione dell’interfaccia utente . . . . . . . . . . . . . . . 44
4.3.1 La disposizione delle stanze . . . . . . . . . . . . . . . 45
4.3.2 Visualizzazione delle stanze . . . . . . . . . . . . . . . 48
4.3.3 Elementi grafici . . . . . . . . . . . . . . . . . . . . . . 51
4.4 Interazione con Dog . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Organizzazione e riusabilità del codice . . . . . . . . . . . . . 57
5 Testing 58
5.1 Svolgimento del test . . . . . . . . . . . . . . . . . . . . . . . 60
ii
INDICE
6 Risultati Ottenuti 62
6.1 Analisi qualitativa . . . . . . . . . . . . . . . . . . . . . . . . 62
6.2 Valutazione rispetto agli obiettivi preposti . . . . . . . . . . . 65
7 Conclusioni e sviluppi futuri 68
7.1 Possibili sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . 69
I Appendici 72
A Test Plan 73
B Commenti utente 80
Elenco delle figure 82
Elenco delle tabelle 84
Bibliografia 85
iii
Introduzione
1
1.1 Contesto generale
Negli ultimi anni, avvenimenti, come i cambiamenti climatici, l’esaurimento
delle fonti energetiche e delle risorse naturali, rendono l’impiego intelligente
ed efficace dell’energia un tema di rilevante importanza e di notevole impat-
to sociale. Secondo alcuni studi sul consumo energetico, infatti, il settore
privato incide per circa il 40% sul consumo finale di energia, valore che può
raggiungere anche più del 70% se consideriamo esclusivamente il consumo
elettrico nei locali residenziali e commerciali, motivato dalla continua mag-
giore richiesta di “benessere e comfort” da parte dell’utente finale, come ad
esempio il crescente utilizzo e la larga diffusione della climatizzazione.
La situazione politica mondiale, la crisi economica e la diffusione di stili di
vita sempre più “green” ed ecosostenibili, nonchè l’esaurimento delle risorse,
stanno fortunatamente spingendo verso un cambiamento globale, orientato
sempre più allo sviluppo e alla diffusione di energie rinnovabili. Tra queste
primeggiano nuove fonti energetiche quali il fotovoltaico, il geotermico, l’eo-
lico e l’idroelettrico. Ma, oltre all’utilizzo di energie rinnovabili, si stanno
diffondendo anche interventi atti a incrementare le prestazioni energetiche
sia degli edifici di nuova costruzione sia di quelli già esistenti, tramite oppor-
tuni progetti di ristrutturazione, utilizzando, ad esempio, materiali isolanti
ad altissime prestazioni o installando pannelli solari sui tetti delle abitazioni.
Nell’immaginario collettivo vi è l’idea, non del tutto corretta, che l’attuazio-
ne di questo tipo di accorgimenti sia sufficiente a rendere il proprio ambiente
domestico un luogo ad alto risparmio energetico e che non sia necessario fare
altro per migliorarne l’efficienza.
Questo infatti è vero solo in parte, perchè per quanto possa essere necessario
rendere la propria casa efficiente e ottimizzata dal punto di vista dell’isola-
mento termico, o parzialmente autosufficiente energeticamente, bisogna an-
1
1.2. LA DOMOTICA E LA BUILDING AUTOMATION
che gestire in modo opportuno gli impianti più energivori della casa, ovvero
quello termico e quello elettrico. In questo contesto entra in gioco la domo-
tica, come strumento capace di aiutarci a gestire e comprendere al meglio
ciò che avviene in tempo reale nella nostra abitazione, e ad amministrarne,
ad esempio, le potenzialità di risparmio energetico offerte dai vari dispositivi
dislocati negli ambienti della casa.
1.2 La Domotica e la Building Automation
La nascita dei sistemi di automazione per la casa e gli edifici è da ricondurre
alla seconda metà degli anni ’80 quando, sulla base di esperienze provenien-
ti dall’automazione di fabbrica, sono state sviluppate e rese fruibili alcune
innovative tecnologie del settore informatico, elettronico e delle telecomuni-
cazioni, con l’obiettivo di rendere più intelligenti, integrati e coordinati gli
impianti tecnici di un edificio (elettrico, condizionamento, antifurto, ecc.).
Nei decenni successivi le stesse tecnologie sono state ulteriormente sviluppate
per essere impiegate in edifici residenziali, ed è proprio in questo periodo che
va affermandosi il termine “domotica”.
Domotica deriva dal termine francese “Domotique” che unisce la radice lati-
na di “Domus” (casa) al termine “informatica”, e riassume così esattamente
il connubio fra i due ambiti: con domotica, infatti, si indica sommariamen-
te l’automazione tecnologica della casa, con sistemi informatici, elettronici
e robotici. Anche se il termine “casa” è inteso in senso lato, in quanto ogni
tipologia abitativa e non abitativa può essere “domotizzata”, anche gli uffici,
i magazzini, gli alberghi, i centri congressi, e via discorrendo. Anzi, gli interi
edifici possono essere predisposti per la domotica, nel qual caso si parla di
Building Automation, mentre per il ramo dedicato alle singole unità (abita-
tive e non) ci si riferisce alla Home Automation.
In sintesi, è possibile considerare la domotica come quell’insieme di tec-
nologie, di sistemi e di servizi atti a rendere intelligente ed integrato il
funzionamento dei differenti tipi di impianti presenti in un’abitazione.
1.2.1 Differenze tra impianti tradizionali ed impianti
domotici
Una volta chiarito per grandi linee cosa si intende, e di cosa si occupa la
domotica, è bene precisare quale sia la differenza sostanziale tra un impian-
2
1.2. LA DOMOTICA E LA BUILDING AUTOMATION
to tradizionale e uno domotico. Un impianto domotico differisce da uno
tradizionale sia in base a come l’impianto stesso viene comandato da parte
dell’utente, sia nella possibilità di integrazione completa degli impianti tecni-
ci presenti nell’ambiente da controllare, che come abbiamo già detto possono
essere svariati: illuminazione, condizionamento, segnalazione d’emergenza,
movimentazione tapparelle e tende, ecc. Il coordinamento, in un impianto
tradizionale, è costituito semplicemente dal collegamento fisico che è utiliz-
zato per realizzare il circuito di comando: in altri termini, un interruttore
deve il suo nome proprio alla funzione di interruzione del circuito che ali-
menta l’utenza. In un impianto domotico, invece, il circuito di comando è
fisicamente separato dal circuito di alimentazione: è costituito, quindi, da
una rete di segnale con cui i dispositivi di comando e di attuazione, dotati
di una propria elettronica di elaborazione e comunicazione, sono in grado di
scambiare informazioni sotto forma di messaggi codificati in forma digita-
le, mentre il circuito di alimentazione collega le sole utenze che necessitano
della tensione di rete (230 Volt) per il loro funzionamento. A differenza di
un impianto tradizionale in cui le singole installazioni sono indipendenti e
non possono comunicare tra loro, un sistema domotico, pertanto, consente
la totale integrazione di tutti gli impianti presenti in un edificio, così come
illustrato in Figura 1.1
Figura 1.1: Confronto tra impianto elettrico tradizionale e impianto domotico
3
1.2. LA DOMOTICA E LA BUILDING AUTOMATION
1.2.2 Vantaggi e campi di applicazione
L’utilizzo di sistemi domotici permette di ottenere dei benefici per l’utente
finale che è difficile, se non impossibile, raggiungere con un impianto tra-
dizionale, in primo luogo l’incremento del comfort e della qualità della vita
all’interno dell’ambiente automatizzato. Il classico interruttore di casa, ad
esempio, che normalmente è dedicato all’accensione o spegnimento delle luci
può essere impiegato come comando dell’impianto di irrigazione o per l’atti-
vazione dell’antifurto. Il concetto chiave è quello di “scenario”: l’esecuzione
contemporanea e coordinata, tramite un solo comando, di molteplici funzioni
che coinvolgono parti di impianti diversi. È possibile, infatti, far dialogare
l’impianto antifurto con l’impianto di videosorveglianza e con tutti gli altri
impianti della casa, e di integrare i dispositivi ad impatto visivo (come le
telecamere di videosorveglianza). Le funzioni domotiche di un edificio posso-
no essere comandate anche da remoto mediante l’utilizzo di un collegamento
Internet o di telefoni cellulari, così come eventuali allarmi o stati di allerta di
un impianto (fughe di gas, intrusione di ladri in appartamento, ecc. ) posso-
no essere inviati via email o tramite SMS. Infine è bene menzionare l’ausilio
sociale che la domotica può offrire, potendo venire incontro alle esigenze delle
persone con limitazioni motorie o con particolari esigenze di fruibilità dell’im-
pianto elettrico, come i bambini e gli anziani. Un esempio potrebbe essere
l’impiego di comandi vocali integrati che permettano l’utilizzo dell’impianto
domotico senza agire fisicamente sui controlli.
1.2.3 Protocolli di comunicazione standard vs. proto-
colli proprietari
Per poter comprendere quale sia la struttura di un impianto domotico può
essere utile rifarsi ai principi costruttivi delle reti di calcolatori: un impianto
domotico è in effetti assimilabile a una rete di comunicazione in cui i di-
spositivi sono collegati tra loro attraverso un mezzo trasmissivo. Per poter
comunicare, i dispositivi devono poter parlare lo stesso linguaggio, ossia de-
vono avere lo stesso protocollo di comunicazione.
È possibile distinguere due tipologie di standard di comunicazione:
1. protocolli proprietari;
2. protocolli standard.
I protocolli proprietari sono sviluppati da un singolo costruttore la cui tecno-
logia è soggetta a brevetti. Per questa tipologia di protocolli la compatibilità
4
1.2. LA DOMOTICA E LA BUILDING AUTOMATION
con sistemi di altre aziende è parziale o inesistente, nonostante le funzionalità
fornite potrebbero anche risultare superiori.
I protocolli standard, invece, presuppongono che le specifiche siano pubbliche
e accessibili a chiunque voglia costruire o integrare dispositivi comunicanti
con il protocollo medesimo. In questo caso, prodotti di marche diverse, se
condividono lo stesso protocollo di comunicazione, possono perfettamente
funzionare tra loro nel medesimo impianto. Pertanto, per la realizzazione
di un sistema domotico perfettamente integrato sarebbe preferibile orientarsi
verso tecnologie standard.
È tuttavia doveroso chiarire che realizzare un impianto domotico utilizzando
solo dispositivi dello stesso produttore, o che si appoggino tutti sullo stesso
standard, può rappresentare un limite sia per l’impianto stesso che per chi
ne usufruisce. Potrebbe infatti verificarsi un problema nel momento in cui
avviene un guasto e non siano più disponibili ricambi in commercio, o sem-
plicemente quando un nuovo componente di controllo è fornito da un solo
produttore che utilizza un protocollo diverso da quello utilizzato nel resto
dell’impianto domotico.
Figura 1.2: Esempio funzionalità gateway domotico
51.3. STRUTTURA DELLA TESI
Si dovrebbero a tal punto sostituire tutti gli altri dispositivi, comportando
un notevole disagio economico, oppure far convivere due sistemi diversi che
lavorino in parallelo, o altresì rinunciare all’installazione di quel dispositivo.
In realtà l’utilizzo di un gateway domotico, mostrato in figura 1.2, proprio
come quello impiegato durante la tesi riesce a risolvere il problema di co-
municazione fra protocolli differenti, portando la comunicazione fra i vari
dispositivi ad un livello di astrazione più elevato e permettendo quindi di
utilizzare protocolli non standard, o di fare un upgrade dell’impianto intro-
ducendo nuove tecnologie come ad esempio delle prese wireless.
Il gateway permette infatti di gestire a basso livello, per mezzo di specifici
driver, tutte le apparecchiature ad esso collegato, occupandosi, tra le altre
cose, della traduzione dei messaggi da e verso i dispositivi, che potranno
pertanto utilizzare protocolli di comunicazione differenti. Si potranno quindi
installare sullo stesso impianto domotico dispositivi di varie marche, purchè
sia possibile fornire il driver di connessione con il gateway.
1.3 Struttura della tesi
In questo primo capitolo, si è cercato di introdurre il contesto e fornire alcuni
strumenti base per comprendere il punto da cui è partita la realizzazione
dell’applicazione che è il prodotto finale di questo progetto. Nei prossimi tre
capitoli, la tesi è organizzata per presentare gli obiettivi e approfondire alcuni
aspetti, seppur di background, necessari a comprendere appieno il come e il
perchè si è realizzata l’interfaccia utente; nei capitoli seguenti, invece, si
mostreranno le fasi di progettazione e di implementazione del progetto e si
presenteranno i risultati ottenuti.
In dettaglio:
• nel capitolo DUE “Obiettivi ” si illustrerà uno studio sui prodotti com-
merciali esistenti relativi alla visualizzazione e il monitoraggio ener-
getico per mezzo di display informativi dislocati in opportuni punti
dell’abitazione. Questo, insieme ai risultati di una ricerca esistente
sulle preferenze dell’utente in merito all’utilizzo di tali dispositivi, aiu-
teranno a tracciare dei requisiti minimi per la realizzazione di un’in-
terfaccia utente semplice e intuitiva da utilizzare per l’applicazione da
sviluppare.
• nel capitolo TRE “Tecnologia utilizzata”, verrà descritto il gateway do-
motico proposto dal Politecnico di Torino, cioè Dog, analizzando breve-
mente l’ontologia che racchiude lo schema della casa e i suoi dispositivi.
61.3. STRUTTURA DELLA TESI
Inoltre si presenterà il sistema operativo per dispositivi mobili Android
e l’ambiente di sviluppo Eclipse, riassumendone, per quanto possibile,
le principali caratteristiche.
• nel capitolo QUATTRO “Design”, si presenteranno le varie scelte pro-
gettuali fatte, si parlerà di come è stata realizzata l’interfaccia utente,
e di come questa interagisce con Dog. Si discuterà anche dell’organiz-
zazione del codice e del suo possibile riutilizzo.
• nel capitolo CINQUE “Risultati ottenuti ”, si presenterà qualche risulta-
to qualitativo e quantitativo derivato dall’utilizzo dell’interfaccia, sof-
fermandosi in particolare ad analizzare l’effettivo miglioramento otte-
nuto rispetto agli studi svolti in precedenza e su quali ci si è basati
come punto di partenza.
• nel capitolo SEI “Conclusione e sviluppi futuri”, verranno elencati al-
cuni sviluppi futuri che il progetto descritto in questa tesi potrà avere.
72
Obiettivi
L’obiettivo principale della tesi è lo studio, la progettazione e la realizzazione
di un’interfaccia grafica per il monitoraggio energetico in ambito domestico.
Si consideri, a tal proposito, la seguente immagine:
Figura 2.1: Vista, ad alto livello, del contesto in cui si colloca l’interfaccia
utente da realizzare
Essa mostra un utente che interagisce con la propria casa (ambiente do-
motico) attraverso un tablet su cui è installata l’applicazione sviluppata. Per
interagire con efficacia, però, necessita di un’interfaccia utente che, da una
8parte, si possa collegare all’ambiente domotico e dall’altra sia gestibile facil-
mente dal tablet.
Assumendo di non avere alcun tipo di problema nel collegare una qualsiasi
interfaccia utente al sistema di controllo domotico Dog, si può notare che
qualche problema potrebbe sorgere proprio nel trovare un’interfaccia uten-
te utilizzabile con un dispositivo touchscreen, che sia al contempo intuitiva,
funzionale, e che risponda a determinati principi di usabilità.
A tale scopo, si è approfondito l’argomento della visualizzazione su display
di informazioni riguardanti il consumo energetico, effettuando svariate ricer-
che sul Web, visitando i siti dei maggiori produttori di impianti domotici e
confrontando alcune delle soluzioni proposte in merito.
Un esempio per tutte viene riportato in figura 2.2 dove viene visualizzata
un’interfaccia che mostra i consumi di alcune stanze presenti in un ambiente
domotico della NNOX Domotics1 .
Figura 2.2: Esempio visualizzazione livelli energetici in un sistema della
NNOX Domotics
Come si può vedere dalla figura 2.2, per questa interfaccia utente è stato
deciso di fornire sia un’informazione numerica, che una grafica. L’informazio-
ne numerica sta ad indicare il consumo energetico attuale, replicato tramite
1
NNOX Domotics: http://nnox.com/energy/
9una rappresentazione grafica di un manometro digitale, che ne indica il li-
vello per mezzo di una lancetta. Si può anche notare come la lancetta di
tale manometro indichi oltre che un valore, se pur approssimativo, anche un
colore di sfondo che varia col consumo energetico, virando dal verde al rosso
e passando dall’arancio, per indicare il passaggio da valori bassi a valori al-
ti di assorbimento. Informazioni, queste, replicate per ogni stanza presente
nell’ambiente controllato.
Da un’analisi più approfondita si nota però come i valori massimi siano iden-
tici per tutti gli ambienti controllati, supponendo quindi che in soggiorno
(Living Room) come in sala da pranzo (Dining Room) o in camera da letto
(Bedroom) vi sia un consumo massimo di 8kW e rapportandone quindi la
visualizzazione grafica rispetto a quei valori. Stiamo ovviamente parlando
di un solo esempio, ma che in quanto tale, mette in evidenza la necessità di
avere per ogni ambiente una regola di visualizzazione rapportata all’effettiva
capacità massima della stanza supponendo di avere tutti i dispositivi attivi.
In particolare, le varie interfacce esistenti prese in considerazione durante la
fase di ricerca, seppur con alcuni aspetti positivi come l’indicazione con co-
lori diversi in base al consumo, o il mostrare a video il consumo attuale per
ogni stanza, non rispettano alcune delle richieste emerse fuori da uno studio
pubblicato precedentemente e da cui l’obiettivo principale della tesi prende
spunto.
Lo studio in questione è “Home energy consumption feedback: A user survey”
che ha l’obiettivo di valutare due differenti modalità di visualizzazione dei
dati energetici e l’interazione da parte dell’utente con esse, per mezzo di un
In-Home Display2 (IHD), testandone l’effettivo funzionamento su un conside-
revole numero di persone abituate ad utilizzare apparecchi elettronici. Per
mezzo quindi di un apposito questionario proposto agli intervistati, si sono
raccolti dati sulle attitudini al risparmio di queste persone, sulla compren-
sione delle visualizzazioni proposte, ed eventuali suggerimenti in merito a
modifiche e miglioramenti da apportare.
Le due modalità di interazione prese in considerazione si suddividono in:
1. visualizzazione di consumi energetici periodici, ad esempio giornalieri
o mensili;
2. feedback visivo immediato di quanto sta avvenendo nell’ambiente do-
mestico.
2
In-Home Display: è un dispositivo di visualizzazione dedicato, progettato per fornire
informazioni relative al settore energetico, quali consumi, costi o messaggi di servizio forniti
direttamente dal distributore di energia o per mezzo di applicazioni di terze parti.
10Per fare ciò sono stati realizzati due prototipi di interfaccia che implementa-
no rispettivamente le due differenti tipologie di visualizzazione sopra citate e
successivamente sono stati registrati due brevi video in time-lapse3 che mo-
strano i cambiamenti di queste interfacce, quali variazioni di colori e dati
riguardanti i consumi, in base all’utilizzo di vari dispositivi di uso quotidiano
in un appartamento nell’arco di una giornata.
È stato quindi chiesto ad un migliaio di persone di guardare i due video e
successivamente rispondere a un questionario, per valutare quanto queste due
visualizzazioni fossero state comprese ed apprezzate.
Nello specifico si mirava a:
• verificare/confermare la volontà degli utenti intervistati di adottare
effettivamente un sistema di visualizzazione dei consumi;
• valutare se le persone comprendevano e accettavano di più l’idea di
un’interfaccia basata su degli obiettivi prefissati di consumo energetico,
o sulla visualizzazione immediata dei consumi e di come questi influisco
globalmente sull’abitazione;
• verificare la validità di un feedback basato sulla variazione dei colori in
parallelo con l’utilizzo di valori espliciti riguardanti i consumi energetici;
• verificare se le informazioni fornite sono di facile comprensione per gli
utenti, se sono utili e se sono necessari più o meno dettagli;
• indagare sulle preferenze riguardanti il posizionamento dell’in-home
display (IHD) in uno specifico punto dell’appartamento.
I risultati di questo studio hanno indicato come la maggior parte delle persone
vorrebbe effettivamente adottare un sistema IHD, dimostrando un importan-
te interesse verso l’argomento risparmio energetico.
Circa la metà degli intervistati vorrebbe un sistema che integrasse entrambe
le visualizzazioni, ma preferirebbe la visualizzazione ad obiettivi periodici se
lo scopo fosse solo quello di incrementare le propria attitudine al risparmio
energetico. Tuttavia il sistema di feedback immediato dell’attività energeti-
ca sembra essere compreso meglio, appunto perchè riesce a rappresentare i
consumi in tempo reale.
3
Time-lapse: è una tecnica cinematografica nella quale la frequenza di cattura di ogni
fotogramma è molto inferiore a quella di riproduzione. A causa di questa discrepanza,
la proiezione con un frame rate standard di 24 fps fa sì che il tempo, nel filmato, sembri
scorrere più velocemente del normale.
11Nonostante quindi la visualizzazione ad obiettivi sia più indicata per mi-
gliorare il consumo di energia globale sul medio/lungo periodo, il feedback
diretto è più utile per visualizzare informazioni relative all’immediato, come
ad esempio verificare la presenza di dispositivi in funzione che nessuno sta
utilizzando.
Inoltre i dati raccolti indicano anche che la visualizzazione basata sui colori
è semplice da capire e molto apprezzata. Per quanto riguarda invece il po-
sizionamento del display in una specifica posizione dell’abitazione, i risultati
suggeriscono cucina o ingresso come luoghi preferiti, esito quest’ultimo di in-
teresse ai fini del posizionamento di una dock station piuttosto che del tablet
stesso, proprio per la natura mobile del tablet, per quanto riguarda la tesi in
esame.
Infine si è tenuto conto, per quanto possibile, dei suggerimenti estratti dai
questionari delle persone intervistate, che possono essere sintetizzati in questi
punti principali:
• riportare il consumo parziale per ogni stanza, anche numericamente;
• realizzare un’interfaccia utente che unisce entrambe le visualizzazioni;
• aggiungere un allarme per avvisare quando il sistema di sicurezza po-
trebbe essere in procinto di disattivare l’erogazione di energia;
• fornire il dettaglio istantaneo del consumo elettrico per gli elettrodo-
mestici.
Dai risultati ottenuti dallo studio e dai suggerimenti sopra elencati, si evince
quindi la necessità di creare un’applicazione con un interfaccia utente chiara,
e con informazioni utili ed a portata di mano.
Risulta utile a tale scopo riassumere gli obiettivi principali riguardanti lo
sviluppo dell’applicazione in oggetto nella seguente tabella:
12Tabella 2.1: Linee guida per lo sviluppo dell’interfaccia
utente dell’applicazione
Requisito Descrizione Priorità
Interfaccia Si implementerà l’interfaccia a feedback di- Richiesto
a feedback retto in quanto è risultata maggiormente
diretto comprensibile e di immediato effetto sui con-
sumi energetici. Si pensi che un metodo simi-
le è ormai adottato su quasi tutte le autovet-
ture di ultima generazione, dove viene mo-
strato il consumo istantaneo di carburante,
rendendo effettivamente il guidatore consa-
pevole e capace di gestire al meglio i consumi
adattando la propria guida all’autovettura.
In modo simile quindi l’utente dovrà essere
in grado di adattare il proprio stile di vita in
casa osservando le proprie cattive abitudini
da un punto di vista diverso, ovvero quello di
un’interfaccia grafica che ti da informazioni
in tempo reale sullo stato dell’abitazione.
Interfaccia a Come si evince dai risultati dell’indagine, lo Richiesto
goal energeti- sviluppo di un’interfaccia a obiettivi periodi-
ci ci sarebbe preferibile per quanto concerne il
risparmio energetico sui lunghi periodi, ad
esempio settimanali o mensili. Un’ulterio-
re sviluppo sarà quello di realizzare un’in-
terfaccia che unisca entrambe le modalità di
visualizzazione.
Continua...
13Tabella 2.1 – Continua dalla pagina precedente
Requisito Descrizione Priorità
Visualizzazione Il software dovrà accostare la visualizzazione Richiesto
dei consumi dei consumi tramite feedback numerici, ad
basta sulla una rappresentazione grafica che gestisce la
variazione dei variazione di potenza associandola a dei co-
colori lori. Nello specifico verde, il giallo/arancio e
rosso, colori che facilmente vengono associati
a qualcosa di positivo o negativo, perchè uti-
lizzati largamente nella quotidianità, come in
un semaforo. Il verde viene comunemente as-
sociato a qualcosa di positivo, ovvero la pos-
sibiltà di attraversare l’incrocio in questione,
quindi nella nostra applicazione rappresente-
rà bassi consumi e più in generale uno sta-
to non preoccupante della situazione ener-
getica; il rosso invece è spesso associato ad
un disagio, nel caso del semaforo a un’atte-
sa, e nel nostro caso a un consumo eccessi-
vo dovuto magari a troppi dispositivi attivi
contemporaneamente.
Consumo Risulterà altresì utile fornire informazioni Opzionale
parziale per sul dettaglio dei consumi per ogni stan-
ogni stanza za, fornendo i dati sia numericamente che
graficamente.
Consumo Potrebbe inoltre essere di interesse, come ef- Opzionale
elettrico dei fettivamente richiesto, fornire la possibilità
dispositivi di visualizzare il consumo di ogni dispositivo
in tempo reale, aprendo le porte così a va-
rie opportunità di sviluppo dell’applicazione
ad un livello piú basso, controllando il singo-
lo dispositivo piuttosto che intere aree della
casa.
Continua...
14Tabella 2.1 – Continua dalla pagina precedente
Requisito Descrizione Priorità
Possibilità di Nonostante l’applicazione sia orientata mag- Opzionale
controllare i giormente alla visualizzazione dei dettagli ri-
dispositivi guardanti i consumi energetici, sarà opportu-
no dare la possibilità all’utente di controlla-
re i dispositivi presenti in casa tramite i co-
mandi di cui essi dispongono, e che dovranno
essere integrati nell’interfaccia sviluppata.
Allarme di- Una funzionalità fortemente richiesta risulta Richiesto
sattivazione essere la possibità di visualizzare un avviso
contatore nel caso in cui ci si avvicini al limite energe-
elettrico tico consentito dal proprio contratto di for-
nitura elettrica, in modo tale da disattiva-
re qualche elettrodomestico non necessario al
momento, o evitare di accenderne altri e pro-
vocare un’interruzione di corrente in tutta la
casa.
Gestione ra- Come si è potuto notare dall’esempio ripor- Richiesto
zionale dei va- tato in figura 2.2, i vari ambienti controllati
ri ambienti erano trattati egualmente, considerando un
consumo standard per tutte le stanze e ripor-
tandolo graficamente tramite un manometro
digitale. Tale rappresentazione non può an-
dare bene in quanto difficilmente una cucina
dove sono presenti forno, lavastoviglie e fri-
go potrà avere un consumo massimo uguale
ad un soggiorno, dove invece i consumi ener-
getici difficilmente saranno elevatissimi. Mo-
tivo per cui, tramite opportune formule, si
dovrà trattare la visualizzazione dei consumi
associata alla colorazione dei vari ambienti
controllati, in modo razionale e diversifica-
to, riuscendo a mantenere un’elevato livello
di comprensibilità.
Continua...
15Tabella 2.1 – Continua dalla pagina precedente
Requisito Descrizione Priorità
Mobilità I dati raccolti indicano che l’utente preferi- Opzionale
sce avere uno o più IHD dislocati nei luo-
ghi maggiormente frequentati o di passag-
gio, come ad esempio la cucina o l’ingres-
so. Il compromesso verrà raggiunto fornendo
un’applicazione per tablet. Il dispositivo mo-
bile sarà in grado quindi di essere spostato in
un qualsiasi punto dell’abitazione, installan-
do eventualmente più postazioni di ricarica
negli ambienti desiderati.
Flessibilità È importante infatti oltre che realizzare le ri- Richiesto
chieste esposte nei precendenti punti, offrire
la possibilità, tramite una schermata di im-
postazioni, di agire su alcuni settaggi, come
la portata massima del contatore elettrico, o
le soglie che gestiscono la colorazione delle
stanze.
Definite quindi le principali linee guida per l’implementazione dell’inter-
faccia grafica, ci si pone un’altro obiettivo ai fini dello sviluppo dell’applica-
zione, che è quello di realizzare software che sia compatibile sulla maggior
parte dei tablet Android. Motivo per cui si è deciso di utilizzare le API di
Android 4.x, che è appunto la versione di tale sistema operativo mobile più
diffusa sui tablet attualmente in commercio.
Grazie alla decisione di utilizzare Android, di cui si parlerà più approfondita-
mente nei prossimi capitoli, si possono realizzare interfacce utente in maniera
semplice e potente, creando codice estremamente leggibile e permettendo la
separazione quasi totale della parte di design (cioè, come l’interfaccia ap-
pare) dalla parte di logica (quali sono i meccanismi per far sì che svolga i
suoi compiti). La parte di design, infatti, viene realizzata interamente in
XML, mentre la parte di logica viene realizzata con una versione particolare
di Java, che differisce solo per alcuni dettagli che verranno chiariti anch’essi
successivamente.
Infine d’ora in poi, faremo riferimento all’applicazione sviluppata con il nome
di “wattsUP ”.
16Tecnologia utilizzata
3
3.1 Introduzione
Prima di parlare del progetto sviluppato, del suo design e delle scelte proget-
tuali adottate, è doveroso dedicare un po’ di tempo per presentare sufficiente-
mente nel dettaglio le soluzioni tecniche con cui l’applicativo deve interagire.
Nel capitolo introduttivo si è parlato di domotica, e si è accennato, in partico-
lare, ad un sistema di controllo dell’ambiente domotico, sviluppato dal grup-
po di ricerca del Politecnico e-lite, chiamato Dog. Si è menzionato, inoltre,
il sistema operativo mobile Android, per cui l’applicazione è stata progetta-
ta, nello specifico per la distribuzione Android ICS (Ice Cream Sandwich) e
successive, riconoscibili anche dal numero di versione 4.x. Possiamo vedere
in figura 3.1 come le varie componenti sono relazionate tra di loro, mentre
nei paragrafi seguenti si spiegherà, più dettagliatamente, come questi com-
ponenti funzionano e come interagiscono con l’applicazione sviluppata.
3.2 Ambiente domotico utilizzato
Come si è precedentemente detto, la domotica è la disciplina che si occupa
di studiare tecnologie informatiche e appartenenti all’area dell’automazione
e della telecomunicazione, per poterle utilizzarle negli ambienti domestici,
al fine di migliorarne il comfort, l’abitabilità e di semplificare la vita delle
persone mentre vivono in questi ambienti.
Con la domotica, quindi, si possono automatizzare semplici funzioni del-
la casa come, per esempio, l’accensione e lo spegnimento delle luci, oppure
sviluppare servizi più “intelligenti” come, per esempio, gli scenari, cioè un
173.2. AMBIENTE DOMOTICO UTILIZZATO
Figura 3.1: Come l’interfaccia utente è connessa a Dog
elenco di attività riguardanti determinati dispositivi domestici che possono
venire attivati o disattivati tutti insieme in un certo momento della giornata,
a scelta dell’utilizzatore.
Un ambiente domotico, pertanto, è un ambiente opportunamente progettato
e tecnologicamente attrezzato, in cui sono presenti impianti e dispositivi che
sfruttano tecnologie che li rendono controllabili da remoto ed eventualmente
anche in grado di comunicare tra di loro.
Anche se il termine “da remoto” può dare l’idea che la casa venga controllata
da un altro posto, al di fuori dell’abitazione, in questo contesto si intende sem-
plicemente che un oggetto o una funzionalità della casa può essere controllata
senza il bisogno di maneggiare o toccare fisicamente l’oggetto in questione.
Quindi, l’oggetto può anche trovarsi di fronte all’utente ma esso lo controlla
in remoto grazie all’applicazione sviluppata durante questo progetto e resa
fruibile su un tablet, che può essere dislocato in un luogo strategico della
casa, o semplicemente usato in qualsiasi punto dell’abitazione, dal soggiorno
al giardino. Inoltre, un ambiente domotico come quello mostrato in figura
183.2. AMBIENTE DOMOTICO UTILIZZATO
Figura 3.2: esempio di architettura domotica
3.2 è composto da una serie di componenti hardware e software.
Le componenti hardware sono gli impianti domotici, che comprendono alcuni
dispositivi e un gateway, che gestisce la comunicazione con ogni dispositivo
appartenente al proprio impianto e con l’House Manager. I gateway dei vari
impianti domotici, a loro volta, sono collegati con un Domotic House Ga-
teway che gestisce la rete di comunicazione tra i diversi gateway.
La componente software, invece, è il cuore del sistema domotico perchè ha
il compito di gestire i dispositivi della casa, non importa in quale impianto
essi si trovino: tale componente prende il nome di House Manager.
L’House Manager si occupa anche di fornire servizi intelligenti e alcune appli-
cazioni che permettano all’utente di interagire con la casa. L’House Manager,
nel contesto che stiamo considerando, altro non è che Dog.
193.2. AMBIENTE DOMOTICO UTILIZZATO
3.2.1 Dog
Dog (Domotic OSGi Gateway) è una piattaforma che permette l’interfaccia-
mento, la gestione e l’integrazione di dispositivi domotici di diversi costruttori
in un singolo sistema software.
Realizzato con tecnologia OSGi, fornisce un ambiente per gli sviluppatori
orientato ai servizi e basato su componenti, offrendo così modi standardizza-
ti di gestire il ciclo di vita del software stesso. Fornisce un framework Java
stabile, sicuro e general-purpose che supporta lo sviluppo di applicazioni di
servizio estensibili chiamate bundle o, in italiano, moduli, che sono facili da
integrare: basta, infatti, che siano conformi ai vincoli di comunicazione defi-
niti nel framework stesso.
Come illustrato nella figura 3.3, Dog è composto da differenti moduli, che
Figura 3.3: L’architettura logica di Dog
hanno i vari usi e ruoli descritti di seguito:
• Network Drivers permette l’interazione diretta con le componenti hard-
ware dell’ambiente domotico. È necessario un driver differente per ogni
protocollo di basso livello utilizzato dalle varie componenti.
Attualmente è formato da tre bundle: Konnex per i sistemi KNX/-
Net IP, BTicino per i sistemi MyHome BTicino, Elite che permette di
203.2. AMBIENTE DOMOTICO UTILIZZATO
emulare i dispositivi fisicamente non disponibili, consentendo così di
utilizzare il software anche in assenza di un ambiente domotico reale,
cioè in simulazione, nodbus, echlor e z-wave;
• Message Dispatcher effettua il routing degli eventi in arrivo dai Net-
work Drivers e i comandi in arrivo dall’Executor; contiene, quindi, una
tabella di routing per mappare la corrispondenza tra i dispositivi e i
Network Drivers che possono comandarli;
• Executor riceve i comandi dal modulo API, ne controlla la correttezza
interagendo con il modulo Status e li esegue inviando i nuovi comandi
al Command Dispatcher;
• House Model contiene la rappresentazione della casa e dei disposi-
tivi appartenenti all’ontologia DogOnt, descritta nel prossimo sotto-
paragrafo;
• Status è una sorta di cache che contiene lo status dei dispositivi pre-
senti nel sistema; risponde alle richieste mandate dal modulo API,
restituendo informazioni sui vari dispositivi;
• Platform Manager gestisce l’installazione, l’avvio e la sospensione dei
bundle all’interno della piattaforma OSGi, fornisce informazioni sullo
stato dei bundle e gestisce la sequenza di bootstrap di sistema;
• Configurator Registry fornisce i dati di configurazione necessari al fun-
zionamento dei singoli moduli;
• API è il punto di accesso esterno al sistema; fornisce una serie di servizi
come l’elenco dei dispositivi presenti nella casa, la possibilità di eseguire
comandi e quella di registrarsi come listener per ricevere determinati
eventi e conoscere lo stato di uno o più dispositivi;
• XmlRpcConnector espone i servizi offerti dal modello API sotto forma
di end-point XML-RPC: l’interfaccia utente utilizzerà questo modulo e
il protocollo XML-RPC per interagire con Dog;
• Dog2Library, infine, specifica le interfacce dei servizi offerti dai bundle,
definendo e implementando le classi di sistema e le eccezioni.
L’interfaccia utente comunicherà con Dog principalmente durante due fasi,
quella iniziale in cui l’interfaccia riceverà il modello della casa con tutti i suoi
dispositivi, insieme con il loro stato e la loro descrizione; e quella operativa in
213.2. AMBIENTE DOMOTICO UTILIZZATO
cui l’interfaccia comunicherà a Dog i comandi che vuole compiere (per esem-
pio, accendere una luce) e Dog risponderà restituendo l’esito dell’operazione
che gli è stata richiesta (“la luce si è accesa”).
Sempre nella fase operativa, Dog potrebbe comunicare all’interfaccia che il
verificarsi di un evento (qualcuno ha premuto un pulsante e la luce si è acce-
sa) e l’interfaccia tratterà questa informazione di conseguenza, generalmente
producendo una notifica destinata all’utente.
La fase operativa, come è facile intuire, è una fase che viene ripetuta diverse
volte, fintanto che Dog e l’interfaccia sono entrambi in funzione e qualcosa
capita all’interno dell’ambiente domotico.
3.2.2 DogOnt
DogOnt è il modello formale per la rappresentazione di un ambiente domo-
tico, composto da due elementi: un’ontologia e un insieme di regole. Una
ontologia è una rappresentazione formale di una interpretazione condivisa
di uno specifico dominio di conoscenza. Non esistendo l’ontologia perfetta,
la rappresentazione di un determinato dominio può essere formalizzata in
una moltitudine di modi e dipende dallo scopo per cui viene creata. Un’on-
tologia assume normalmente una struttura a grafo connesso con concetti e
relazioni che li collegano. Le componenti fondamentali di una ontologia sono:
Classi - insiemi, collezioni o tipi di oggetti;
Attributi - proprietà, caratteristiche o parametri che gli oggetti possono
avere e condividere;
Relazioni - modi in cui gli oggetti possono essere messi in relazione gli
uni con gli altri;
Individui - istanze del modello, che sono gli elementi di base.
Le classi di un’ontologia sono concetti astratti che esprimono una classifi-
cazione delle entità rilevanti del dominio.
L’ontologia ha generalmente una classe radice chiamata Thing da cui discen-
dono tutte le altre. Le classi nell’ontologia seguono il principio dell’eredita-
rietà padre-figlio a livello di classe e proprietà.
Analizzando la figura 3.4, si può notare che l’ontologia di DogOnt si sviluppa
lungo cinque rami principali:
223.2. AMBIENTE DOMOTICO UTILIZZATO
Figura 3.4: L’ontologia di DogOnt
• Building Thing: rappresenta gli oggetti disponibili (controllabili, come
una luce, oppure no);
• Building Environment: rappresenta dove gli oggetti sono collocati;
• State: rappresenta le configurazioni stabili (gli stati, come “acceso” o
“spento”) che gli oggetti controllabili possono assumere;
• Functionality: rappresenta cosa gli oggetti controllabili possono fare
(accendersi e spegnersi, per esempio); la maggior parte degli oggetti
istanziabili non ha funzionalità comandabili con più di tre comandi.
• Domotic Network Component: rappresenta delle caratteristiche pecu-
liari di ogni impianto domotico.
233.3. ANDROID
Ogni ramo, a sua volta, avrà un certo numero di altri rami figli, a seconda di
cosa deve rappresentare: “Building Thing”, che è uno dei rami dell’ontologia
più interessanti poichè contiene tutti i dispositivi, gli elementi di mobilio e
quelli architetturali che ci possono essere nella casa, si divide in Controllable
e Uncontrollable, per separare gli oggetti che sono controllabili da quelli che,
come il tavolo del soggiorno, non lo sono.
DogOnt, inoltre, rappresenta ogni dispositivo come un oggetto che possiede
un insieme di funzionalità e di stati.
Le funzionalità sono automaticamente aggiunte a ogni istanza del dispositivo,
in base alle restrizioni definite al livello di classe. Esse sono condivise da tutti
i dispositivi della stessa classe: pertanto, diversi tipi di lampade appartenenti
alla stessa classe potranno avere delle funzionalità in comune. D’altra parte,
invece, gli stati sono peculiari a ogni dispositivo.
Quindi, se si volesse ottenere un modello della casa personalizzato e “vir-
tuale”, per esempio per eseguire alcune simulazioni, basterebbe creare una
istanza per ogni camera che si vuole avere nella casa (le stanze si trovano nel
ramo “Building Environment”); dopodichè basterebbe creare le istanze dei
dispositivi che si vogliono avere nelle singole stanze, come luci, interruttori
o elettrodomestici (si trovano tutti in “Building Thing” > “Controllable” >
“White Goods”) e assegnargli i tipi di funzionalità e i tipi di stato che sono
previsti nelle loro classi.
Fornendo alcune modalità di ragionamento, inoltre, DogOnt è in grado di
fornire la posizione di un dispositivo domotico nella casa, elencare l’insieme
delle sue caratteristiche, fornire le caratteristiche tecnologie necessarie per
interfacciarsi con quel dispositivo, dire come è composto l’ambiente domesti-
co e presentare gli elementi architetturali e di mobilio che sono presenti nella
casa.
Ci sarebbe ancora molto da dire riguardo questo argomento ma, per gli obiet-
tivi di questa tesi non è necessario sapere altro: l’interfaccia utente si collega
direttamente con Dog che gli fornisce il modello della casa con tutti i suoi
dispositivi e non ha bisogno di modificare nè l’ontologia nè le regole di Do-
gOnt. è sufficiente sapere cos’è un’ontologia, che i vari dispositivi hanno delle
funzionalità e degli stati e che Dog prende da qui il modello della casa, senza
il quale nulla potrebbe funzionare.
3.3 Android
Conclusa la parte riguardante la domotica e in particolare Dog, focalizziamo
l’attenzione su Android, cercando di spiegare cosa è e come funziona, senza
243.3. ANDROID
scendere troppo nel dettaglio. Android è un sistema operativo open-source
basato su kernel Linux e pensato per operare esclusivamente su dispositivi
mobili come smartphone e tablet, anche se negli ultimi tempi l’enorme suc-
cesso di questa piattaforma, e l’estrema versatilità che essa sta dimostrando,
stanno portando i maggiori produttori di gadget tecnologici a pensare di
espanderne l’utilizzo su dispositivi come fotocamere, navigatori ed altri ac-
cessori di quotidiano utilizzo.
Android è distribuito da Google, ma la paternità del progetto è di una pic-
cola società, Android Inc., acquisita nel 2005 proprio da Google che aveva
intuito l’enorme potenzialità del progetto. La prima release è datata novem-
bre 2007 anche se si dovette però aspettare fino al 23 settembre 2008 per il
lancio della versione 1.0 Apple Pie. Da lì in poi si sono succedute versioni
su versioni, sviluppate con dei nomi in codice, rilasciate in ordine alfabetico
ed identificate ognuna da una differente rappresentazione grafica, che hanno
reso questo “simpatico” sistema operativo, il punto di riferimento per tutti i
produttori intenzionati ad affacciarsi al mondo dei dispositivi mobili.
In figura 3.5 troviamo le maggiori distribuzioni commerciali di Android.
3.3.1 Risorse per gli sviluppatori
Le applicazioni per Android si possono differenziare per aspetto, utilità e per
il modo in cui vengono gestite dal sistema stesso. Abbiamo infatti:
• Attività (Activity ) Le attività sono quelle applicazioni destinate a
una interazione diretta con l’utente. Un esempio sono l’applicazione
sviluppata per il progetto che si stà discutendo in questa tesi, i video-
giochi, i software per l’ufficio o i visualizzatori di E-book. Le attività
vengono generalmente distribuite sotto forma di file “.APK”, vengono
poi installate in delle cartelle nella memoria del dispositivo o in una
memoria esterna (MicroSD card), infine viene creata una icona per
l’utente, che gli permetterà di eseguirla in qualsiasi momento. Le at-
tività vengono create come oggetti di classe Activity da cui ereditano
proprietà e metodi.
• Servizio (Service) I servizi sono, al contrario, quelle applicazioni che
per loro natura svolgono delle operazioni autonome e che vengono ri-
chiamati dalle attività al bisogno. Il sistema operativo fornisce alle
applicazioni vari servizi già pronti all’uso, per ottenere l’accesso al-
l’hardware o a risorse esterne (ad esempio dei web services di mes-
saggistica). I servizi sono oggetti di classe Services. Un esempio di
253.3. ANDROID
Figura 3.5: Maggiori distribuzioni commerciali di Android
servizio com.android.inputmethod.latin, ossia il componente che fa
comparire la tastiera quando si seleziona (con i tasti o con un tocco
sul touch-screen) un campo di input testuale. I servizi possono essere
eseguiti o interrotti direttamente dall’utente, sebbene siano eventualità
alquanto rare.
• Fornitori di contenuti (Content provider ) I fornitori di contenuti
sono dei contenitori di dati generati dalle applicazioni che ne forniscono
una condivisione; i dati possono essere contenuti nel file System, in un
database SQLite, sul web o in una qualunque locazione di dati. La
classe alla quale appartengono questi oggetti è ContentProvider.
• Ricevitori di trasmissioni diffuse (Broadcast receivers): I Broa-
dcast receivers, di cui si fa ampio uso in wattsUP , permettono di rice-
vere segnali rivolti a tutte le apps in esecuzione, per la condivisione di
dati o di segnali di servizio (come ad esempio quello di batteria scarica).
I broadcast receivers, sebbene non usino l’interfaccia del sistema, pos-
263.3. ANDROID
sono far apparire messaggi informativi che si sovrappongono all’output
dell’activity corrente.
• Il kernel e le librerie di base Questi componenti non sono sostitui-
bili; al massimo sono aggiornabili alcune parti per correggere eventuali
problemi di sicurezza. Quando viene rilasciata una nuova versione di
Android, significa che alcune di queste parti sono state aggiornate o
sostituite.
• Il file APK Il software viene solitamente distribuito sotto forma di
pacchetto autoinstallante, quindi un file con estensione .APK . Questo
non è altro che un file compresso, contenente il software (file con esten-
sione .dex), le sue risorse (immagini, suoni ecc...) e alcuni file XML.
L’utente medio non ha necessariamente bisogno di conoscere tale tipo-
logia di file, dato che il dispositivo gestisce tutta la parte di installazione
mediante web services come Google Play.
All’interno di questo file c’è anche un certificato che permette l’instal-
lazione di un pacchetto .APK su un dispositivo Android se questo non
è stato compromesso o revocato. Il certificato deve essere presente in
qualsiasi pacchetto, altrimenti Android non installerà l’applicazione al
suo interno. Il certificato viene creato dallo sviluppatore dell’applicazio-
ne, che può scegliere di crearne uno di debugging (quindi a uso interno)
o di mercato (per la distribuzione) e può deciderne la sua diffusione del-
le copie (libera o limitata). Il distributore (per esempio Google Play)
ci aggiungerà poi una sua chiave, che potrà successivamente revocare,
se necessario. In caso di revoca, l’applicazione non è più installabile
nè eseguibile in nessun dispositivo Android. Se uno sviluppatore indi-
pendente vuole poter distribuire un suo software con pacchetto .APK,
senza passare per un web service certificato, può autocertificarsi il cer-
tificato. In tal caso, l’utente riceverà un avviso che sta installando un
software di questo tipo (self-signed); a questo punto potrà annullare
l’installazione o farla proseguire a suo rischio.
• Le classi La classe è un concetto della programmazione ad oggetti. Per
semplificare, consiste nella suddivisione di un software in componenti,
questo per evitare di usare il vecchio paradigma della programmazione
lineare, che consiste nello stilare una lista di istruzioni sequenziali che
possono essere poco adattabili per l’aggiunta di ulteriori funzionalità
in futuro. Su Android tutti i componenti sono catalogati come classi e
richiamabili da altri componenti se il programmatore ne permette que-
sta possibilità.
Per fare qualche esempio, le classi del package android.bluetooth
273.3. ANDROID
permettono a uno sviluppatore indipendente di includere nella sua ap-
plicazione la possibilità di comunicare con un’applicazione (la stessa o
un’altra) installata su un altro dispositivo mobile, utilizzando il Blue-
tooth. Esiste anche il package android.gesture, con al suo interno le
classi che permettono a una applicazione di ricevere le gestures, ossia i
tracciamenti di un dito che sfiora il touch-screen.
Internamente, tutti i processi dei servizi in esecuzione vengono eseguiti
con tali nomi e sono visibili nel menu Impostazioni.
3.3.2 Android SDK
Dopo aver parlato della suddivisione e della tipologia delle applicazioni che
possiamo ritrovare in Android, ci soffermiamo su alcuni aspetti leggermente
più tecnici riguardanti ciò che stà alla base del software che viene sviluppato
per questo sistema operativo. Le applicazioni di Android sono sviluppate,
infatti, all’interno di un framework, ossia di una struttura dati specifica. La
struttura del framework è molto chiara se si utilizza l’ambiente di sviluppo
(SDK) con Eclipse1 ; il mancato utilizzo di Eclipse, tuttavia, non impedisce
di scrivere applicazioni Android funzionanti.
Le applicazioni Android sono caratterizzate da una certa dualità: parti di-
namiche scritte in Java e parti statiche scritte in XML. Tipico delle parti
statiche possono essere quelle caratteristiche che non cambiano durante l’e-
secuzione dell’applicazione, come per esempio il colore dello sfondo. Tipico
delle parti dinamiche sono gli aspetti programmatici come per esempio la ge-
stione degli eventi. Questa dualità è però solo apparente. Durante l’esecuzio-
ne, infatti, la Dalvik Virtual Machine (DVM) esegue sempre un programma.
Per lo sviluppo delle applicazioni è disponibile una completa documentazione
la quale, anche graficamente, riprende la struttura tipica della documenta-
zione Java del sito Oracle.
La Dalvik Virtual Machine
Tramite l’SDK (o meglio tramite gli strumenti utilizzati mediante l’SDK) tra-
sformiamo la nostra applicazione Android in un codice intermedio chiamato
bytecode. Questo ad esempio è esattamente quello che accade abitualmente
in Java, ossia:
1
Eclipse: eclipse è un ambiente di sviluppo integrato multi-linguaggio e multipiattafor-
ma ideato da un consorzio di grandi società quali Ericsson, HP, IBM, Intel, MontaVista
Software, QNX, SAP e Serena Software, chiamato Eclipse Foundation sullo stile dell’open
source. http://www.eclipse.org/
28Puoi anche leggere
