• Save
Cecutti Federico - Progetto e sviluppo di un'applicazione domotica per telefoni cellulari basati su Bluetooth
Upcoming SlideShare
Loading in...5
×
 

Cecutti Federico - Progetto e sviluppo di un'applicazione domotica per telefoni cellulari basati su Bluetooth

on

  • 1,737 views

Tesi di laurea triennale in Ingegneria Informatica di Federico Cecutti, Università degli Studi di Trieste, A.A. 2008-2009

Tesi di laurea triennale in Ingegneria Informatica di Federico Cecutti, Università degli Studi di Trieste, A.A. 2008-2009

Statistics

Views

Total Views
1,737
Views on SlideShare
1,737
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Cecutti Federico - Progetto e sviluppo di un'applicazione domotica per telefoni cellulari basati su Bluetooth Cecutti Federico - Progetto e sviluppo di un'applicazione domotica per telefoni cellulari basati su Bluetooth Document Transcript

  • UNIVERSITÀ DEGLI STUDI DI TRIESTE FACOLTÀ DI INGEGNERIA Corso di laurea triennale in Ingegneria Informatica Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth LAUREANDO RELATORE Federico Cecutti chiar.mo prof. Alberto Bartoli ANNO ACCADEMICO 2008/2009
  • Sommario 1. Introduzione 5 2. Requisiti e progettazione 7 2.1. Requisiti di progetto 7 2.1.1. Portabilità 7 2.1.2. Semplicità 7 2.1.3. Selezionabilità del server 8 2.1.4. Predefinizione 8 2.1.5. Profilo di comunicazione 8 2.1.6. Comando M 8 2.1.7. Formato dei dati inviati dal server 8 2.1.8. File di configurazione XML 9 2.2. Linguaggio e caratteristiche generali 10 2.2.1. Linguaggio 10 2.2.2. Ambiente di sviluppo 10 2.2.3. Configurazioni e profili 11 2.3. Interazione con il server 11 2.3.1. Organizzazione del workflow di base 11 2.3.2. Predefinizione 12 2.3.3. Da fasi operative a schermate 12 2.3.4. Casi di errore 13 2.3.5. Classi per l’interazione 15 2.4. Interpretazione dei dati ricevuti 17 2.4.1. Header e payload: un primo parser 17 2.4.2. Modello degli oggetti 17 2.4.3. Parser XML 19 2.4.4. Cache dei moduli e I/O recenti 19 2.4.5. Casi di errore 20 3. Realizzazione 22 3.1. Implementazione 22 3.1.1. Multithreading e ricerche 22 3.1.2. Connessione 22 3.1.3. Timeout 23
  • 3.1.4. Ricezione dei dati 24 3.1.5. Comandi 24 3.1.6. SplashScreen 24 3.1.7. Predefinizione 25 3.1.8. Organizzazione della classe ComunicazioneMIDlet 26 3.1.9. Organizzazione dei package 27 3.1.10. Parsing XML 27 3.1.11. Record di cache e interpretazione 29 3.1.12. Interfaccia utente 31 3.2. Tecniche di debug e simulazione 32 3.2.1. Schermate 32 3.2.2. Testi 33 3.2.3. Dati simulati 34 3.3. Interfaccia utente 35 3.3.1. Installazione 35 3.3.2. Utilizzo 35 3.3.3. Esempio di utilizzo 37 3.4. Rilascio 38 3.4.1. Test 38 3.4.2. Offuscamento 38 3.4.3. Javadoc 38 4. Conclusioni 39 4.1. Obiettivi 39 4.2. Sviluppi futuri 39 4.3. Aspetti quantitativi 39 4.4. Conclusioni personali 40 5. Bibliografia 41
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 1. Introduzione Il lavoro oggetto della tesi consiste nel progetto e realizzazione di un programma per telefoni cellulari che permette di visualizzare i dati gestiti da un server di un sistema domotico. Il programma è un’evoluzione del software realizzato nell’ambito del progetto Linkasa, durante il tirocinio presso l’azienda P.C.E. di Treppo Grande (UD). Linkasa è un sistema di monitoraggio e gestione domotica. È basato su una scheda server a cui si interfacciano dei moduli periferici collegati a dispositivi elettrici di varia natura (elettrodomestici, motori elettrici, strumenti di misura, inverter di impianti fotovoltaici). Il server è in grado di ricevere delle informazioni dai moduli e di inviare loro dei comandi. La scheda server presenta due diverse tipologie di interfacce umane: un programma client su personal computer e un’interfaccia web. Questa tesi ha come obiettivo la realizzazione di un programma per l’interfacciamento del server Linkasa con un telefono cellulare tramite la comunicazione Bluetooth. Nel quadro del progetto, questa modalità di accesso dà la possibilità all’utente di consultare i dati del server in modo quanto più possibile rapido e leggero, e senza dovere necessariamente disporre di un calcolatore. La semplicità di accesso è data dal fatto che la comunicazione avviene senza bisogno di collegare alcun cavo. Per contro, è fruibile solamente nelle immediate vicinanze. Figura 1.1: UML deployment diagram che evidenzia l’architettura fisica del sistema 5
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Per la realizzazione è stata lasciata ampia libertà riguardo alle modalità di programmazione. Si è scelto di sviluppare il programma utilizzando Java Micro Edition. Dopo la raccolta dei requisiti e una fase iniziale di documentazione tecnica sul linguaggio e sulle modalità di programmazione, il progetto è stato suddiviso in varie fasi operative. I prossimi capitoli ripercorreranno le fasi della messa a punto del programma. A partire dall’elenco dei requisiti e dalle scelte progettuali generali, verrà presentata la progettazione. L’applicazione sarà studiata da un punto di vista concettuale e saranno definite le specifiche, strutturali e procedurali, che il codice dovrà rispettare. Le sezioni del capitolo ricondurranno i contenuti ai due nuclei tematici dell’applicazione: l’interazione con il server e l’interpretazione dei dati ricevuti. Seguirà un capitolo relativo alla realizzazione. Dapprima si evidenzieranno i costrutti implementativi più rilevanti, facendo riferimento al codice sviluppato; si tratteranno poi le tecniche di debug e simulazione adottate per testare le varie parti del programma; si descriveranno gli aspetti legati all’interfaccia utente mostrando come utilizzare l’applicazione; si concluderà con una sezione dedicata al rilascio. Infine, saranno esposte delle conclusioni complessive sul progetto. Figura 1.2: Server Linkasa 6
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 2. Requisiti e progettazione Il capitolo si apre con l’elenco dei requisiti di progetto. Nella progettazione del sistema, si distingue la parte legata alla comunicazione con il server dalla parte di interpretazione dei dati ricevuti. Per il progetto dell’interazione con il server ci si basa su un workflow; nell’interpretazione dei dati il punto centrale è creare una gerarchia di classi che ne modellizzi la struttura. 2.1 Requisiti di progetto I requisiti di progetto possono essere catalogati in tre aree di afferenza: • caratteristiche generali del sistema • interazione con il server • interpretazione dei dati ricevuti Si esamina ora in dettaglio ciascuna delle sezioni. 2.1.1 Portabilità Il software deve essere utilizzabile con il maggior numero possibile di telefoni cellulari. Tutte le scelte progettuali e implementative devono evitare soluzioni applicabili a uno specifico modello, basandosi sulle modalità più standard e comuni. Il sistema deve presentare un’interfaccia visualizzabile su qualsiasi tipo di schermo, e in particolare con qualsiasi risoluzione. I messaggi devono fornire informazioni in modo essenziale e diretto. 2.1.2 Semplicità Si richiede che il software sia utilizzabile anche da utenti non esperti. Dal punto di vista dell’utilizzatore finale, il programma dovrebbe presentarsi come qualcosa di simile a un telecomando che permetta di visualizzare i dati. Deve essere disponibile una breve guida utente. 7
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 2.1.3 Selezionabilità del server Un’architettura complessa può comprendere più di un server, ciascuno dei quali gestisce dei propri moduli. È possibile che più server si trovino nel raggio di azione del Bluetooth: il programma deve quindi consentire la selezione del dispositivo desiderato. 2.1.4 Predefinizione Le connessioni successive ad uno stesso server devono avvenire nel modo più rapido possibile. 2.1.5 Profilo di comunicazione La comunicazione con il server deve avvenire utilizzando il Serial Port Profile (SPP). 2.1.6 Comando M Una volta effettuata la connessione al server, è necessario richiedere i dati con uno specifico comando, denominato comando M, dall’iniziale della parola “moduli”. Il comando deve essere composto da: • 2 byte di marcatura iniziale: ‘L’ e ‘K’ • 2 byte che specificano la lunghezza totale del comando, big-endian • il byte ‘M’ 2.1.7 Formato dei dati inviati dal server Ricevuto il comando, il server invia i dati relativi ai moduli con cui è collegato. Per ciascun modulo il server genera un flusso di byte che segue questa struttura: • marcatura iniziale ‘L’, ‘K’ • 2 byte per la lunghezza del flusso relativo al modulo (comprensivo di marcatura e • terminazione), big-endian • dati (struttura XML da interpretare) • terminazione con CR+LF La parte relativa ai dati di ogni modulo è strutturata in un formato XML in cui sono previsti i seguenti elementi: • <m>: modulo (root element) • <mac>: indirizzo MAC del server • <c>: codice del modulo 8
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth • <TY>: tipo del modulo • <ti>: timestamp in formato UNIX • <st>: stato del modulo • <ai>: ingresso analogico (analogic input) • <di>: ingresso digitale (digital input) • <ao>: uscita analogica (analogic output) • <do>: uscita digitale (digital output) All’interno dei quattro tipi di I/O sono contenuti i seguenti tag: • <n>: numero (ogni tipologia ha una propria numerazione) • <v>: valore (intero senza segno a 32 bit) Il sistema deve ignorare eventuali elementi sconosciuti, che potrebbero essere introdotti in tempi successivi. 2.1.8 File di configurazione XML L’interpretazione dei dati dei moduli viene standardizzata mediante un file di configurazione XML, unico per tutte le aree del progetto. Il file contiene l’elenco dei tipi di modulo supportati (elementi <tm>). Ha l’elemento <linkasa> come root element. Ogni modulo ha: • <cod>: codice • <nome>: nome • <display>: una libreria dll utilizzata dal software client per PC (qui irrilevante) e può supportare i quattro tipi di I/O previsti, a cui corrispondono quattro tag. Le unità di tipo “ai” sono dotate delle seguenti caratteristiche: • <n>: numero • <um>: unità di misura • <mind>, <maxd>: valore minimo e massimo possibile della grandezza reale Figura 2.1.8.1: porzione del • <minv>, <maxv>: valore minimo e massimo file di configurazione XML 9
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth possibile del valore ricevuto • <dn>: utilizzato nella dll associata nel programma client per PC (qui irrilevante) • <lbl>: etichetta • <ndec>: numero di decimali da visualizzare Il file di configurazione deve essere caricato all’interno del programma. Questo dovrà consultarlo localmente per interpretare i dati ricevuti dal server e rappresentarli nella giusta scala e unità di misura. L’interfaccia dovrà limitarsi a visualizzare i dati relativi agli I/O di tipo “ai”, i più importanti e comuni per i moduli che interessano il sistema. 2.2 Linguaggio e caratteristiche generali 2.2.1 Linguaggio Il programma è stato sviluppato nel linguaggio Java Micro Edition (ME). La scelta è dovuta principalmente a ragioni di reperibilità, robustezza del codice generato e grande disponibilità di documentazione; inoltre, la maggior parte dei telefoni cellulari che supportano il Bluetooth dispongono di Java. Infine si è potuta sfruttare la precedente conoscenza di Java Standard Edition (SE). 2.2.2 Ambiente di sviluppo Lo sviluppo è stato svolto utilizzando la versione di NetBeans che supporta JavaME, provvista di strumenti quali: interprete sintattico e semantico delle istruzioni, dizionario dei dati, strumenti di cross-referencing, code completion, refactoring, debugging. In questa versione, dedicata allo sviluppo di applicazioni per dispositivi diversi dal PC, sono caricabili diversi simulatori, che permettono un test del programma direttamente nell’IDE, anche se non sempre supportano tutte le funzionalità del codice. Un utile componente dell’IDE è il Visual Mobile Designer (VMD), che permette di sviluppare in modo automatico il codice riguardante gli aspetti più vicini all’interfaccia 10
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth grafica (essenzialmente schermate e oggetti visuali sui form) e all’interazione con l’utente (comandi ed eventi), seguendo l’approccio della programmazione visuale. 2.2.3 Configurazioni e profili Per lo sviluppo del codice è necessario specificare una configurazione e un profilo1, parametri che caratterizzano la complessità del dispositivo. Il migliore compromesso tra il requisito della massima portabilità e delle prestazioni richieste è la configurazione CLDC-1.1 (Connected-Limited Device Configuration) e il profilo MIDP-2.0 (Mobile Information Device Profile). 2.3 Interazione con il server 2.3.1 Organizzazione del workflow di base Limitatamente alla parte riguardante l’interazione tra client e server, si organizzano le fasi necessarie, iniziando da uno schema di base e procedendo per raffinamenti successivi, come illustrato nei prossimi paragrafi. La prima fase è la ricerca dei dispositivi remoti. Ad un primo avvio del programma, il client non dispone di alcuna informazione sul server, e la ricerca gli indica tutti i dispositivi Bluetooth raggiungibili. Al termine di questa fase possono presentarsi tre diverse situazioni: • non è stato trovato alcun server Linkasa • è stato trovato un server Linkasa • sono stati trovati diversi server Figura 2.3.1.1: Linkasa UML activity diagram dell’interazione di base tra client e server 1 In questo contesto, il termine “profilo” si riferisce alle API di JavaME e non ha alcun legame con le caratteristiche della comunicazione Bluetooth. 11
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Viene fornita all’utente la lista dei dispositivi trovati, che ha il duplice scopo di: • far capire all’utente se un certo server è raggiungibile o è troppo distante • permettere all’utente la selezione di un certo server Se il server desiderato non è visibile perché troppo distante o non in funzione, l’utente può scegliere se ripetere la ricerca, magari da più vicino, o terminare il programma. Una volta selezionato il server, il client dà inizio alla fase di service discovery, in cui verifica che il dispositivo remoto renda disponibile il servizio alla base della comunicazione. Un fallimento della service discovery implica che l’utente sta tentando di connettersi a un dispositivo che non ha le caratteristiche di un server Linkasa. Oppure potrebbe essere venuta meno la raggiungibilità del server, magari perché durante la ricerca il client si è allontanato. Anche in questo caso si dà all’utente la possibilità di ripetere la ricerca. Se il servizio viene trovato, si procede con l’instaurazione della connessione e con la comunicazione. 2.3.2 Predefinizione In alternativa alla ricerca di dispositivi e servizi, è possibile selezionare un server predefinito, il cui URL è già noto da una connessione precedente. Il salvataggio di questa informazione costituisce l’unico caso di memorizzazione permanente. Poiché la scrittura è un’operazione che può richiedere del tempo (è percepibile dall’utente su molti dispositivi), si ottimizza la velocità del software evitando scritture inutili: • si scrive il dato solo nel caso in cui sia stata effettivamente fatta una ricerca • si scrive il dato solo dopo l’interpretazione corretta dei dati, evitando di memorizzare dispositivi che provochino errori di qualsiasi tipo 2.3.3 Da fasi operative a schermate Le fasi che precedono la comunicazione con il server sono piuttosto onerose in termini di tempo, specie nel caso in cui si debba fare la ricerca. È importante che l’utente sia informato sul procedere delle operazioni: il programma presenta una serie di schermate di attesa, durante le quali esegue un task in background. 12
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Al termine di una o più fasi operative, il programma mostra all’utente il risultato dell’elaborazione, e gli chiede come proseguire. Il VMD permette di creare delle sequenze di schermate, sfruttando l’approccio visuale. Una palette comprende diverse sottoclassi della classe astratta Displayable, che rappresenta il modello della schermata generica. Tra queste vi sono: • Form • WaitScreen • Alert Se le classi Form e Alert rappresentano degli standard dei profili di tipo MID e sono incluse nel package javax.microedition.lcdui, WaitScreen è invece una classe fornita da NetBeans (org.netbeans.microedition.lcdui). Corrisponde a una schermata che lancia un task in background, realizzando una semplice forma di multithreading. La progettazione di un flowchart di schermate a livello di VMD si riflette sul sorgente introducendo del codice autogenerato. 2.3.4 Casi di errore Ogni fase che precede la comunicazione può incorrere in un fallimento. Ogni WaitScreen ha due modalità di terminazione: SUCCESS_COMMAND e FAILURE_COMMAND. Quando il task in background genera un’eccezione (non catturata all’interno del codice), viene generato un evento di fallimento; se il task termina senza eccezioni, viene generato un evento di successo. L’inizializzazione locale corrisponde all’attivazione dell’interfaccia Bluetooth del telefono cellulare. Se questa fase fallisce, il telefono non è in grado di gestire le funzionalità Bluetooth, e non ha senso proseguire: il programma termina, subito dopo aver informato l’utente con un Alert. Un eventuale fallimento della ricerca dei dispositivi remoti potrebbe non compromettere la connessione diretta al server predefinito. In questo caso, dopo un Alert che segnali l’anomalia, si ritorna al form principale, quello che segue l’inizializzazione locale. Il caso di un’eccezione nel task di connessione al server è particolarmente critico. Se il client tenta di aprire una connessione con il server e si verifica un errore, in generale il 13
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth client non è in grado di determinare la situazione della connessione. Il server potrebbe aver aperto e chiuso la connessione, averla persa senza terminarla o non averla mai aperta. In questo caso il programma termina, dopo aver informato l’utente. Dopo l’invio del comando M al server, il client si aspetta di ricevere i dati entro un tempo massimo. Se ciò non avviene, il maggiore sospetto è che la connessione si sia persa, magari perché il client si è allontanato troppo. L’utente dovrà scegliere se è il caso di terminare il programma o di tentare una nuova connessione. Il caso di un’eccezione sull’interpretazione dei dati è analogo al precedente: si richiede all’utente di scegliere se terminare il programma o se ritentare la connessione. L’ultimo caso di errore riguarda l’impossibilità della scrittura del server predefinito. Delle possibili cause di fallimento a questo punto sono: • spazio insufficiente nella memoria permanente • scrittura permanente non supportata Se questa funzionalità accessoria non fosse disponibile, resterebbe comunque la possibilità di collegarsi effettuando una ricerca. Il programma può quindi proseguire ignorando l’anomalia. Figura 2.3.4.1: Flowchart del VMD 14
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 2.3.5 Classi per l’interazione Per l’interazione con il server, dalle fasi preliminari alla comunicazione, sono state definite due sole classi: • ComunicazioneMIDlet (extends MIDlet implements CommandListener) • DiscoveryListenerLinkasa (implements DiscoveryListener) Un’applicazione del profilo MID deve estendere la classe astratta MIDlet. L’implementazione dei metodi astratti di interazione con l’application manager2 è autogenerata dal VMD. A livello di VMD è presente uno speciale riquadro, intitolato Mobile Device, che rappresenta l’esterno dell’applicazione. Ogni flusso entrante in questo riquadro rappresenta l’uscita dalla MIDlet; i flussi uscenti hanno origine da uno dei due stati di attivazione della MIDlet: Started o Resumed. Per rispondere ai comandi che permettono la transizione da una schermata all’altra, vi deve essere una classe che implementi CommandListener. Per semplicità, il VMD utilizza un’unica classe, che estende MIDlet e implementa CommandListener. Ne deriva che tutto il codice autogenerato per la gestione dell’interfaccia utente è contenuto in un’unica classe, in questo caso denominata ComunicazioneMIDlet. Una classe che implementa l’interfaccia DiscoveryListener rileva gli eventi legati alla ricerca dei dispositivi e dei servizi. L’implementazione di DiscoveryListener non può essere realizzata dalla stessa MIDlet, perché gli oggetti istanze delle due classi devono poter agire indipendentemente l’uno dall’altro. 2 Application manager: modulo software del telefono preposto alla gestione delle applicazioni. In seguito ad eventi asincroni esterni può richiedere la variazione di stato della MIDlet (Active, Paused, Destroyed) invocando i suoi metodi startApp, pauseApp o destroyApp. 15
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Figura 2.3.5.1: UML class diagram di ComunicazioneMIDlet Figura 2.3.5.2: UML class diagram di DiscoveryListenerLinkasa 16
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 2.4 Interpretazione dei dati ricevuti 2.4.1 Header e payload: un primo parser Il flusso di byte inviato dal server presenta, per ogni modulo, uno header con informazioni di controllo. Una prima operazione consiste nella validazione di questi controlli e nell’isolamento del payload relativo al modulo. 2.4.2 Modello degli oggetti Il flusso di dati viene processato creando una gerarchia di oggetti che riflette la struttura descritta nell’XML ricevuto. L’oggetto padre di tutti gli altri è definito dalla classe Modulo. La classe ha tanti field quante sono le proprietà del modulo e un vettore di oggetti Ai. Anche se comprese nell’XML, le altre tipologie di I/O che possono riguardare un modulo vengono trascurate, in quanto irrilevanti per l’applicazione. La costruzione di un oggetto Modulo avviene durante il parsing dell’XML ricevuto, nel quale vengono riconosciuti i tag e valorizzate le corrispondenti proprietà dell’oggetto Modulo. Inoltre, ad ogni tag <ai> incontrato, si aggiunge un elemento al vettore di oggetti Ai. Per limitare l’allocazione di risorse, l’oggetto Modulo esegue il parsing anche dell’XML interno ai tag <ai>, passando ai corrispondenti oggetti i contenuti dei sottotag. Questi contenuti permetteranno alla classe Ai di eseguire la trasformazione dei valori riportati nell’XML ricevuto in grandezze significative, con proprie caratteristiche e unità di misura. 17
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Figura 2.4.2.1: UML class diagram di Modulo Figura 2.4.2.2: UML class diagram di Ai 18
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 2.4.3 Parser XML Per il parsing dell’XML si è importata nel progetto la libreria open source (con licenza EPL) kXML 1.1, contenente un parser di tipo pull3. La libreria è progettata per applicazioni con risorse di memoria limitate, e implementa solamente le funzionalità più importanti. 2.4.4 Cache dei moduli e I/O recenti I dati ricevuti dal server vanno interpretati alla luce del contenuto del file di configurazione, che specifica in particolare: • informazioni aggiuntive relative ai moduli: nel programma per telefono cellulare ha rilievo soltanto il nome del server • modalità di interpretazione del valore contenuto nell’elemento <v> del flusso ricevuto dal server Il file di configurazione contiene informazioni relative a un gran numero di moduli; di fatto viene quindi utilizzato solo in minima parte. Si introduce allora un meccanismo di caching delle informazioni di configurazione di interesse: per ogni “ai” cui si riferisce l’XML ricevuto dal server, si verifica se sono disponibili le informazioni di configurazione nella cache. Se lo sono, è sufficiente ricavarle dalla cache, senza bisogno di analizzare l’XML di configurazione. La verifica è realizzata durante la costruzione di un oggetto Ai, invocando un metodo dell’oggetto cache (Tabella.PredisponiTabella). Se nella cache non è presente l’“ai” in questione, viene “tabulato” l’intero modulo corrispondente, ovvero viene effettuato il parsing della porzione dell’XML di configurazione relativa al modulo e vengono aggiunti tutti i suoi Ai nella cache. La cache è definita nella classe Tabella, che estende java.util.Hashtable, rendendo ogni record (RecordAi) accessibile mediante una chiave. Poiché ogni record della cache corrisponde ad un I/O lato configurazione, la chiave deve indicare: • il codice del modulo che contiene l’I/O • il tipo di I/O • il numero dell’I/O La chiave viene formata concatenando questi tre elementi. 3 Il parser XML di tipo pull legge il documento un poco alla volta, su richiesta delll’applicazione, che richiede ripetutamente la lettura di una porzione successiva. 19
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Figura 2.4.4.1: UML class diagram di RecordAi 2.4.5 Casi di errore Si analizzano ora le situazioni nelle quali il flusso di dati inviato dal server presenti delle incompatibilità con le informazioni di configurazione. Sebbene si tratti di situazioni estremamente rare, una loro analisi è indispensabile nella costruzione di un modello robusto di interpretazione del flusso inviato dal server. Potrebbero verificarsi le situazioni seguenti: 1) il codice del modulo specificato nell flusso non è presente nel file di configurazione 2) la tipologia di I/O specificata nel flusso non è riconosciuta 3) lato configurazione non esiste l’I/O specificato per quel modulo, e non si presenta nessuno degli altri casi La prima situazione è facilmente individuabile: durante il parsing dell’XML di configurazione, non si trova alcun modulo con il codice specificato. La seconda situazione è rilevabile ancor più facilmente: è sufficiente controllare che la tipologia specificata sia quella supportata. La terza situazione è più complessa. 20
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth La cache non trova un elemento corrispondente alla chiave indicata; per ipotesi vi sono altri elementi con lo stesso modulo e tipo di I/O, ma la cache non è in grado di identificarli. Quindi tenta di inserire il nuovo elemento, creando dei doppioni degli elementi con lo stesso modulo e tipo di I/O. Si avrebbe quindi l’effetto di creare nella cache una moltitudine di record uguali, ma non si risolverebbe la situazione di errore, in quanto l’“ai” cercato non ha corrispondenza nel file di configurazione e quindi non potrebbe essere inserito. Per risolvere questo problema, l’oggetto Tabella è dotato di un vettore, che tiene traccia dei moduli tabulati. Nel caso in cui non si trovi nella cache un record corrispondente a una certa chiave, si richiederà la tabulazione soltanto se il modulo in questione non è già stato tabulato. In caso contrario si avrà modo di individuare l’errore relativo alla terza situazione. Figura 2.4.5.1: UML class diagram di Tabella 21
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3. Realizzazione 3.1 Implementazione 3.1.1 Multithreading e ricerche La ricerca dei dispositivi e dei servizi è il solo punto in cui è necessaria un’interazione tra la classe ComunicazioneMIDlet, contenente la sequenza delle schermate, e la classe DiscoveryListenerLinkasa, di segnalazione degli eventi di ricerca. Durante i WaitScreen, ComunicazioneMIDlet dà inizio in background alle fasi di ricerca richiamando i metodi di un oggetto DiscoveryAgent, quindi rimane in attesa delle segnalazioni, bloccandosi sul WaitScreen. La fase di ricerca ha una durata limitata, anche nel caso in cui non venga trovato alcun dispositivo. La sincronizzazione tra le due classi è realizzata mediante un monitor. Al momento della sua creazione, un oggetto ComunicazioneMIDlet istanzia un generico Object; dopo aver dato inizio alla ricerca, ComunicazioneMIDlet rilascia il monitor invocando una wait() su questo oggetto. Una volta completata la inquiry, l’oggetto DiscoveryListenerLinkasa sblocca il monitor invocando una notify() sullo stesso oggetto, e permettendo la terminazione del WaitScreen. 3.1.2 Connessione Nel WaitScreen di inizializzazione della comunicazione si compiono, in sequenza, le seguenti operazioni: • apertura della connessione • inizializzazione dell’output, per il flusso verso il server • inizializzazione dell’input, per il flusso dal server • invio del comando M Queste operazioni sono precedute da una chiusura preliminare della connessione, per evitare di avere due connessioni aperte, nel caso anomalo in cui una precedente connessione non fosse stata rilasciata correttamente. 22
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Un Connector viene aperto sull’URL di connessione determinato al momento della scoperta del servizio, e una StreamConnection assume il valore del Connector con un cast. Questa operazione permette di aprire correttamente il lato client della connessione e costituisce il cuore operativo del programma. L’input e l’output vengono inizializzati agganciando un oggetto InputStream e uno OutputStream alla connessione. Il protocollo di comunicazione Linkasa si basa su byte, con significato numerico e di carattere: è quindi indispensabile utilizzare un I/O a basso livello. Tramite OutputStream, si inviano sulla connessione i byte relativi al comando M, che richiede al server i dati relativi ai moduli. L’invio dei byte è effettuato in due fasi: scrittura nell’OutputStream e flushing. È essenziale finalizzare correttamente tutti gli oggetti creati, in particolar modo la connessione. Se questa non venisse rilasciata, non se ne potrebbero instaurare altre, nemmeno chiudendo il programma. L’unico rimedio possibile sarebbe il riavvio del telefono. 3.1.3 Timeout Una volta inviato il comando M al server, è necessario impostare un timeout di ricezione. La classe WaitScreen non permette di introdurre direttamente un timeout sul task in background: è necessario implementare un meccanismo via software. Il task realizza un polling che verifica se vi sono dati disponibili un numero limitato di volte. Tra un controllo e l’altro si introduce un’attesa, realizzata mettendo il thread in sleeping per 10 ms. Supponendo il tempo di test trascurabile, il timeout è dato dal prodotto del tempo di attesa per il numero massimo di esecuzioni del test. Il metodo AspettaRisposta(int millisAttMax) generalizza questa logica accettando come parametro il tempo di attesa desiderato. Coerentemente con altri metodi standard di Java, il tempo viene specificato in millisecondi; tuttavia, generando attese di 10 ms alla volta e trascurando i tempi di test, il metodo garantisce una precisione del centesimo di secondo. 23
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Nel caso in cui si superi la massima attesa accettabile, viene lanciata una AttesaRispostaScadutaException, un’eccezione specifica per questo caso. 3.1.4 Ricezione dei dati Il flusso ricevuto deve essere suddiviso nelle parti relative ai singoli moduli. Per ognuno si verifica inizialmente che i primi due byte corrispondano alla marcatura iniziale ‘L’, ‘K’, viene quindi letta la lunghezza del messaggio. Si leggono poi i dati, sino a incontrare il byte CR, o una inaspettata terminazione del flusso (end of stream), o a raggiungere un numero di caratteri letti troppo elevato rispetto alla lunghezza del messaggio. Viene infine letto il carattere LF. Si verifica a questo punto se l’InputStream presenta ancora dei caratteri pronti per essere letti e, in caso affermativo, si reitera l’intera procedura. Una serie di eccezioni modellizza i casi di errore possibili in ciascuno di questi passaggi. 3.1.5 Comandi Come da standard del VMD, le transizioni tra una schermata e l’altra sono mediate da comandi della classe javax.microedition.lcdui.Command. Ogni form include un comando principale, che nell’uso ordinario del programma permette di proseguire all’operazione successiva: si utilizza un meccanismo di priorità. In ogni form e nella lista dei dispositivi si è assegnato il livello 1 al comando da premere in condizioni normali, il livello 2 ai comandi di uscita e i livelli successivi, 3 e 4, agli altri. In ogni form e nella lista dei dispositivi remoti, l’utente ha la possibilità di terminare il programma, o di annullare il collegamento o la comunicazione con il dispositivo remoto già selezionato. 3.1.6 SplashScreen Coerentemente con la maggior parte delle MIDlet, la prima schermata è uno SplashScreen con un’immagine rappresentativa del programma. Lo SplashScreen viene visualizzato finché l’utente preme il tasto di conferma del telefono oppure fino a un timeout di 3 secondi. Termina con l’esecuzione del comando non grafico DISMISS_COMMAND. 24
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth L’immagine dello SplashScreen è una risorsa del programma e viene salvata nel package di progetto it.linkasa, nel formato compresso JPEG. 3.1.7 Predefinizione Il sistema di predefinizione richiede la gestione della scrittura e della lettura di dati persistenti, in parti separate del programma. La modalità più portabile per salvare i dati permanenti nelle MIDlet è il Record Management System (RMS), una semplice base dati fondata su record. I dati sono raccolti in RecordStore (javax.microedition.rms) e hanno il numero intero recordId come chiave primaria. Il primo record inserito ha recordId=1. La scrittura è realizzata dal metodo RegistraRemoto, che apre o crea il RecordStore disp (dispositivo) inserendo le informazioni sul server alla posizione 1 e cancellando tutti gli eventuali altri record. Ogni server viene memorizzato in un array di byte così organizzato: • nome del server • byte 00h separatore • URL del server • byte 00h terminatore e salvato nel RecordStore. In caso di RecordStoreException, vista l’accessorietà del sistema di predefinizione, l’applicazione prosegue e non avverte l’utente, evitando di bloccare l’applicazione per una problematica secondaria. Nella parte di inizializzazione, il programma apre il RecordStore disp dopo averne verificato l’esistenza e legge nome e URL del server. Il nome sarà utilizzato successivamente per comporre la label del comando di connessione al server predefinito. Il form principale è stato progettato nel VMD includendo la voce di selezione del server predefinito, poiché nella maggior parte delle situazioni questo è disponibile. Se invece la predefinizione non è disponibile, questo comando viene rimosso. Se l’utente esegue una nuova ricerca di server, e questo comunica correttamente con il telefono, il server trovato diventa quello predefinito; il relativo comando di selezione viene nuovamente creato. 25
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3.1.8 Organizzazione della classe ComunicazioneMIDlet La classe ComunicazioneMIDlet costituisce il nucleo centrale dell’applicazione e contiene parecchio codice autogenerato. Date le dimensioni della classe, è opportuno organizzare attentamente la sua struttura. Il codice autogenerato fornisce l’ossatura del programma, rispecchiando il flowchart di figura 2.3.4.1, e realizza le funzionalità indispensabili per la gestione dell’interfaccia utente. La suddivisione logica all’interno della classe vuole mettere in evidenza le parti codificate manualmente, e seguire per quanto possibile l’ordine di utilizzo: • field codificati manualmente: o per l’interazione con il server o per l’interpretazione dei dati o per il controllo della predefinizione • field autogenerati • metodi autogenerati: o generali (gestione della MIDlet e transizioni tra schermate) o commandAction (gestore degli eventi generati dai comandi) o getter dei field autogenerati • metodi codificati manualmente: o altri metodi di gestione della MIDlet o metodi specifici, relativi alle fasi di interazione con il server Si vogliono distinguere ulteriormente i metodi codificati a mano denominandoli con l’iniziale maiuscola, pur essendo questa convenzione diversa dalla prassi della programmazione Java. Riguardo il livello di visibilità di field e metodi, i field sono stati dichiarati quasi tutti privati, essendo raramente utili all’esterno della classe. La maggior parte dei metodi non autogenerati sono stati dichiarati di visibilità protetta, consentendone l’utilizzo solo da parte di classi concettualmente vicine a quella esistente: o ereditanti, o nello stesso package. 26
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3.1.9 Organizzazione dei package I sorgenti sono organizzati nei seguenti package: Figura 3.1.9.1: Javadoc dei package 3.1.10 Parsing XML Il parsing XML della libreria scelta si fonda sulla ricerca di determinati elementi all’interno di altri. La libreria non solleva eccezioni quando un elemento non viene trovato. Si è modificata la libreria introducendo una TagNotFoundException nel package org.kxml.kdom e adattando il metodo di ricerca getElement().getText() perché lanci questa eccezione. Si è introdotto poi il nuovo metodo getTextInElement, che ritorna un valore di default se rileva una TagNotFoundException. La scelta dell’uno o dell’altro metodo dipende dalla gravità dell’errore nel caso in cui l’elemento non venga trovato. 27
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Figura 3.1.10.1: Metodo aggiunto alla classe org.kxml.kdom.Node Figura 3.1.10.2: Codice di tabulazione di un “ai”, nella classe Tabella In figura 3.1.10.2 si può vedere un esempio dei due tipi di chiamata: nel primo blocco i tag cercati sono fondamentali perché in loro mancanza non è possibile interpretare i dati ricevuti. Nel secondo blocco si utilizzano invece dei default. Al termine si crea un oggetto per una riga della cache di configurazione. 28
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3.1.11 Record di cache e interpretazione Gli oggetti contenuti all’interno di un’istanza di Tabella sono definiti dalla classe RecordAi. Si tratta naturalmente di oggetti lato configurazione. Un RecordAi contiene le informazioni di configurazione relative a un certo “ai” di un certo modulo. Un oggetto che debba interpretare i dati di un ingresso analogico è molto avvantaggiato dall’utilizzo della cache. In primo luogo, come già illustrato, non deve attendere il parsing dell’XML di configurazione; inoltre, i dati di configurazione si presentano in una forma più fruibile rispetto a quelli dell’XML. Al momento della sua creazione, un oggetto RecordAi compie una prima elaborazione dei dati estratti dall’XML. Figura 3.1.11.1: UML class diagram di RecordAi Il cuore dell’elaborazione riguarda la configurazione dei parametri di minimo e massimo del valore ricevuto (<minv>, <maxv>), che verrà trasmesso all’interno del tag <v>, e minimo e massimo del valore reale (<mind>, <maxd>). I possibili valori del dato vengono mappati nell’intervallo di valori reali che può assumere la grandezza fisica che viene misurata. La funzione è una retta nel piano dato - valore reale, con un proprio coefficiente angolare e una quota. 29
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Figura 3.1.11.2: Costruttore della classe RecordAi Durante la costruzione di un oggetto Ai si utilizzano i parametri di configurazione conservati nella cache per trasformare il dato ricevuto dal server in una grandezza concreta. Analizzando il codice del costruttore principale dell’oggetto Ai, riportato di seguito, si può vedere che la prima istruzione (riga 22) richiede la “predisposizione” della cache: se questa non contiene già i dati relativi all’ingresso analogico, deve ricavarli dal file di configurazione. Si preleva il RecordAi corrispondente all’“ai” in costruzione accedendo alla cache con la chiave corrispondente (riga 42). Infine, si valorizzano gli attributi dell’“ai”; in particolare si calcola il valore reale della grandezza fisica utilizzando il dato ricevuto e coefficiente angolare e quota del RecordAi di configurazione (riga 47). 30
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Figura 3.1.11.3: Costruttore della classe Ai 3.1.12 Interfaccia utente Tutte le schermate presentano una struttura analoga: un titolo, un corpo e un eventuale ticker. Nei WaitScreen, schermate che possono avere durate anche considerevoli, si utilizza un ticker per segnalare all’utente che il programma è ancora attivo. Tutte le schermate di attesa riportano come corpo e come ticker un invito ad aspettare. Tutti i messaggi sono terminati da tre puntini, che sottolineano la temporaneità della schermata. Molti comandi sono dotati di label e di long label, in modo che il telefono possa mostrare quella più opportuna, a seconda della risoluzione. Le schermate di errore sono caratterizzate da un titolo tutto maiuscolo, che può essere: • ATTENZIONE, in caso di anomalia o errore non grave • ERRORE, in caso di errore grave non recuperabile Nel corpo dell’Alert si riporta una spiegazione esaustiva dell’errore. L’uscita da una schermata di errore richiede sempre l’interazione dell’utente, che dovrà premere un bottone. 31
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3.2 Tecniche di debug e simulazione Per testare i blocchi di codice sono state adoperate sia prove in ambiente simulato, direttamente all’interno dell’IDE, sia prove su tre diversi telefoni cellulari. Entrambi i tipi di test presentano dei vantaggi e degli svantaggi. L’ambiente simulato ha il pregio di essere integrato nell’IDE, permettendo quindi di sfruttarne tutte le capacità di debug. D’altra parte non tutte le funzionalità sono direttamente testabili, prima tra tutte l’instaurazione di una connessione Bluetooth. Il caricamento del programma nel telefono, necessitando del trasferimento fisico dell’eseguibile e spesso di un’installazione, costituisce una forma di test molto meno immediata. Inoltre, la limitatezza dello schermo e delle risorse non permettono né l’utilizzo di un debugger né la visualizzazione di informazioni dettagliate sullo stato del programma. Si analizzano prima le tecniche per effettuare i test sul telefono cellulare, quindi quelle nell’IDE. 3.2.1 Schermate Nella fase di progettazione si è messo in luce il legame tra funzionalità del programma e schermate: ogni parte operativa percepibile dall’utente è stata messa in background a un WaitScreen recante un messaggio di attesa significativo. In caso di eccezione, l’utente può rilevare la fase in cui si è presentato qualche problema grazie all’Alert conseguente al FAILURE_COMMAND. Sfruttando lo stesso principio, ma dal punto di vista del programmatore, è possibile impostare una strategia di test che utilizzi delle schermate, mettendo in background a ciascun WaitScreen una porzione di codice critica, e segnalando eventuali eccezioni. Si tratta ovviamente di una tecnica grossolana, perché utilizzandola da sola è possibile individuare una zona di codice responsabile dell’errore, ma tale zona può essere anche molto grande. Si presta ad essere applicata a porzioni di codice limitate. Durante la realizzazione del progetto sono state introdotte a fini di test, per ciascuna macroarea di codice, un numero di schermate maggiore di quelle necessarie nella versione finale. Effettuati i test necessari in ogni porzione di codice, le schermate si sono unificate, riportando le funzionalità ad un unico WaitScreen. 32
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Nonostante la necessità di diverse ristrutturazioni, un’implementazione di questo tipo ha reso notevolmente più agevole individuare gli errori di codifica, e ha permesso un notevole risparmio di tempo. 3.2.2 Testi Per disporre di informazioni più dettagliate in caso di errore, è utile creare delle variabili di debug. A seconda della criticità delle operazioni, le variabili possono essere: • messaggi: stringhe, in genere molto brevi, che segnalano che una certa operazione è avvenuta • log: cronologia delle operazioni di interesse; normalmente implementato con StringBuffer Durante le fasi di test sono stati aggiunti diversi Form intermedi, a carattere provvisorio, per mostrare questi messaggi. In alternativa i messaggi sono stati inseriti direttamente nel WaitScreen, interrompendolo per qualche secondo con Thread.sleep(int millis). I log, che sono più lunghi, venivano riportati in schermate a parte richiamabili dai Form con un apposito comando. Figura 3.3.2.1: Esempio di log e messaggi di debug nella classe ComunicazioneMIDlet La figura 3.3.2.1 riporta una parte del codice relativo al primo parser, quello che separa lo header dai dati in ciascun flusso di byte relativo a un modulo, evidenziando i due tipi di codice aggiunto a fini di test. 33
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth L’istruzione commentata è un esempio di messaggio; le altre costruiscono un log. Ogni riga del log corrisponde a una delle operazioni di validazione dello header, fornendo delle indicazioni molto più dettagliate rispetto al semplice messaggio. Ultimati i test, sono stati eliminati i comandi di visualizzazione dei log. Tuttavia la costruzione dei log viene mantenuta per ragioni di manutenibilità del programma. 3.2.3 Dati simulati In ambiente simulato non è possibile testare la comunicazione con il server, alla base dello scambio di dati. Il modulo di interpretazione dei dati è stato testato introducendo nel progetto una nuova configurazione, in cui si simulava la ricezione dei dati dal server precaricando un dump di XML ricevuto dal server. È stata creata una nuova MIDlet per testare il tutto sfruttando la tecnica delle schermate descritta nel paragrafo precedente. Ci si è avvalsi ancora del VMD, che ha introdotto nuovo codice autogenerato. I dump di dati sono stati impiegati in svariati contesti: • modulo di interpretazione dei dati ricevuti: simulando l’XML ricevuto dal server, si è potuta testare separatamente l’interpretazione dei dati • parser di separazione tra header e payload dei moduli: simulando l’XML ricevuto dal server, si è potuto testare separatamente il parser • lettura della predefinizione: simulando il contenuto di un RecordStore (senza realizzare la scrittura del server predefinito), si è potuto testare separatamente il reperimento di nome e URL predefiniti Per rendere più agevoli eventuali modifiche future o manutenzioni, le MIDlet così introdotte vengono conservate. 34
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3.3 Interfaccia utente 3.3.1 Installazione Il programma è contenuto nel file Linkasa.jar, da caricare nel telefono cellulare. Il telefono deve supportare Java Micro Edition (almeno CLDC-1.1 e MIDP-2.0) e la comunicazione via Bluetooth™. Le modalità di caricamento dipendono dal produttore del dispositivo; nella maggior parte dei casi si richiede l’utilizzo di un software specifico rilasciato dalla stessa casa produttrice. Per alcune marche di telefono, può essere richiesta una installazione del software dopo il caricamento. 3.3.2 Utilizzo Appena avviato il programma, compare il logo Linkasa. È possibile saltarlo premendo il tasto di conferma (o centrale, se disponibile) del telefono. Seguono due schermate di inizializzazione, che normalmente non durano molto: • Rilevamento del dispositivo locale • Configurazione del server predefinito Dalla schermata principale sono disponibili queste operazioni: • Ricerca dei dispositivi remoti • Collegamento a un server predefinito (se è disponibile) • Accesso alla guida del programma • Uscita dal programma La ricerca dà inizio ad una fase, anche piuttosto lunga, in cui vengono rilevati i dispositivi nei paraggi. Al termine viene fornita una lista in cui è possibile selezionare (con il tasto centrale o con il comando “ok”) il server desiderato. In alternativa è possibile terminare il programma o effettuare nuovamente la ricerca. Una volta selezionato un dispositivo, seguono diverse schermate in cui si richiede di attendere: • Collegamento • Ricerca dei servizi • Connessione 35
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth • In attesa dei dati • Interpretazione dei dati • (eventualmente) Salvataggio del server predefinito Segue una schermata in cui si possono vedere i dati dei moduli che si interfacciano con il server prescelto. Da qui è possibile terminare l’applicazione o richiedere nuovamente i dati al server. Nel caso in cui si richieda l’aggiornamento dei dati, vengono presentate nuovamente le schermate, a partire da quella di attesa dei dati. Se si effettua il collegamento utilizzando il server predefinito, si passa direttamente alla schermata di attesa per il collegamento. Buona parte delle schermate di attesa sono molto rapide e non visibili. Quelle che normalmente richiedono più tempo sono quella di ricerca dei dispositivi, di ricerca dei servizi, di collegamento e di interpretazione dei dati. Nessuna schermata di attesa può durare più di 15 secondi. Ciascuna fase di attesa può terminare in modo anomalo e dare luogo a un messaggio: • Impossibile rilevare il dispositivo locale (errore): il telefono non è in grado di attivare le funzionalità Bluetooth™; è molto probabile che non le supporti. L’applicazione viene terminata • Impossibile effettuare la ricerca dei dispositivi remoti (errore): il telefono non è in grado di ricercare i dispositivi remoti; se è disponibile un server predefinito, è possibile tentare comunque la connessione ma è probabile che il telefono non sia adeguato • Il dispositivo non è un server Linkasa (anomalia in fase di collegamento o di ricerca dei servizi): ripetere la ricerca ed effettuare una nuova connessione o utilizzare il server predefinito • Impossibile connettersi o comunicare con il server (anomalia in fase di connessione): provare ad utilizzare il programma più vicino al server. L’applicazione viene terminata • Il server sta impiegando troppo tempo a rispondere (anomalia in fase di attesa dei dati): provare ad avvicinarsi; è possibile riprovare o tornare alla schermata principale • I dati ricevuti non sono corretti o la connessione è stata persa (anomalia in fase di interpretazione dei dati): provare ad avvicinarsi: è possibile riprovare o tornare alla schermata principale Per un sussidio sulle funzionalità generali del programma è possibile consultare la guida, attivandola dalla schermata principale. 36
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3.3.3 Esempio di utilizzo Figura 3.3.3.1: Figura 3.3.3.3: Logo iniziale Figura 3.3.3.2: Schermata principale In attesa dopo la ricerca Figura 3.3.3.4: Figura 3.3.3.5: Lista dei dispositivi In attesa dei servizi remoti trovati del dispositivo scelto Figura 3.3.3.6: Visualizzazione dei dati All’avvio del programma viene visualizzato il logo di presentazione. Dopo le fasi di inizializzazione, si giunge alla schermata principale. Premendo il comando “ricerca” e attendendo qualche secondo, si perviene alla lista dei dispositivi trovati: tra questi figura “Mario”, il nome del server Linkasa con cui ci si vuole connettere. Selezionandolo e premendo il tasto centrale, hanno inizio varie fasi di attesa, che terminano nella visualizzazione dei dati. Dalla schermata Figura 3.3.3.7: principale si accede alla guida, utilizzando l’apposito Guida Linkasa comando, disponibile nel menu centrale. 37
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 3.4 Rilascio 3.4.1 Test Tutte le fasi di sviluppo sono state via via testate su tre modelli di cellulare: • INQ 1, con Java Micro Edition CLDC-1.1, MIDP-2.0 • Motorola MOTORAZR V3i, con Java Micro Edition CLDC-1.1, MIDP-2.0 • Motorola SLVR L6, con Java Micro Edition CLDC-1.1, MIDP-2.0 I test sono stati svolti in maniera esaustiva verificando le fasi del funzionamento e l’utilizzo dei comandi utente, anche in sequenze diverse da quelle scontate. Si è inoltre cercato di riprodurre varie situazioni di errore: • server fuori uso • distanza eccessiva dal server • allontanamento fuori portata Bluetooth dopo la connessione • presenza di altri dispositivi Bluetooth nelle vicinanze • spegnimento improvviso del telefono e recupero dei dati predefiniti 3.4.2 Offuscamento La versione di NetBeans utilizzata include un programma per effettuare l’offuscamento dei file compilati .class . Si è impostato il programma al massimo livello di offuscamento, che ha lo scopo di rendere difficilmente comprensibile tutto il codice eccetto i metodi pubblici delle classi che estendono MIDlet. Questo livello di offuscamento è indicato da NetBeans come adatto per le applicazioni. 3.4.3 Javadoc Il programma è corredato da una documentazione javadoc. 38
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 4. Conclusioni 4.1 Obiettivi Al termine del lavoro, si è giunti a un programma funzionante che ha raggiunto gli obiettivi desiderati. Il programma rilasciato è acquistabile come opzione del sistema Linkasa. 4.2 Sviluppi futuri Il progetto attuato costituisce il primo nucleo applicativo per l’interfacciamento tra telefono cellulare e server Linkasa. Presenta un’interfaccia funzionale ma estremamente semplice, che può risultare poco accattivante per un utente esigente. Una delle prime direttrici per un possibile miglioramento futuro è l’introduzione di un’interfaccia grafica. 4.3 Aspetti quantitativi Il package principale, it.linkasa, comprende 24 classi, di cui 9 modellizzano delle eccezioni. Package Numero di Di cui Numero di Tipo di classi eccezioni interfacce package it.linkasa 24 9 - principale fedlib 1 - - libreria interna org.kxml 3 - 1 libreria esterna org.kxml.io 4 1 - libreria esterna org.kxml.kdom 5 1 - libreria esterna org.kxml.parser 5 - - libreria esterna 39
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Classi principali per numero di righe di codice: ComunicazioneMIDlet 2003 (di cui circa il 61% autogenerate) Tabella 322 Modulo 292 RecordAi 144 Ai 115 DiscoveryListenerLinkasa 62 Queste classi sono tutte incluse nel package principale it.linkasa, che conta complessivamente 4530 righe di codice (di cui circa il 53% autogenerate). 4.4 Conclusioni personali Questo progetto ha permesso di acquisire conoscenze su delle modalità di programmazione particolari e all’avanguardia. Al giorno d’oggi è sempre più comune l’esigenza di integrare nei sistemi informatici un interfacciamento via telefono cellulare, spesso in parallelo all’ormai consolidato web, spostando l’interesse verso l’accessibilità ovunque, in parte a scapito della ricchezza di informazione. La conoscenza delle problematiche legate a questo tipo di dispositivi e le tecniche di programmazione sono risorse che in questi ultimi anni stanno diventando sempre più importanti nel mercato del software. 40
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth 5. Bibliografia Generalità su Java e JavaME “Learn Java Now”, Stephen R. Davis, Microsoft Press, 1996 “Bluetooth Application Programming with the Java APIs – Essentials Edition”, Timothy J. Thompson, Paul J. Kline, C. Bala Kumar, Morgan Kaufmann Series, 2008 “Guida J2ME”, Emanuele Pecorari http://java.html.it/guide/leggi/124/guida-j2me/ Glossario Java molto dettagliato http://mindprod.com/jgloss/jgloss.html Documentazione API e documentazione ufficiale di JavaME http://java.sun.com/javame/reference/apis.jsp API J2SE per comunicazioni Bluetooth, con spiegazioni dettagliate http://bluecove.org/bluecove/apidocs/index.html Librerie Libreria kXML http://kxml.sourceforge.net/about.shtml Tutorial e articoli Il mondo JavaME in NetBeans http://netbeans.org/kb/trails/mobility.html Articoli, tutorial, forum sul package per Bluetooth JSR82 http://www.jsr82.com/ Raccolta di codici di base in JavaME http://www.java2s.com/Tutorial/Java/0430__J2ME/Catalog0430__J2ME.htm “MIDP Network Programming using HTTP and the Connection Framework”, Qusay Mahmoud, 2000 http://developers.sun.com/mobility/midp/articles/network/ 41
  • Federico Cecutti Progetto e sviluppo di un’applicazione domotica per telefoni cellulari basati su Bluetooth Guida di riferimento del Javadoc http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javadoc.html Tutorial della Sun sull’I/O in Java http://java.sun.com/docs/books/tutorial/essential/io/ 42