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

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.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.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

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

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

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

• <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

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

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

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.

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

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

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

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

Figura 2.3.5.1: UML class diagram di ComunicazioneMIDlet

Figura 2.3.5.2: UML class diagram di DiscoveryListenerLinkasa

16

Federico Cecutti

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

Figura 2.4.2.1: UML class diagram di Modulo

Figura 2.4.2.2: UML class diagram di Ai

18

Federico Cecutti

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

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

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

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

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

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

L’immagine dello SplashScreen è una risorsa del programma e viene salvata nel package
di progetto it.linkasa, nel formato compresso JPEG.

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

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

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

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

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

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

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

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

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

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

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

• 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

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

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

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

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

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

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

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

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (13)

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

Similar a Cecutti Federico - Progetto e sviluppo di un'applicazione domotica per telefoni cellulari basati su bluetooth (20)

Último

Último (8)

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