1. UNIVERSITA’ DEGLI STUDI DI TRIESTE A.A. 2011/2012
UNIVERSITA’ DEGLI STUDI DI TRIESTE
FACOLTA’ DI INGEGNERIA
TESI DI INGEGNERIA INFORMATICA
Sviluppo di un applicativo su dispositivo mobile per la
visualizzazione su mappe georeferenziate di messaggi di allerta
Relatore :
Prof. Ing. Raffaela Cefalo
Dipartimento di ingegneria e architettura
Università degli studi di Trieste
Laureanda:
Cramastetter Sabrina
Corso di studi in ingegneria informatica
Università degli studi di Trieste

2. INDICE
1. INTRODUZIONE 4
2. ANALISI 9
2.1 CAP –Common Alerting Protocol 9
2.2 TSO – Tactical Situation Object 11
2.3 JIXEL – Applicazione software per lo scambio dati 13
3. PROGETTAZIONE 16
3.1 DEFINIZIONE DEI REQUISITI 16
3.2 SCELTA DELLE TECNOLOGIE 16
3.3 STRUTTURA DELL’APPLICAZIONE 19
4. REALIZZAZIONE 25
4.1 INTERFACCIA GRAFICA 25
4.2 IMPLEMENTAZIONE 30
4.2.1 Funzionamento generale 30
4.2.2 La classe CapViewer 32
4.2.3 La classe MsgParser 35
4.2.4 La classe AnalisiXML 36
4.2.5 La classe loadImage 38
CONCLUSIONI 40
BIBLIOGRAFIA 42
APPENDICE A – classe CapViewer 44
APPENDICE B – classe MsgParser 47
APPENDICE C – classe AnalisiXML 50
APPENDICE D – classe loadImage 53
APPENDICE E – Struttura e dizionario del TSO 55
2

3. L’obiettivo della presente tesi è quello di documentare la realizzazione di un’applicazione,
per dispositivi mobili, che permetta la visualizzazione di una mappa contenente le
informazioni georiferite, descritte in un messaggio di allerta, che identificano la zona
interessata dall’evento.
Questo progetto si basa su un’applicazione precedentemente realizzata come tesi, e si
concentra sul miglioramento e ampliamento di questa, inserendo appunto la funzionalità
sopra descritta.
Questo documento inizia con una breve descrizione generale degli eventi naturali disastrosi
che interessano maggiormente il suolo italiano, i quali sono frane, terremoti e valanghe.
Concentrandosi su questi eventi pericolosi, si affronta poi una breve analisi dei formati di
interscambio dati esistenti, che permettono la distribuzione delle informazioni tra gli
operatori di soccorso durante queste situazioni di emergenza; esistono diverse applicazioni
software che utilizzano questi formati per raccogliere e distribuire messaggi d’allerta, come
il Jixel, che è stata fonte di ispirazione per questa tesi.
Si passa poi al progetto vero e proprio, con la definizione dei requisiti che dovrà avere
l’applicazione, e sulla base di questi, si effettuano le opportune scelte che riguardano le
tecnologie da utilizzare.
Dopo una breve panoramica sulla struttura generale che avrà l’applicazione, ci si concentra
sulla struttura del codice Java che ha permesso la realizzazione di tale applicazione,
offrendo anche il risultato finale di tale funzionalità, cioè la visualizzazione sul dispositivo
mobile della mappa nei tre possibili casi di evento di emergenza sui quali ci siamo
concentrati.
3

4. 1. INTRODUZIONE
Nell’ultimo decennio, l’Europa è stata coinvolta in un numero crescente di eventi
catastrofici dovuti a fenomeni e ad incidenti di carattere naturale, causati da una particolare
combinazione di cambiamenti ed evoluzioni climatiche e territoriali.
Il territorio europeo è caratterizzato da particolari proprietà geofisiche e climatiche, che lo
rendono suscettibile ad una vasta gamma di eventi naturali estremi e pericolosi
pericolosi.
Frane, valanghe e terremoti sono fenomeni naturali ed ordinari, responsabili da sempre,
responsabili,
dell’evoluzione del territorio e del suo paesaggio, e proprio su questi eventi si concentra il
presente progetto.
Fig. 1: Numero di eventi disastrosi rilevati tra il 1980 e il 2009 in Europa
Europa.
I dissesti franosi sono sicuramente tra i fenomeni naturali più eclatanti e pericolosi; la frana
è un ‘processo geomorfologico’ che indica un movimento di una massa di roccia, terra o
detrito, lungo un versante.
Le frane, a causa della loro alta pericolosità, in alcune zone abitate, devono essere oggetto
di attenti studi e continui monitoraggi per tenere sotto controllo il territorio e per
individuare, il prima possibile, eventuali cambiamenti sospetti. Sono dei fenomeni locali, e
ima
perciò è particolarmente importante raccogliere tutte le informazioni sul pericolo e rischio,
coinvolgendo pienamente le attività presenti come parti interessate nel processo.
4

5. Un altro tipo di evento catastrofico è la valanga, che è costituita da masse nevose che si
distaccano dai pendii di un rilievo, precipitando verso valle ed accrescendosi di volume
durante il loro percorso. La prevenzione dei pericoli derivanti dalle valanghe, sul territorio
montano, si basa sull’emissione di un bolletino nivometeorologico, che contiene le
informazioni sulla passata evoluzione delle condizioni meteo e del manto nevoso e inoltre
le valutazioni sulle possibili valanghe.
Fig.2: Scala europea per il pericolo delle valanghe.
Per prevedere e prevenire le valanghe, è stata ideata una scala unificata europea, definita
nel 1993, che contiene i concetti fondamentali a cui fanno riferimento tutti gli strumenti di
valutazione del pericolo per questo fenomeno.
L’Italia è uno dei Paesi a maggiore rischio sismico tra quelli affacciati sul Mediterraneo,
sia per la frequenza dei terremoti che hanno storicamente interessato il suo territorio, sia
per l’intensità che alcuni di essi hanno raggiunto.
Anche se le informazioni di base sui terremoti e sul loro impatto sono abbastanza complete
ed integrate, le banche dati, che riguardano i disastri globali, si potrebbero ulteriormente
migliorare attuando alcuni semplici accorgimenti, come ad esempio la progettazione e
l’utilizzazione di un approccio standardizzato e sistematico per la valutazione dei costi
complessivi dei terremoti.
Per proteggere e salvaguardare la vita dei cittadini e il patrimonio delle comunità, non
bisogna puntare unicamente su soccorsi tempestivi, ma occorre dedicare energie e risorse
importanti alla previsione e alla prevenzione delle calamità.
5

6. L’attività di gestione e di riduzione del rischio di un disastro, in Europa, si è spostata da un
approccio orientato unicamente alla risposta all’evento di emergenza, verso una gestione
integrata dei rischi (IRM – Integrated Risk Management) che include la prevenzione, la
preparazione, la risposta e il recupero in una situazione di emergenza.
Fig. 3: Schema del ciclo di gestione delle calamità naturali.
In Italia, l’attività di previsione di un evento di emergenza è assicurata da un sistema di reti
che collega la protezione civile italiana a numerosi centri nazionali di ricerca e di raccolta
di informazioni scientifiche. Questa valuta le situazioni di possibile rischio, allerta il
sistema di intervento con il massimo anticipo utile, ma anche fornisce alle autorità
coinvolte gli elementi necessari a prendere decisioni ragionate e tempestive, attraverso
l’utilizzo di messaggi di allerta accurati e completi.
Le strategie di riduzione dei rischi di calamità si basano su cinque importanti concetti:
1. La riduzione del rischio deve avere una priorità locale e nazionale con una solida base
istituzionale per la sua attuazione.
2. I rischi di catastrofe devono essere identificati, valutati e monitorari costantemente ed è
necessario migliorare l’avvertimento precoce.
3. La conoscenza, l’innovazione e l’educazione sono alla base di una cultura del soccorso
e della resilienza a tutti i livelli.
4. I fattori di rischio sottostanti devono essere ridotti.
5. La preparazione a catastrofi deve essere rafforzata per una risposta rapida ed efficace.
6

7. Sulla base delle considerazioni appena introdotte, è necessario ora concentrarsi sulla
gestione e sulla visualizzazione delle informazioni che devono pervenire a tutti i soggetti
coinvolti nel disastro.
Queste informazioni offrono, al soggetto che le riceve sul proprio dispositivo, tutte le
notizie o gli eventuali aggiornamenti di un evento catastrofico in corso; tutto ciò viene
catastrofico
annunciato con un messaggio di testo che descrive la situazione d’emergenza.
Proprio la tempestività, con cui questi messaggi raggiungono tutti i soggetti interessati, è
uno degli obiettivi più importanti per limitare e affrontare nel modo migliore tale
situazione.
Fig. 4: Schema di gestione delle informazioni a seguito di una calamità
Il presente lavoro ha come punto di partenza un progetto già esistente, che è stato creato da
uno studente di Ingegneria Informatica come propria tesi triennale; tale progetto si
come
concentrava sulla creazione di un prototipo di un’applicazione in grado di gestire e
visualizzare, su un generico dispositivo mobile, il contenuto di un messaggio di allerta.
Il formato scelto per la codifica dei messaggi d’allerta, in questo specifico caso, è il CAP
(Common Alerting Protocol), che verrà analizzato nelle prossime pagine.
L’applicazione di partenza è in grado di visualizzare, sottoforma di righe di testo, i dati
contenuti nel messaggio di emergenza, ed utilizzando i tasti del dispositivo mobile, sul
quale l’applicazione è in funzione, si possono raggiungere e visualizzare ogni tipo di
informazione contenuta in quel particolare messaggio.
7

8. Partendo da ciò, lo scopo della presente tesi è quello di ampliare e migliorare tale
applicazione, introducendo un’ulteriore importante funzionalità.
L'obiettivo principale è stato quello di visualizzare su dispositivo mobile una mappa
contenente l'informazione georiferita che identifica la zona interessata dall’evento descritto
nel messaggio.
Questa documento è articolato come segue: nella prima parte vengono analizzati i formati
di interscambio dati, CAP (paragrafo 2.1) e TSO (paragrafo 2.2), e la loro applicazione
software nelle situazioni di emergenza Jixel (paragrafo 2.3), che porteranno ad individuare
alcuni dei requisiti dell’applicazione che dovrà essere realizzata.
Dopo aver definito tutti i requisiti (paragrafo 3.1), si descrivono le varie tecnologie che
saranno utilizzate per lo sviluppo (paragrado 3.2) e la realizzazione del progetto (paragrafo
3.3).
Nell’ultima parte di questo documento, l’attenzione si concentra sulla realizzazione
dell’applicazione (capitolo 4), soffermandosi sia sull’interfaccia grafica (paragrafo 4.1) sia
sul suo funzionameno interno (paragrafo 4.2), descrivendo e analizzando il codice
informatico.
8

9. 2. ANALISI
2.1 CAP – Common Alerting Protocol
Il CAP (Common Alerting Protocol = Protocollo di avviso comune) è il primo standard
redatto dal Comitato Tecnico per la Gestione delle Emergenze dell’OASIS (Organization
for the Advancement of Structured Information Standards), ed è un’attività di interscambio
dati, utilizzata per raccogliere tutti gli avvisi di pericolo, con lo scopo di inviare e ricevere
informazioni legate ai sistemi di gestione e diffusione degli allarmi.
Il CAP migliora la gestione e la diffusione della consapevolezza dell’evento che richiede
l’assistenza di sistemi di emergenza, fornendo allo stesso tempo aggiornamenti continui su
un database che gestisce i messaggi di allarme.
Il CAP è un formato standard basato sul linguaggio XML per lo scambio di dati inerenti ad
avvisi pubblici ed ad emergenze tra i vari sistemi di allerta, che permette di inviare un
messaggio di avviso che viene simultaneamente diffuso su molti sistemi di allarme e su
molte applicazioni.
L’applicazione principale del messaggio di tipo CAP è quella di fornire un unico formato
in uscita per effettuare l’attivazione di tutti i tipi di sistemi di allarme pubblici, riducendo
così notevolmente il carico di lavoro associato all’utilizzo contemporaneo di più sistemi e,
allo stesso tempo, garantisce la consistenza dell’informazione trasmessa su sistemi multipli
di consegna.
Fig.5: Struttura del CAP
9

10. La struttura del messaggio è articolata in quattro blocchi principali, chiamati segmenti, i
quali, a loro volta, contegono delle specifiche informazioni riguardanti l’evento di
emergenza a cui si riferiscono.
I segmenti di un messaggio CAP sono:
- <alert> : è il segmento principale sempre presente, e racchiude tutti i sottoelementi del
messaggio.
- <info> : è un segmento opzionale ed è correlato con <alert>, e contiene gli elementi
essenziali per delineare e caratterizzare l’evento che è oggetto del messaggio.
- <resource> : è un segmento opzionale ed è correlato con <info>, e contiene gli
elementi utilizzati per descrivere i file addizionali correlati al messaggio.
- <area> : è un segmento opzionale ed è correlato anch’esso con <info>; contiene le
informazioni inerenti alla descrizione dell’area coinvolta nell’evento.
Il segmento, che è stato oggetto di studio per lo sviluppo di questo progetto, è stato proprio
quest’ultimo, cioè il segmento <area>; infatti, proprio al suo interno, si trovano le
informazioni che verranno utilizzate per localizzare sulla mappa la zona interessata
dall’evento.
Il segmento <area> è composto da alcuni sottoelementi:
- <areaDesc> : è l’unico elemento obbligatorio nel segmento, e contiene una descrizione
testuale dell’area di interesse del messaggio.
- <polygon> : contiene i punti che definiscono un poligono che delinea l’area di
interesse; il poligono geografico è rappresentato da una lista di coppie di coordinate.
- <circle> : contiene la coppia di coordinate che localizzano un punto e la lunghezza del
raggio in chilometri che delinea l’area circolare interessata.
- <geocode> : è il codice geografico che indica l’area di interesse.
- <altitude> : indica la minima o specifica altitudine dell’area interessata dal messaggio.
- <ceiling> : deve essere usato solo in combinazione con l’elemento <altitude> e indica
l’altitudine massima dell’area interessata dal messaggio.
Dopo un’attenta valutazione, si giunge alla conclusione che le informazioni che riguardano
la localizzazione geografica dell’evento su un’eventuale mappa sono contenute all’interno
degli elementi <polygon> e <circle>; se nel messaggio questi non sono presenti, allora la
localizzazione dell’evento non è immediata, in quanto vengono fornite solamente
indicazioni testuali che individuano il luogo interessato indicando nomi di città o di paesi
vicini e quindi nessun tipo di coordinata.
10

11. Quindi riassumendo, le informazioni di interesse sono che l’elemento <polygon> contiene
una serie di coppie di coordinate che delineano i confini dell’area interessata, mentre
l’elemento <circle> contiene sia le coordinate del luogo in cui è avvenuto l’evento di
emergenza, sia la lunghezza di un eventuale raggio per formare una circonferenza, che in
molti casi risulta essere zero, e perciò non è presente.
2.2 TSO – Tactical Situation Object
Il TSO (Tactical Situation Object) è uno dei principali mezzi utilizzati per raggiungere il
livello minimo di interoperabilità tra le varie agenzie di soccorso, in quanto definisce una
struttura di informazioni che consente la memorizzazione di una determinata situazione di
emergenza.
Esistono diversi metodi per aumentare e migliorare il livello di interoperabilità tra le
diverse agenzie di soccorso che operano in modo congiunto in una situazione d’emergenza.
La situazione ideale che si vuole raggiungere è quella di poter condividere lo stesso
modello di dati e di aver accesso ad un grande e comune database virtuale, così ogni parte
di informazione è immediatamente disponibile e condivisibile tra tutte le agenzie.
La complessità della struttura del messaggio è stata intenzionalmente limitata per facilitare
la compatibilità con il sistema e le infrastrutture esistenti; lo scopo della specifica è quello
di garantire che il significato di ogni singolo messaggio sia inequivocabile.
L’utilizzo principale del TSO è lo scambio di informazioni complete ed esaurienti tra due o
più entità di tipo operativo; per questo tipo di scambio, il mittente del TSO deve ritenere
che il collegamento, con i destinatari del messaggio, potrebbe venire interrotto, e perciò
l’informazione contenuta nel TSO deve essere fin da subito la più completa possibile.
La struttura di un messaggio TSO definisce la struttura del messaggio XML, il tipo di dati
di ogni elemento, ed eventuali vincoli sui valori validi di ogni elemento; un numero
significativo di elementi è definito da codici specifici che identificano i concetti da fornire
all’utente finale.
Le informazioni importanti, contenute all’interno del TSO, sono:
o Le INFORMAZIONI DI IDENTIFICAZIONE descrivono l’origine dell’informazione e
quando questa è stata creata.; sono informazioni obbligatorie all’interno del TSO.
o La DESCRIZIONE DELL’EVENTO fornisce informazioni importanti riguardanti il
tipo di evento, la sua estensione, il numero delle vittime, le sue conseguenze, etc.
11

12. o La DESCRIZIONE DELLE RISORSE fornisce le informazioni riguardanti le risorse
umane, la loro eventuale disponibilità, la loro posizione e la loro capacità.
Ogni singola agenzia coinvolta dispone di varie risorse ed è quindi necessario conoscere
quali sono già state utilizzate o quali risorse sono disponibili.
o La DESCRIZIONE DEI COMPITI permette di informare le varie agenzie coinvolte
sulle attività che si stanno svolgendo o che si svolgeranno a breve per coordinare e
gestire la situazione il meglio possibile.
Il TSO consente lo scambio di informazioni tattiche tra diverse agenzie durante
un’emergenza; nonostante il gran numero di dati, che possono essere inclusi all’interno di
un messaggio TSO, la struttura di base è semplice.
È un dizionario di tipo gerarchico (vedi Appendice E); ogni singola applicazione è a
conoscenza di una parte di questo dizionario, quella parte che è inerente all’uso di quella
determinata applicazione.
Un altro vantaggio nell’utilizzo del TSO è quello di avere la possibilità di utilizzare diverse
versioni del dizionario gerarchico; un’applicazione che sta usando un dizionario vecchio
deve essere in grado di ricevere informazioni sulla base del dizionario più recente, così
come un’applicazione che usa un dizionario recente deve essere in grado di ricevere
informazioni sulla base del contenuto di un vecchio dizionario.
Fig.6: Struttura del TSO
12

13. 2.3 JIXEL - Applicazione software per lo scambio dati
Lo schema generale, per la risposta ad una situazione di rischio, necessita della conoscenza
del fenomeno stesso, di un monitoraggio ambientale costante, di un allarme rapido dei
servizi, di tempi brevi di intervento e dell’impiego ottimale delle risorse che si hanno a
disposizione.
L’elemento chiave risiede quindi nella velocità, nel coordinamento e nel trasferimento
efficiente e tempestivo delle informazioni necessarie per effettuare interventi mirati per le
situazioni di emergenza e per i vari servizi di soccorso al cittadino.
Ogni singola informazione è un importante contributo per migliorare la comprensione
dell’evento che si sta verificando, ed è visualizzata come un messaggio, basato sul formato
di interscambio dati CAP (Common Alerting Protocol).
Il CAP viene utilizzato da molte applicazioni per permettere lo scambio di messaggi tra le
varie sale operative dei servizi di emergenza; una di queste è il Jixel, che è una suite di
applicazioni di tipo software, basate sul web, che ha lo scopo di consentire ai servizi di
emergenza di scambiarsi informazioni, sia durante le operazioni giornaliere di soccorso, sia
nella gestione straordinaria di eventi catastrofici e delle loro conseguenze.
Il CAP è il formato dati XML standard che Jixel usa per gestire le varie informazioni e i
dati rilevanti che riguardano un determinato incidente.
Gli aspetti più importanti e significativi del CAP sono l’interoperabilità con tutti i sistemi
di emergenza, la completezza, in quanto il formato deve prevedere tutti gli elementi di un
sistema di avviso pubblico, la struttura XML e il formato multiuso, che è in grado di
supportare tutti i tipi di messaggi multipli e multilingua.
Come il CAP, anche il TSO (Tactical Situation Object) è un protocollo basato sulla
struttura dati XML, composta da differenti blocci di informazione, che offre un livello
minimo di interoperabilità tra i servizi di emergenza.
Lo stesso TSO definisce una serie di codici che identificano univocamente una determinata
tipologia di emergenza; Jixel utilizza i codici definiti nel dizionario del TSO all’interno
della struttura dati CAP permettendo, così, una completa comprensione dell’evento.
La struttura del Jixel è quella definita dal CAP e il suo contenuto informativo è inserito
utilizzando i campi definiti dalla struttura CAP facendo anche uso dei termini definiti dal
TSO.
L’architettura del Jixel è composta da 3 importanti blocchi : CAP Generator, CAP Router e
CAP Viewer.
13

14. Il CAP Generator permette di creare e condividere i dati sull’incidente attraverso l’utilizzo
di un’interfaccia grafica intuitiva; si possono segnalare gli incidenti assegnando le
coordinate geografiche e tante altre informazioni, ad esempio la descrizione dell’incidente,
le risorse, gli allegati, ecc.
Fig.7: Schermata di Jixel Demo – Cap Generator
Il CAP Router è il servizio web che viene utilizzato per la distribuzione dei messaggi alle
organizzazioni partner a cui sono destinati; si possono configurare i destinatari per ogni
specifica tipologia di messaggio e per questo il CAP Router è in grado di creare un
meccanismo di scambio dati sicuro e criptato per ognuno di essi.
Fig.8: Schermata di Jixel Demo – Cap Viewer
14

15. Infine, il CAP Viewer ha il compito di visualizzare, filtrare e raggruppare, su un’interfaccia
geografica, le informazioni contenute nei messaggi distribuiti dal CAP Router.
Proprio quest’ultimo è stato la fonte di ispirazione per il presente progetto, in quanto
contiene tutte le funzionalità di cui si vuole arricchire e migliorare il precedente prototipo.
La caratteristica del software Jixel, che è il punto centrale di questo elaborato, è la
possibilità di visualizzare su una mappa gli incidenti di cui ci si occupa, utilizzando
l’interfaccia tipica di Google Maps.
In questo caso, la modalità di rappresentazione degli incidenti varia in base al livello di
zoom che si sta utilizzando, in modo da lasciare all’utente in utilizzo la possibilità di
decidere se avere una visione globale degli incidenti oppure una vista dettagliata delle
caratteristiche degli incidenti.
Il presente lavoro si concentra unicamente sulla funzionalità di visualizzazione dell’evento
e lascia ad eventuali ritocchi futuri il compito di rendere accessibile all’utente anche la
possibilità di zoomare sulla mappa.
15

16. 3. PROGETTAZIONE
3.1 DEFINIZIONE DEI REQUISITI
Sulla base delle considerazioni fatte finora, l’applicazione dovrà essere in grado di gestire
un messaggio conforme al protocollo CAP, cioè un file formato XML; successivamente
dovrà estrarre le informazioni utili all’utente, quelle contenute in <polygon> e in <circle>,
che verranno elaborate e, attraverso un collegamento internet, si potrà accedere alla mappa
che localizzerà l’evento di interesse.
L’applicazione dovrà essere indipendente dalla piattaforma sulla quale verrà eseguita, per
rimanere concorde alle caratteristiche di interoperabilità e portabilità proprie del CAP.
Questo progetto ha il compito di elaborare l’applicazione base già esistente, in modo tale
da permettere la visualizzazione in formato grafico delle informazioni contenute nel
messaggio di allerta, con lo scopo di far conoscere all’utente, il più rapidamente possibile,
quale area è interessata dall’evento e se si potrebbe trovare coinvolto da esso.
La tipologia di utenza per questa applicazione un generico utente in movimento, come ad
esempio un cittadino coinvolto nell’emergenza oppure un operatore di soccorso.
Perciò l’utilizzo di tale applicazione avverrà unicamente su dispositivi mobili,
caratterizzati da due importanti fattori: la dimensione ridotta dello schermo su cui si
visualizzeranno le informazioni e le contenute risorse di calcolo e di memorizzazione.
Riassumendo, i requisiti base dell’applicazione sono:
1. Gestione ed estrazione di informazioni specifiche da un documento XML
2. Indipendenza dalla piattaforma di esecuzione
3. Necessità di esecuzione su dispositivi mobili
4. Collegamento ad internet e visualizzazione della mappa
3.2 SCELTA DELLE TECNOLOGIE
Il sistema di sviluppo scelto per l’applicazione è Java Micro Edition System Development
Kit3.0, in quanto Java è uno dei linguaggi informatici più utilizzati e non dipende
dall’architettura su cui viene eseguito, purchè ci siano i requisiti e gli strumenti per
interpretare il codice Java.
16

17. La piattaforma Java ME è organizzata in virtual machine, con configurazioni, profili ed
API opzionali, che opportunamente combinati consentono di realizzare una vastissima
gamma di prodotti e servizi applicativi.
Per soddisfare il primo requisito, si è scelta una libreria Java che permettesse la gestione di
un documento in formato XML, cioè la libreria kXML, la quale fornisce tutte le
funzionalità di cui abbiamo bisogno.
kXML è una libreria di API che implementa un pull parser di codice XML; è molto
importante perché permette di fare il parsing di documenti XML nei dispositivi cellulari, in
altre parole il testo viene accuratamente analizzato in maniera sintattica.
Per quanto riguarda l’ultimo requisito, la piattaforma Java ME è stata progettata fin dal
principio con un forte orientamento alla connettività, e HTTP (HyperText Transfer
Protocol) è l’unico protocollo garantito su qualsiasi implementazione MIDP.
L’HTTP è stato il protocollo di trasporto universale per la creazione di sistemi distribuiti
ed interoperabili: è un protocollo client/server testuale (poiché i codici di controllo del
protocollo sono espressi come stringhe di testo semplice), sincrono (poiché l’invio della
risposta da parte del server è contestuale alla ricezione della richiesta e il trasferimento
avviene all’interno della medesima connessione) e stateless (poiché non vi è correlazione
tra invocazioni successive), basato sulla sequenza request-response tra client e server.
Considerando ora la visualizzazione della mappa, si è pensato di ricorrere all’utilizzo delle
cosiddette Google Static Maps API, cioè una metodologia che consente di incorporare
un’immagine di Google Maps su un’eventuale pagina web senza la necessità di ricorrere a
JavaScript o al caricamento di pagine dinamiche.
Questo servizio, offerto da Google Maps, crea una mappa sulla base dei parametri che
vengono immessi nell’URL, che vengono poi inviati tramite una richiesta HTTP standard;
viene restituita una mappa come un’immagine statica nel formato gif, png e jpeg.
Per ogni richiesta, è possibile specificare la posizione della mappa, la dimensione
dell’immagine, il livello di zoom, il tipo di mappa che si vuole visualizzare, e il
posizionamento di eventuali marcatori, e molto altro ancora.
La forma base per un URL di Google Static Maps API è :
http://maps.googleapis.com/maps/api/staticmap?parameters
Esistono numerosi tipi di parametri che permettono di personalizzare le mappe, ma per
questo progetto ci siamo concentrati unicamente sui seguenti:
17

18. - center : definisce il centro della mappa, equidistante da tutti i bordi della mappa;
questo parametro può assumere una determinata posizione sia come una coppia di valori
separati da virgola, cioè latitudine,longitudine, ad esempio “40.714728,
-73.998672”, oppure come un indirizzo di stringa, per esempio “City Hall, New York,
NY”; in questo elaborato si è scelto di occuparci della localizzazione del centro della
mappa con l’utilizzo delle coordinate descritte all’interno del messaggio di allerta.
- zoom: definisce il livello dello zoom della mappa determinando il livello di
ingrandimento della stessa; i valori per lo zoom vanno dallo 0, cioè il più basso livello
di zoom che permette di visualizzare il mondo intero sulla mappa, al 21+, che permette
di visualizzare singoli edifici.
- size: è un parametro obbligatorio che definisce le dimensione dell’immagine; richiede
una stringa della forma horizontal_value x vertical_value; in questo
progetto, avendo a che fare con dei dispositivi mobili muniti di uno schermo di ridotte
dimensioni, si è predisposta come dimensione standard la 250x270, e in questo modo
l’immagine viene visualizzata interamente ed è delle stesse dimensioni dello schermo.
- maptype: definisce il tipo di mappa da costruire; ci sono diversi valori possibili per
questo parametro, tra cui roadmap (valore di default, specifica un’immagine standard
così come viene normalmente visualizzata sul sito web di Google Maps), satellite
(specifica un’immagine satellitare), hybrid (specifica un ibrido tra l’immagine
satellitare e l’immagine di default, mostrando uno strato trasparente di strade principali
e toponimi sull’immagine satellitare) e terrain (specifica una mappa in rilievo che
mostra terreno e vegetazione); per questo progetto si è l’hybrid.
- markers: definisce uno o più indicatori che vengono allegati all’immagine in posizioni
specifiche, e può assumere valori diversi separati dal carattere pipe (|).
- path: definisce un unico percorso di due o più punti collegati tra loro che va a
sovrapporsi all’immagine nella località specificata; questo parametro richiede una
stringa di definizioni per ogni punto separata dal carattere pipe (|); c’è la possibilità di
non specificare i valori per i parametri di center e zoom se è presente questo
parametro, avendo così un posizionamento implicito per la mappa.
- sensor: è un parametro obbligatorio che specifica se si utilizza un sensore per
determinare la posizione attuale dell’utente; i valori possibili sono true o false.
Le Google Static Maps API sono in grado di identificare con precisione le posizioni di
particolari punti sulla mappa e di mettere a fuoco la mappa nella posizione corretta, usando
18

19. il parametro center, e/o di allegare un qualsiasi marcatore opzionale sulla mappa,
utilizzando il parametro marker.
Le Google Static Maps API utilizzano i numeri per i valori di latitudine e longitudine
oppure stringhe o indirizzi per specificare queste posizioni, e questi valori identificano in
maniera geocodificata una posizione.
Le latitudini e le longitudini sono definite con dei numeri all’interno di una stringa separata
da virgole di testo che devono avere al massimo una precisione di sei cifre decimali, ad
esempio “40.714728,-73.998672” è un valore geocodificato valido; la precisione al di
là delle sei cifre decimali viene ignorata.
Si utilizza come sistema di riferimento WGS84 (World Geodetic System 1984), ovvero un
sistema di riferimento geodetico concepito per coprire tutto il globo terreste; è un sistema
globale geocentrico, definito attraverso osservazioni spaziali e costituito da una terna
cartesiana destrorsa con origine coincidente con il centro di massa della Terra, l’asse Z
parallelo alla direzione del CTP (Polo Convenzionale Terrestre), l’asse X passante per il
meridiano di Greenwich e l’asse Y diretto in modo tale da completare la terna ortogonale
destrorsa.
A questo sistema è associato l’ellissoide WGS84, anch’esso definito attraverso
osservazioni spaziali, con centro e assi coincidenti con quelli della terna cartesiana.
I valori di latitudine e longitudine devono corrispondere ad un percorso valido sulla
superficie della terra: le latitudini possono assumere valori compresi tra -90 e +90, mentre i
valori della longitudine devono essere compresi tra -180 e +180.
Se si specifica una latitudine o una longitudine non valida, la richiesta per quella
particolare mappa verrà respinta.
3.3 STRUTTURA DELL’APPLICAZIONE
La struttura di base, da cui si è partiti per effettuare le opportune modifiche per visualizzare
la mappa dell’evento, è suddivisa in due parti principali: la prima è destinata unicamente
alla gestione della parte grafica, mentre la seconda alla gestione del codice XML di cui è
composto il messaggio.
Le modifiche apportate al progetto iniziale sono dei ritocchi nella parte grafica e
l’inserimento di due nuove importanti parti: una si concentra sulla gestione della
connessione internet e del caricamento dell’immagine associata a un determinato URL,
19

20. mentre la seconda è l’analisi del documento XML e l’estrazione di informazioni per la
creazione della mappa.
L’applicazione deve visualizzare il testo del messaggio CAP e deve informare l’utente
sulla zona interessata dall’evento utilizzando la mappa.
Ci siamo concentrati, in modo specifico, su eventi catastrofici, quali terremoti, valanghe e
frane; per ognuno di questi eventi, si è ricercata una situazione di emergenza realmente
accaduta, e sulla base delle informazioni rinvenute, si è creato un ipotetico messaggio CAP
che avrebbe potuto essere inviato in quella particolare situazione di emergenza.
Come evento sismico si è scelto il terremoto avvertito in Emilia il 25 gennaio 2012.
Dopo le scosse di terremoto che hanno provocato paura nel Veronese, un’altra scossa
molto forte è stata registrata alle 9:06 in provincia di Reggio Emilia, e questa scossa è stata
di magnitudo 4.9 della scala Richter.
La struttura XML del messaggio CAP di questo evento potrebbe essere la seguente:
Fig.9: Esempio di struttura XML di un messaggio di allerta per un terremoto
Come evento franoso si è scelta la frana di San Fratello, in provincia di Messina; nel
pomeriggio del 13 febbraio 2010, nel comune di San Fratello, si è innescata una frana, e
tale fenomeno, con un movimento di tipo retrogressivo, è progredito verso monte
coinvolgendo la porzione orientale del centro abitato.
Il messaggio CAP, associato a tale avvenimento catastrofico, potrebbe essere il seguente:
20

21. Fig.10: Esempio di struttura XML di un messaggio di allerta per una frana
Come evento valanghivo, ci si è concentrati sulla valanga della Marmolada del 7 aprile
2011; una valanga si è staccata dalla Marmolada finendo su una delle piste da sci
sottostanti, sopra il rifugio Fedaia, non distante dalla partenza degli impianti.
Il messaggio CAP associato a questa situazione di emergenza potrebbe essere il seguente:
Fig.11: Esempio di struttura XML di un messaggio di allerta per una valanga
21

22. Come si può notare da questi tre esempi di messaggi CAP, il codice XML, da cui sono
composti, è articolato a livelli; il livello sul quale dobbiamo concentrarci è quello relativo
al segmento <area>; le informazioni di cui dobbiamo disporre per la creazione di una
mappa sono <circle> o <polygon>.
L’applicazione dovrà quindi essere in grado di accedere al codice XML, e scorrerlo
completamente per cercare le informazioni contenute nell’elemento <circle> o <polygon>,
che verranno poi estratte e modificate adeguatamente per poter essere utilizzate per creare
l’URL che definirà la mappa del luogo in questione.
La struttura dell’applicazione sarà quindi articolata in quattro classi, come si può vedere
nel relativo diagramma:
MsgParser
Attributes
private parser
private doc
private root
CapViewer
Attributes Operations
private filename Pprotected MsgParser (filename)
protected display protected [0..*]parseElement (el_name,level)
protected select1
protected select2
protected select3
protected frm AnalisiXML
protected frm2
protected frmMap Attributes
protected si
private parser
protected si2
private doc
protected exitCmd
private root
protected backCmd public circle
protected imageCmd
public polygon
private imageItem
public valnull
private aImage
public v_str
public v_str2
Operations
public CapViewer( )
public startApp( ) Operations
public pauseApp ( ) public String read(filename)
public destroyApp (unconditional)
public commandAction (c,d)
LloadImage
Operations
public image loadImage (URL)
Fig.12: Diagramma delle classi
22

23. La classe CapViewer ha il compito di gestire l’interfaccia grafica dell’applicazione, per la
visualizzazione delle informazioni contenute nel messaggio CAP; tra gli attributi, notiamo
protected imageCmd, che è l’identificativo del tasto del menu per accedere alla mappa.
private imageItem e private aImage sono due attributi necessari per la creazione e la
visualizzazione della mappa corrispondente al messaggio di allerta.
Tra i vari metodi (operations), all’interno di questa classe, è molto importante
CapViewer(),il costruttore, che si occupa della gestione complessiva dell’applicazione,
in quanto al suo interno si inizializzano le variabili per la gestione dell’interfaccia grafica.
startApp() si occupa dell’avvio dell’applicazione e delle operazioni che avvengono nel
corso del funzionamento; in questo metodo, è presente un’importante sequenza di linee di
codice che crea l’URL della mappa, a partire dalle informazioni lette dal messaggio XML,
e carica l’immagine associata a quel determinato URL attraverso un collegamento internet.
commandAction() gestisce le interazioni che avvengono tra utente ed applicazione, in
altre parole, la gestione del menu delle possibili azioni che può svolgere l’utente; nel caso
in cui l’utente decida di voler visualizzare la mappa dell’evento, può cliccare sul tasto
relativo al comando ImageMAP presente nella schermata principale del messaggio.
I restanti due metodi di questa classe sono: pauseApp(), gestisce un eventuale stato di
pausa dell’applicazione, e destroyApp(), si occupa delle operazioni necessarie per
portare a termine l’applicazione.
La classe MsgParser ha il compito di analizzare e leggere l’intero codice XML che
compone il messaggio d’allerta, utilizzando due metodi (operations): MsgParser() si
occupa dell’accesso al file contenente il codice XML e parseElement() gestisce
l’estrazione e la gestione delle informazioni richieste dall’utente.
La classe AnalisiXML fornisce le informazioni necessarie alla creazione della mappa; tra i
vari attributi, notiamo v_str e v_str2, due vettori, che permetteranno di estrarre e
manipolare specifiche informazioni di testo.
circle e polygon saranno i valori che il metodo read() restituirà a seconda delle
informazioni presenti nel messaggio CAP; conterranno i valori per le coordinate del punto
centrale o dei punti di un percorso, già modificati, per poter essere inseriti come parametri
all’interno dell’indirizzo URL che permetterà di visualizzare la mappa del luogo
interessato.
23

24. La classe loadImage è composta da un unico metodo (operations) loadImage(), che ha
il compito di aprire una connessione http per poter accedere ad internet, in modo tale da
scaricare da un determinato URL l’immagine associata alla mappa dell’evento.
L’interazione tra queste classi avverrà nel seguente modo: quando sarà necessario, la classe
principale CapViewer invocherà uno dei metodi della classe MsgParser a seconda
dell’operazione che dovrà essere effettuata, ovvero, a seconda del tasto che l’utente
premerà, verranno richiamati dei metodi della classe MsgParser con valori inerenti
all’azione da compiere.
La classe CapViewer invocherà sempre il metodo read() della classe AnalisiXML, per
essere al corrente, fin da subito, di quali informazioni si dispone ad ogni messaggio di
allerta; all’avvio dell’applicazione si creerà la connessione internet e si scaricherà già
l’immagine della mappa associata all’evento, oppure un’immagine vuota, se le
informazioni di <circle> o <polygon> non sono presenti.
Solamente se l’utente ricercherà, tra i comandi del menù, la funzionalità per la
visualizzazione di un’eventuale mappa associata al messaggio, l’immagine verrà inserita
nella schermata corrente e sarà finalmente visibile sullo schermo; altrimenti resterà caricata
nel sistema e non verrà agganciata a nessun Form finchè questo non sarà richiesto
dall’utente che sta usando l’applicazione.
24

25. 4. REALIZZAZIONE
4.1 INTERFACCIA GRAFICA
All’avvio dell’applicazione, l’interfaccia grafica si presenta come di seguito:
Fig.13: Visualizzazione schermata principale dell’applicazione
Come si può osservare da questa immagine, è presente sullo schermo una lista di contenuti
che fanno parte del segmento principale <alert> del codice XML di un generico messaggio
CAP, che si può scorrere utilizzando i tasti direzionali del dispositivo e, per ogni elemento
visualizzato, sono disponibili i corrispondenti sottoelementi.
Per visualizzare questo contenuto, è necessario evidenziare l’elemento di interesse e usare
il tasto di selezione del dispositivo.
A seconda del tipo di contenuto dell’elemento selezionato, verrà visualizzata una
schermata diversa: nel caso di elementi composti unicamente da informazioni testuali, si
aprirà una schermata che conterrà il nome dell’elemento appena selezionato assieme al suo
valore; nel caso, invece, di elementi composti da liste che contengono ulteriori elementi
testuali, verrà presentata una lista interattiva, in cui l’utente dovrà evidenziare l’elemento
desiderato ed accedervi selezionandolo con il tasto del dispositivo.
25

26. In altre parole, la visualizzazione degli elementi testuali che compongono il messaggio
CAP, che giunge al dispositivo mobile, potrebbe essere la seguente:
Fig.14: Visualizzazione di un elemento testuale e visualizzazione di un elemento complesso
Nella schermata principale, quando si avvia l’applicazione, si nota la presenza di due
importanti tasti: il tasto “Exit”, che ha il compito di permettere la chiusura
dell’applicazione se esso viene selezionato, e il tasto “ImageMAP” che è il frutto di questo
progetto.
Selezionando questo tasto, si accede direttamente alla visualizzazione della mappa
associata al messaggio d’allerta corrente.
A seconda del tipo di evento di emergenza, considerato volta per volta, si riscontrano
alcuni importanti aspetti nella visualizzazione delle relative mappe.
Nel momento in cui giunge, sul dispositivo mobile, un messaggio di emergenza, l’utente ha
la possibilità, con la pressione di un unico tasto, di rendersi conto della gravità del danno
causato dall’evento localizzando il luogo o la zona colpita.
Se consideriamo gli eventi di emergenza prima discussi, cioè il terremoto dell’Emilia, la
valanga sulla Marmolada e la frana di San Fratello, notiamo alcune caratteristiche
interessanti, che permettono di comprendere meglio l’importanza e il notevole contributo
26

27. che offre l’utilizzo di un oggetto, quale la mappa, per affrontare nel modo migliore un
evento d’emergenza.
Prendiamo ora in esame la situazione di emergenza causata dal terremoto che ha colpito
l’Emilia nel gennaio di quest’anno, e, sulla base del messaggio XML che prima abbiamo
proposto come esempio per questo evento, viene creata una mappa che verrà visualizzata
come segue:
Fig.15: Visualizzazione della mappa inerente un messaggio d’allerta terremoto
Come prima cosa, si nota che, al centro della mappa, è presente un marcatore, di colore
blu, che individua la zona interessata dall’evento d’emergenza; la presenza di questo
elemento aggiuntivo sulla mappa, è stato possibile in quanto, dal codice XML del
messaggio CAP considerato, sono state estratte le informazioni contenute nell’elemento
<circle> del segmento <area>, in cui sono presenti le coordinate del punto interessato
dall’evento.
In questo caso, si utilizzano queste coordinate sia per individuare il luogo dell’evento sulla
mappa, e quindi centrare la mappa sullo schermo, sia per posizionare il marcatore a quelle
coordinate; in altre parole, questi dati individuano lo stesso punto.
Per rendere la lettura della mappa più semplice ad un eventuale utente, viene inserito
questo marcatore che mette in evidenza il punto interessato, indirizzando l’attenzione
unicamente su questo.
27

28. Grazie alle coordinate esatte del luogo colpito, è possibile individuare sulla mappa il luogo
preciso a cui fa riferimento il messaggio d’allerta.
Inoltre, è importante osservare come, attraverso l’utilizzo di una mappa di tipo hybrid,
sia più facile localizzare il luogo selezionato, in quanto sono presenti i nomi delle località
vicine alla zona di interesse.
Esaminando ora l’evento valanghivo che ha interessato il comprensorio montano della
Marmolada nell’aprile dell’anno scorso, e le considerazioni fatte sull’esempio di codice
XML associato ad un eventuale messaggio CAP per questo evento, la mappa basata sulle
informazioni contenute in questo codice verrà visualizzata come segue:
Fig.16: Visualizzazione della mappa inerente un messaggio d’allerta valanga
In questo caso, sulla mappa viene evidenziato il percorso che la valanga ha seguito durante
la sua discesa, dal suo distaccamento dalle pareti rocciose fino alla sua fermata alle pendici
del monte; questa informazione è presente sulla mappa, in quanto, i dati che sono stati
estratti dal codice XML del messaggio d’allerta, erano contenuti all’interno dell’elemento
<polygon> del segmento <area>.
L’individuazione del tragitto seguito dalla valanga è molto importante per le squadre di
recupero, nel caso in cui ci siano delle persone disperse, in quanto, proprio lungo quel
percorso, si concentreranno le ricerce e le attività di soccorso.
28

29. Infine esaminiamo la mappa, associata al codice XML relativo all’evento franoso che ha
colpito il paese di San Fratello in provincia di Messina nel febbraio del 2010; sulla base
delle informazioni contenute nel messaggio CAP, la mappa relativa a questo evento sarà
visualizzata come segue:
Fig.17: Visualizzazione della mappa inerente un messaggio d’allerta frana
Le informazioni contenute nella mappa riguardano la delimitazione della zona interessata
dalla frana, e sono molto importanti per determinare la gravità della situazione sulla base
delle dimensioni dell’area colpita.
Anche in questo caso, grazie all’utilizzo di una mappa di tipo hybrid, è più facile
localizzare il luogo colpito dall’evento.
Infine, nel caso in cui il messaggio CAP non contenga informazioni sulla
georeferenziazione del luogo in cui l’evento è localizzato, cioè non ci sono dati per gli
elementi di <circle> e <polygon>, l’immagine che viene caricata sarà la seguente:
29

30. Fig.18: Visualizzazione dell’immagine vuota
In tutti questi esempi, sulle schermate in cui vengono caricate le immagini delle mappe, si
nota la presenza del tasto “Back”; alla pressione di questo, l’utente si ritrova nella
schermata principale da cui siamo partiti, e da lì può accedere alle informazioni di testo del
messaggio, oppure nuovamente alla visualizzazione della mappa.
4.2 IMPLEMENTAZIONE
Ora ci si occupa dell’analisi del funzionamento interno dell’applicazione, commentando le
scelte apportate per le varie classi progettate o modificate di cui prima abbiamo discusso.
Dopo una presentazione delle operazioni svolte dall’applicazione al suo avvio, che
riguardano appunto tutte le classi, si entrerà nel dettaglio dei moduli che compongono
ciascuna delle classi interessate nelle operazioni per ottenere e visualizzare la mappa del
luogo coinvolto nell’evento di emergenza.
30

31. 4.2.1 Funzionamento generale
Una volta avviata l’applicazione, si definisce il nome del file XML che dovrà essere
utilizzato nel funzionamento dell’intera sessione di lavoro, sul dispositivo mobile; viene
eseguita la classe AnalisiXML passandole questo come parametro principale.
La classe AnalisiXML estrarrà le informazioni, riguardanti la georeferenziazione,
contenute nel messaggio, e fornirà alla classe CapViewer principale questi valori già
modificati per il loro futuro utilizzo all’interno di un indirizzo URL.
A questo punto il costruttore della classe Capviewer inizializzerà le componenti necessarie
a creare l’interfaccia grafica del’applicazione.
Si passa ora alle operazioni che avvengono durante il funzionamento dell’applicazione:
sulla base dei valori di georeferenziazione prima ricavati dal codice XML, si crea l’URL
appropriato che rappresenterà il collegamento internet con l’immagine della mappa che è
associata all’evento descritto nel messaggio dall’allerta preso in esame.
Si fornisce poi, alla classe MsgParser, le indicazioni necessarie per individuare il file
contenente il messaggio di cui si vuole analizzare il contenuto testuale, ovvero si fornisce il
nome del file che è stato fissato all’inizio; ora la classe MsgParser potrà accedere al file
rendendolo accessibile alla classe CapViewer mediante i suoi metodi.
Avendo ora accesso al file, CapViewer potrà creare una lista di elementi del primo livello,
cioè quelli contenuti nel segmento <alert> del codice XML, e renderla visibile sulla
schermata principale dell’interfaccia grafica.
Viene eseguita ora la classe loadImage, fornendole come parametro l’URL, prodotto
prima; questa classe creerà il collegamento internet necessario per accedere, attraverso
l’indirizzo URL, all’immagine della mappa ad esso associato; quest’immagine verrà
caricata ma non sarà ancora visualizzata sul dispositivo.
Ora tutto è pronto e l’applicazione sarà nelle mani dell’utente: a seconda del comando
scelto dall’utente, sullo schermo del dispositivo verranno visualizzati elementi diversi:
l’applicazione reagirà solamente ai comandi dell’utente, che potrà scegliere di terminare
l’applicazione attraverso la pressione del tasto “Exit”, oppure potrà visualizzare il
contenuto di uno degli elementi della lista visualizzata sullo schermo, oppure potrà
accedere, attraverso la pressione del tasto “ImageMAP” alla mappa del luogo dell’evento
descritto nel messaggio d’allerta.
Se sceglierà di accedere alla mappa dell’evento, l’applicazione allegherà l’immagine
caricata precedentemente da internet attraverso il collegamento Http, ad una nuova
31

32. schermata in cui, oltre alla mappa, comparirà anche il tasto “Back” che permetterà
all’utente di ritornare alla schermata principale quando questo verrà selezionato.
4.2.2 La classe CapViewer
Tutti i numeri di linea di codice, contenuti in questo paragrafo, fanno riferimento
all’Appendice A, visualizzata nelle pagine successive.
Nelle prime linee di codice, [3,8], sono contenute le dichiarazioni delle librerie da
importare: la libreria javax.microedition.lcdui fornisce una serie di funzionalità
applicabili all’interfaccia utente per le applicazioni MIDP (Mobile Information Device
Profile – è un’applicazione Java che fornisce le funzioni richieste dai dispositivi mobili, tra
cui l’interfaccia utente, la connettività di rete, memorizzazione locale dei dati e
l’applicazione per la gestione del ciclo di vita), il cui utilizzo principale è rivolto a
dispositivi di informazione mobili.
La libreria javax.microedition.midlet definisce le applicazioni per il profilo di un
dispositivo mobile e le interazioni tra l’applicazione e l’ambiente in cui viene eseguita.
Le seguenti due librerie, la libreria javax.microedition.io.Connector e la libreria
javax.microedition.io.HttpConnection, definiscono i metodi e le costanti per la
creazione e l’utilizzo di una generica connessione Http.
La libreria java.io.DataInputStream permette all’applicazione di utilizzare un flusso
di dati in uscita per scrivere i dati che possono essere poi letti da un flusso di dati in input.
L’ultima libreria importata è la java.io.IOException, che gestisce le eccezioni
prodotte da operazioni di Input/Output che falliscono o che si interrompono.
Le linee [16,29] contengono le dichiarazioni delle variabili che verranno utilizzate in
seguito; ci si sofferma ora su quelle utilizzate per ottenere la visualizzazione della mappa
dell’evento: la variabile di tipo Form frmMap viene dichiarata alla linea [20]: un form non
è altro che una schermata che può contenere diversi tipi di oggetti, come immagini, campi
di testo, campi dati, etc; in questo caso, questa sarà la schermata a cui si allegherà
l’immagine della mappa caricata da internet con specifiche dimensioni.
Alla linea [24] si dichiara la variabile Command imageCmd che è un costrutto che
incapsula le informazioni di tipo semantico di un’azione che può essere compiuta
all’interno dell’applicazione; il comportamento che il comando attiva non è contenuto in
32

33. questo oggetto, ciò significa che il comando contiene solamente le informazioni sul
‘comando’ e non l’azione reale che si verifica quando questo è attivato.
In questo progetto imageCmd sarà il comando utilizzato per accedere alla mappa del
messaggio.
La linea [26] contiene l’inizializzazione della variabile filename, che è una variabile di
tipo stringa, che contiene appunto una stringa di caratteri che è l’indirizzo della risorsa a
cui accede l’applicazione; modificando questo indirizzo, si può accedere a tutti i file con
estensione .xml contenuti nella cartella src/files all’interno del progetto.
Le linee [28,29] sono molto importanti, in quanto contengono le dichiarazioni di due
variabili che verranno utilizzate per la visualizzazione delle immagini sul dispositivo:
ImageItem imageItem è un elemento che può contenere un’immagine e ogni oggetto
ImageItem contiene un riferimento ad un oggetto immagine; Image aImage contiene
solamente i dati che appartengono ad un’immagine grafica, ed esiste indipendentemente
dal dispositivo di visualizzazione che si utilizza.
Le linee [31,34] del codice richiamano il metodo read() della classe AnalisiXML, che
legge e cerca, all’interno del codice XML del file, le informazioni contenute negli elementi
di <circle> o di <polygon>; i valori che vengono trovati sono quindi inseriti nelle variabili
di tipo stringa pol e cir.
All’interno del costruttore della classe, cioè linee [37,51], vengono inizializzate le variabili
necessarie per la gestione dell’interfaccia grafica: quelle, utilizzate per il nostro progetto,
sono alla linea [40] imageCmd, a cui si associa il chiamato ‘ImageMAP’ e diviene un
pulsante, e alla linea [44] frmMap, che viene inizializzato come una schermata dal titolo
‘CAP MAP’.
Successivamente si incontra il metodo startApp() che si concentra sulle operazioni di
avvio e sul funzionamento dell’applicazione: nelle prime linee di questo metodo, [54,59],
si crea l’indirizzo URL a cui si dovrà accedere, tramite un collegamento http, per caricare i
dati dell’immagine della mappa appropriata.
La creazione della stringa URL si basa sui dati raccolti dall’esecuzione della classe
AnalisiXML: in un generico messaggio CAP, le informazioni di georeferenziazione
dell’evento sono contenute o nell’elemento <circle> o nell’elemento <polygon> e mai in
entrambi contemporaneamente, anche perché sarebbe alquanto insensato.
Sulla base di queste considerazioni, descriviamo ora questo importante passaggio: se la
stringa cir, che rappresenta le informazioni contenute nell’elemento <circle> del
33

34. messaggio, risulta essere vuota, e al tempo stesso la stringa pol, che rappresenta le
informazioni contenute nell’elemento <polygon>, è piena, allora si creerà un indirizzo
URL che permetterà la visualizzazione di una mappa con una serie di marcatori uniti tra
loro, in modo tale da definire una linea o un poligono che verrà sovvrapposto all’area della
mappa desiderata.
Viceversa, se la stringa pol sarà vuota e, nello stesso tempo, la stringa cir sarà piena,
allora si creerà un indirizzo URL che permetterà la visualizzazione di una mappa con un
unico marcatore che definirà il punto esatto descritto da <circle>.
Nel caso in cui il messaggio CAP non contenga informazioni per la georeferenziazione del
luogo dell’evento d’emergenza, cioè né <circle> né <polygon> sono presenti, l’URL sarà
quello di un’immagine contenente il testo “Image Not Found”, che informerà così l’utente,
che sta utilizzando l’applicazione, che la mappa relativa al messaggio corrente non è
disponibile.
Alla linea [66] si assegna il comando imageCmd alla schermata iniziale dell’applicazione
che contiene già una lista di elementi e un comando ‘Exit’ per uscire dall’applicazione
stessa; in questo modo, all’avvio, verrà visualizzata una schermata in cui, assieme agli altri
comandi e oggetti, sarà presente anche un comando chiamato ‘ImageCAP’ che, se
selezionato, permetterà di accedere direttamente all’immagine della mappa.
Le linee [76,79] si concentrano sulla creazione dell’immagine della mappa; viene utilizzato
un costrutto try-catch per poter gestire eventuali eccezioni.
Questo costrutto è molto utile per la gestione degli errori e delle eccezioni in Java; il codice
in cui si desiderano intercettare gli errori è contenuto all’interno del blocco try, e quando si
verifica un’eccezione, questa viene generata fuori dal blocco try e intercettata
dall’istruzione catch che la elabora.
Il controllo a questo punto passa a catch e il blocco try termina; in pratica, catch non viene
chiamato, ma è l’esecuzione del programma ad essere trasferita all’istruzione, e dopo
l’esecuzione dell’istruzione catch, il controllo del programma prosegue con le istruzioni
successive a questa.
Si richiama la classe loadImage che permette di creare un collegamento http e, passando
come parametro l’URL precedentemente prodotto, si assegna alla variabile aImage
l’immagine caricata da internet; a questo punto, linea [78], si inizializza imageItem
assegnando a questo oggetto l’immagine appena ottenuta.
34

35. Le seguenti tre linee, [81,83], hanno il compito di completare il Form frmMap inserendo al
suo interno imageItem, cioè l’immagine caricata da internet, e un comando ‘Back’ per
poter tornare alla schermata precedente.
La linea [83] attiva il controllo dei comandi al Form frmMap, ovvero ora i comandi
assegnati al suo interno potranno essere utilizzati e saranno funzionanti.
Alla linea [86] si incontra il metodo pauseApp(), che si occupa della gestione della
sospensione delle funzionalità MIDlet; successivamente, è presente il metodo
destroyApp(boolean unconditional) che gestisce la chiusura dell’applicazione,
che può variare in base al parametro boolean passato come argomento, ovvero true se si
vuole che tutte le risorse vengano rilasciate e liberate all’uscita, o false se si vuole che
tale fase non avvenga immediatamente.
Alla linea [94] all’interno del metodo CommandAction() si determina le possibili azioni
associate ai comandi prensenti all’interno dell’applicazione; se l’utente seleziona il tasto
‘imageCmd’, prima creato, allora verrà visualizzata la schermata che conterrà il Form
frmMap.
Si definiscono anche i tasti ‘Exit’, ‘Back’, e quelli inerenti alla selezione degli elementi
delle liste che vengono visualizzate sullo schermo: se viene selezionato il tasto ‘Exit’ viene
terminata l’applicazione utilizzando le due importanti istruzioni destroyApp(false) e
notifyDestroyed().
Nelle ultime righe del codice, alla linea [143], si determina il controllo degli eventi alla
selezione del tasto ‘Back’, in particolare nel caso in cui venga premuto quello contenuto
nel Form frmMap; in questa situazione, si visualizzerà la schermata principale.
4.2.3 La classe MsgParser
Questa classe viene utilizzata dall’applicazione, ma non è stata oggetto di modifiche per
questo progetto, in quanto ha come scopo l’analisi e la lettura del documento XML per
intero, a seconda delle richieste dell’utente; in altre parole, la visualizzazione della mappa,
che è l’obiettivo di questo lavoro, non influisce e non viene influenzata da questa parte di
codice.
Perciò, il codice rimane esattamente com’è ed il suo funzionamento rimane immutato, e
può comunque essere osservato nell’Appendice B nelle pagine successive.
35

36. 4.2.4 La classe AnalisiXML
Tutti i numeri di linea di codice, contenuti in questo paragrafo, fanno riferimento
all’Appendice C, visualizzata nelle pagine successive; questa classe ha il compito di
analizzare il contenuto del documento XML e di estrarre le informazioni necessarie alla
creazione dell’indirizzo URL associato ad una determinata mappa, che verrà poi
visualizzata sul dispositivo.
Nelle prime linee del codice, [5,10], sono contenute le dichiarazioni delle librerie da
importare: la prima libreria, linea [5], è stata già discussa nel paragrafo precedente, in
quello inerente alla classe CapViewer.
Alla linea [6], la libreria java.io.InputStream è una classe astratta ed è la superclasse
di tutte le classi che rappresentano un flusso di byte in input.
La libreria java.io.InputStreamReader, linea [7], è una classe che legge i byte e li
trasforma in caratteri utilizzando uno specifico charset (codifica di caratteri – codice che
associa un insieme di caratteri ad un insieme di altri byte).
La libreria successiva, java.util.Vector, permette di utilizzare dei vettori per lavorare
con array di stringhe di caratteri, ed è possibile modificare la lunghezza del vettore anche
durante l’esecuzione dell’applicazione; in questo progetto si utilizzano i vettori per estrarre
le informazioni testuali dal codice XML e per poi modificarli per gli usi successivi.
Le ultime due librerie, alle linee [9,10], si concentrano sull’utilizzo dei documenti in
formato XML.
Si passa ora al codice che è il corpo della classe AnalisiXML: come prima cosa, sono
presenti le dichiarazioni delle variabili che verranno utilizzate; quelle per l’accesso al file
XML sono alle linee [42,44] e quelle per la trasmissione delle informazioni da una classe
all’altra sono alle linee [48,50].
Successivamente, linee [62,73], si passa al metodo interno che si occupa dell’analisi del
file che contiene il codice XML: per accedere a questo file, il cui nome viene passato come
parametro per questo metodo, viene utilizzato un costrutto try-catch, nel quale si tenta di
aprire un canale di comunicazione verso il file stesso, che contiene il messaggio, e, nel
caso non dovesse andare a buon fine questa operazione e si creasse un’eccezione di
input/output, viene specificata la gestione di tale eccezione.
36

37. A questo punto si assegna alla variabile root l’elemento radice del codice XML, e grazie a
questo elemento, si può avviare la ricerca delle informazioni che ci interessano all’interno
del messaggio.
Nelle linee [96,114] vengono utilizzati due costrutti try-catch per gestire l’analisi delle
informazioni necessarie alla visualizzazione dell’immagine della mappa.
Le linee di codice [97,98] rappresentano l’istruzione che determina il testo dell’elemento
<polygon> contenuto nell’elemento <area> dell’elemento <info> appartenente alla root
prima inizializzata; se nel file non è presente l’elemento <polygon>, questa istruzione crea
un’eccezione che viene gestita dal blocco di codice catch sucessivo.
Se, invece, nel file è presente l’elemento <polygon>, si estrae il testo che esso contiene:
questo testo viene modificato per poi essere inviato alle fasi successive per creare la stringa
di testo per l’indirizzo URL della mappa: nel testo estratto dal codice XML vengono
sostituite le virgole ‘,’ con barre ‘|’ e gli spazi ‘ ’ con le virgole ‘,’: in altre parole si passa
da un testo ‘46.44906 11.8767, 46.45081 11.8801,46.45105 11.8836’ , che
rappresenta le coordinate dei vari punti descritte nel file, ad un testo
‘46.44906,11.8767|46.45081,11.8801|46.45105,11.8836’ che rappresenta le
coordinate dei punti che vengono passate ed inserite come parametri nell’indirizzo URL.
All’interno del blocco catch, è inserito un altro costrutto try-catch che gestisce l’estrazione
delle informazioni di <circle>; l’istruzione alle linee [106,107] individua il testo contenuo
nell’elemento <circle> contenuto nell’elemento <area> dell’elemento <info> appartenente
alla root prima inizializzata; se nel file viene individuata la presenza dell’elemento
<circle>, si estrae il testo contenuto in esso, e questo testo viene modificato per essere poi
inviato alle fasi successive per creare l’indirizzo URL della mappa.
Se l’elemento <circle> non è presente nel file, questa istruzione crea un’eccezione che
viene gestita attraverso la restituzione di un valore nullo alle linee [113,114].
La forma generica di un elemento <circle> è la seguente: le coordinate di latitudine e
longitudine del punto considerato, separate da una virgola, seguite da uno spazio e il raggio
di un’eventuale circonferenza, calcolata in chilometri.
Le informazioni, che ci interessano in questo caso, sono solamente del coordinate del
punto e perciò, dopo aver individuato il carattere dello spazio nella stringa di testo, si
estrae unicamente la prima parte del testo fino allo spazio che appunto separa le
informazioni di coordinate e raggio; si ricava così una sottostringa che contiene
unicamente le coordinate di un punto.
37

38. 4.2.5 La classe loadImage
Tutti i numeri di linea di codice, contenuti in questo paragrafo, fanno riferimento
all’Appendice D, riportata nelle pagine successive; questa classe ha il compito di gestire la
connessione Http che permette, attraverso l’utilizzo dell’indirizzo URL passato come
parametro, di accedere all’immagine della mappa dell’evento di emergenza considerato.
Nelle prime linee del codice, linee [3,6], sono contenute le dichiarazioni delle librerie che
vengono importate dalla classe per il suo funzionamento: java.io contiene le classi per
effettuare operazioni di Input/Output.
La libreria successiva, javax.microedition.lcdui, è stata già discussa in precedenza
nel paragrafo inerente alla classe CapViewer.
Le ultime due librerie sono addette alla gestione della connessione internet: la libreria
javax.microedition.io.Connector è utilizzata per creare il tipo più semplice di
connessione; la libreria javax.microedition.io.HttpConnection, invece, definisce
i metodi e le costanti necessarie per gestire una connessione Http.
L’elemento fondamentale è proprio la classe ‘Connector’, che viene usata per creare un
qualsiasi tipo di connessione, come ad esempio verso file, protocollo Http, etc usando
un’istruzione che ha la seguente sintassi:
‘Connector.open(protocol:address:parameters);’ .
L’interfaccia HttpConnection dispone della principale modalità di comunicazione che
un’applicazione J2ME possa avere con l’esterno; ciascun dispositivo J2ME è in grado di
connettersi a server esterni attraverso l’utilizzo del protocollo HTTP 1.1.
Alle linee [29,31] sono presenti le dichiarazioni delle variabili che verranno utilizzate di
seguito nel metodo: alla linea [29] incontriamo HttpConnection che è la
specializzazione dell’interfaccia Connection dedicata alla gestione della connessione Http,
creata a partire dallo schema ‘http://’.
Come avviene per altri linguaggi di programmazione, la connessione gestita attraverso
HttpConnection è una piccola tecnologia a stati, ovvero, appena creata, la connessione è
in grado di riconoscere i parametri operativi che vengono impostati; l’apertura di uno
stream di input o la lettura di un attributo della risposta provoca la transizione nello stato
‘Connected’, in cui non è più possibile modificare i parametri.
Quando, poi, tutti i dati sono stati letti, la connessione giunge allo stato ‘Closed’, nel quale
non è consentito effettuare ulteriori operazioni né di lettura né di scrittura.
38

39. Alla linea [30] si definisce un elemento di tipo DataInputStream, che permette
all’applicazione di leggere i dati primitivi di Java da un flusso di byte in ingresso; alla linea
successiva è definita una variabile di tipo intero che rappresenterà il valore della
dimensione in byte dei dati che rappresentano l’immagine caricata attraverso il
collegamento Http.
Le linee di codice successive sono definite attraverso il costrutto try-finally che gestisce la
connessione Http: alla linea [35] si determina la connessione, attraverso l’utilizzo
dell’istruzione, prima discussa, ‘Connector.open(url)’; si passa poi alla linea [36],
che attraverso l’utilizzo del metodo getLength() dell’HttpConnection, si ottiene la
dimensione del dato inviato al dispositivo dal server e, nel caso in cui la dimensione non
sia nota, il valore restituito sarà -1, e quindi verrà creata un’eccezione che sarà gestita dal
blocco finally.
Alla linea [41] si inizializza la variabile di DataInputStream, e la lettura dei dati
avviene attraverso l’uso degli stream di input della connessione, che sono restituiti dal
metodo openInputStream().
Molto importante è la linea successiva, in cui si utilizza il metodo readFully(), che
riceve come argomento un array di byte, per leggere l’insieme completo dei dati: questo
metodo ha un comportamento particolare, in altre parole non ritorna finchè il buffer
passato come argomento non è stato completamente riempito, finchè non è stata raggiunta
la fine dello stream e quindi non sono disponibili altri dati.
A questo punto, alla linea [44], il metodo restituisce l’immagine associata all’URL passato
come parametro, utilizzando l’istruzione createImage() che crea appunto un’immagine
immutabile decodificata a seconda dei dati memorizzati nella matrice di byte che specifica
l’offset e la dimensione dell’immagine:
‘createImage(byte[] imageData, int imageOffset, int imageLength)’.
Nelle linee [47,50] c’è il contenuto del blocco finally, che è il codice che verrà sempre
eseguito, indipendentemente dal fatto che si siano verificate eccezioni o meno; in questo
caso verrà chiusa sia la connessione e sia il DataInputStream utilizzato per leggere i
byte.
39

40. CONCLUSIONI
In questo capitolo si verifica se gli obiettivi, che sono stati prefissati all’inizio di questo
progetto di tesi, sono stati raggiunti.
Lo scopo della presente tesi è quello di ampliare e migliorare un'applicazione in grado di
gestire e visualizzare, su un generico dispositivo mobile, il contenuto di un messaggio di
allerta, conforme al protocollo CAP.
Il contributo, che è stato dato nella presente tesi, consiste nella visualizzazione di una
mappa contenente l'informazione georiferita che identifica la zona interessata dall’evento
descritto nel messaggio.
Il risultato a cui siamo giunti è il miglioramento di questa applicazione, non destinato
all’utilizzo nella forma in cui si trova, ma che necessita ancora di alcune aggiunte e
modifiche che potrebbero rendere tale applicazione maggiormente utilizzabile.
Il prototipo, che era inizialmente composto unicamente da due classi, ora è articolato in
quattro classi, ognuna delle quali ha un compito ben specifico, e assieme costituiscono una
rete di interazioni e operazioni che permettono all’utente, che utilizza questa applicazione,
di interagire con essa in modo facile ed intuitivo.
Nei capitoli precedenti ci siamo concentrati su alcuni importanti requisiti, che sono stati le
linee guida che ci hanno permesso di elaborare e progettare questa applicazione creando,
appunto, ciò che ci eravamo prefissati di ottenere.
Riprendendo i quattro requisiti principali, determinati nel capitolo 3, possiamo fare qualche
considerazione ora che la nostra applicazione è finita e funzionante:
1. Gestione ed estrazione di informazioni specifiche da un documento XML:
questo primo requisito è stato soddisfatto pienamente, in quanto nel documento XML
vengono estratte le informazioni inerenti alla georeferenziazione del luogo interessato
dall’evento di emergenza, contenute negli elementi <circle> e <polygon>; nel caso in
cui nel messaggio non siano presenti questi due elementi, l’applicazione riesce a gestire
questa situazione senza bloccarsi o generare errori.
2. Indipendenza dalla piattaforma di esecuzione:
questo requisito è stato rispettato già nel prototipo di base dal quale si è partiti per
elaborare questo progetto; infatti si è utilizzato, come linguaggio di programmazione
per l’applicazione, Java che permette di eseguire questo prototipo su qualsiasi
40

41. dispositivo che è in grado di utilizzare la Java Virtual Machine, responsabile del
caricamento del codice, dell’isolamento del runtime Java dal resto del sistema
operativo, della gestione della memoria, dei thread e delle altre risorse fondamentali per
l’esecuzione delle applicazioni.
3. Necessità di esecuzione su dispositivi mobili:
l’utilizzo del linguaggio Java, e in particolare quello nella versione dedicata all’utilizzo
nei dispositivi mobili, Java Micro Edition, soddisfa anche questo importante requisito.
Java ME è un nuovo tipo di piattaforma modulare, flessibile, portabile ed economica,
che si concentra sullo sviluppo e l’esecuzione delle applicazioni per sistemi mobili; è
un’architettura appositamente progettata per risolvere le problematiche di questo
particolare settore applicativo.
4. Collegamento ad internet e la visualizzazione della mappa:
l’accesso ad internet è ormai un requisito fondamentale per un qualsiasi dispositivo
programmabile; la piattaforma Java ME è stata progettata fin dal principio con un forte
orientamento alla connettività, in termini di funzionalità e di supporto alla sicurezza.
Le API standard consentono agli sviluppatori di accedere ai servizi principali della rete
e agli utenti di disporre di potenti applicazioni network-oriented sui propri terminali
mobili.
In ambito networking, i limiti di un dispositivo possono consistere nella mancanza del
supporto per un determinato protocollo, in un vincolo sulle modalità di accesso ai dati,
etc; le reti di telefonia mobile espongono criticità specifiche che possono condizionare,
se non del tutto impedire, le operazioni di networking dei dispositivi.
Accesso su rete privata, connessione automatica attraverso un proxy (programma che si
interpone tra un client e un server facendo da tramite o interfaccia tra i due host, ovvero
inoltrando le richieste e le risposte dall’uno all’altro) e filtraggio di certi tipi di
connessione, rappresentano situazioni spesso imprevedibili che possono inibire il
funzionamento di applicazioni perfettamente collaudate in altri contesti.
41

42. BIBLIOGRAFIA
[1] Disaster Risk Reduction Strategies and Risk Management Practices: Critical Elements for
Adaptation to Climate Change, Submission to the UNFCCC Adhoc Working Group on Long
Term Cooperative Action by The Informal Taskforce on climate change of the Inter-Agency
Standing Committee1 and The International Strategy for Disaster Reduction2, 11 November
2008.
[2] OASIS Common Alerting Protocol version 1.2
http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
[3] Vos F, Rodriguez J, Below R, Guha-Sapir D. Annual Disaster Statistical Review 2009: The
Numbers and Trends. Brussels: CRED; 2010
European Environment Agency, Mapping the impacts of natural hazards and technological
accidents in Europe — An overview of the last decade. Copenhagen: EEA, 2010.
[4] Raffaela Cefalo, Integration of SatCom/SatNav Technologies for Environmental Monitoring
and Management of Emergencies, 3rd ICG Meeting Pasadena, Los Angeles, 8-12 December
2008, http://www.unoosa.org/pdf/icg/2008/icg3/29.pdf
[5] Calderan M., Cefalo R., Montefusco C., Development and Applications of an Experimental
Data Server hosting EGNOS and RTCM /RTK messages, 3rd ICG Meeting Pasadena, Los
Angeles, 8-12 December 2008, http://www.unoosa.org/pdf/icg/2008/icg3/29.pdf
[6] Brundl M., Bartelt P., Schweizer J., Keiler M., Glade T., Review and future challenges in snow
avalanche risk analysis
Geomorphological Hazards and Disaster Prevention, published by Cambridge University,
edited by Irasema Alcàntara-Ayala and Andrew Goudie, 2010
[7] Glade T., Anderson T., Crozier M., Landslides hazards and risk: issues, concepts and
approach
eds. Landslide Hazard and Risk. Chichester: John Wiley and Sons, pp 1-40, 2005
[8] Varnes D. Landslides Hazards Zonation: A review of Principles and Practise. Paris: UNESCO.
[9] JIXEL : http://www.jixel.eu/aboutjixel.php
http://www.vigilfuoco.it/aspx/download_file.aspx?id=5963
[10] TSO : http://www.tacticalsituationobject.org/documents.html
[11] Google Static Maps API : https://developers.google.com/maps/documentation/staticmaps/
42

43. [12] Simone Maver, Tesi Ingegneria Informatica : “Formato e trasmissione di messaggi di allerta
per la gestione di emergenze ambientali”
[13] Attività della protezione civile italiana:
http://www.protezionecivile.gov.it/jcms/it/homepage.wp
43

44. Appendice A – classe CapViewer
1 package CapViewer;
2
3 import javax.microedition.lcdui.*;
4 import javax.microedition.midlet.*;
5 import javax.microedition.io.Connector;
6 import javax.microedition.io.HttpConnection;
7 import java.io.DataInputStream;
8 import java.io.IOException;
9
10 /**
11 * @author simonemaver & sabrinacramastetter
12 */
13
14 public class CapViewer extends MIDlet implements CommandListener{
15
16 private MsgParser parser;
17
18 protected Display display;
19 protected List select1, select2, select3;
20 protected Form frm, frm2, frmMap;
21 protected StringItem si, si2;
22 protected Command exitCmd;
23 protected Command backCmd;
24 protected Command imageCmd;
25
26 String filename = "/files/ex1.xml";
27
28 private ImageItem imageItem;
29 private Image aImage;
30
31 AnalisiXML analisi = new AnalisiXML();
32 String coord = analisi.read(filename);
33 String pol = analisi.polygon;
34 String cir = analisi.circle;
35 String URL;
36
37 public CapViewer() {
38 exitCmd = new Command("Exit", Command.EXIT, 1);
39 backCmd = new Command("Back", Command.BACK, 1);
40 imageCmd = new Command ("ImageMAP", Command.SCREEN, 1);
41
42 frm = new Form("");
43 frm2 = new Form("");
44 frmMap = new Form ("CAP MAP");
45
46 si = new StringItem("", "");
44

45. 47 si2 = new StringItem("", "");
48
49 frm.append(si);
50 frm2.append(si2);
51 }
52
53 public void startApp(){
54 if (cir == null & pol != null) {URL = "http://maps.googleapis.com/maps/api/"+
55 "staticmap?size=250x270&path=" + pol +&maptype=hybrid&sensor=false";}
56 else if (pol == null & cir != null){URL ="http://maps.googleapis.com/maps/api/"+
57 "staticmap?center=" + cir + "&zoom=13&size=250x270&maptype=hybrid&"+
58 "markers=color:blue%7C" + cir + "&sensor=false";}
59 else{URL="http://upload.wikimedia.org/wikipedia/en/d/d1/Image_not_avaibile.png";}
60
61 parser = new MsgParser(filename);
62
63 select1 = new List("Message Content: ",List.IMPLICIT,parser.parseElement(null, 1),
64 null);
65 select1.addCommand(exitCmd);
66 select1.addCommand(imageCmd);
67 select1.setFitPolicy(Choice.TEXT_WRAP_ON);
68 select1.setCommandListener(this);
69 display.setCurrent(select1);
70
71 frm.addCommand(backCmd);
72 frm.setCommandListener(this);
73 frm2.addCommand(backCmd);
74 frm2.setCommandListener(this);
75
76 try{ loadImage a = new loadImage();
77 aImage = a.loadImage(URL);
78 imageItem = new ImageItem (null, aImage, ImageItem.LAYOUT_CENTER, "CAP MAP");
79 } catch (IOException ioe){ }
80
81 frmMap.append(imageItem);
82 frmMap.addCommand(backCmd);
83 frmMap.setCommandListener(this);
84 }
85
86 public void pauseApp(){}
87
88 public void destroyApp(boolean unconditional){}
89
90 public void commandAction(Command c, Displayable d){
91 if(c == exitCmd){
92 destroyApp(false);
93 notifyDestroyed(); }
94 if (c == imageCmd) { display.setCurrent(frmMap);}
95 if(c == List.SELECT_COMMAND){
45

46. 96 int list_level;
97 if( d == select1){
98 list_level = 1;
99 String selection = select1.getString(select1.getSelectedIndex());
100 if(selection.equals("info")) {
101 select2 = new List(selection.toUpperCase(),List.IMPLICIT,
102 parser.parseElement(selection,list_level),null);
103 select2.addCommand(backCmd);
104 select2.addCommand(exitCmd);
105 select2.setFitPolicy(Choice.TEXT_WRAP_ON);
106 select2.setCommandListener(this);
107 display.setCurrent(select2);
108 } else { si.setLabel(selection);
109 si.setText(parser.parseElement(selection, list_level)[0]);
110 display.setCurrent(frm);}
111 } else if(d == select2){
112 list_level = 2;
113 String selection2 = select2.getString
114 (select2.getSelectedIndex());
115 if(selection2.equals("eventCode")||
116 selection2.equals("parameter")) {
117 si2.setLabel(selection2 + "n");
118 String str = "";
119 for(int i=0; i<parser.parseElement(selection2,
120 list_level).length;i++) {
121 str += parser.parseElement(selection2,
122 list_level)[i]; }
123 si2.setText(str);
124 display.setCurrent(frm2);
125 } else if(selection2.equals("resource") || selection2.equals("area")){
126 select3 = new List(selection2.toUpperCase(),List.IMPLICIT,
127 parser.parseElement(selection2,list_level),null);
128 select3.addCommand(backCmd);
129 select3.addCommand(exitCmd);
130 select2.addCommand(exitCmd);
131 select3.setFitPolicy(Choice.TEXT_WRAP_ON);
132 select3.setCommandListener(this);
133 display.setCurrent(select3);
134 }else { si2.setLabel(selection2);
135 si2.setText(parser.parseElement(selection2, list_level)[0]);
136 display.setCurrent(frm2);
137 }
138 }
139 }
140 if(c == backCmd){ // controlla gli eventi del comando Back
141 if(d == frm || d == select2){ display.setCurrent(select1); }
142 if(d == frm2 || d == select3){ display.setCurrent(select2); }
143 if(d == frmMap ){ display.setCurrent(select1); }
144 }}}
46

47. Appendice B – Classe MsgParser
1 package CapViewer;
2
3 import java.io.IOException;
4 import java.io.InputStream;
5 import java.io.InputStreamReader;
6 import java.util.Vector;
7 import org.kxml.Xml;
8 import org.kxml.kdom.*;
9 import org.kxml.parser.*;
10
11 /**
12 * @author simonemaver
13 */
14
15 public class MsgParser{
16
17 private XmlParser parser = null;
18 private Document doc;
19 private Element root;
20
21 protected MsgParser(String filename){
22 doc = new Document();
23 try { InputStream in = this.getClass().getResourceAsStream(filename);
24 InputStreamReader is = new InputStreamReader(in);
25 parser = new XmlParser(is);
26 doc.parse(parser);
27 parser = null;
28 }catch(IOException ioe){ System.err.println(ioe);
29 ioe.printStackTrace();
30 parser = null;
31 doc = null;
32 }
33 root = doc.getRootElement();
34 }
35
36 protected String[] parseElement(String el_name, int level){
37 String[] str_arr = null;
38 Vector v_str = new Vector();
39
40 if(level == 1){
41 if(el_name == null){
42 for(int i = 0; i < root.getChildCount(); i++){
43 if(root.getType(i) == Xml.ELEMENT){
44 v_str.addElement(root.getElement(i).getName());}
45 }
46 } else if(root.getElement(el_name).getType(0) == Xml.TEXT){
47

48. 47 v_str.addElement(root.getElement(el_name).getText());
48 } else if(el_name.equals("info")){
49 for(int j = 0; j < root.getElement("info").getChildCount(); j++){
50 if(root.getElement("info").getType(j) != Xml.ELEMENT){ continue; }
51 if(root.getElement("info").getElement(j).getType(0) == Xml.TEXT){
52 v_str.addElement(root.getElement("info").getElement(j)
53 .getName());
54 continue;}
55 v_str.addElement(root.getElement("info").getElement(j).getName());
56 }
57 }
58 } else if(level == 2){
59 if(root.getElement("info").getElement(el_name).getType(0) == Xml.TEXT){
60 v_str.addElement(root.getElement("info").getElement(el_name).getText());
61 } else if(el_name.equals("eventCode") || el_name.equals("parameter")){
62 for(int i = 0; i <root.getElement("info").getElement(el_name).
63 getChildCount(); i++){
64 if(root.getElement("info").getElement(el_name).getType(i)!=
65 Xml.ELEMENT){ continue; }
66 if(root.getElement("info").getElement(el_name).getElement(i)
67 .getType(0) == Xml.TEXT){
68 v_str.addElement("-"+root.getElement("info").
69 getElement(el_name).getElement(i).getName()+": ");
70 v_str.addElement(root.getElement("info").
71 getElement(el_name).getElement(i).getText()+"n");
72 continue;
73 }
74 }
75 } else if(el_name.equals("resource") || el_name.equals("area")){
76 for(int i = 0; i < root.getElement("info").getElement(el_name).
77 getChildCount(); i++){
78 if(root.getElement("info").getElement(el_name).getType(i) !=
79 Xml.ELEMENT){continue; }
80 if(root.getElement("info").getElement(el_name).getElement(i).
81 getType(0) == Xml.TEXT){
82 v_str.addElement(root.getElement("info").
83 getElement(el_name).getElement(i).getName()+": "+
84 root.getElement("info").getElement(el_name).
85 getElement(i).getText());
86 continue;
87 }
88 v_str.addElement(root.getElement("info").getElement(el_name).
89 getElement(i).getName());
90 for(int j = 0; j < root.getElement("info").getElement(el_name).
91 getElement(i).getChildCount(); j++){
92 if(root.getElement("info").getElement(el_name).
93 getElement(i).getType(j) != Xml.ELEMENT){ continue; }
94 if(root.getElement("info").getElement(el_name).
95 getElement(i).getElement(j).getType(0) == Xml.TEXT){
48

49. 96 v_str.addElement("-"+root.getElement("info").getElement
97 (el_name).getElement(i).getElement(j). getName()+": "+
98 root.getElement("info").getElement(el_name).getElement(i).
99 getElement(j).getText());
100 continue;}
101 }
102 }
103 }
104 }
105 str_arr = new String[v_str.size()]; // Si converte da vettore a stringa
106 for(int i = 0; i < v_str.size(); i++){str_arr[i] = (String)v_str.elementAt(i);}
107 return str_arr;
108 }
109 }
49

50. Appendice C – classe AnalisiXML
1 // Analisi del documento XML per l'estrazione delle informazioni necessarie alla
2 // creazione e visualizzazione della mappa associata al messaggio CAP
3 package CapViewer;
4
5 import java.io.IOException;
6 import java.io.InputStream;
7 import java.io.InputStreamReader;
8 import java.util.Vector;
9 import org.kxml.kdom.*;
10 import org.kxml.parser.*;
11
12 /** java.io.IOException è la classe generale delle eccezioni prodotte da
13 * operazioni di I/O fallite o interrotte
14 *
15 * java.io.InputStream è la superclasse di tutte le classi che rappresentano un
16 * flusso di input di byte
17 *
18 * java.io.InputStreamReader è una classe che legge i byte e li trasforma in
19 * caratteri utilizzando uno specifico charset
20 *
21 * java.util.Vector implementa degli array di object e si può modificare la
22 * lunghezza del vettore durante l'esecuzione; si hanno, oltre ai costruttori,
23 * 3 tipi di metodi, metodi per modificare il vettore, metodi per ottenere i
24 * valori presenti nel vettore e metodi per gestire la crescita del vettore
25 *
26 * org.kxml.kdom.* è un pacchetto che fornisce un limitato modello del documento
27 * oggetto; al fine di consentire la generazione personalizzata di un oggetto in
28 * J2ME, viene aggiunto un costruttore di default e il costruttore esistente
29 * verrà sostituito dal metodo init
30 *
31 * org.kxml.parser.* è un pacchetto che contiene le classi relative all'analisi
32 * dei dati xml
33 * /
34
35 /**
36 * @author sabrinacramastetter
37 */
38
39 // La classe AnalisiXML ha il compito di gestire il codice XML
40 public class AnalisiXML{
41 // Dichiarazione delle variabili per l'accesso al file XML
42 private XmlParser parser = null;
43 private Document doc;
44 private Element root;
45
46 // Dichiarazione delle variabili che verranno utilizzate per la trasmissione
50

51. 47 // dei dati da una classe all'altra
48 String circle, polygon, valnull;
49 Vector v_str = new Vector();
50 Vector v_str2 = new Vector ();
51
52 // Metodo che si occupa dell'accesso al file contenente il codice XML
53 String read(String filename){
54
55 doc = new Document();
56
57 // Viene utilizzato un costrutto try-catch nel quale avviene il
58 // tentativo di aprire il canale di comunicazione verso il file che
59 // contiene il messaggio e, nel caso non dovesse andare a buon fine
60 // e fosse sollevata un'eccezione di input/output, viene specificata
61 // la gestione dell'eccezione
62 try {
63 InputStream in = this.getClass().getResourceAsStream(filename);
64 InputStreamReader is = new InputStreamReader(in);
65 parser = new XmlParser(is);
66 doc.parse(parser);
67 parser = null;
68 } catch(IOException ioe){
69 System.err.println(ioe);
70 ioe.printStackTrace();
71 parser = null;
72 doc = null;
73 }
74 root = doc.getRootElement();
75
76 // Vengono utilizzati due costrutti try-catch che gestiscono l'analisi delle
77 // informazioni necessarie per la visualizzazione dell'immagine
78 // Se nel file viene individuato un elemento <polygon> si estrae il testo a
79 // questo associato: questo testo viene modificato per poi essere inviato
80 // alle fasi successive per creare la mappa : vengono sostituite le ','
81 // virgole con '|' barre e gli' 'spazi con ','
82 // Se nel file non viene individuato l'elemento <polygon> viene creata
83 // un'eccezione e nell'eccezione si gestisce il secondo costrutto try-catch
84 // : se nel file viene individuato un elemento <circle> si estrae il testo a
85 // questo associato : questo testo viene modificato per poi essere inviato
86 // alle fasi successive per creare la mappa.
87 //La forma generica per l'elemento <circle> è:
88 // LATITUDINEcentro,LONGITUDINEcentro raggioCirconferenzaKm
89 // Le informazioni che interessano sono solamente le coordinate del centro e
90 // perciò si individua il carattere dello spazio nel testo e si estrae
91 // unicamente la prima parte del testo fino allo spazio che appunto separa
92 // le informazioni di coordinate e raggio; si ricava quindi una sottostringa
93 // che contiene unicamente le coordinate Se nel file non viene individuato
94 // nemmeno l'elemento <circle>, viene creata una nuova eccezione che
95 // restituisce un generico valore nullo
51