INS microNEWS: progettazione e sviluppo di una

Transcript

INS microNEWS: progettazione e sviluppo di
una applicazione multicanale basata su
tecnologie J2EE e J2ME
Tesi di Laurea di primo livello in Ingegneria
Informatica
Anno Accademico 2003/2004
Maurizio Frigerio (653618)
Francesco Ostini (653672)
Aldo Puglisi (655671)
Relatore: Prof. Piero Fraternali
5 Ottobre 2004
INDICE
CAPITOLO PRIMO : Tecnologie
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Java 2 Micro Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Differenze tra J2ME e J2EE . . . . . . . . . . . . . . . . . . . . . . . 8
Mobile Information Device Profile . . . . . . . . . . . . . . . . . . . 10
Download di una MIDlet . . . . . . . . . . . . . . . . . . . . . . . . . 14
I vantaggi di J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Elenco dispositivi mobili compatibili . . . . . . . . . . . . . . . . . 16
CAPITOLO SECONDO: Progettazione
2.1 Raccolta dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Requisiti di business . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Individuazione utenti . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Requisiti Funzionali . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Requisiti non funzionali . . . . . . . . . . . . . . . . . . . .
28
28
29
29
30
2.2 Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1 Gruppi di utenti . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1 Diagramma del caso d’uso per i docenti . . . . . . . . . 34
2.3.2 Fogli di specifica casi d’uso . . . . . . . . . . . . . . . . . . 34
2.4 Dizionario dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
CAPITOLO TERZO: Implementazione
3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 INS Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Interfaccia Web . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.2 Mobile Interaction . . . . . . . . . . . . . . . . . . . . . . . .
3.2.3 Application Core . . . . . . . . . . . . . . . . . . . . . . . . .
43
43
47
50
3.3 microNEWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1 Mobile Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.2 Interfaccia Grafica . . . . . . . . . . . . . . . . . . . . . . . . 62
1
CAPITOLO QUARTO: Appendice
4.1 Ambiente di Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2 Testing e Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.3 Conclusioni e sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . 71
CAPITOLO QUINTO: Bibliografia
5.1 Bibliografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2
PREFAZIONE
In questa frenetica società mobilità e necessità di scambiare informazioni sono
in costante aumento ed è ormai indispensabile per ogni individuo poter
comunicare ovunque e in ogni momento della giornata.
Conseguentemente a questa tendenza stanno evolvendosi dispositivi,
infrastrutture ed apparati il cui fine è permettere all’individuo di affacciarsi alla
rete internet, di comunicare con il sistema informativo dell’azienda ovunque
egli si trovi.
Nascono proprio in questi anni i primi progetti di cablaggio totale wireless di
intere città, un esempio su tutte Amsterdam, già parzialmente coperta, ma
anche Barcellona, Bruxelles e molte alte.
Abbiamo sviluppato l’applicazione INS al fine di ottenere confidenza con
l’universo mobile e di acquisire esperienza nello sviluppo di un’applicazione sia
multicanale che multipiattaforma.
Inoltre ci è sembrato opportuno sviluppare uno strumento che potesse giovare
alla vita dell’ateneo, consentendo ai docenti di comunicare direttamente con i
propri studenti e a quest’ultimi di essere avvertiti tempestivamente di ritardi,
rinvii e ogni quant’alto riguardi lezioni, esercitazioni, scadenze ed esami.
3
CAPITOLO 1
TECNOLOGIE
1.1 Introduzione
Lo scopo del capitolo è quello di introdurre ed illustrare lo scenario tecnologico
all’interno del quale è sviluppata l’applicazione.
Prima di iniziare il progetto vero e proprio è stata effettuata un’ampia ricerca
sulle tecnologie utilizzate nel mondo mobile per sviluppare applicazioni.
Sin da subito, escludendo l’obsoleto WAP con le sue vetuste GUI e tralasciando
Symbian che, oltre ad essere riservato a poche devices, esulava dal nostro
momentaneo interesse, le alternative si sono ristrette a due possibilità:
Microsoft .Net CF e J2ME.
La scelta è subito caduta su J2ME, dettata non solo da affetti e sentimenti
rivoluzionari contratti durante il periodo Linux (Slackware per gli uni e
ArchLinux per gli altri) ma soprattutto da concreti motivi commerciali: è
evidente (e ben pubblicizzato) l’esponenziale interesse dei costruttori di device
mobili nel supportare e sviluppare applicazioni e giochi J2ME, tanto che un
colosso come nokia ha dichiarato che in futuro tutti i telefonini che
commercializzerà avranno supporto j2me.
In aggiunta, nel corso dei nostri studi, ci è sempre stata mostrata SUN come la
via migliore per i “developers” e per quelli che “le cose le fanno bene”.
A supporto della nostra scelta è stata allegata la seguente tabella che colloca
chiaramente il target delle nostre alternative:
.Net Compact
Framework
J2ME Connected
Device Configuration
J2ME Connected
Limited Device
Configuration
Device
requirement
Powerful,
expensive
Powerful, expensive
Cheap, pervasive
Cost
High
High
Medium
Market focus
Enterprise
Enterprise
Consumer and
enterprise
Language
support
C#, VB.Net
Java
Java
Platforms
Pocket PC,
Windows CE
Major mobile platforms
All mobile platforms
except Palm OS
Byte code
compatibility
Standard .Net
CLR
Standard Java 2
Not compatible with
J2SE or CDC
Subset of .Net
Subset of J2SE plus
standard optional
packages
Partial compatibility
with CDC with
additional standard
optional packages
API
compatibility
4
Native APIs
P/Invoke;
consistent across JNI; device- and OSsupported
specific
devices
Development
tools
VS.Net 2003
Command line, vendor
SDKs, CodeWarrior,
and WebSphere
Command line, vendor
SDKs, all major Java
IDEs
Specification
process
Single company
Community
Community
Service
gateway
N/A
Run gateways as OSGi
servlets; run gateway
clients via vendorspecific SDKs
Run gateway clients
via vendor-specific
SDKs
Security
model
Simplified .Net
model
Full Java security
manager
Limited Java 2 model
supplemented by OTA
specification
Client
installation
ActiveSync,
Internet Explorer Sync, download
download
Life cycle
management
N/A
OSGi for gateway apps,
J2EE Client
Provisioning
Specification for
generic clients
N/A
Formal OTA
specification
Included in OTA spec,
works with J2EE
Client Provisioning
Specification
Per tutta questa serie di motivi quindi Java 2 Micro Edition è la nostra scelta.
Lo scopo del seguente capitolo, è quello di introdurre e mostrare la tecnologia
SUN Java 2 Micro Edition (J2ME) utilizzata per lo sviluppo dell’applicazione.
J2ME è un set di librerie Java, ottimizzato e alleggerito per i dispositivi mobili,
come PDA, telefoni cellulari di ultima generazione e TV decoders. Si affianca
quindi a Java 2 Enterprise Edition (J2EE), dedicato alle applicazioni server.
1.2 Java 2 Micro Edition
I livelli più bassi delle APIs J2ME sono la Java Virtual Machine (JVM) e la
Kilobyte Virtual Machine (KVM), ovvero il Java Runtime Environment (JRE)
di dimensioni piccolissime, realizzate appositamente per dispositivi con
memoria e potenza di calcolo limitate. J2ME deve adattarsi anche a display
particolarmente ridotti, ad esempio un piccolo telefono cellulare può disporre di
12.288 pixel (96 ×128), un PDA di 20.000, anche se ultimamente l’evoluzione
tecnologica tende ad abbattere queste barriere con display sempre più ampi e
con sempre più colori.
5
L’architettura Java 2 ME si rivolge ad una moltitudine di apparecchi anche
profondamente eterogenei tra loro (Internet ScreenPhone, cerca persone,
telefonini, decoder, PDA, elettrodomestici, ...), per questo SUN ha introdotto
due concetti fondamentali, quello di Configurazione e Profilo.
•
La configurazione definisce i requisiti minimi di memoria, dello schermo
e la connettività che il dispositivo deve possedere per essere dichiarato
conforme alla data configurazione.
J2ME comprende due Configurazioni (CDC e CLDC).
Connected Device Configuration (CDC) specifica l’ambiente Java per
dispositivi “always on” e ad alta banda, ad es. decoder satellitari e palmari. Le
caratteristiche principali di questa configurazione sono:
512 KB minimo di memoria per applicazioni Java (codice)
256 kB minimo di memoria "runtime", allocata dall'applicazione
6
Connected Limited Device Configuration (CLDC) specifica l’ambiente Java
per i dispositivi con connettività wireless, ridotta banda e accesso discontinuo.
Le caratteristiche di questa configurazione sono:
128 kB di memoria per Java
32 kB di memoria "runtime"
Interfaccia utente ridotta
Bassi consumi, alimentazione a batteria
“L’idea principale è quella di partire da una base comune per tutti i dispositivi,
con un set di APIs limitato a fornire le funzionalità principali per una qualunque
device a limitata configurazione. Saranno poi i produttori di particolari
categorie di dispositivi ad aggiungere nuove funzionalità al CLDC, generando il
profilo”.
Sun Microsystem
•
Il profilo può essere considerato come un’estensione alla configurazione
in
quanto
fornisce
librerie
aggiuntive,
che
devono
essere
necessariamente implementate dai costruttori (che intendono fregiare il
proprio prodotto della conformità a tal profilo).
Il primo profilo proposto è MIDP (Mobile Information Device Profile), che
riguarda principalmente terminali wireless, in grado di instaurare connessioni
basate sul protocollo HTTP.
Il profilo MIDP, definisce le API per componenti di interfaccia utente, per gli
input, la gestione degli eventi, la memoria persistente RMS, le funzioni di rete i
timer…
7
Un dispositivo MIDP deve garantire un set di requisiti minimi sia hardware che
software. In particolare un dispositivo che aderisca a questo standard deve
avere:
Uno schermo almeno 96x54 pixel
Dispositivi input per utente (tastiera, penna, ...)
128 K per eseguire i componenti MIDP
8 K per memorizzare dati persistenti (attraverso la libreria RMS)
32 K per eseguire Java
Connettività di rete wireless
Nel paragrafo 1.4 analizzeremo in dettaglio il profilo MIDP, evidenziando le
caratteristiche delle librerie comprese in esso.
L’architettura base di Java 2 Micro Edition può essere riassunta dal seguente
schema:
Mobile Information Device Profile
Connected Limited Device Configuration
Kilobyte Virtual Machine
Sistema Operativo (es: Symbian OS)
1.3 Differenze tra J2ME e J2EE
Analizzando in dettaglio le caratteristiche della Micro Edition di Java, possiamo
notare delle differenze rispetto alla J2EE.
Queste differenze risiedono tanto nel linguaggio quanto nella Java Virtual
Machine.
Per quanto riguarda le differenze di linguaggio è doveroso citare:
1. Calcoli in virgola mobile. I calcoli in virgola mobile fanno un uso
intenso del processore e, a causa delle limitate risorse del processore e
dell'assenza
di
un
co-processore
matematico,
si
è
deciso
(nell'implmentazione del CLDC) di non supportare la virgola mobile.
Questo si traduce nell'assenza (nel linguaggio Java per J2ME) dei tipi
primitivi float e double.
2. Finalizzazione. In una classe J2SE si può dichiarare un metodo con il
nome finalize() che venga chiamato dal garbage collector prima di
rimuovere l'oggetto. Il CLDC non supporta questo metodo dato che
l'overload necessario, in termini di tempo, per la deallocazione delle
risorse sarebbe troppo onerosa per il processore.
3. Gestione delle eccezioni. La JVM supporta un numero limitato di
eccezioni. Il motivo principale è da ricercare nel fatto che la gestione
delle eccezioni in J2SE è molto complessa e tutti questi compiti sono
pesanti da far svolgere ad un processore limitato, inoltre i sistemi
embedded forniscono loro stessi una gestione degli errori interna, quindi,
8
al presentarsi di un errore non si avrebbe il tempo di "catturare"
l'eccezione in quanto il sistema avrebbe già reagito per noi.
Una Java Virtual Machine per J2ME possiede le seguenti limitazioni:
1. Gruppi di thread. Per questa implementazione JVM i thread sono
trattati ordinatamente, oggetto per oggetto. La JVM non supporta la
classe ThreadGroup quindi non si possono lanciare (o fermare) più
thread contemporaneamente ma devono essere avviati uno alla volta.
2. Finalizzazione. Non supportando il linguaggio Java di J2ME l'uso del
metodo finalize() nemmeno la JVM ne supporta l'implementazione.
3. Calcoli a virgola mobile. Dato che il linguaggio Java non supporta i dati
in virgola mobile le implementazioni Java per J2ME mancano di tale
supporto.
4. Interfaccia Nativa Java. Per ridurre il livello di danneggiamento di
informazioni a livello del sistema, sono state eliminate le APIs per
l’invocazione di metodi nativi, quindi non è possibile chimare funzioni
native del sistema operativo ospite per effettuare operazioni (come
accedere alla rubrica)
5. Caricatore di classi personalizzate. CLDC richiede che la JVM
implementi un class-loader. Il caricatore di classi subisce severi controlli
e non può essere sostituito, ignorato o modificato.
6. Reflection. In J2SE si possono usare le classi Reflection per ottenere
informazioni sulla JVM in esecuzione. Queste API (causa consumo di
risorse) non sono disponibili in CLDC
Un lato molto importante da analizzare nella tecnologia J2ME è la sicurezza.
E’ utile sottolineare che ogni dispositivo su cui viene eseguita un’applicazione
Java, necessita di una protezione da un eventuale codice “maligno” che possa
accedere alle informazioni private o a risorse “vitali” del sistema. Ad esempio,
non è possibile accedere alla rubrica del telefono, oppure ai messaggi ricevuti.
Per ovviare al problema della sicurezza la configurazione CLDC utilizza il
modello conosciuto come “sandbox” che vieta l’accesso a tutto ciò che è fuori
dalla “scatola”, ovvero non è possibile utilizzare solo un numero ristretto di
risorse del dispositivo.
La configurazione CLDC utilizza un modello a “sndbox” per proteggere le
risorse critiche del dispositivo e i dati personali del proprietario: come in ogni
modello di questo tipo il software può quindi accedere solo ad un numero
ristretto di risorse.
Ultimo aspetto dell'architettura è la verifica dell’integrità dei file di classe.
Il codice, prima di essere eseguito, viene processato dalla J2SE per verificare
che tutte le sue operazioni siano lecite. Questa operazione di verifica richiede
da sola un minimo di 50 KB di memoria ed un tempo di calcolo relativamente
elevato. Inutile dire che, date le risorse limitate del dispositivo, queste
operazioni non possono essere eseguite a run-time.
Per cercare di rendere meno oneroso il processo di verifica a run-time,
vengono introdotti due nuovi concetti:
9
1. Pre-verifica: Durante il processo di programmazione, o prima di
caricare una classe su di un apparecchio mobile, si esegue un
programma per l’inserimento di attributi addizionali nel file di classe.
Queste informazioni riducono l’ammontare di tempo e di memoria
necessari alla JVM per seguire la verifica.
2. Verifica: Una volta che il dispositivo carica una classe pre-verificata, il
verificatore interno dell’apparecchio ne percorre tutte le istruzioni. In un
qualsiasi momento di questa fase il caricatore può rilevare un errore e
scartare il file di classe.
Grazie a questa funzione il dispositivo è in grado di rifiutare codice
potenzialmente "difettoso".
1.4 Mobile Information Device Profile (MIDP)
E’ possibile immaginare una configurazione come un’astrazione dell’hardware,
mentre il profilo l’insieme delle librerie (API) necessarie per poter sviluppare
applicazioni.
La libreria MIDP è formata da sette package:
Classi che fornisce sistemi di input ed output
attraverso strema
java.lang
Classi di sistema derivate dalla J2SE
java.util
Classi di utilità derivate da J2SE
javax.micoredition.io
Supporto per le connessioni wireless
javax.microedition.lcdui Supporto per l'interfaccia utente wireless
javax.microedition.midlet Classi di base per le MIDlet
javax.microedition.rms
Supporto per il sistema di persistenza dei dati
java.io
Come esposto nella tabella soprastante, i primi tre package rappresentano la
compatibilità con il J2SE, mentre gli atri quattro rappresentano la libreria MIDP
e tutte le classi necessarie per sviluppare applicazioni wireless.
Il package più importante tra tutti i è sicuramente javax.microedition.midlet
che contiene una classe javax.microedition.midlet.MIDlet ed una eccezione
javax.microedition.midlet.MIDletStateChangeException.
Una MIDlet è una applicazione definita nel profilo MIDP.
Ogni MIDlet deve estendere la classe javax.microedition.midlet.MIDlet, per
permettere al software di controllo delle applicazioni (implementato a livello di
10
CLDC) di recuperare le proprietà definite nell'application descriptor e di
notificare le richieste di stato. I metodi di questa classe consentono al software
di gestione delle applicazioni di creare, avviare, mettere in pausa e distruggere
una MIDlet.
Una volta terminato lo sviluppo di un'applicazione, per poterla distribuire è
necessario creare un file che contenga tutte le classi e le risorse (immagini,
dati), compresso come JAR.
Nella cartella META-INF è contenuto il file manifest.mf, si trovano attributi
fondamentali per la definizione della MIDlet, riportati nella tabella sottostante:
Nome Attributo
MIDlet-Name
MIDlet-Version
MIDlet-Vendor
MIDletMicroEdition-Profile
MicroEditionConfiguration
MIDlet-Icon
MIDlet-Info-URL
Utilizzo
Nome della MIDlet
Numero di versione del MIDlet
Autore della MIDlet
Riferimento ad un MIDlet specifico
all'interno della Suite
Richiesto
Si
Si
Si
Si
Si (MIDP1.0)
Si (CLDCQuale configurazione viene richiesta
1.0)
Icona usata dal gestore dell'applicazione No
URL per le info supplementari
No
Quale profilo J2ME viene richiesto
Parte del contenuto del file manifest è sottoposto a vincoli che saranno
analizzati in seguito.
Ulteriore componente del file JAR è l’application descriptor (JAD) il cui ruolo è
quello di fornire informazioni aggiuntive sulla MIDlet suite in cui è contenuto.
Il file JAD fornisce informazioni al gestore dell'applicazione sul contenuto di un
JAR e fornisce uno strumento di passaggio dei parametri tra MIDlet.
Così come il file manifest.mf, anche il file JAD definisce attributi, obbligatori e
non, alcuni dei quali devono necessariamente essere conformi ai parametri del
file manifest.mf: pena l'impossibilità di installare il file JAR.
Nome Attributo
MIDlet-Name
MIDlet-Version
MIDlet-Vendor
MIDletMIDlet-Jar-URL
MIDlet-Jar-Size
MIDlet-Data-Size
Scopo
Nome della MIDlet
Numero di versione del MIDlet
Autore della MIDlet
Riferimento ad un MIDlet specifico
all'interno della Suite
URL del file JAR
Dimensione del file JAR in byte
Numero minimi di byte richiesti per i
recordStore
Richiesto
Si *
Si *
Si *
Si
Si
Si
No
11
MIDlet-EditionTesto che descrive il MIDlet
No
Description
* Questi attributi devono essere identici a quelli definiti del file manifest.mf
Come precedentemente citato, una MIDlet deve estendere la classe
javax.microedition.midlet.MIDlet e implementare alcuni metodi astratti di
questa per fornire alcuni servizi. Questi metodi sono:
abstract protected void destroyApp(boolean unconditional)
Segnala alla MIDlet di terminare e di entrare nello stato Destroy
String getAppProperty(String key)
Fornisce alla MIDlet il meccanismo per recuperare alcune proprietà definite
all'interno del file JAD
void notifyDestroyed()
Usato dal una MIDlet per richiedere al sistema di essere terminata e di
passare allo stato Destroy
void notifyPaused()
Notifica al sistema che la MIDlet non vuole essere attiva e di entrare nello
stato di Pause
protected abstract void pauseApp()
Segnala alla MIDlet di fermarsi e di entrare nello stato Pause
void resumeRequest()
Segnala alla MIDlet che è intenzionata a tornare ad uno stato Active
protected abstract void startApp()
Segnala alla MIDlet che è entrata nello stato Active
Quindi una semplice applicazione MIDP può essere cosi implementata:
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;
public class MyMIDlet extends MIDlet {
// Costruttore della classe
public MyMIDlet() {
super();
}
// Metodo invocato dal sistema all’avvio della MIDlet
protected void startApp() throws MIDletStateChangeException {
}
// Metodo invocato dal sistema per mettere in pausa la MIDlet
protected void pauseApp() {
}
// Metodo invocato dal sistema per chiudere la connessione
protected void destroyApp(boolean arg0) throws
MIDletStateChangeException
}
}
{
Ad una prima lettura del codice può sembrare che alcuni metodi svolgano la
medesima funzione. E’ importante sottolineare questo fatto per mettere in
12
evidenza che una MIDlet ha una comunicazione bidirezionale con il gestore
delle applicazioni, infatti, così come il gestore può mettere in pausa una
MIDlet, la MIDlet stessa può richiedere al gestore di essere messa in pausa o
distrutta.
Per capire meglio quanto accade è bene spiegare il ciclo di vita di una MIDlet.
Una suite MIDlet è un insieme di classi “disegnate” per essere eseguite e
controllate dal sistema MIDP attraverso un meccanismo a stati.
Gli stati consentono al gestore delle applicazioni di monitorare una MIDlet e di
invocare i metodi opportuni ogni volta che questa cambia stato. Supponiamo
che si riceva una telefonata mentre è in esecuzione un’applicazione: il sistema
di gestione (CLDC) intercetta l'evento e, cambiando stato, chiama il metodo
della MIDlet che mette in pausa l’applicazione; terminata la chiamata, chiede
se continuare o meno con l'utilizzo dell'applicazione.
Una MIDlet passa attraverso fasi differenti nel suo ciclo di vita si può trovare in
uno dei seguenti stati:
•
•
•
Paused: La MIDlet viene messa in stato di pausa dopo la chiamata del
costruttore ma prima di essere avviato dal gestore di applicazioni. Una
volta che la MIDlet è stata avviato, può passare alternativamente tra gli
stati di Pausa e di Attivo.
Active: La MIDlet è in esecuzione
Destroyed: La MIDlet ha rilasciato tutte le risorse che aveva acquisito
ed è stato terminato dal gestore di applicazioni
Non appena la MIDlet viene creata (attraverso il suo costruttore) per default
entra nello stato di Pause anche se il suo metodo pauseApp() non viene
invocato.
La differenza tra i metodi destroyApp, pauseApp, startApp ed i metodi
notifyDestroyed, notifyPaused, notifyRequest è che i primi vengono invocati
13
dalla MIDlet per indicare un tipo di comportamento (la MIDlet comunica che ha
intenzione di mettersi in pausa o di chiudersi) mentre i secondi sono delle
richieste effettuate al gestore dell'applicazione da parte della MIDlet.
Supponendo ad esempio di voler implementare un pulsante di “exit”.
L'applicazione chiama il metodo della MIDlet destroyApp(). L'esito di questo
comando deve essere interpretato come una comunicazione che la MIDlet fa a
tutti i suoi componenti dell'intenzione di chiudersi. La semplice invocazione di
questo metodo non chiude la MIDlet. Lo scopo di questo metodo è quello di
chiudere tutte le risorse che la MIDlet ha allocato (database, thread, ecc). La
vera chiusura dell'applicazione si ottiene con la chiamata al metodo
notifyDestroyed(). Con questo metodo la MIDlet chiede al gestore di poter
essere terminata incondizionatamente dato che avrà già provveduto a chiudere
tutte le risorse allocate.
Un esempio di metodo per poter chiudere correttamente un'applicazione
potrebbe essere il seguente:
public void exitApplication() {
try {
destroyApp(false);
notifyDestroyed();
} catch (MIDletStateChangeException e) {
}
}
Un altro metodo importante della classe MIDlet è il metodo getAppProperty()
che serve a leggere gli attributi definiti nel file manifest.mf.
Un'osservazione va fatta anche sul metodo startApp(). Quando una MIDlet sta
per essere posto in stato di attività, il gestore di applicazioni chiama il metodo
startApp(). Questo metodo può essere chiamato più volte nel corso del ciclo di
vita di un MIDlet dato che può passare più volte tra gli stati di Pause e di
Active.
Il codice che crea strutture dati che devono esistere durante tutto il ciclo di vita
di un MIDlet deve essere allocato una volta sola, nel costruttore e non nel
metodo startApp() altrimenti si avrebbe la loro inizializzione ad ogni riavvio
della MIDlet.
1.5 Download di una MIDlet
Un dispositivo J2ME consente di scaricare un’applicazione nei seguenti modi:
•
Standard Over The Air (OTA) tramite WAP:
o Sul server WAP vengono collocati i due file JAR/JAD, e viene creato
un link al file JAD. Selezionando il suddetto link, se la rete supporta
il trasferimento di file con dimensioni maggiori di 15-25 Kb
(dimensione media di una MIDlet) l’applicazione viene installata e
resa disponibile in maniera persistente.
14
•
Connessione con personal computer
o La connessione con un pc può essere effettuata via cavo
seriale/usb, porta infrarossi, bluetooth. Utilizzando il software di
sincronizzazione fornito dal produttore è possibile inviare al
telefonino l’installer dell’applicazione.
1.6 I vantaggi di J2ME
I vantaggi offerti dalle MIDlet sono molteplici, quali la portabilità multipiattaforma, la programmazione Object Oriented, il Garbage Collector, e molti
altri vantaggi ereditati da Java.
Questi vantaggi sono direttamente traducibili in una riduzione di tempi, e
quindi costi, dovuti alle fasi di sviluppo e mantenimento del software, in
particolar modo se esso è sviluppato per più hardware e sistemi operativi.
Interfacciare una MIDlet con piattaforme web che lavorano con JAVA (Servlet o
JSP) è pressoché immediato. La possibilità di interagire con applicazioni web
J2EE permette di sviluppare applicazioni client/server per quella categoria di
utenti denominati mobile-worker, ovvero che devono avere la possibilità di
interagire col sistema informativo aziendale o della infrastruttura a cui
appartengono, benché distanti dall’ufficio o più in generale da un PC.
Probabilmente è in questo settore che si apriranno più possibilità di business,
piuttosto che su applicazioni residenti unicamente su dispositivo mobile.
Analisti affermati del wireless sostengono che, entro la fine del 2004, J2ME
diventerà la piattaforma di sviluppo dominante per dispositivi mobili. Oggi, un
gran numero di produttori di dispositivi mobili tra i quali Motorola, Nokia,
Panasonic (vedi tabella) e le maggiori società operanti nel mondo delle reti
wireless come Nextel, SprintPCS e BT Cellnet, stanno investendo nella
tecnologia J2ME. Con le prospettive sopra elencate lo standard proposto dalla
SUN si sta “allargando”, infatti la frequenza con cui gli stessi produttori di
telefonini definiscono librerie proprietarie è molto elevata. Siemens ad esempio
ha definito una serie di librerie proprietarie che risiedono solo sui propri
terminali e che permettono di controllare alcune funzionalità del telefono come
ad esempio la vibrazione e la lettura di file.
15
1.7 Lista dei dispositivi mobili compatibili con tecnologia Java 2 Micro
Edition (aggiornato 2004)
Manufact.
Model
Wireless
Technology
Frequenc
y
(MHz)
Alcatel
One Touch
735i
E-GSM,
GSM
Alcatel
Software
Screen Avail.
900,
1800
MIDP 2.0,
WMA 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
One Touch 756 E-GSM,
GSM
900,
1800,
1900
JTWI 1.0,
128x1 Yes
MIDP 2.0,
60/18
MMAPI 1.1, bits
MIDP 1.0,
CLDC 1.0,
WMA 1.1
Casio
C452CA
CDMA
800
MIDP 1.0,
CLDC 1.0
120x1 Yes
33/8
bits
Fujitsu
F503i
PDC
800
CLDC 1.0
120x1 Yes
30/8
bits
Fujitsu
F503iS
PDC
800
CLDC 1.0
120x1 Yes
30/10
bits
Fujitsu
F504i
PDC
800
CLDC 1.0
16 bits Yes
Hitachi
C3001H
CDMA
800
MIDP 1.0,
CLDC 1.0
120x1 Yes
62/12
bits
Kyocera
C3002K
CDMA
800
MIDP 1.0,
CLDC 1.0
120x1 Yes
60/16
bits
LG
Electronics
C-nain 2000
CDMA2000
1X
800
MIDP 1.0,
CLDC 1.0
120x1 Yes
33/8
bits
LG
Electronics
C-nain 2100
CDMA2000
1X
800
MIDP 1.0,
CLDC 1.0
8 bits
LG
Electronics
Cyber-ez-X1
CDMA
1900
CLDC 1.0
128x1 Yes
28/2
bits
LG
Electronics
I-Book
CDMA
1900
CLDC 1.0
128x1 Yes
28/2
Yes
16
bits
LG
InfoComm
LX5350
AMPS,
CDMA2000
1X
800,
1900
MIDP 1.0,
CLDC 1.0
120x1 Yes
98/16
bits
LG
InfoComm
VX1
AMPS,
CDMA2000
1X
800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
04
Mitsubishi
D2101V
W-CDMA
CLDC 1.0
132x1 Yes
62/18
bits
Mitsubishi
D503i
PDC
800
CLDC 1.0
132x1 Yes
42/10
bits
Mitsubishi
D503iS
PDC
800
CLDC 1.0
132x1 Yes
42/10
bits
Mitsubishi
D504i
PDC
800
CLDC 1.0
18 bits Yes
Mitsubishi
J-D05
PDC
1500
MIDP 1.0,
CLDC 1.0
12 bits Yes
Motorola
A388
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
240x3 Yes
20/2
bits
Motorola
A388c
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
240x3 Not
20/16 yet
bits
Motorola
A760
MIDP 2.0,
CLDC 1.0
320x2 Yes
40/16
bits
Motorola
A820
Motorola
A830
MIDP 1.0,
CLDC 1.0
176x2 Yes
20/12
bits
Motorola
A835
MIDP 1.0,
CLDC 1.0
176x2 Yes
20/16
bits
Motorola
Accompli
008/6288
GSM/GPRS
900,
1800
MIDP 1.0,
CLDC 1.0
240x3 Yes
20/2
bits
Motorola
Accompli 009
GSM/GPRS
900,
1800,
MIDP 1.0,
CLDC 1.0
240x1 Yes
60/8
GSM/GPRS, 900,
W-CDMA
1800,
1900
176x2 Not
20/12 yet
bits
17
1900
bits
Motorola
E380
GSM/GPRS
900,
1800
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Motorola
i50sx
iDEN
800
MIDP 1.0,
CLDC 1.0
111x1 Yes
00/2
bits
Motorola
i55sr
iDEN
800
MIDP 1.0,
CLDC 1.0
111x1 Yes
00/2
bits
Motorola
i58sr
MIDP 1.0,
CLDC 1.0
111x1 Yes
00/2
bits
Motorola
i80s
iDEN
800
MIDP 1.0,
CLDC 1.0
119x6 Yes
4/1 bit
Motorola
i85s
iDEN
800
MIDP 1.0,
CLDC 1.0
111x1 Yes
00/2
bits
Motorola
i90c
iDEN
800
MIDP 1.0,
CLDC 1.0
111x1 Yes
10/2
bits
Motorola
i95cl
iDEN
800
MIDP 1.0,
CLDC 1.0
120x1 Yes
60/8
bits
Motorola
T280i
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
00/2
bits
Motorola
T720
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
120x1 Yes
60/12
bits
Motorola
T720
AMPS,
CDMA2000
1X
800,
1900
MIDP 1.0,
CLDC 1.0
120x1 Yes
60/12
bits
Motorola
V60i
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
96x64 Yes
Motorola
V60i
AMPS,
CDMA
800,
1900
MIDP 1.0,
CLDC 1.0
96x64 Yes
Motorola
V60i
AMPS,
TDMA
800,
1900
MIDP 1.0,
CLDC 1.0
96x64 Yes
Motorola
V66i
GSM/GPRS
900,
1800,
MIDP 1.0,
CLDC 1.0
96x64 Not
yet
18
1900
Motorola
T720i
GSM/GPRS
NEC
N2002
W-CDMA
NEC
N503i
PDC
NEC
N503iS
NEC
1900
MIDP 1.0,
CLDC 1.0
120x1 Yes
60/12
bits
CLDC 1.0
16 bits Yes
800
CLDC 1.0
120x1 Yes
30/10
bits
PDC
800
CLDC 1.0
120x1 Yes
30/10
bits
N504i
PDC
800
CLDC 1.0
16 bits Yes
Nokia
3100
GSM/GPRS
900,
1800,
1900
WMA 1.0,
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
3105
CDMA2000
1X
800
WMA 1.0,
MIDP 1.0,
CLDC 1.0
128x1 Not
28/12 yet
bits
Nokia
3108
GSM
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
3120
GSM
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
3200
GSM/GPRS/ 900,
EDGE
1800,
1900
WMA 1.0,
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
3300
GSM/GPRS
900,
1800
WMA 1.0,
128x1 Yes
MMAPI 1.0, 28/12
MIDP 1.0,
bits
CLDC 1.0
Nokia
3300
GSM/GPRS
850,
1900
WMA 1.0,
128x1 Yes
MMAPI 1.0, 28/12
MIDP 1.0,
bits
CLDC 1.0
Nokia
3410
GSM
900,
1800
MIDP 1.0,
CLDC 1.0
96x65 Yes
/1 bit
Nokia
3510i
GSM/GPRS
900,
1800
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Nokia
3520
AMPS,
TDMA
800
MIDP 1.0,
CLDC 1.0
96x65 Not
/12
yet
19
++bits
Nokia
3530
GSM/GPRS
900,
1800
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Nokia
3560
AMPS,
TDMA
800,
1900
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Nokia
3570
CDMA2000
1X
1900
MIDP 1.0,
CLDC 1.0
96x65 Yes
/2 bits
Nokia
3585
AMPS,
CDMA2000
1X
800,
1900
MIDP 1.0,
CLDC 1.0
96x65 Yes
/2 bits
Nokia
3585i
AMPS,
CDMA2000
1X
800,
1900
MIDP 1.0,
CLDC 1.0
96x65 Yes
/2 bits
Nokia
3586i
AMPS,
CDMA2000
1X
800,
1900
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Nokia
3590
GSM/GPRS
850,
1900
MIDP 1.0,
CLDC 1.0
96x65 Yes
/1 bit
Nokia
3595
GSM/GPRS
850,
1900
WMA 1.0,
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Nokia
3600
GSM/GPRS
850,
1900
WMA 1.0,
176x2 Yes
MMAPI 1.0, 08/12
MIDP 1.0,
bits
CLDC 1.0
Nokia
3650
GSM/GPRS
900,
1800,
1900
WMA 1.0,
176x2 Yes
MMAPI 1.0, 08/12
MIDP 1.0,
bits
CLDC 1.0
Nokia
5100
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
5140
GSM
900,
1800,
1900
MIDP 2.0,
CLDC 1.1
128x1 Yes
28/12
bits
Nokia
6010
GSM
850,
1900
MIDP 2.0,
CLDC 1.1,
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Nokia
6100
GSM/GPRS
900,
MIDP 1.0,
128x1 Yes
20
1800,
1900
CLDC 1.0
28/12
bits
Nokia
6200
GSM/GPRS/ 850,
EDGE
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
6220
GSM/GPRS/ 900,
EDGE
1800,
1900
WMA 1.0,
MIDP 1.0,
CLDC 1.0
128x1 Not
28/12 yet
bits
Nokia
6225
AMPS,
CDMA2000
1X
800,
1900
WMA 1.0,
MIDP 1.0,
CLDC 1.0
128x1 Not
28/12 yet
bits
Nokia
6230
E-GSM,
GSM
900,
1800,
1900
MIDP 2.0,
CLDC 1.1
128x1 Yes
28/16
bits
Nokia
6310i
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
95x65 Yes
/1 bit
Nokia
6585
AMPS, GSM 800, 850, MIDP 2.0,
1800,
CLDC 1.0
1900
128x1 Yes
28/12
bits
Nokia
6600
GSM/GPRS
900,
1800,
1900
JABWT 1.0, 176x2 Yes
MIDP 2.0,
08/16
WMA 1.0,
bits
MMAPI 1.0,
CLDC 1.0
Nokia
6610
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
6610i
GSM
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
6620
GSM
850, 900, MIDP 2.0,
1800,
MIDP 1.0,
1900
CLDC 1.0
176x2 Not
08/16 yet
bits
Nokia
6650
GSM/GPRS, 900,
W-CDMA
1800
MIDP 1.0,
CLDC 1.0
128x1 Yes
60/12
bits
Nokia
6800
GSM/GPRS
900,
1800
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
6800
GSM/GPRS
850,
1900
WMA 1.0,
MIDP 1.0,
128x1 Yes
28/12
21
CLDC 1.0
bits
Nokia
6810
GSM
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
6820
E-GSM,
GSM
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
7200
GSM
900,
1800
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/16
bits
Nokia
7210
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
7250
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
7250i
GSM/GPRS
900,
1800,
1900
WMA 1.0,
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
7600
GSM/GPRS, 900,
W-CDMA
1800
Nokia
7610
GSM
850, 900, MIDP 2.0,
1800,
CLDC 1.1,
1900
CLDC 1.0
176x2 Yes
08/16
bits
Nokia
7650
GSM/GPRS
900,
1800
MIDP 1.0,
CLDC 1.0
176x2 Yes
08/12
bits
Nokia
7700
GSM
850, 900, MIDP 2.0,
1800,
CLDC 1.1
1900
640x3 Not
20/16 yet
bits
Nokia
8910i
GSM/GPRS
900,
1800
MIDP 1.0,
CLDC 1.0
96x65 Yes
/12
bits
Nokia
9210
GSM
Communicator
900,
1800
MIDP 1.0,
640x2 Yes
CLDC 1.0, 00/12
JavaPhone bits
1.0,
PersonalJav
a 1.1.1
Nokia
9210i
900,
MIDP 1.0,
GSM
WMA 1.0,
128x1 Not
MMAPI 1.0, 60/16 yet
MIDP 1.0,
bits
CLDC 1.0
640x2 Yes
22
Communicator
1800
CLDC 1.0, 00/12
JavaPhone bits
1.0,
PersonalJav
a 1.1.1
Nokia
9290
GSM
Communicator
1900
MIDP 1.0,
640x2 Yes
CLDC 1.0, 00/12
JavaPhone bits
1.0,
PersonalJav
a 1.1.1
Nokia
9500
GSM,
GSM/GPRS
850, 900, JTWI 1.0,
640x2 Not
1800,
MIDP 2.0,
00/16 yet
1900
M3DAPI
bits
1.0, LAPI
1.0, CLDC
1.1, MMAPI
1.1, WMA
1.1
Nokia
Nokia N-Gage
Game Deck
GSM/GPRS
900,
1800,
1900
WMA 1.0,
176x2 Yes
MMAPI 1.0, 08/12
MIDP 1.0,
bits
CLDC 1.0
Nokia
3120
GSM
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
128x1 Yes
28/12
bits
Nokia
7610
GSM
850, 900, MIDP 2.0,
1800,
MIDP 1.0,
1900
CLDC 1.0
176x2 Yes
08/16
bits
Panasonic
C3003P
CDMA
800
MIDP 1.0,
CLDC 1.0
132x1 Yes
76/16
bits
Panasonic
P2101V
W-CDMA
CLDC 1.0
176x2 Yes
20/18
bits
Panasonic
P503i
PDC
800
CLDC 1.0
120x1 Yes
30/8
bits
Panasonic
P503iS
PDC
800
CLDC 1.0
120x1 Yes
30/8
bits
Panasonic
P504i
PDC
800
CLDC 1.0
16 bits Yes
GSM/GPRS
1900
MIDP 1.0,
160x1 Yes
Research In BlackBerry
23
Motion
Sharp
5810
J-SH51
PDC
1500
MIDP 1.0,
CLDC
1.0
CLDC 1.0
122x1 Yes
60/1
bit
62
Siemens In C(T)56
Research
BlackBerry
Motion
5820
GSM,
GSM/GPRS
GSM/GPRS
850,
900,
1800
1900
MIDP 1.0,
CLDC 1.0
Yes
Siemens
Samsung
C55
SCH-X130
900,
800
1800
Siemens
C60
GSM/GPRS
CDMA2000
1X
GSM/GPRS
Samsung
SCH-X230
Siemens
C61
Samsung
SCH-X250
Siemens
C65
Samsung
SCH-X350
CDMA2000
1X
Samsung
Siemens
SGH-S100
C66
GSM/GPRS
GSM
Samsung
SPH-A500
AMPS,
CDMA
Samsung
Siemens
SPH-N400
CF62
AMPS,
GSM/GPRS
CDMA
Samsung
Siemens
SPH-X4209
CX65
CDMA2000
GSM
1X
Sanyo
A3011SA
CDMA2000
1X
Sanyo
Siemens
SCP-4900
M46
AMPS,
CDMA2000
GSM/GPRS
1X
800,
1900
Sanyo
Siemens
SCP-5300
M50
800,
900,
1900
1800
MIDP 1.0,
CLDC 1.0
Siemens
Sharp
M65
J-SH07
AMPS,
GSM/GPRS
CDMA2000
1X
GSM
PDC
900,
1500
1800,
1900
Sharp
J-SH08
PDC
1500
JTWI 1.0,
MIDP 1.0,
2.0,
CLDC1.0,
1.0
LAPI
CLDC 1.1,
MMAPI
1.1, 122x1 Yes
MIDP 1.0,
WMA
1.1
CLDC 1.0
62
CDMA2000
1X
GSM/GPRS
CDMA2000
1X
GSM
900,
1800,
800
1900
850,
1900
800
900,
1800,
800
1900
900,
1800,
850,
1900
1800,
1900
800,
1900
800,
900,
1900
1800,
1900
800
900,
1800,
800
1900
101x6
160x1
60/1bit
4/1
bit
MIDP 1.0,
101x6
MIDP 1.0,
CLDC
1.0
128x1
4/1
bit
CLDC 1.0
28/2
MIDP 1.0,
101x8
bits
CLDC 1.0
0/12
MIDP 1.0,
120x1
bits
CLDC 1.0
60/8
MIDP 1.0,
101x8
bits
CLDC 1.0
0/12
MIDP 1.0,
120x1
bits
CLDC 1.0
60/8
JTWI 1.0,
130x1
bits
MIDP 2.0,
30
MIDP1.0,
LAPI
1.0,
128x1
CLDC 1.0
1.1, 28/2
MMAPI 1.1, bits
WMA 1.1
MIDP 1.0,
128x1
CLDC 1.0,
JTWI
1.0
60/16
130x1
MIDP 2.0,
bits
30
LAPI 1.0,
128x1
CLDC 1.1,
28/12
MMAPI 1.1,
bits
WMA 1.1
MIDP 1.0,
128x9
MIDP 1.0,
130x1
CLDC 1.0
6/16
CLDC 1.0
30/16
bits
bits
MIDP 1.0,
128x1
JTWI 1.0,
132x1
CLDC 1.0
60
MIDP 2.0,
76
MIDP1.0,
1.0,
132x1
LAPI
CLDC 1.0
1.1, 76/16
MMAPI 1.1, bits
WMA
MIDP 1.1
1.0,
120x9
CLDC 1.0,
1.0
MIDP
CLDC 1.0
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Not
yet
Yes
Yes
Yes
Yes
Yes
Not
yet
Yes
6/12
101x6 Yes
bits bit
4/1
128x1 Yes
101x6
32/16
4/1 bit
bits
132x1 Yes
120x1
Yes
76
60/16
bits
24
Siemens
S55
SL42
GSM
900,
1800,
1800
1900
900,
850, 900
1800
Siemens
Siemens
SL45i/6688i
S56
GSM
GSM/GPRS
Siemens
SL55
GSM
Siemens
S57
Siemens
SL65
GSM/GPRS
Siemens
S65
GSM/GPRS
Siemens
SX1
GSM
Siemens
S66
GSM/GPRS
Sony
Ericsson
A3014S
CDMA2000
1X
Sony
Ericsson
A5402S
CDMA2000
1X
800
Sony
Ericsson
Siemens
F500i
S6C
GSM/GPRS
GSM/GPRS
900,
1800,
900,
1900
1800,
1900
Sony
Ericsson
Siemens
K500c
GSM/GPRS
S6V
GSM/GPRS
900,
1800,
1900
900,
1800,
1900
Sony
Ericsson
K500i
GSM/GPRS
900,
1800,
1900
900,
1800,
900,
1900
1800,
1900
900,
1800,
1900
850,
1800,
800
1900
900,
1800,
1900
MIDP 1.0,
CLDC 1.0
101x8
0/8 bit
0/1
bits
MIDP 1.0,
101x8
MIDP 1.0,
CLDC
1.0
101x8
0/1
bit
CLDC 1.0
0/8
MIDP 1.0,
101x8
bits
CLDC 1.0
0/12
MIDP 1.0,
101x8
bits
CLDC 1.0
0/8
JTWI 1.0,
130x1
bits
MIDP 2.0,
30/12
JTWI 1.0,
M3DAPI
132x1
bits
MIDPLAPI
1.0,
2.0,
76/16
JABWT
1.0,
CLDC
1.4, bits
M3DAPI
1.1,
MMAPI
1.0, WMA
1.1,
LAPI
1.0, CLDC
1.1
1.1, MMAPI
WMA 1.0,
176x2
1.1, WMA
MMAPI 1.0, 20/16
1.1
MIDP 1.0,
bits
JTWI 1.0,
CLDC
1.0
132x1
MIDP 2.0,
76/16
MIDP 1.0,
120x1
JABWT 1.4, bits
CLDC 1.0
20/16
M3DAPI
bits
1.0, LAPI
MIDP
1.0,
240x3
1.0, CLDC
CLDC
1.0
1.1, MMAPI 20/18
bits
1.1, WMA
1.1
JTWI 1.0,
128x1
Yes
Yes
Yes
Yes
Not
yet
Yes
Yes
Yes
Not
yet
Yes
Yes
Yes
MIDP
2.0,
60/16
JTWI 1.0,
132x1 Yes
M3DAPI
bits
MIDP 2.0,
76/16
1.0,
CLDC
JABWT 1.4, bits
1.1,
MMAPI
M3DAPI
1.1,
MIDP
1.0, LAPI
1.0, WMA
CLDC
1.1
1.1, MMAPI
1.1,
JTWIWMA
1.0,
128x1 Not
1.1
MIDP 2.0,
60/16 yet
M3DAPI
JTWI 1.0,
1.0,
MIDPCLDC
2.0,
1.1,
MMAPI
JABWT 1.4,
1.1,
MIDP
M3DAPI
1.0, WMA
LAPI
1.1
1.0, CLDC
1.1,
JTWIMMAPI
1.0,
1.1,
MIDPWMA
2.0,
1.1
M3DAPI
bits
132x1 Yes
76/16
bits
128x1 Yes
60/16
bits
25
Sony
Ericsson
P800
GSM/GPRS
900,
1800,
1900
Sony
Sony
Ericsson
Ericsson
P802
K506c
GSM/GPRS
GSM/GPRS
900,
900,
1800,
1800,
1900
1900
Sony
Ericsson
P900
GSM/GPRS
900,
1800,
1900
Sony
Ericsson
Sony
Ericsson
K508c
GSM/GPRS
P908
GSM/GPRS
900,
1800,
900,
1900
1800,
1900
Sony
Sony
Ericsson
Ericsson
P910a
K508i
GSM/GPRS
GSM/GPRS
900,
900,
1800,
1800,
1900
1900
Sony
Ericsson
Sony
Ericsson
P910c
GSM/GPRS
K700c
GSM/GPRS
900,
1800,
900,
1900
1800,
1900
Sony
Ericsson
P910i
GSM/GPRS
Sony
Ericsson
K700i
GSM/GPRS
Sony
Ericsson
S700c
GSM/GPRS
900,
1800,
1900
900,
1800,
1900
900,
1800,
1900
MIDPCLDC
1.0,
1.0,
1.1, MMAPI
CLDC
1.0,
1.1, MIDP
PersonalJav
1.0,
a
1.1.1
WMA
1.1
MIDP 1.0,
JTWI 1.0,
CLDC
1.0,
MIDP 2.0,
PersonalJav
M3DAPI
a
1.1.1
1.0, CLDC
JABWT 1.0,
1.1, MMAPI
MIDP 2.0,
1.1, MIDP
CLDC 1.0,
1.0, WMA
PersonalJav
1.1
a 1.1.1,
JTWI 1.0,
WMA
1.1
MIDP 2.0,
JABWT 1.0,
M3DAPI
MIDP 2.0,
1.0, CLDC
CLDC 1.0,
1.1, MMAPI
PersonalJav
1.1, MIDP
a 1.1.1,
1.0, WMA
WMA 1.1
1.1
JABWT 1.0,
JTWI 1.0,
JTWI 1.0,
MIDP 2.0,
MIDP 2.0,
M3DAPI
CLDC 1.0,
1.0, CLDC
PersonalJav
1.1, MMAPI
a 1.1.1,
1.1, MIDP
WMA 1.1
1.0, WMA
JABWT
1.0,
1.1
JTWI 1.0,
JTWI 1.0,
MIDP 2.0,
MIDP 2.0,
CLDC 1.0,
M3DAPI
PersonalJav
1.0, CLDC
a 1.1.1,
1.1, MMAPI
WMA 1.1
1.1, MIDP
JABWT
1.0,
1.0, WMA
JTWI
1.1 1.0,
MIDP 2.0,
JTWI 1.0,
CLDC 1.0,
MIDP 2.0,
PersonalJav
M3DAPI
a 1.1.1,
1.0, CLDC
WMA 1.1
1.1, MMAPI
JTWI
1.0,
1.1, MIDP
MIDP
2.0,
1.0, WMA
M3DAPI
1.1
1.0, CLDC
208x3 Yes
20/12
bits
208x3 Yes
128x1 Not
20/12
60/16 yet
bits
bits
208x3 Yes
20/16
bits
128x1 Not
60/16 yet
208x3 Yes
bits
20/16
bits
208x3
128x1
20/18
60/16
bits
bits
Not
Not
yet
yet
208x3 Not
20/18 yet
176x2 Yes
bits
20/16
bits
208x3 Not
20/18 yet
bits
176x2 Yes
20/16
bits
240x3 Not
20/18 yet
bits
26
1.1, MMAPI
1.1, MIDP
1.0, WMA
1.1
Sony
Ericsson
S700i
GSM/GPRS
900,
1800,
1900
JTWI 1.0,
240x3 Not
MIDP 2.0,
20/18 yet
M3DAPI
bits
1.0, CLDC
1.1, MMAPI
1.1, MIDP
1.0, WMA
1.1
Sony
Ericsson
S710a
GSM/GPRS/ 800, 850, JTWI 1.0,
240x3 Not
EDGE, PDC 1800,
MIDP 2.0,
20/18 yet
1900
M3DAPI
bits
1.0, CLDC
1.1, MMAPI
1.1, MIDP
1.0, WMA
1.1
Sony
Ericsson
SO503i
PDC
800
CLDC 1.0
128x1 Yes
28/16
bits
Sony
Ericsson
SO503iS
PDC
800
CLDC 1.0
128x1 Yes
28/16
bits
Sony
Ericsson
SO504i
PDC
800
CLDC 1.0
128x1 Yes
28/16
bits
Sony
Ericsson
SO505i
PDC
800,
1500
CLDC 1.0
256x3 Yes
20/18
bits
Sony
Ericsson
SO506iC
PDC
800,
1500
CLDC 1.0
240x3 Yes
20/18
bits
Sony
Ericsson
T610
GSM/GPRS
900,
1800,
1900
MMAPI 1.0, 128x1 Yes
MIDP 1.0,
60/16
CLDC 1.0
bits
Sony
Ericsson
T616
GSM/GPRS
850,
1800,
1900
WMA 1.0,
128x1 Yes
MMAPI 1.0, 60/16
MIDP 1.0,
bits
CLDC 1.0
Sony
Ericsson
T618
GSM/GPRS
900,
1800,
MIDP 1.0,
60/16
27
TTPcom
B'Ngo
GSM/GPRS
900,
1900
1800,
900,
1900
1800,
1900
MIDP 1.0,
CLDC
1.0
CLDC 1.0
MMAPI 1.0,
MIDP 1.0,
CLDC 1.0
Sony
Ericsson
T628
GSM/GPRS
Sony
Ericsson
T630
Sony
Ericsson
220x1 Not
bits
76/16 yet
128x1 Yes
bits
60/16
bits
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
60/16
CLDC 1.0
bits
T637
GSM/GPRS
900,
1800,
1900
WMA 1.0,
128x1 Yes
MMAPI 1.0, 60/16
MIDP 1.0,
bits
CLDC 1.0
Sony
Ericsson
Z1010
GSM/GPRS, 900,
W-CDMA
1800,
1900
JTWI 1.0,
176x2 Yes
MIDP 2.0,
20/16
CLDC 1.1, bits
MMAPI 1.1,
MIDP 1.0,
WMA 1.1
Sony
Ericsson
Z500a
GSM/GPRS
900,
1800,
1900
JTWI 1.0,
128x1 Not
MIDP 2.0,
60/16 yet
M3DAPI
bits
1.0, CLDC
1.1, MMAPI
1.1, MIDP
1.0, WMA
1.1
Sony
Ericsson
Z500i
GSM/GPRS
900,
1800,
1900
JTWI 1.0,
128x1 Not
MIDP 2.0,
60/16 yet
M3DAPI
bits
1.0, CLDC
1.1, MMAPI
1.1, MIDP
1.0, WMA
1.1
Sony
Ericsson
Z600
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
60/16
CLDC 1.0
bits
Sony
Ericsson
Z608
GSM/GPRS
900,
1800,
1900
MIDP 1.0,
60/16
CLDC 1.0
bits
Toshiba
C5001T
CDMA
800
MIDP 1.0,
CLDC 1.0
144x1 Yes
76/12
bits
Toshiba
J-T06
PDC
1500
MIDP 1.0,
CLDC 1.0
16 bits Yes
28
CAPITOLO 2
PROGETTAZIONE
2.1 Raccolta dei requisiti
2.1.1 Requisiti di business
Il Politecnico di Milano è una nota università Italiana affermata per essere
sempre all’avanguardia nei settori di ricerca e sviluppo di applicazioni ad alto
contenuto tecnologico e informatico.
Per migliorare l’attuale sistema di comunicazione tra docenti e studenti, sta
sviluppando un’applicazione che permetta ai docenti la pubblicazione di avvisi e
notifiche da terminali mobili puntando sull’immediatezza d’uso dell’applicazione
e sui vantaggi offerti dalle ultimissime tecnologie in termini di multicanalità.
La missione primaria del progetto “Instant News System” è quella di facilitare
ai docenti la pubblicazione di notizie nella bacheca elettronica e l’invio di Email
a gruppi di studenti, integrandole con un sistema di notifica via sms.
Gli utenti primari dell’applicazione sono quindi i docenti, i quali avranno a
disposizione due canali di accesso all’applicazione:
• Accesso da dispositivo mobile, che consente l’invio di messaggi
attraverso i canali di comunicazione desiderati (mail, web, sms), la
personalizzazione e l’utilizzo di template di messaggi, la selezione dei
gruppi destinatari di tali messaggi
• Accesso tramite web tradizionale, che permette la personalizzazione delle
funzioni dell’applicazione, quali la modifica di template di messaggi e la
definizione dei corsi destinatari, oltre alle stesse funzioni offerte
dall’accesso mobile.
Altro Gruppo di utenti è quello degli studenti, che potranno consultare le
comunicazioni su dispositivi mobili (tramite sms) o da personal computer
(tramite bacheca elettronica e mail).
L’applicazione opererà direttamente sulla base di dati del Politecnico, di modo
da ottenere maggiore consistenza e integrità dei dati.
Questo progetto mira anche all’apprendimento di ulteriori conoscenze riguardo
alla programmazione Java, più precisamente nell’ambito dello sviluppo di
applicazioni per dispositivi mobili (Java2MicroEdition).
29
2.1.2 Individuazione utenti
-
Gruppo Professori (Utenti Interni)
Gruppo Studenti (Utenti Esterni)
2.1.3 Requisiti funzionali
-
-
Gruppo Docenti:
o Accesso Web:
Definizione/Organizzazione di gruppi destinatari (Collaboratori,
Studenti, ..)
o Accesso Mobile:
Inserimento/modifica notizie in bacheca
Interazione multicanale (SMS, Mail, ..) con gruppi destinatari
Gruppo Studenti:
o Accesso Web:
Consultazione notizie
Requisiti dei dati
-
Entità coinvolte:
o Utenti (Docenti, studenti)
o Corsi
o Notizie
o Destinatari
o Riferimenti template
Requisiti personalizzazione
-
Gruppo Docenti:
o Definizione template messaggi
o Definizione gruppi destinatari
Requisiti dei dispositivi di accesso
-
Dispositivi Mobile:
o Compatibilità J2ME (MIDP, CLDC)
Web Browser
30
2.1.4 Requisiti non funzionali
-
-
-
-
Usabilità:
o Alta personalizzazione
o Velocità di interazione ( pochi click necessari )
Prestazioni:
o Ottimizzazione utilizzo risorse dispositivo mobile (cpu, ram,
batteria, ...)
o Minimizzazione del traffico wireless (UMTS, GPRS, …)
Disponibilità:
o Non Critica (?)
Scalabilità:
o Numero finito di utenti (Docenti e Collaboratori)
Sicurezza:
o Autenticazione utente
o Integrità dei dati: Garantita dalla servlet con cui interagisce
l’applicazione (unico punto di accesso)
o Integrità dispositivo: Garantita dalla midlet sandbox (privatezza
SMS, rubrica, …)
Manutenibilità:
o Java Advantage
31
2.2 Analisi dei requisiti:
2.2.1 Gruppi di utenti
Nome
Gruppo Docenti
Descrizione
Utente principale dell’applicazione, i cui ruoli sono
inserire, modificare, eliminare news, contattare
studenti, mailing list, ed altri contatti.
Dati profilo
Nome, cognome, indirizzo di posta elettronica, ateneo
di appartenenza. I dati sono inseriti esplicitamente
dall’utente.
Super-Gruppo
Nessuno.
Sotto-Gruppi
Nessuno.
Casi d’uso
“Login”, “Crea Notizia”, “Modifica Notizia”, “Rimuovi
Notizia”, “Invia Messaggio a mailing list o contatto”,
“Modifica dati profilo”.
Ogg. Access. in lettura Notizie.
Ogg. Access. in scrittura
Dispositivi di accesso
Nome
Notizie.
Dispositivo mobile compatibile con la tecnologia Sun
Java 2 Micro Edition e web browser
Gruppo Studenti
Descrizione
Studenti di un corso universitario.
Dati profilo
Nome, cognome, indirizzo di posta elettronica, recapito
telefonico.
Super-Gruppo
Nessuno.
Sotto-Gruppo
Nessuno.
32
Ogg. Access.
in lettura
Ogg. Access.
in scrittura
Dispositivi di accesso
Nessuno.
Notizie.
Web browser
2.2.2 Requisiti funzionali
Requisiti funzionali per gli studenti
Gli studenti possono accedere all’applicazione tramite web.
Le operazioni compiute da questa categoria di utenti sono limitate alla lettura
di informazioni riguardanti i corsi frequentati, annunci da parte dei docenti.
33
Gli studenti vengono informati dell’inserimento di un nuovo messaggio
ricevendo un sms sul proprio dispositivo mobile.
Ovviamente ogni studente deve specificare il proprio numero di cellulare
all’atto di immatricolazione, tramite il PoliSelf oppure WebPoliSelf e consentire
al sistema l’invio di news sul proprio telefonino.
Requisiti funzionali per i docenti
I docenti hanno il ruolo di inserire e modificare contenuti relativi ai corsi, quali
variazioni d’orario di lezioni o esami, l’avvicinarsi scadenze, la pubblicazione di
risultati, e molte altre informazioni utili.
Le operazioni sono ad accesso ristretto, quindi i docenti possono utilizzare
l’applicazione solo dopo l’autenticazione.
Come mostrato nel seguente diagramma il docente ha a disposizione due
tipologie di accesso all’applicazione, una mobile (il proprio telefonino) e una
fissa (computer ufficio, casalingo).
Ad ogni tipo d’accesso corrispondono varie e differenti operazioni.
34
2.3 Casi d’uso
Di seguito sono riportati i casi d’uso, espressi tramite diagramma UML e da
Fogli di specifica testuali, riguardanti gli attori principali dell’applicazione: il
gruppo docenti.
2.3.1 Diagramma del caso d’uso per i docenti:
2.3.2 Fogli di specifica casi d’uso
Analisi dettagliata delle operazioni dell’applicazione.
Foglio di specifica per il caso d’uso “Login”
Titolo
Login
Descrizione
Autenticare l’utente che sta accedendo all’applicazione,
sia per motivi di sicurezza che di personalizzazione del
servizio.
Pre-Condizione
L’utente non ha ancora effettuato la procdura di Login
nella sessione corrente.
35
Post-Condizione
L’utente è riconosciuto e sono impostati i permessi sulle
operazioni.
Workflow
Il caso d’uso prevede i seguenti passi:
1. L’utente compila la form di Login ed invia i dati al
server.
2. Si eseguono verifiche sulla validità dei dati ricevuti
3. Se i dati non sono corretti l’utente riceve un
messaggio di errore e viene rimandato alla
schermata contenente la form di inserimento
credenziali.
4. Se le credenziali sono corrette l’utente viene
autenticato e viene visualizzata la schermata
principale dell’applicazione
Foglio di specifica per il caso d’uso “Sincronizza DB”
Titolo
Sincronizza DB
Descrizione
Mantenere sincronizzato il contenuto della base di dati
del dispositivo mobile con quello del DB sul Server.
Pre-Condizione
L’utente deve aver effettuato la procedura di Login
all’interno della sessione corrente.
Post-Condizione
Il contenuto della base di dati mobile è aggiornato.
Workflow
1. L’utente riceve i dati aggiornati direttamente dalla
base di dati.
2. Si eseguono verifiche sulla validità dei dati ricevuti
3. Se i dati non sono corretti l’utente riceve un
messaggio di errore e l’operazione viene annullata.
4. Se i dati sono corretti il contenuto della base di dati
mobile viene aggiornato.
36
Foglio di specifica per il caso d’uso “Edit Oggetto”
Titolo
Edit Oggetto
Descrizione
Inserire o modificare l’oggetto della comunicazione in
questione.
Pre-Condizione
all’interno della sessione.
Post-Condizione
Il contenuto del campo “Oggetto” della comunicazione è
aggiornato.
Workflow
1 L’utente seleziona il Template o il Messaggio di cui
desidera editare l’oggetto.
2 Appare la schermata di modifica, in cui è possibile
modificare il valore dell’ “Oggetto”.
3 Il campo “Oggetto” dell’oggetto selezionato è
aggiornato
Foglio di specifica per il caso d’uso “Edit Testo”
Titolo
Edit Testo
Descrizione
Inserire o modificare il testo della comunicazione in
esame.
Pre-Condizione
all’interno della sessione corrente e deve aver
selezionato la comunicazione di cui desidera modificare
il testo.
Post-Condizione
Il contenuto del campo “Testo” della comunicazione è
modificato.
Workflow
1. L’utente seleziona il Template o il Messaggio di cui
desidera editare il testo.
2. Appare la schermata di modifica, in cui è possibile
modificare il valore del “testo”.
37
3. Il campo “testo” dell’oggetto selezionato è
aggiornato
Foglio di specifica per il caso d’uso “Associa Corso”
Titolo
Associa Corso
Descrizione
Associare gli studenti a cui è destinata la
comunicazione.
Pre-Condizione
L’utente deve aver effettuato l’operazione di Edit
Messaggio e deve aver ciccato sul bottone “invia”
Post-Condizione
destinatari.
Alla comunicazione corrente sono associati i corsi
Workflow
1. Viene visualizzata la lista dei corsi in cui è coinvolto
l’utente.
2. L’utente seleziona i corsi a cui è destinato il
messaggio.
3. Vengono effettuati controlli (almeno un corso
destinatario).
4. Viene visualizzata la schermata di editing del testo
del Messagigo
Foglio di specifica per il caso d’uso “Definisci Visibilità”
Titolo
Definisci visibilità
Descrizione
Definisce la visibilità della comunicazione, in accordo
con la priorità della stessa: esposta nella bacheca
elettronica, inviata tramite mail o sms agli studenti dei
corsi destinatari.
Pre-Condizione
selezionato la comunicazione di cui desidera impostare
la visibilità.
Post-Condizione
La visibilità della comunicazione è impostata.
38
Workflow
1. L’utente decide dove inserire la comunicazione
corrente.
2. Si eseguono controlli sui permessi dell’utente.
3. Gli attributi di visibilità sono impostati.
Foglio di specifica per il caso d’uso “Invia Notizia”
Titolo
Invia Notizia
Descrizione
Inviare la comunicazione selezionata.
Pre-Condizione
effettuato (anche in sessioni distinte) le operazioni “Edit
Template”, “Associa Corso” e “Definisci Visibilità” sulla
comunicazione da inviare.
Post-Condizione
La comunicazione è inviata ai destinatari selezionati.
Workflow
1.
2.
3.
4.
5.
Entrare nella schermata di Invio Notizia.
Editare Oggetto e Testo della comunicazione.
Effettuare l’operazione “Associa Corso”.
Effettuare l’operazione “Definisci visibilità”.
Ciccare sul pulsante “Invia notizia”.
Foglio di specifica per il caso d’uso “Edit Template”
Titolo
Edit Template
Descrizione
Creare o modificare template di messaggi personali;
consta sostanzialmente delle operazioni “Edit Testo”,
“Edit Oggetto”.
Pre-Condizione
all’interno della sessione. Per modificare un messaggio
39
si presuppone, ovviamente, l’esistenza del messaggio
stesso.
Post-Condizione
Viene inserito un nuovo template di messaggio, o ne
viene modificato uno esistente.
Workflow
1.
2.
3.
4.
Raggiungere la schermata “Modifica Template”.
Selezionare il Template da modificare.
Effettuare le operazioni di “Edit Testo” ed “Edit
Oggetto”.
Ciccare sul pulsante “Modifica”.
2.4 Dizionario dei dati
Necessario ai fini della specifica dei requisiti di un’applicazione è la definizione
di un dizionario dei dati il cui compito è quello di eliminare ogni possibile
malinteso o confusione riguardante i dati utilizzati dall’applicazione.
Fornisce inoltre il primo passo verso la creazione del diagramma ER e quindi
verso la realizzazione della Base di Dati dell’applicazione.
Nome
Notizia
Sinonimi
Nessuno
Descrizione
Comunicazione inviata dal docente
Istanze Campione
Progetto di Basi di Dati Prof. Brambilla
L'appello, durante il quale avverrà la consegna degli
elaborati, è fissato per il giorno venerdì 10/09 alle ore
14.30 in aula 3.7
Chi desidera consegnare il progetto in questa data è
pregato di contattare il docente, per fissare un ordine di
consegna.
Proprietà
Oggetto
Testo
Bacheca
Email
Sms
Titolo della notizia
Corpo della notizia
Valore booleano che indica l’inserimento in bacheca
Valore booleano che indica la notifica via mail
Valore booleano che indica la notifica via sms
40
Relazioni
Notizia_Docente
Notizia_Corso
Nome
Associa una notizia al docente che l’ha pubblicata
Associa una notizia al corso a cui si
Template
Sinonimi
Nessuno
Descrizione
Identifica un template di messaggio precompilato,
contenente dei caratteri di escape che permettono la
rapida pubblicazione di notizie attraverso il terminale
mobile (es: %L per luogo, %C per corso)
Istanze Campione
Rinvio Esercitazione
Rinviata esercitazione di %C al giorno %G, ore %H, in
aula %A
Proprietà
Oggetto
Testo
Titolo sintetico del template
Testo del template, comprensivo di caratteri di escaping
Relazioni
Template_Docente
Associa un template al docente che lo ha creato
Nome
Docente
Sinonimi
Nessuno
Descrizione
Identifica il docente correntemente loggato
nell’applicazione
Istanze Campione
Giovanni Toffetti Carughi
Dottorando di ricerca
Proprietà
Nome
Cognome
Ruolo
Nome anagrafico del docente
Cognome anagrafico del docente
Posizione ricoperta dal docente all’interno dell’università
Relazioni
Docente_Notizia
Docente_Corso
Associa un docente alle notize da lui pubblicate
Associa un docente ai corsi da lui tenuti
41
Nome
Corso
Sinonimi
Nessuno
Descrizione
Identifica un insegnamento
Istanze Campione
Tecnologie Informatiche per il Web (5 CFU)
Obiettivo del corso è l'introduzione delle metodologie,
tecniche e architetture per l'analisi, progettazione e
realizzazione di sistemi informativi fruibili via Web. Il
corso affronta lo sviluppo delle applicazioni web da tre
punti di vista: architetture, processo di sviluppo e
tecniche di realizzazione.....
Proprietà
Nome
Crediti
Programma
Relazioni
Corso_Docente
Corso_Notizia
esso
Corso_Studente
Nome
Nome del corso
Valore espresso in Crediti Formativi del corso
Programma del corso
Associa un corso al docente da cui è tenuto
Associa un corso alle notizie pubblicate relative ad
Associa un corso agli studenti che lo frequentano
Studente
Sinonimi
Nessuno
Descrizione
Identifica uno studente iscritto al servizio
Istanze Campione
653672 Francesco Ostini
+393281776xxx
[email protected]
Proprietà
Matricola
Nome
Cognome
Cell
Mail
Matricola dello studente
Nome anagrafico dello studente
Cognome anagrafico dello studente
Numero telefonico dello studente (per notifica via sms)
Indirizzo email dello studente (per notifica via mail)
Relazioni
Corso_Docente
Corso_Notizia
Associa un corso al docente da cui è tenuto
Associa un corso alle notizie pubblicate relative ad esso
42
Corso_Studente
Associa un corso agli studenti che lo frequentano
2.5 Diagramma Entità Relazione
Diretta conseguenza di un dettagliato dizionario dei dati è il diagramma ER,
fondamentale nell’implementazione del DataBase applicativo.
Il precedente diagramma ER riassume la struttura della base di dati,
implementata “lato server”.
Sono facilmente individuabili le entità principali, Docenti, Corsi, Notizie e Site
View, e le relazioni che le collegano a quelle secondarie, Studenti e Template.
Una volta definita la base di dati su cui si opererà lo sviluppo dell’applicazione
è pronto per entrare nel vivo: l’implementazione.
43
CAPITOLO 3
IMPLEMENTAZIONE
3.1 Introduzione
La realizzazione dell’applicazione porta allo sviluppo di due software, uno da
installare sul dispositivo mobile, microNews, e l’altro risiedente
sull’application server, INS Server.
Abbiamo deciso di sviluppare in primo luogo l’application server, in modo da
definire, implementare, testare ed utilizzare sin da subito tutte le funzionalità
richieste dall’applicazione.
3.2 INS Server
L’applicazione INS Server consta a sua volta di 3 componenti: l’interfaccia web,
composta da pagine jsp, la Mobile interaction, il cui compito è di intercettare
interpretare e inoltrare le richieste dei client mobili, ed infine l’application core,
vero e proprio motore del sistema contiene tutte le servlet e le classi
d’appoggio concepite e sviluppate per esser utilizzate sia da web che da device
mobile.
44
3.2.1 Interfaccia Web
L’interfaccia web è un insieme di pagine jsp e servlet che permettono di
visualizzare avvisi, notizie e comunicazioni inserite dai docenti in bacheca e di
utilizzare le funzioni dell’applicazione previa una verifica di credenziali, tramite
la procedura di Login.
Ogni utente viene accolto da index.jsp che controlla l’esistenza di una sessione
a lui appartenente e, in accordo con la definizione delle site-view, mostra o
cela le funzioni riservate di invio comunicazioni e modifica template messaggi.
Di seguito è riportata la pagina inviaMessaggio.jsp.
45
Questa pagina non solo permette di inserire nei campi “Oggetto” e “Testo” gli
omonimi componenti della comunicazione da pubblicare, ma mostra anche tutti
i corsi di cui il docente è titolare, permettendo di selezionarli come destinatari,
ed inoltre consente di selezionare, in accordo con la priorità del messaggio
stesso, il mezzo con cui avvertire i destinatari.
Supponendo di voler affiggere un avviso in bacheca, è sufficiente inserire nella
form “oggetto”, “testo” e attivare la checkbox “Bacheca”. Non è necessario
selezionare alcun corso come destinatario in quanto la notizia verrà comunque
inserita in bacheca e, di conseguenza, sarà visibile da ogni studente.
Al contrario, per inviare una comunicazione urgente via sms, è necessario
specificare almeno un corso-destinatario, in modo da permettere al sistema di
contattare gli studenti frequentanti il dato corso.
L’applicazione permette inoltre di creare messaggi partendo da template (frasi
pre-composte) parametrici.
E’ di seguito riportata la pagina modificaTemplate.jsp che, appoggiandosi alla
servlet ModificaTemplate, permette di visualizzare i propri template e di
modificarli.
Inoltre, sfruttando componiMessaggio.jsp, consente di inviare un messaggio
partendo dal template selezionato.
Cliccando sul pulsante “Invia” viene aperta la pagina componiTemplate.jsp, di
cui è riportato uno spaccato, che permette di valorizzare i parametri all’interno
del testo del template, e di inoltrare il tutto (oggetto e testo) a inviaMessaggio
46
dove, come gia illustrato, sarà possibile selezionare la destinazione della
comunicazione.
Conseguenza della pressione del bottone “Conferma Messaggio” è la seguente
pagina:
47
3.2.2 Mobile Interaction
L’obbiettivo principale è stato assicurare una solida e sicura interazione fra
Mobile e Server, inoltre ci siamo prefissati di sfruttare al massimo il “javaadvantage”, per poter costruire, all’interno dell’application core, delle servlet
modulari: in grado di soddisfare parallelamente e in modo trasparente le
richieste indipendentemente dal canale di provenienza, sia esso il web o la
wireless network.
Ritenendo ottimale gestire ogni operazione in modo atomico, per garantire
maggior integrità, coerenza e consistenza dei dati, e non potendo disporre di
un microbrowser, alle richieste è stato imposto un percorso forzato all’interno
dell’application server in modo da assicurare che nessuna di esse possa
perdersi, portare il server verso esecuzioni non previste oppure accedere a
servizi non concessi. E’ stato quindi necessario implementare, all’interno delle
servlet, metodi di forwarding anziché di redirezione.
E’ riportato il codice del metodo implementato per effettuare la redirezione e il
semplice utilizzo che ne deriva.
private void fwd (String destinationPage, HttpServletRequest req,
HttpServletResponse res)
throws ServletException, IOException{
RequestDispatcher disp = req.getRequestDispatcher(destinationPage);
disp.forward(req, res);
}
fwd(page,request,response);
48
49
Il primo passo del sistema di interazione con la device mobile è composto dalla
servlet J2meInterceptor che, invocata dalle midlet attraverso richieste http, si
occupa di:
•
•
•
•
intercettare tutte le richieste provenienti dal Mobile
controllare se per ognuna di esse esiste già una sessione aperta e, di
conseguenza, se l’utente che tenta di accedere ai servizi è gia
autenticato
inoltrare le richieste da parte di utenti non autenticati alla procedura di
Login
interpretare, formattare ed inoltrare le richieste autorizzate verso
RequestServlet
RequestServlet può essere considerata come la porta d’accesso verso
l’application core in quanto questa servlet si occupa di indirizzare le richieste
dei client mobili alle varie operazioni/servlet dell’application core basandosi su
un sistema di operation code.
RequestServlet a questo punto fa forward alla servlet desiderata passando
sessione, request e response.
Frammento di codice di RequestServlet
void executeCommand(String c, HttpSession session, HttpServletRequest request,
HttpServletResponse response) {
ResultSet result;
String tmp;
if(session.getAttribute("userid")!=null){
try{
DbInterface DB = new DbInterface();
if(c.equals("1")){ //login
}else if(c.equals("2")){ //Sincro Template
result =
DB.selectQuery("OID,OGGETTO,TESTO","TEMPLATE","OWNERID='"+
session.getAttribute("userid")+"'");
while(result.next()){
tmp=result.getString("OID")+"§§§"+
result.getString("OGGETTO")+"§§§"+
result.getString("TESTO");
out.println(tmp);
}
}else if((c.equals("3"))){ //Invio messaggio
fwd("InviaMessaggio",request,response);
}else if(c.equals("4")){ // 4 = monitoraggio email
fwd("MailControl",request,response);
}else if(c.equals("5")){ //Sincro Corsi
50
result =
DB.selectQuery("CORSO.CODCORSO,CORSO.NOME","
INSEGNA INNER JOIN CORSO ON
INSEGNA.CORSO=CORSO.CODCORSO","
(INSEGNA.DOCENTE)='"(String)session.getAttribute("userid")+");
while(result.next()){
tmp=result.getString(1)+"§§§"+result.getString(2);
out.println(tmp);
}
}else if(c.equals("5")){ // 5 = invio fax
fwd("FaxServlet",request,response);
}
DB.closeConn();
}catch(Exception e){
e.printStackTrace();
}
}
}
Successivamente l’application core svolge le funzioni richieste e indirizza gli
output di ogni operazione a CompletedRequest, la servlet che si occupa di
rispondere al dispositivo mobile, sia in caso di interruzioni che di operazioni
completate con successo.
3.2.3 Application Core
E’ il vero motore di tutta l’applicazione, essenzialmente costituito da servlet e
classi di utilità.
Questa porzione di software è stata sviluppata appositamente per poter gestire
in modo completamente trasparente sia le richieste web che quelle provenienti
dai dispositivi mobili.
Inoltre è necessario riconoscere la provenienza di ogni richiesta affinché,
durante il suo iter all’interno dell’application server, venga maneggiata di
conseguenza.
L’identificazione delle richieste avviene attraverso la studio dell’header http
“User-Agent”, permettendo di capire se il client utilizza un browser oppure una
MIDlet.
If (request.getHeader("User-Agent").startsWith("Profile/MIDP")) {
destinationPage = "J2meInterceptor";
response.setContentType("text/plain");
}
51
Ogni servlet dedicata all’invio di notizie quindi deve discernere fra request
mobili e fisse per decidere a chi effettuare forward una volta terminata la
propria esecuzione.
Per quanto riguarda invece l’implementazione delle funzionalità applicative
vere e proprie tutto è gestito dal reciproco rapporto fra servlet e classi:
FaxSender con FaxServlet, MailReceiver con MailControl e MailSender, etc..
Sostanzialmente una richiesta di invio messaggio, dopo esser stata filtrata ed
analizzata, giunge alla servlet InviaMessaggio la quale si occupa di:
•
•
•
•
selezionare i canali di comunicazione (bacheca, mail, sms) richiesti
selezionare i destinatari della comunicazione attraverso una query a DB
invocare i relativi metodi di invio
comunicare al client, fisso o mobile, il risultato dell’invio
Frammento di InviaMessaggio
Address[] to;
if(mail!=null){
mail="1";
to= this.selezionaDestinatari("MAIL",corsi);
try{
stmt=conn.prepareStatement("SELECT MAIL FROM DOCENTE
WHERE USERNAME = '"+userid+"'");
res = stmt.executeQuery();
res.next();
param = res.getString(1);
}catch(SQLException w){
w.printStackTrace();
param = "";
}
MailSender sendmail = new MailSender(param,to,oggetto,testo);
}else mail="0";
if(sms!=null){
sms="1";
to= this.selezionaDestinatari("CELL",corsi);
SmsSender sendsms = new SmsSender(to,"OGGETTO:
"+oggetto+"\n TESTO: "+testo);
sendsms.start();
System.out.println("Inviato al Sms Gateway");
}else sms="0";
if(bacheca!=null){
bacheca="1";
}else bacheca="0";
int ij=0;
StringBuffer tes = new StringBuffer();
Escaper es= new Escaper();
testo=es.escape(testo);
52
stmt = conn.prepareStatement("SELECT MAX(OID) FROM NOTIZIA");
res= stmt.executeQuery();
res.next();
int oid = Integer.parseInt((res.getString(1)));
out.println(String.valueOf(oid));
stmt=conn.prepareStatement("INSERT INTO NOTIZIA (OID, OGGETTO,
TESTO, IDOWNER, BACHECA, SMS, MAIL, DATA)
values ('"+(oid+1)+"','"+oggetto+"','"+testo+"',
'"+userid+"','"+bacheca+"','"+sms+"','"+mail+"','"+data+"')");
stmt.execute();
stmt.close();
RequestDispatcher disp =
request.getRequestDispatcher(destinationPage);
disp.forward(request, response);
}catch(SQLException e){
session.setAttribute("error","Errore: Problemi con il DB");
RequestDispatcher disp =
request.getRequestDispatcher(destinationPage);
disp.forward(request, response);
}
Metodo di selezione dei destinatari:
private Address[] selezionaDestinatari(String canale, Vector listaCorsi)throws SQLException{
Connection conn=DriverManager.getConnection("jdbc:odbc:INS","","");
int i=0;
int dim=0;
ResultSet res;
PreparedStatement stmt;
Address[] outPut=new Address[dim];
String temp;
int cc;
Iterator g = listaCorsi.iterator();
while(g.hasNext()){
temp=(g.next()).toString();
cc = Integer.parseInt(temp);
System.out.println("Cod Corso: "+cc);
stmt = conn.prepareStatement("SELECT STUDENTE."+canale+" FROM STUDENTE
INNER JOIN FREQUENTA ON STUDENTE.MATRICOLA=FREQUENTA.MATRICOLA WHERE
FREQUENTA.CODCORSO ="+cc);
res= stmt.executeQuery();
while(res.next()){
Address[] tmpAddress=new Address[dim+1];
for (int k=0; k<dim; k++) {
tmpAddress[k]=outPut[k];
}
outPut=tmpAddress;
String indirizzi=res.getString(canale);
System.out.println("Addr: "+indirizzi);
53
try{
Address to = new InternetAddress(indirizzi);
outPut[dim]=to;
}catch(AddressException Ae){Ae.printStackTrace();}
System.out.println("Address "+dim+": "+outPut[dim].toString());
dim++;
}
}
return outPut;
}
Invio SMS
La gestione degli Short Message System (SMS) è stata implementata
utilizzando le librerie Java COMM API e JSMSEngine API.
Le librerie Java COMM sono una estensione della Java 2 Standard Edition, e
permettono ad una applicazione scritta in Java di comunicare con dispositivi
collegati ad una porta COM del computer.
Le librerie JSMSEngine permettono ad una applicazione, sfruttando le Java
COMM, Java di inviare SMS utilizzando come gateway SMS un modem GSM,
oppure il proprio telefono cellulare collegato al computer tramite infrarossi
(IRDA).
Un vincolo delle librerie JSMSEngine, è che “comunicano” con il dispositivo
utilizzato come gateway SMS solo tramite porta COM del computer.
Nel caso di un modem GSM il problema non sussiste, infatti questo è collegato
direttamente alla porta COM (tipicamente ad una delle prime 4), e l’invio del
messaggio avviene aprendo un canale di comunicazione tra il modem e librerie
Java COMM, e sfruttando nel codice i servizi messi a disposizione dalle
JSMSEngine API.
Nel caso di un telefono cellulare invece, per poter comunicare con il dispositivo
occorre che la porta IRDA del computer sia “mappata“ su una porta COM,
oppure occorre utilizzare un simulatore IRDA-COM.
Come mostrato nella figura sottostante, il processo di invio SMS è stato
simulato utilizzando come SMS gateway un telefono cellulare. Il simulatore
IRDA-COM utilizzato per il test della nostra applicazione è irCOMM2k.
54
Il processo di invio SMS può essere cosi riassunto:
1. Grazie all’emulatore irCOMM2k, il telefono cellulare benché sia connesso
alla porta infrarossi, viene simulato sulla porta COM3
2. Nel codice della applicazione Java (classe SmsSender), viene istanziato
un servizio di JSMSEngine, indicando la COM da utilizzare per connettersi
con il telefono e la velocità della stessa:
CService srv = new CService("com3", 9600);
3. In seguito dopo opportuni settaggi, viene creato l’oggetto message ed
inviato:
COutgoingMessage msg = new COutgoingMessage(destSMS,mes);
Invio FAX
Per il sevizio di invio fax, sono state utilizzate le librerie Java COMM API e RFax
API.
Come precedentemente citato, le Java COMM API sono delle librerie che
permettono ad una applicazione scritta in Java di comunicare con un
dispositivo collegato ad una porta COM.
Le librerie RFax invece, sono delle librerie proprietarie che sfruttano il modem
56k di un computer per inviare un fax.
Le librerie RFax sono state utilizzate nella classe FaxSender. Il processo di
invio di un fax può essere cosi riassunto:
55
1. Viene creato l’oggetto FaxModem sfruttando le librerie RFax:
FaxModem modem=new FaxModem();
2. Si setta la porta su cui è in ascolto il modem:
modem.setPortName("com4");
3. Si imposta la classe appartenenza del modem (0,1,2):
modem.faxClass=1;
4. Si invia il fax:
modem.open(this);
modem.sendFax("0123456789");
Per interfacciare l’applicazione al Data Base Management System, abbiamo
introdotto la classe DbInterface, che permette di eseguire interrogazioni alla
Java, in modo tale che, per adattare il software ad un nuovo DBMS, sia
sufficiente cambiare pochissime righe di codice.
56
3.3 microNEWS
L’applicativo microNEWS è costituito da un package “ins”, contenente tutte le
interfacce grafiche, e da un sottopackage “ins.core”, che si occupa della
gestione dei dati vitali dell’applicazione, sottostanti l’interfaccia grafica.
57
3.3.1 Mobile Core
Tutte le classi contenute in ins.core sono responsabili della gestione dei dati
necessari alla logica di business dell’applicazione, offrendo funzionalità di:
•
•
•
•
Memorizzazione persistente dei dati
Connessione HTTP
Gestione profilo utente
Gestione template
Memorizzazione persistente dei dati
Per i motivi spiegati nel capitolo 1 è ancor oggi praticamente impossibile
utilizzare un DBMS relazionale su dispositivo mobile.
Dovendo comunque mantenere all’interno memoria locale una porzione di dati
persistenti relativi al profilo utente, si è scelto di memorizzare i dati tramite
Record Management System,utilizzando le librerie javax.microedition.rms
Questa soluzione ha però lo svantaggio di salvare tutti i record in una tabella
costituita da tuple di una sola cella, indicizzate in modo crescente.
Analizzando il recordStore che memorizza i dati dell’utente (“userinfo”),
vediamo che è costituito da:
58
id
1
2
Valore
Userid
Password
Per quanto riguarda invece la memorizzazione dei template, si è scelto di
creare un recordStore per ogni template, realizzato nel modo seguente:
id
1
2
Valore
Titolo template
Testo template
Si è reso necessario inoltre creare una apposita classe RMSManager, custodita
nel package util, che agisce da wrapper sull’RMS, semplificando notevolmente
la programmazione ovunque richieda accesso a dati.
•
Costruttore
...
recordStore = RecordStore.openRecordStore(name, true);
...
•
Metodo Insert
...
recordStore.addRecord(record.getBytes(),0,record.length());
...
•
Metodo Update
...
recordStore.setRecord(id,S.getBytes(),0,S.length());
...
•
Metodo Select
...
byte[] buffer = new byte [50];
String recordValue = null;
if (recordStore.getRecordSize(id) > buffer.length)
buffer = new byte[recordStore.getRecordSize(id)];
int len = recordStore.getRecord(id, buffer, 0);
recordValue = new String(buffer, 0, len);
return recordValue;
...
59
Connessione HTTP
Seguendo le specifiche SUN MIDP 2.0, la connessione viene istanziata in un
thread differente dal quello che cattura i comandi dalla device, si è quindi
scelto di implementare ServletInteraction come Thread.
La suddetta classe che si occupa di effettuare connessioni al server j2ee,
inviare richieste, interpretare risposte e notificare il successo di queste
operazioni
Le classi ServletUpdTemplates, ServletUpdCorsi, estendono ServletInteraction,
ridefinendo solamente il metodo process(), all’interno di quale si svolgono le
attività caratterizzanti l’operazione (processamento della response e successivo
aggiornamento di corsi e template).
Si riportano i frammenti di codice più significativi:
•
Metodo Success
o Visualizzazione della notifica di successo/insuccesso dell’operazione
void success(boolean success, String message) {
message=message;
AlertType alertType=AlertType.ERROR;
if (success)
alertType=AlertType.INFO;
Alert splashScreenAlert;
splashScreenAlert = new Alert("", message, null, alertType);
splashScreenAlert.setTimeout(Alert.FOREVER);
display.setCurrent(splashScreenAlert,disp);
}
•
Metodo Process
o Processamento della response (in se non molto significativo)
void process(String response) {
progress.setValue(9);
if (code==200)
success(true, defSuccess);
else
success(true, defError);
}
•
Metodo Run
o Chiamato all’avvio del thread
...
StringBuffer buffer = new StringBuffer();
try {
progress=new ProgressMonitor(11);
Form tmpForm= new Form("");
tmpForm.append(progress);
display.setCurrent(tmpForm);
60
conn =
(HttpConnection)Connector.open(url+queryString,Connector.READ_WRITE);
conn.setRequestMethod(HttpConnection.POST);
conn.setRequestProperty("User-Agent","Profile/MIDP-2.0
Configuration/CLDC-1.0");
if (data!=null) {
conn.setRequestProperty("Content-Type","application/x-www-formurlencoded");
conn.setRequestProperty("ContentLength",String.valueOf(data.length()));
OutputStream os = null;
os = conn.openOutputStream();
os.write(data.getBytes());
os.close();
}
InputStream is = conn.openInputStream();
int ch;
while ((ch = is.read()) != -1) {
buffer.append( (char)ch );
}
is.close();
String response=buffer.toString();
if (response.startsWith("Errore")) {
success(false,response);
}
else
process(response);
}
catch ( Exception e ) {
if (e instanceof IOException)
success(false, " Errore di Connessione \n");
else
success(false,defError);
}
...
•
Metodo process in ServletUpdTemplates
o Effettua il parsing della response, memorizzando tramite la classe
apposita, i template del docente
void process(String response) {
int j=0;
while (j<response.length()-2) {
StringBuffer lineBuff=new StringBuffer();
while((response.charAt(j) != '\n')) {
lineBuff.append(response.charAt(j));
j++;
61
}
parseLine(lineBuff.toString());
j++;
}
}
success(true, defSuccess);
void parseLine(String line) {
int id;
String title;
String text;
int j=0;
char c=line.charAt(j);
id=c-48;
while(line.charAt(j) == '§') j++;
StringBuffer titleBuff= new StringBuffer();
while(line.charAt(j) != '§') {
titleBuff.append(line.charAt(j));
j++;
}
while(line.charAt(j) == '§') j++;
StringBuffer textBuff= new StringBuffer();
while((line.charAt(j) != '§')&&(j<line.length()-1)) {
textBuff.append(line.charAt(j));
j++;
}
textBuff.append(line.charAt(j));
title=titleBuff.toString();
text=textBuff.toString();
Templates.modTemplate(id, title,text);
}
In maniera analoga è realizzato il metodo process() della classe responsabile
dell’aggiornamento dei corsi.
Gestione profilo utente
La classe principale implementata per gestire il profilo utente è ins.core.UserId,
realizzata staticamente, e dotata dei seguenti metodi:
•
public static void setInfo(String usr, String pwd, String url)
o Memorizza su RMS le informazioni relative al profilo utente
•
•
•
public static String getUser()
public static String getPass()
public static String getUrl()
o Restituiscono i dati relativi al profilo utente
•
public static void setCorsi(String[] corsi)
o Memorizza su RMS la lista dei corsi con relativo id
62
•
public static Course[] getCorsi()
o Restituisce un array di oggetti Course
•
public static void initData()
o Metodo chiamato all’avvio dell’applicazione per caricare i dati da
RMS e renderli disponibili sulle classi a runtime
Altra classe utilizzata è ins.core.Course, le cui istanze rappresentano i corsi (id,
nome corso) relativi al docente correntemente loggato nell’applicazione
Gestione Template
La classe responsabile della gestione dei template è ins.core.Templates, la
quale, realizzata staticamente, fornisce i seguenti metodi:
•
•
public static void modTemplate(int pos, String title, String text)
o Modifica il template in posizione pos, settando i valori titolo e testo
public static Template getTemplate(int pos)
o Restituisce un oggeto oggetto di tipo Template in base
all’identificato della posizione
Ins.core.Templates utilizza la classe ins.core.Template, le
rappresentano un singolo template identificato da titolo e testo
cui
istanze
3.3.2 Interfaccia Grafica
L’interfaccia grafica è realizzata tramite le librerie javax.microedition.lcdui.* le
quali permettono di definire delle primitive di visualizzazione, lasciando poi al
dispositivo il rendering grafico vero e proprio.
Questa caratteristica è molto importante poichè permette di sviluppare
software J2ME in modo totalmente indipendente dalla device su cui poi verrà
visualizzato. Come esempio riportiamo la visione del nostro applicativo su due
telefonini diversi:
63
La midlet ins.Main è l’applicativo che viene lanciato all’apertura del
programma, presentando un menù (realizzato tramite List) attraverso il quale
è possibile accedere a tutte le funzionalità offerte dall’applicazione:
•
•
•
•
•
•
Invio Messaggi
Gestione Template
Configurazione
Monitoraggio Email
Invio Fax
Informazioni
Configurazione
64
Attraverso la schermata di configurazione è possibile salvare i dati necessari
all’autenticazione del docente e l’indirizzo del server a cui connettersi, oltre alla
funzione di sincronizzazione dei corsi, la quale prevede il download e la
memorizzazione persistente sul dispositivo dell’elenco dei corsi tenuti da un
docente.
Segue un frammento di codice di ins.SubConfigure:
void save() {
UserId.setInfo(tfUsr.getString(), tfPwd.getString(), tfUrl.getString());
}
Come è possibile vedere il metodo di salvataggio dei dati utilizza la classe
ins.core.UserId.
void syncronize() {
String usr=tfUsr.getString();
String pwd=tfPwd.getString();
String queryString = "?username="+usr;
String postData = "&password="+pwd+"&opcode=5";
try{
Thread servlet = new ServletUpdCorsi(queryString, postData, main.menu);
servlet.start();
servlet.setPriority(Thread.MAX_PRIORITY);
}
} catch(Exception e){e.printStackTrace();}
Gestione Template
65
La schermata di Gestione Template (realizzata attraverso Form) contiene una
lista (ChoicheGroup) dei template disponibili per l’invio messaggi, editabili
tramite la schermata di Modifica Template, e sincronizzabili con quelli presenti
nel database, utilizzando la classe ins.core.ServletUpdTemplates, la quale
funziona in modo molto simile a ServletUpdCorsi
Invio Messaggi
La funzione di Invio Messaggi (non a caso posizionata come prima opzione del
menù) è la più importante dell’applicazione, permette appunto l’invio di un
messaggio, attraverso un iter di 3 fasi:
1. Scegliere se il nuovo messaggio deve essere composto da zero, oppure
se si vuole semplicemente compilare un template precedentemente
impostato.
66
2. Inserimento titolo e testo messaggio oppure riempimento dei campi
relativi al template selezionato
3. Scelta dei corsi a cui il messaggio è riferito e del canale di comunicazione
desiderati (bacheca, mail, sms)
Terminato il suddetto iter, cliccando sul pulsante opzioni e selezionando
“invia”, l’applicativo si connette al server J2EE, e invia la richiesta, attraverso il
seguente metodo di ins.core.ServletInteraction:
void submit() {
String usr=UserId.getUser();
String pwd=UserId.getPass();
String queryString = "?username="+usr;
postData+=("&password="+pwd+"&opcode=3");
boolean[] selectedChan = new boolean[3];
67
chan.getSelectedFlags(selectedChan);
if (selectedChan[0])
postData+="&bacheca=on";
postData+="&mail=on";
postData+="&sms=on";
boolean[] selectedCors = new boolean[corsi.length];
cors.getSelectedFlags(selectedCors);
for (int i=0; i<corsi.length; i++) {
if (selectedCors[i])
postData+="&"+corsi[i].getId()+"=on";
}
try{
Thread servlet = new ServletInteraction(queryString, postData,
main.menu);
servlet.start();
servlet.setPriority(Thread.MAX_PRIORITY);
main.mainMenu();
} catch(Exception e) {
}
}
Invio Fax
La schermata di invio fax è stata ideata come modo veloce ed economico per
mandare fax testuali, infatti interagisce mandando solamente una HTTP
request (contenente i dati del fax da inviare) all’application server, il quale di
occupa di inviare il fax tramite l’infrastruttura in cui è collocato.
L’interazione è svolta direttamente da ins.core.ServletInteraction in modo
68
Monitoraggio Email
La funzione di monitoraggio email permette di controllare se nella propria
casella di posta elettronica (settando username e password del server POP3)
sono arrivati messaggi inviati da un particolare mittente, specificato nel campo
“indirizzo da monitorare”
Alla ricezione di una mail da parte dell’indirizzo specificato, si riceverà un sms
che riporterà oggetto e i primi caratteri del testo
69
CAPITOLO 4
APPENDICE
4.1 Ambiente di Sviluppo
L’applicazione è stata sviluppata sia su piattaforma Windows che GNU-Linux.
Per quanto concerne INS Server, è stato sviluppato interamente con NetBeans
IDE, la base di dati è gestita da Access tramite bridge JDBC-ODBC (sono stati
effettuati test di compatibilità con database MySQL e PostgreSQL).
Lo sviluppo di MicroNEWS è stato effettuato con SUN ONE Studio MobileEd,
versione rivisitata ad hoc di NetBeans per lo sviluppo di applicazioni J2ME,
integrato con Nokia Developer Suite.
4.2 Testing e Debugging
Al termine della fase di implementazione si è testato l’applicazione alla ricerca
di “bugs”. I test sono stati effettuati su web server Tomcat per quanto riguarda
INS Server, e su un telefonino Nokia 6600 (oltre che su svariati emulatori) per
quanto riguarda MicroNEWS.
Sulla macchina ospitante il web server sono state installate le librerie
necessarie per simulare l’invio di mail, sms e fax.
Un primo problema riscontrato nell’utilizzo dell’applicazione è stato quello di
gestire la connessione http da client mobile verso il web server.
Infatti, al primo tentativo di connessione, si è riscontrato un problema relativo
ai processi in esecuzione sul dispositivo mobile, ovvero l’impossibilità di
effettuare una connessione http nello stesso thread della applicazione
principale, è stato quindi necessario istanziarla in un thread separato, per
evitare di bloccare di il telefono in caso di fallimento della connessione.
Inoltre per poter mandare dati tramite post, ma allo stesso tempo renderli
reperibili tramite una tradizionale request.GetAttribute, è stato necessario
impostare i parametri della connessione nel modo seguente:
String data=”&param=”+param; //i parametri sono inseriti come in una querystring
conn = (HttpConnection)Connector.open(url+queryString,Connector.READ_WRITE);
conn.setRequestMethod(HttpConnection.POST);
conn.setRequestProperty("User-Agent","Profile/MIDP-1.0 Configuration/CLDC-1.0");
conn.setRequestProperty("Content-Type","application/x-www-form-urlencoded");
conn.setRequestProperty("Content-Length",String.valueOf(data.length()));
OutputStream os = null;
os = conn.openOutputStream();
os.write(data.getBytes());
//os.flush();
os.close();
70
E’ importante notare la property content-Type che è stata settata come
application/x-www-form-urlencoded, e il non utilizzo del metodo flush()
sull’outputstream os che può causare problemi a causa di un noto bug.
Dopo avere risolto il problema della connessione http, è stato deciso di testare
l’interazione con il DBMS direttamente da dispositivo mobile.
Nella classe DbInterface, adibita alla gestione del DB, sono state riscontrate
difficoltà nell’interazione con il sistema software per la gestione dei dati, infatti
esiste un problema relativo all’uso di caratteri speciali, quali apici,
attraverso jdbc-odbc driver.
Per ovviare al problema è stata introdotta la classe Escaper che permette di
sostituire questi caratteri “pericolosi” per questo driver (stile “ ’ ”) con altri
meno usati e decisamente più “safe”.
Nella parte di invio messaggi sono stati riscontrati svariati problemi dovuti all’
utilizzo di un SMS gateway. Non avendo a disposizione un vero SMS gateway,
nella fase di test si è utilizzato un telefono cellulare per riuscire ad inviare
questo tipo di messaggi. Come dettagliatamente illustrato nel capitolo
precedente, per poter utilizzare un cellulare come SMS gateway, sono state
utilizzate le librerie Java COMM e JSMSEngine nella classe SmsSender,
“mappando” la porta IRDA sulla porta com3 grazie al simulatore irComm2k.
Dopo svariati tentativi, e problemi dovuti soprattutto al tipo di device mobile
utlizzato come SMS gateway, e all’uso delle librerie Java COMM, come illustrato
nella figura sottostante, è stato possibile inviare il primo SMS.
Log dell’application server:
Sto usando jSMSEngine API 1.2.4:
14-set-2004 04:09:17 org.jsmsengine.CSerialDriver open
INFO: Connecting...
Informazioni addizionali sul dispositivo:
Produttore
: Nokia
Modello
: Nokia 7210
Serial No
: 351114103561xxx
IMSI
: * N/A *
Versione SW
: V 3.0902-10-02NHL-4(c) NMP.
Livello Batteria
: 26%
Livello Segnale
: 32%
SMS per +393293632xxx inviato!
SMS per +393281776xxx inviato!
14-set-2004 04:09:48 org.jsmsengine.CSerialDriver close
INFO: Disconnecting...
L' invio SMS è avvenuto correttamente!
Particolari difficoltà sono sorte nell’utilizzo di Record Management System:
questa forma primitiva di DBMS infatti “affatica” molto la device mobile,
soprattutto nella procedura di inizializzazione.
71
Da sottolineare il fatto che testare l’applicazione su un vero telefono cellulare
(data la minore tolleranza in fatto di gestione eccezioni a runtime) ha messo in
evidenza svariati bug che faticano a manifestarsi sugli emulatori.
Altro grosso problema incontrato è un Bug nell’implementazione del profilo
MIDP (più specificamente una errata visualizzazione degli Alert) del Nokia 6600
(firmware 3.42), documentato nella Nokia knowledge base, per il quale non è
ancora stato rilasciato un aggiornamento.
Nel processo di sviluppo dell’applicazione la decisione di implementare prima la
sezione Server ha semplificato notevolmente lo sviluppo di microNEWS
poiché ha consentito di effettuare test estensivi e debug ad ogni ampliamento /
modifica del codice, permettendo di individuare con tempestività bug ed
imperfezioni.
4.3 Conclusioni e sviluppi futuri
Lo sviluppo di una applicazione multicanale ha permesso di svelare numerosi
aspetti non ancora affrontati nel curriculum di studi, e di affinare una certa
sensibilità verso le tematiche di ottimizzazione del codice (per quanto riguarda
il dispositivo mobile), e di modularità, volendo poter riutilizzare al massimo le
stesse funzioni sia lato mobile che lato web.
Da sottolineare la non completa maturità della tecnologia, che potrebbe
scoraggiare lo sviluppatore, in quanto per poter realizzare una applicazione
veramente funzionante su una vasta gamma di telefonini deve contemplare
anche i bug nell’implementazione dei vari profili, in quanto si è constatato che
un codice che utilizza estensivamente le librerie MIDP (seppur rimanendo
conforme ad esse) potrebbe non risultare compatibile con tutte le device
presenti sul mercato.
Il più naturale sviluppo dell’applicazione è quello di mettere effettivamente a
regime l’applicazione e integrarla con il sistema informativo del Politecnico di
Milano. Per fare questo è necessario ridefinire solamente le servlet che si
occupano dell’ interazione con il database, avendo a disposizione lo schema ER
della base di dati del Politecnico. Altro passo indispensabile è quello di
interfacciare lNS Server con un reale SMS Gateway.
Ulteriori sviluppi futuri saranno una più profonda conoscenza dell’architettura
J2EE-J2ME, in modo da impiegare le capacità e tecniche acquisite anche in
ambito professionale.
72
CAPITOLO 5
BIBLIOGRAFIA
Sito ufficiale SUN Microsystem
http://www.sun.com/
http://java.sun.com/j2me/
Portale ufficiale sviluppatori Nokia
http://www.forum.nokia.com
Portale ufficiale sviluppatori Ericsson
http://www.ericsson.com/mobilityworld/
Portale ufficiale sviluppatori Siemens
http://www.siemens-mobile.com
Portale ufficiale sviluppatori Motorola
http://www.motorola.com/developers
News sul modo wireless
http://www.pec-forum.com/index.htm
Introduzione a J2ME
A Brief Look at Java 2 Micro Edition - Michael Nygard
Applet, MIDlet, Xlet
Understanding J2ME Application Models - Eric Giguere
Programmare in J2ME
Architettura J2ME e libreria MIDP – Fabrizio Russo
API MIDP per l'interfaccia utente – Fabrizio Russo
Record Management System - Fabrizio Russo
Track wireless sessions with J2ME/MIDP
http://www.javaworld.com/
Analisi mercato 2003 – 2007
Embedded Java punta alla leadership
Sicurezza in J2ME
J2ME End to End Security for M-Commerce – W. Itani and Ayman I.Kayssi
Record Management System
Using RMS Files - Recital Corporation
73
Bluetooth Special Interest Group Memeber
Specification of the bluetooth system: Core
https://ww.bluetooth.org/foundry/specification/document/specification
Hypertext Transfer Protocol – HTTP/1.1
IETF RFC 2616
JSMSEngine API
http://www.jsmsengine.org
Java COMM API
http://java.sun.com/products/javacomm/index.jsp
Java MAIL API
http://java.sun.com/products/javamail/
Fax for the Java Platform
http://www.java4less.com/java_fax.htm
Java2me.org Forum
http://forum.java2me.org/
WMLScript Forum
http://www.wmlscript.it/j2me/index.asp
74

INS microNEWS: progettazione e sviluppo di una

Transcript

Documenti analoghi

Programmazione J2ME - Gianpiero Di Blasi

Scheda Sanitaria 2016

log splitters / glspcle80 log splitter

Mini-Box - Sintéleia Srl

Domanda per il rilascio di passaporto a maggiorenne

chiodi di garofano macinati

Questionario Medical Malpractice Aziende Sanitarie Private

Scheda valutazione in lingua inglese

MTC Metaltecnica Trays Cart - Metaltecnica Produzioni Srl

Mod. US/ITALY 1