Introduzione a Java 2 Micro Edition. Dr. Francesca Martelli f.martel@di.unipi.it Stanza: 382 DB Tel:

Transcript

1 Introduzione a Java 2 Micro Edition Dr. Francesca Martelli f.martel@di.unipi.it Stanza: 382 DB Tel:

2 Cosa sappiamo e cosa faremo Conoscenza di java? Conoscenza di HTML? Java 2 MicroEdition Introduzione alla programmazione J2ME J2ME Wireless Toolkit Il linguaggio XHTML 2

3 Cosa Serve (1) Documentazione J2ME MIDP 2.0, CLDC Qualsiasi tutorial che trovate su internet Queste slide che troverete sulla mia home page Libri (opzionali): James Keogh, J2ME: The Complete Reference, McGraw- Hill R. Riggs, A. Taivalsaari, J. Van Peursem, J. Huopaniemi, M. Patel, A. Uotila, Programming Wireless Devices with the Java 2 Platform, Micro Edition, Second Edition, Addison Wesley 3

4 L Architettura Java Compilatore Java: trasforma il linguaggio di programmazione Java in un insieme di bytecode Java Java Virtual Machine (JVM): interpreta il bytecodes Java per eseguire il programma Java Vantaggi di Java: Portabilità: write once, run anywhere Sicurezza: scaricando applicazioni da un ambiente potenzialmente inaffidabile, le chiamate di sistema vengono controllate dalla Java Native Interface (JNI) possibilità di sfruttare le applicazioni in locale, residenti e funzionanti anche off-line interfacciamento con le piattaforme web che lavorano con JAVA (Servlet o JSP) è immediato 4

5 Le versioni di Java 5

6 Java 2 Java 1.2 diventa semplicemente Java 2, anche se le versioni di JDK e JRE rimangono 1.2. La piattaforma Java viene divisa in 3 edizioni: Java 2 Standard Edition (J2SE): per lo sviluppo di applicazioni convenzionali da desktop Java 2 Enterprise Edition (J2EE): sovrainsieme di J2SE, rivolto alla programmazione di impresa, con particolare enfasi sullo sviluppo dal lato server, tramite l uso di Enterprise JavaBeans, applicazioni web (servlets e JavaServer Pages), CORBA, e XML Java 2 Micro Edition (J2ME): sottoinsieme di J2SE, orientato ai dispositivi portatili che non possono supportare un implementazione totale di J2SE Nonostante la sovrapposizione, questa divisione agevola l evolvere di Java in differenti direzioni mantenendo intatto lo spirito del linguaggio 6

7 Java 2 Micro Edition La mancanza di uniformità delle configurazioni hardware fra i vari piccoli dispositivi ha posto una grossa sfida per la comunità Java J2ME è nato per superare questo limite, ed è uno standard che serve molti dispositivi a capacità limitate (telefoni cellulari, PDA e dispositivi plug-in), che hanno configurazioni hardware non standard La JCP ha usato un duplice approccio: La definizione di due CONFIGURAZIONI: Una per i dispositivi portatili Una per i dispositivi plug-in La definizione di PROFILI, per ogni categoria di dispositivo 7

8 Configurazioni Una configurazione definisce l ambiente base di esecuzione: Limitata JVM, nucleo di classi derivate da J2SE Il punto chiave è che ogni configurazione è specifica per una famiglia di dispositivi con capacità simili Ad oggi, sono definite 2 configurazioni, entrambe prevedono connettività alla rete, fissa o wireless: Connected Device Configuration (CDC): box TV, sistemi di navigazione per auto,... Connected Limited Device Configuration (CLDC):cellulari,PDA Non c è netta linea di confine fra le due configurazioni: CDC è un sovrainsieme del CLDC, con in più alcune classi di J2SE e altre nuove 8

9 Profili Un profilo estende una configurazione, aggiungendo classi per specifici usi dei dispositivi, omesse nella configurazione di base (per esempio, classi per l interfaccia utente) Il Mobile Information Device Profile (MIDP) è basato su CLDC Classi per la memorizzazione locale, una user interface, funzionalità per il networking 9

10 Profili (2) Altri profili sono: Personal Digital Assistant Profile (PDAP): estende CLDC per sfruttare le maggiori capacità dei PDA rispetto ai semplici dispositivi MIDP, (migliori display e maggiore memoria Foundation Profile: aggiunge classi J2SE al CDC, ma non per l interfaccia utente; è la base per costruire altri profili Personal Profile (con configurazione CDC): ridefinisce PersonalJava come profilo J2ME; estende il Foundation Profile per implementare una user interface sofisticata Personal Basis Profile: simile al Personal Profile (con configurazione CDC e Foundation Profile), ma implementa user interface più semplice Game Profile (con configurazione CDC): contiene le classi specifiche per sviluppare giochi...j2me è in evoluzione... In una configurazione possono coesistere più profili 10

11 Connected Limited Device Configuration Per capire MIDP bisogna prima conoscere la configurazione CLDC 1.1, definita nel JSR Per dispositivi things that you hold in your hand, caratterizzati da connettività wireless, banda ridotta, accesso discontinuo, batterie limitate e bassa potenza di calcolo e memoria Da 128KB a 512KB di memoria non-volatile (codice) 32KB di memoria volatile (runtime) Processori a 16-bit (o 32-bit) Possono non avere interfaccia utente I dispositivi CLDC usano la KJava Virtual Machine (KVM), versione molto ridotta della JVM 11

12 CLDC: Requisiti (1) No floating point: tipi e costanti floating-point, le classi di J2SE che trattano con valori floating-point non sono supportati (computazione pesante); i metodi che ritornano valori floating point sono rimossi; con opportune librerie è possibile utilizzare il calcolo in virgola mobile No object finalization: il metodo finalize è rimosso da java.lang.object, per semplificare il compito del garbage collector, che semplicemente recupera tutti gli oggetti non referenziati (così si evita il risorgere degli oggetti); Errori a runtime: eccezioni sottoclassi di java.lang.error lanciate dalla virtual machine. Solo 3 classi di errori: java.lang.error, java.lang.outofmemoryerror, java.lang.virtualmachineerror Ogni altra situazione di errore è trattata in modo dipendente dall implementazione della KVM, tipicamente la terminazione 12

13 CLDC: Requisiti (2) Interfaccia Nativa Java (JNI) non supportata: non è possibile chiamare funzioni native del sistema operativo ospitante No reflection: non si possono usare le classi Reflection per ottenere informazioni sulla JVM in esecuzione No object serialization No gruppi di thread: la VM non supporta la classe ThreadGroup quindi non si possono lanciare (o fermare) più thread insieme Le classi ereditate da J2SE devono essere un sottoinsieme delle classi di J2SE 1.3. I metodi possono essere omessi, ma nessun nuovo metodo public può essere aggiunto, per ovvie ragioni di compatibilità Le classi definite dal CLDC e i suoi profili stanno nel package o nei sottopackage di javax.microedition, per identificare facilmente le specifiche classi del CLDC Supporto minimo per internazionalizzazioni: il CLDC fornisce un supporto di base per convertire le codifiche dei caratteri da/per Unicode. Tuttavia, non ha capacità di localizzazione, per la visualizzazione di data, ora, valuta, ecc. 13

14 Connected Device Configuration Per dispositivi things that you plug into a wall, cioè collegati in rete, possibilmente always on, ad alta banda e con buona potenza di calcolo e memoria I dispositivi CDC usano un architettura a 32-bit, Hanno almeno 2MB di memoria disponibile Implementano la JVM di J2SE con tutte le sue funzionalità, incluso il debugging a basso livello e le interfacce native, o meglio, una nuova virtual machine chiamata Compact VM, sviluppata appositamente Dispositivi CDC: Box TV digitali Apparecchi per la domotica Sistemi di navigazione Terminali del pagamento fai-da-te... 14

15 Struttura a livelli dell Architettura J2ME Livello Configurazione: La JVM interagisce con il sistema operativo Lo strato configurazione gestisce le interazioni tra il profilo e la JVM 15

16 Struttura a livelli dell Architettura J2ME Livello Profilo: Insieme minimo di APIs 16

17 Struttura a livelli dell Architettura J2ME Livello MIDP: APIs per le connessioni di rete, memorizzazione e interfaccia utente Interazione con l utente tramite la visualizzazione di comandi, sostanzialmente di tre tipi: Richiesta di elaborazione Richiesta di connessione alla rete Visualizzazione di un altra schermata 17

18 Struttura a livelli dell Architettura J2ME Applicazioni e classi original equipment manufacturer (OEM): Le classi sono usate da MIDP per usi specifici del dispositivo (spedire/ricevere un messaggio), o accedere a dati Le applicazioni sono programmi forniti dal produttore, come un address book 18

19 Le applicazioni per MIDP Sono dette MIDlet e devo essere realizzate per funzionare su qualsiasi dispositivo senza alcuna modifica Ciò è particolarmente difficile soprattutto per le interfacce utente I dispositivi hanno schermi di varie dimensioni, a toni di grigio ed a colori Inoltre i dispositivi di input sono molteplici: tastiere numeriche ed alfa-numeriche, soft key, mini joystick ed anche touch screen 19

20 Applicazioni multi-device Data la grande varietà di dispositivi, ci sono due modi per creare applicazioni multi-device astrazione: specificare una UI astratta, relegando alla MIDP di crearla in concreto (ad esempio invece di dire visualizza la parola 'Avanti' sullo schermo sopra il soft key, si dice dammi il comando 'Avanti' da qualche parte in questa UI scoperta: l'applicazione scopre le caratteristiche del dispositivo a run-time e adatta la UI al volo (per esempio si scoprono le dimensioni dello schermo e si scala l'applicazione) 20

21 Applicazioni multi-device (2) L'API MIDP supporta entrambi i sistemi l'astrazione è il metodo preferito poiché permette di scrivere meno codice e delega tutto alla MIDP in alcuni casi (ad esempio i videogame) è invece necessario un approccio di tipo scoperta per conoscere con certezza le caratteristiche del dispositivo ed adattare il comportamento in modo adeguato L'API MIDP è progettata in modo tale da permettere facilmente anche il mix di queste due tecniche nella stessa applicazione 21

22 MIDlet e MIDlet Suite (1) Comunemente, MIDlets correlate sono raggruppate in una MIDlet suite (package), e verranno considerate come un gruppo unico in fase di installazione/disinstallazione Vantaggio: i membri di una MIDlet suite condividono Le risorse dell ambiente ospitante Le classi Java istanziate La VM Svantaggio: condividere espone ad errori causati da accessi concorrenti nella lettura/scrittura dei dati Rischio ridotto dalle primitive di sincronizzazione per l accesso ai dati volatili e persistenti Se la MIDlet usa multi-threading, è responsabile per il coordinamento degli accessi ai dati 22

23 MIDlet e MIDlet Suite (2) I dati non possono essere condivisi tra MIDlets che non appartengono alla stessa MIDlet suite, perché il nome della MIDlet suite è usato per identificare i dati associati alla suite. Una MIDlet di una diversa MIDlet suite è considerata una sorgente non attendibile Una MIDlet suite è installata, eseguita e rimossa dall Application Manager (AM) che gira sul dispositivo, fornito dal produttore. L AM è responsabile degli accessi alle classi della JVM e CLDC da parte delle MIDlets. L AM inoltre mette il file Java ARchive (JAR) e il file Java Application Descriptor (JAD) a disposizione dei membri della MIDlet suite 23

24 JAD & JAR Le MIDlet Suite sono distribuite dalla coppia di file JAD & JAR: JAD, Java Application Description: contiene tutte le informazioni che descrivono le applicazioni, i requisiti per l'installazione, le proprietà e gli eventuali parametri per l'esecuzione, permessi richiesti sulle API JAR, Java ARchive: contiene le classi dell'applicazione, le eventuali librerie di terze parti, risorse (file di testo, immagini, suoni, dati binari) necessari all'esecuzione dell'applicazione La coppia è generata automaticamente dal tool di sviluppo 24

25 JAR File Svolge lo stesso ruolo che ha in J2SE, con alcune differenze: deve contenere l'indispensabile per l'esecuzione dell'applicazione: il dispositivo potrebbe non essere in grado di salvare l'archivio e il costo di trasferimento potrebbe essere troppo oneroso non è possibile caricare classi e risorse da JAR file diverso da quello di avvio Specificità dei dispositivi: i terminali possono avere una limitazione sulla dimensione massima del JAR (ad esempio: 64K) alcuni terminali richiedono esplicitamente che il file JAR sia compresso 25

26 JAR File Tutti i file necessari per implementare una MIDlet suite devono essere contenuti nell archivio JAR, e sono: Classi delle MIDlet Immagini grafiche (se richieste) Il file Manifesto Il Manifest file contiene una lista degli attributi e relative definizioni usate dall AMS per installare i file contenuti nel JAR nel dispositivo Gli attributi sono nove, di cui tre opzionali; non includere i sei obbligatori nel manifest file induce l AM a interrompere l installazione del JAR file. Il manifest file è un semplice documento di testo 26

27 Attributi del Manifest File 27

28 Esempio di Manifest File MIDlet-Name: Mia MIDlet MIDlet-Version: 2.0 MIDlet-Vendor: MiaSocietà MIDlet-1: MiaMIDlet, /images/miamidlet.png, Mia.MiaMIDlet MicroEdition-Profile: MIDP-2.0 MicroEdition-Configuration: CLDC-1.0 L ordine di comparsa degli attributi non è importante Ogni coppia deve terminare con un ritorno carrello 28

29 JAD File Contiene le informazioni sull'applicazione, mostrate all'utente prima che si proceda con il download e l'installazione del software Il JAD file fornisce all application manager maggiori informazioni sul contenuto del JAR file, per decidere se la MIDlet suite può essere implementata sul dispositivo (configurazione, profilo...) e se il bytecode proviene da un dominio autorizzato ad utilizzare certe funzionalità Può essere un modo per passare parametri a una MIDlet senza modificare il JAR file (il web service, ad esempio, potrebbe inserire dinamicamente delle informazioni nel JAD) Il JAD file è simile al manifest file come coppie attributovalore Cinque attributi sono obbligatori: MIDlet-Name, MIDlet- Version, MIDlet-Vendor, MIDlet-n e MIDlet-Jar-URL 29

30 Attributi del JAD File 30

31 Esempio file JAD MIDlet-Version: MIDlet-Vendor: Francesca Martelli MIDlet-Jar-URL: MicroEdition-Configuration: CLDC-1.1 MicroEdition-Profile: MIDP-2.0 MIDlet-1: Demo1, /image/img1.png, it.unipi.di.fmartel.labjavame.helloworld MIDlet-Jar-Size: MIDlet-Name: HelloWorld Attenzione! i valori degli attributi MIDlet-Name, MIDlet-Version e MIDlet-Vendor nel JAD file devono essere identici a quelli nel manifest. Se così non è, il JAR file non viene installato l'indicazione della dimensione del file JAR deve essere esatta, altrimenti alcuni dispositivi non caricano l'archivio E' consigliabile che l'url del JAR sia assoluto 31

32 Rilascio delle MIDlet suite Il rilascio dell'applicazione per l'installazione su dispositivo può avvenire in tre modalità principali: Over-The-Air: l'applicazione è resa disponibile su un server WAP o WEB pubblico, attraverso il quale il terminale J2ME può scaricarla e procedere con l'installazione PC-based: si procede all'installazione attraverso software dedicato fornito dal produttore del dispositivo OBEX: il terminale J2ME riceve il file jar attraverso trasferimento OBEX (Push o FTP a seconda delle funzionalità del terminale e del PC di appoggio) e provvedere all'installazione in maniera autonoma 32

33 Processo di sviluppo di un MIDlet 33

34 MIDlet Scrivere una MIDlet è simile a creare un applicazione J2SE (applet), solo che è meno robusta Il nome deve essere conforme alla convenzione di nominazione delle classi Java Deve estendere la classe javax.microedition.midlet.midlet È un interfaccia tra i comandi dell applicazione e l ambiente run-time, controllato dall application manager 34

35 Struttura della MIDlet L AM gestisce il ciclo di vita della MIDlet chiamando i metodi startapp(), pauseapp(), and destroyapp(), dichiarati abstract nella classe MIDlet: startapp(): comandi per l inizio dell esecuzione pauseapp(): comandi per la sospensione dell applicazione; per ripartire si richiama il metodo startapp destroyapp(): comandi per la terminazione I metodi startapp() e pauseapp() sono public e non hanno né valore di ritorno, né parametri Il metodo destroyapp() è pubblico e non ritorna valore, ma ha un parametro booleano settato a true se la terminazione della MIDlet è incondizionata, e false se la MIDlet può lanciare una MIDletStateChangeException, per dire all AM che non vuole essere distrutta in quel momento 35

36 Ciclo di vita di una MIDlet 36

37 MIDlet skeleton import javax.microedition.midlet.*; public class MyMIDlet extends MIDlet { //costruttore public MyMIDlet() { } //metodi base: public void startapp() { } public void pauseapp() { } public void destroyapp(boolean unconditional) { } } 37

38 Inizializzazione e avvio Una MIDlet è un applicazione event-based. Tutte le routine eseguite nella MIDlet sono invocate in risposta a un evento riportato dall AM. L evento iniziale occorre quando la MIDlet è lanciata e l AM invoca il metodo startapp() L'inizializzazione della MIDlet deve avvenire nel costruttore: creazione dell'interfaccia grafica allocazione delle strutture dati principali lettura parametri di piattaforma Il metodo startapp() può essere invocato più volte: esso, dunque, non inizializza alcun oggetto ma si occupa di: visualizzare l'interfaccia grafica: tipicamente schermata di dati e invito all utente a scegliere fra una o più opzioni avviare eventuali Thread 38

39 Sospensione Il metodo pauseapp() è invocato al sopraggiungere di una chiamata o altro evento per il quale è richiesto di sospendere l'applicazione Sospendere non significa andare in background! L'applicazione deve congelare il proprio stato (così da riprendere l'esecuzione alla successiva invocazione di startapp()), fermare i thread e chiudere eventuali connessioni di rete. Per sicurezza meglio salvare qualche dato sulla flash del dispositivo! :-( 39

40 Interazione con l'application Manager L'applicazione notifica all'application Manager eventuali variazioni nel suo stato, attraverso i metodi definiti nella classe MIDlet: notifypaused(): l'applicazione ha rilasciato le risorse ed è in stand-by resumerequest(): l'applicazione chiede all'application Manager di essere riavviata 40

41 Chiusura di una applicazione Il ciclo di vita di una MIDlet è gestito dall'application Manager: per questo motivo, l'applicazione non conclude la sua esecuzione con il classico System.exit(EXIT_CODE) bensì notificando all'application Manager che tutte le risorse sono state deallocate e l'applicazione è pronta per essere terminata: notifydestroyed() 41

42 J2ME Software Development Kits Gratis: Sun Java Wireless Toolkit ( Third-party: Borland JBuilder Mobile Set, Sun One Studio 4 (ex Forte for Java) WebGain VisualCafe Enterprise Suite. Bisogna scaricare 3 software da java.sun.com: Java Development Kit (1.3 o successivo) Connected Limited Device Configuration (CLDC) Mobile Information Device Profile (MIDP) Gli ultimi due software sono già inclusi nel WTK 42

43 Creare un MIDlet con J2ME Wireless Toolkit Aprire la Ktoolbar Cliccare su New Project e specificare: Nome del progetto Nome del MIDlet iniziale Nella schermata successiva, specificare le metainformazioni sul JAR file: Da notare il tab MIDlets per aggiungere ulteriori MIDlet nello stesso JAR 43

44 Creazione del progetto (2) Nella cartella apps, apriamo la cartella HelloWorldProject bin: contiene il file JAR e il relativo descrittore res: cartella generica di risorse, tipo le immagini src: cartella di lavoro project.properties è il descrittore Alla prima compilazione verrà creata la cartella classes 44

45 Contenitori Il contenitore principale è il Display Manager implementato nella classe javax.microedition.lcdui.display Ad un Display è associato un oggetto Displayable che è un contenitore di oggetti grafici 45

46 HelloWorld.java import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class HelloWorld extends MIDlet{ Display display; Form form; public void startapp(){ //ottengo il display display=display.getdisplay(this); //creo il contenitore form=new Form("Hello World Program"); //creo il componente StringItem sitem=new StringItem(null,"Hello World!"); //aggiungo il componente al contenitore form.append(sitem); //imposto come displayable corrente display.setcurrent(form); } public void pauseapp(){} public void destroyapp(boolean unconditional){ notifydestroyed(); } } 46

47 Lanciamo il nostro primo progetto! Torniamo su Ktoolbar e clicchiamo su Build Se non ci sono errori, clicchiamo su Run che caricherà l'applicazione sull'emulatore selezionato La prima schermata sull'emulatore, è la lista delle MIDlet presenti nel progetto Selezionando la MIDlet e premendo il tasto Launch vediamo l'esecuzione vera e propria della MIDlet HelloWorld 47

48 Qualche consiglio pratico Sviluppare applicazioni per piccoli dispositivi è una bella sfida: bisogna rivedere l approccio, con qualche accorgimento per fronteggiare il problema delle risorse Differenze tra i dispositivi tradizionali e piccoli: Alimentazione: i primi sono continuamente alimentati, i secondi si affidano a batterie Connessione di rete: i dispositivi mobili sono connessi via radio o infrarossi, la qualità varia con la distanza dal ricevitore e la potenza del segnale generato dal dispositivo Inconsistenza nella connessione di rete, tipicamente richiede all utente di sincronizzare spesso dati e applicazioni con un computer o un server Programmi e dati sono memorizzati nella memoria del dispositivo e vengono persi se cade l alimentazione, quindi devono essere ricaricati nel dispositivo: dati memorizzati offline, piuttosto che sulla memoria primaria del dispositivo 48

49 Qualche consiglio pratico (2) Mantenere l applicazione semplice: Pianificare l applicazione dividendola in oggetti con dati e metodi associati Pianificare l applicazione dividendola in piccoli pezzi Limitare l applicazione alle minime funzionalità richieste, mettendo ogni componente funzionale in una MIDlet (se possibile), e impacchettare le varie MIDlet nella stessa MIDlet suite. Questo facilita l AM del dispositivo nel gestire meglio le MIDlets e le risorse che usano Mantenere l applicazione piccola La dimensione di un applicazione J2ME è un punto critico per svilupparla efficientemente. Rimuovere tutte le componenti non necessarie (tipo i suoni) 49

50 Qualche consiglio pratico (3) Limitare l uso della memoria Gestione globale della memoria: riduce la memoria totale necessaria all applicazione Per ridurre il fabbisogno evitare di usare i tipi oggetto; meglio i tipi scalari. In ogni caso, usare sempre il tipo di dato minimo per memorizzare un certo dato (per i flag, meglio i boolean che gli int...) Gestione della memoria in un picco temporale: minimizzare la quantità di memoria usata negli istanti di maggior uso del dispositivo. Dipende dal garbage collector, per facilitarlo: Allocare un oggetto subito prima di usarlo Settare tutte le referenze agli oggetti a null quando non servono più all applicazione Riusare gli oggetti piuttosto che crearne di nuovi Ridurre la probabilità di eccezione, rilasciando tutte le risorse subito dopo il loro uso 50

51 Qualche consiglio pratico (4) Computazioni pesanti sui Server L applicazione deve fare il minimo calcolo possibile, ma se è necessaria una computazione pesante l alternativa è costruire l applicazione di tipo client-server: il calcolo pesante lo fa il server che poi invia i risultati al client web-services: tre livelli Livello client (presentazione): è dove l utente interagisce facendo la richiesta Livello della logica del servizio: è dove viene chiamato il software appropriato Livello del processamento Esempio: corriere insicuro di un indirizzo, interroga il database della sua azienda 51

52 Qualche consiglio pratico (5) Gestire l uso della connessione alla rete Fare trasmissioni brevi, trasferendo il minimo indispensabile per completare un compito Es: , invece di scaricare i messaggi, visualizzare prima i campi Da, Oggetto,... per poi decidere quale leggere, quale cancellare Considerare l uso della tecnologia store-forwarding e un server-side agent che gira su un server che raccoglie la richiesta dal dispositivo mobile, va a prendere l informazione da una data sorgente, la tiene memorizzata finché il dispositivo mobile non ne fa richiesta, e quindi viene forwardata Esempio: corriere che non sa la strada per raggiungere un indirizzo, e vuole interrogare il sistema di tracking Prevedere sempre un meccanismo per ripristinare una connessione caduta Per esempio, tenere a disposizione le informazioni chiave sulla richiesta, in modo da ritrasmetterle automaticamente 52

53 Qualche consiglio pratico (6) Fare un interfaccia utente semplice Grande varietà di forme e configurazioni hardware fra i piccoli dispositivi, impossibile fare un interfaccia standard per tutti. Nel realizzare la propria user interface: Dove possibile, sfruttare l interfaccia utente fornita dal dispositivo, piuttosto che disegnarla ex-novo Se creata, considerare i meccanismi di input disponibili (icone vs testo) Controllare le disponibilità dei caratteri della tastiera Limitare la quantità di input da parte dell utente, in modo da semplificare la selezione dal menu (regola del pollice) Non concatenare le stringhe (al limite usare StringBuffer) Evitare il più possibile le sincronizzazioni 53