Aplicatii Java pe Telefoane Mobile. Mesagerie Sms. Cmcchat

Cuprins

Introducere…………………………………………………..3

Limbajul Java………………………………………………………….3

J2ME…………………………………………………………………..8

Specificațiile CLDC……………………………………………………..13

CLDC 1.0………………………………………………………………………………….13

CLDC 1.1………………………………………………………………………………….42

Specificațiile MIDP………………………………………………………44

MIDP 1.0…………………………………………………………………………………..44

MIDP 2.0…………………………………………………………………………………..57

Wireless Java API……………………………………………………….64

Comunicatii wireless.Prezentare……………………………………………….64

Specificația Java pentru Bluetooth…………………………………65

SMSChat…………..……………………………………….68

Introducere……….…………………………………………………..68

Implementare…………………………………………………………70

Interfata…….…………………………………………………………75

Bibliografie…………………………………………………79

Introducere

Limbajul Java

Java este un limbaj de programare dezvoltat inițial de Sun Microsystems și lansat în 1995 ca element de bază al platformei Java. Limbajul moștenește în mare parte sintaxa de la C și C++, dar are un model-obiect mai simplu și mai puține facilități low-level. În mod caracteristic, aplicațiile Java sunt compilate într-un format standard numit cod de octeți (bytecode) care este intermediar între codul mașină (dependent de tipul calculatorului) și codul sursă și care poate fi rulat pe orice mașină virtuală Java (JVM), indiferent de arhitectura computerului.

Limbajul Java a fost creat de către James Gosling în iunie1991 pentru a fi folosit la unul din multele sale proiecte pentru adaptoare de semnal de televiziune. Scopul lui Gosling era de a implementa o mașină virtuală și un limbaj care era asemănător ca stil semantic cu C/C++. Prima implementare publică a fost Java 1.0 în 1995. Promitea “scrie o dată, rulează oriunde”, oferind timpi de rulare fără supracost pe cele mai populare platforme de la acea vreme. Era relativ securizată și securitatea era configurabilă pentru a restricționa accesul la fișiere si la rețea. În scurt timp, majoritatea aplicațiilor de navigare a Internetului erau capabile de a rula applet-uri Java, transformând Java într-un limbaj popular. O dată cu apariția Java 2, noile versiuni aveau configurații multiple pentru diferite tipuri de platforme. De exemplu, J2EE (Entreprise Edition) era versiunea pentru aplicații de antrepriză, iar mult redusa versiune J2ME (Micro-Edition) era pentru aplicații mobile. J2SE era denumirea pentru versiunea standard.

Au fost cinci mari scopuri ale creerii limbajului Java:

1. Trebuia să fie un limbaj de programare orientată pe obiecte.

2. Trebuia să permită rularea aceluiași program pe mai multe sisteme de operare.

3. Trebuia să conțină suport integrat pentru folosirea rețelelor de calculatoare.

4. Trebuia să fie proiectat astfel încât să poată executa cod din surse nelocale în mod securizat.

5. Trebuia să fie ușor de folosit prin selectarea a ceea ce erau considerate părțile bune ale altor limbaje de programare orientată pe obiecte.

O caracteristică importantă, independența de platformă înseamnă că programele scrise în Java ar trebui să ruleze în mod similar pe orice arhitectură de procesor/sistem de operare suportat. Prima premisă era: scrie un program o dată, compilează-l o dată, rulează-l oriunde.

Compilatoarele Java realizează acest lucru prin compilarea codului până “la jumătate”, în cod de octeți, adică instrucțiuni mașină simplificate specifice platformei Java. Apoi, codul este rulat pe o mașină virtuală, care este un program scris în cod nativ pe sistemul de operare care interpretează și execută cod de octeți Java generic.

Figura 1: Compilarea și interpretarea codului Java

Primele implementări ale limbajului foloseau o mașină virtuală interpretoare pentru a obține portabilitate. Acestea produceau programe care rulau vizibil mai încet decât programe compilate în executabile native, spre exemplu scrise în C sau C++, deci Java a suferit o reputație de performanțe slabe. Cu timpul, implementările de mașini virtuale Java s-au îmbunătățit folosind mai multe tehnici.

Una din tehnici, cunoscută sub numele de just-in-time compilation (JIT), “compilare chiar-la-timp”, traduce codul de octeți în cod nativ în timpul rulării programului, ceea ce rezultă în timpi de execuție mai mici decât ai codului interpretat, dar apar costuri indirecte ale compilării la rulare. Unele mașini virtuale mai sofisticate folosesc recompilare dinamică, prin care mașina virtuală poate analiza comportamentul programului în timpul rulării pentru a recompila și a optimiza părți critice ale programului.

O altă metodă, cunoscută sub numele de compilare statică, presupune compilarea codului Java direct în cod nativ, fără a mai trece prin starea intermediară de cod de octeți, astfel rezultând în performanțe mai bune față de interpretare, deficitul fiind la portabilitate, executabilul acestor compilatoare poate fi rulat pe o singură arhitectură. Unii ar putea argumenta că o astfel de metodă combate însăși ideea de a programa în Java.

Ideea din spatele modelului automat de gestionare a memoriei al platformei Java este ca progroamtorii să fie scutiți de a se ocupa de această sarcină manual. În unele limbaje de programare este datoria programatorului de a aloca spațiu pe heap pentru anumite obiecte și de asemenea de a dezaloca mai târziu acea zonă de memorie. Dacă programatorul uită să dezaloce memorie ocupată sau scrie cod care nu reușește sa facă acest lucru, o scurgere de memorie poate avea loc și programul poate consuma cantități nederminate de memorie. De asemenea, dacă programul încearcă să dezaloce același spațiu de heap de mai multe ori, comportamentul programului este indefinit, poate sa devină instabil sau să clacheze. În aceste limbaje de programare există mereu un cost suplimentar și o complexitate sporită a codului scris de programator pentru a găsi și finaliza alocările.

În Java, aceste probleme sunt evitate prin automatic garbage collection (colectarea automată a reziduurilor). Programatorul determină când obiectele sunt create, iar Java runtime este responsabil de ciclul de viață al obiectelor. Programul sau alte obiecte pot referi alte obiecte ținând o referință la acel obiect, ceea ce din punct de vedere low-level este o adresă de heap. Când nu mai rămân referințe la un obiect, acesta devine de neatins și eligibil pentru eliberare de către garbage collector – poate fi dezalocat oricând. Scurgeri de memorie mai pot avea loc dacă programatorul uită ca păstrează referințe la obiecte de care nu mai are nevoie, adică la un nivel conceptual mai înalt.

Folosirea garbage-collector-ului poate influența și anumite paradigme ale progrmării. Spre exemplu, dacă programatorul consideră costul alocării și dezalocării obiectelor a fi destul de mic, ar putea alege să construiască obiecte mai liber, decât să le preinițializeze și să le refolosească. Costul penalizărilor de performanță fiind mic, aceasta facilitează izolarea thread-urilor și încapsularea datelor. Folosirea obiectelor imutabile efemere minimizează programarea cu efecte nedorite.

Garbage-collection este încorporat în platforma Java și practic invizibil programatorului. Cu alte cuvinte, e posibil ca progamatorii să nu aibă nici o idee când eliberarea memoriei are loc, pentru că nu se corelează cu nici o acțiune executată de codul pe care îl scriu. În funcție de aplicația dorită acest lucru poate fi avantajos sau dezavantajos: programatorul este scutit de a efectua sarcini low-level, dar în același timp pierde opțiunea de a scrie cod low-level. În plus, garbage-collector-ul necesită atenție sporită la setările mașinii virtuale, întrucât s-a observat că dimensiuni mari ale heap-ului pot cauza scăderi aleatoare ale performanței aplicației.

Java nu suportă aritmetica pointer-ilor, cum spre exemplu suportă C++. Acest lucru se explică prin faptul că garbage-collector-ul poate reloca obiecte referite, invalidând astfel de pointeri. Un alt motiv este că siguranța tipurilor și a obiectelor nu mai poate fi garantată dacă este permisă manipularea arbitrară a pointer-ilor.

Sintaxa limbajului Java a fost în mare parte derivată din C++. Spre deosebire de C++, care combină sintaxă pentru programare structurată, generică și orientată pe obiecte, Java a fost construită exclusiv pentru programare orientată pe obiecte. În consecință, aproape totul este un obiect și tot codul este scris în interiorul unei clase. Excepțiile sunt reprezentate de tipurile de date primitive (numerele întregi și reale, valori booleene și caractere), care nu sunt clase din considerente de performanță.

Java suprimă mai multe trăsături (cum ar fi supraîncărcarea operatorilor sau moștenirea multiplă) ale claselor, pentru a simplifica limbajul, pentru “a salva programatorii de ei înșiși” și pentru a preveni posibile erori și proiectarea anti-tipar.

J2ME

Tehnologia Java Micro Edition (J2ME) a fost initial creata pentru a adresa constrangerile asociate cu dezvoltarea de aplicatii pentru dispozitive mici. In acest scop, Sun a definit bazele tehnologiei care sa se potriveasca unui mediu limitat si care sa faca posibila creerea de aplicatii Java rulate pe dispozitive mici in conditii de memorie, afisaj si putere de calcul limitate.

Platforma J2ME este o colectie de tehnologii si specificatii care pot fi combinate pentru a construi un Java runtime enviroment (JRE) complet, specific pentru un anumit tip de dispozitiv, rezultatul fiind flexibilitate in a suporta o larga arie de dispozitive limitate.

Tehnologia J2ME se bazeaza pe trei elemente:

1. o configuratie ofera cel mai de baza set de librarii si capabilitati ale masinii virtuale pentru cat mai multe dispozitive posibile

2. un profil este un set API (Application Programming Interface) care suporta un numar mai mic de dispozitive

3. un pachet optional este un set API specific unei anumite tehnologii

Pe parcursul istoriei Java, Sun si alte organizatii au folosit Java pentru a acomoda diverse marimi si forme de aparate de calcul. Totusi, atentie speciala asupra folosirii Java pe dispozitive mici sau pe aparate de calcul personale, nu a fost organizat si ghidat de specificatii decat pana tarziu in anii '90. Cu cat dispozitive de calcul si comunicare mai puternice au inceput sa fie impachetate in dispozitive din ce in ce mai mici, un nou interes a fost indreptat catre Java pentru aceste sisteme. In iunie 1999, la conferinta JavaOne 1999, Sun a introdus trei editii ale platformei Java: J2SE, J2EE si J2ME. In acelasi timp, a fost dezvaluita prima masina virtuala J2ME, adica o versiune a KVM sau masina virtuala K (K Virtual Machine).

Ar trebui sa nu fie o surpriza foarte mare ca printre cei mai mari sustinatori ai tehnologiei J2ME sunt producatorii de dispozitive mici: telefoane celulare, pagere sau PDA-uri; cum ar fi: Motorola, Ericsson, Nokia, Research In Motion, Palm, Siemens si altii. Suporterii includ membri ai producatorilor de electronice casnice, de birou sau pentru automobile: Fujitsu, Hitachi, Matsushita (Panasonic), Samsung, Sharp si Sony. Vanzatorii de software traditionali cum ar fi Oracle, de asemenea, sunt implicati.

J2ME nu e singura posibilitate de pe piata. Companii ca IBM sau HP si-au dezvoltat propriile platforme Java pentru dispozitive mici sau integrate. Din faptul ca se dezvolta produse Java proprietare, este evident ca toate aceste organizatii vad beneficiile de a introduce Java in electronicele de larg consum si in platforma dispozitivelor integrate.

Sustinatorii J2ME participa la imbunatatirea si avansarea specificatiilor prin Java Community Process (JCP). Este vorba de un proces formal initiat de Sun Microsystems pentru a dezvolta si revizui specificatiile tehnologiei Java in cooperare cu comunitatM sau masina virtuala K (K Virtual Machine).

Ar trebui sa nu fie o surpriza foarte mare ca printre cei mai mari sustinatori ai tehnologiei J2ME sunt producatorii de dispozitive mici: telefoane celulare, pagere sau PDA-uri; cum ar fi: Motorola, Ericsson, Nokia, Research In Motion, Palm, Siemens si altii. Suporterii includ membri ai producatorilor de electronice casnice, de birou sau pentru automobile: Fujitsu, Hitachi, Matsushita (Panasonic), Samsung, Sharp si Sony. Vanzatorii de software traditionali cum ar fi Oracle, de asemenea, sunt implicati.

J2ME nu e singura posibilitate de pe piata. Companii ca IBM sau HP si-au dezvoltat propriile platforme Java pentru dispozitive mici sau integrate. Din faptul ca se dezvolta produse Java proprietare, este evident ca toate aceste organizatii vad beneficiile de a introduce Java in electronicele de larg consum si in platforma dispozitivelor integrate.

Sustinatorii J2ME participa la imbunatatirea si avansarea specificatiilor prin Java Community Process (JCP). Este vorba de un proces formal initiat de Sun Microsystems pentru a dezvolta si revizui specificatiile tehnologiei Java in cooperare cu comunitatea utilizatorilor Java, cu numele de Java Specification Request (JSR). Fiecare specificatie dezvoltata in JCP trebuie sa treaca printr-un proces bine definit.

Procesul incepe cu o cerere din partea comunitatii Java pentru dezvoltarea unei noi specificatii sau revizuirea uneia existente. Cererea poate fi acceptata sau respinsa de catre Sun Process Management Office. Daca este acceptata, Sun Process Management Office formeaza un grup de experti care vor lucra la specificatie. Grupul de experti studiaza si rafineaza proiectul lor pentru o perioada de timp dupa care il promoveaza la statutul de proiect public. Proiectul public este apoi deschis comunitatii Java pentru analiza si comentare publica. Dupa suficiente reviziuri si modificari, Process Management Office va promova proiectul la statutul de versiune finala a specificatiei, va publica versiunea si va dizolva grupul de experti

Desi Sun Microsystems a condus majoritatea proiectelor Java, compania nu detine in intregime tehnologia. Aceasta este evident din faptul ca alte organizatii au introdus produse pe piata electronicelor de consum mici si a dispozitivelor integrate inainte ca J2ME sa fie lansat.

J2ME nu este o implementare, ci o specificatie sau mai precis o serie de specificatii. Sun detine implementari ale unor specificatii, dar si alte organizatii au propriile implementari. Se pune, bineinteles, intrebarea: “de ce sa oferi o implementare alternativa a J2ME?”. Sun nu a fost mereu cel mai bun implementator de specificatii pe care le-au initiat sau condus. Spre exemplu, este considerat in mod general in comunitatea Java ca IBM ofera un compilator Java mult mai rapid si superior numit Jikes. De asemenea, numeroase organizatii au alte implementari ale masinii virtuale Java si API-uri care satisfac specificatiile J2ME, dar care au amprente reduse si performante mai bune decat implementarile Sun.

Exista si alti competitori Java ai J2ME, care ruleaza in acelasi mediu general, dar nu respecta specificatiile J2ME. Acest lucru se intampla din motiv ca desi Sun a avut tentative timpurii de a introduce Java pe electronicele de consum, J2ME este o tehnologie relativ noua. De asemenea, se incearca rezolvarea unei probleme foarte dificile, si anume, cum sa scrii software intr-un singur limbaj de programare pentru o diversitate de aparate de la pagere la aparate digitale de televiziune. Alte organizatii s-au concentrat pe a face disponibil Java pe un set restrans de dispozitive. Totusi, altele au luat o abordare care permite programatorilor sa foloseasca limbajul Java, dar fara a adresa preocuparile pentru particularitatile dispozitivelor tinta. Cu alte cuvinte, ei plaseaza mai multa responsabilitate pe programator in a se asigura independenta de platforma a aplicatiilor.

Pe parcursul timpului, J2ME a fost separata in doua configuratii de baza, una directionata catre dispozitive mobile mici si alta catre dispozitive mobile mai capabile, de genul smart-phone. Configuratia pentru dispozitive mici se numeste Connected Limited Device Configuration (CLDC), iar configuratia mai capabila se numeste Connected Device Configuration (CDC)

Figura 2: Relația standardelor J2ME și J2SE

Connected Device Configuration (CDC)

Configuratia CDC avea ca tinta dispozitive mai puternice si cu o conexiune la retea, spre exemplu PDA (Personal Digital Assistant). Scopurile configuratiei erau de a oferi capabilitati tehnologice si unelte de dezvoltare bazate pe Java Standard Edition (J2SE) si de a pune in valoare caracteristicile integrate ale unei arii largi de dispozitive incadrandu-se in acelasi timp in limitele lor de resurse.

Observand beneficiile configuratiei CDC aduse diferitelor grupe din lantul de valorificare (producatori de dispozitive, dezvoltatori de aplicatii, utilizatori), urmatoarele pot fi spuse:

– Intreprinderile beneficiaza prin folosirea de aplicatii conectate la o retea, care extind logica afacerilor la clienti, parteneri si angajati.

– Utilizatorii beneficiaza de compatibilitatea si securitatea tehnologiei Java

– Dezvoltatorii de aplicatii beneficiaza de siguranta si productivitatea limbajului de programare Java si bogata colectie de API-uri ale platformei Java.

Connected Limited Device Configuration (CLDC)

Configuratia care adreseaza dispozitive constranse din punct de vedere al resurselor cum sunt telefoanele mobile se numeste Connected Limited Device Configuration (CLDC). Este conceputa in mod specific pentru a suporta o platforma Java care sa ruleze pe dispozitive cu memorie limitata, putere de procesare redusa si capabilitati grafice mici. Deasupra diferitelor configuratii, paltforma J2ME specifica de asemenea un numar de profiluri care definesc un set API de nivel mai inalt care extind definitia aplicatiei. Un exemplu comun adoptat este de a combina CLDC cu Mobile Information Device Profile (MIDP), pentru a oferi un mediu de aplicatie Java complet pentru telefoane mobile si alte aparate cu resurse asemanatoare.

Specificatiile CLDC

Specificatia CLDC a fost dezvoltata in cadrul Java Community Process ca JSR 30 (CLDC 1.0) si JSR 139 (CLDC 1.1)

CLDC 1.0

Specificatia CLDC 1.0 a fost finalizata in luna mai a anului 2000 in cadrul JSR 30. Tinta acestei cereri a fost definirea unei platforme Java standard, cu amprenta minima pentru dispozitive mici, conectate, constranse din punct de vedere al resurselor cu urmatoarele caracteristici:

– intre 160 kB si 512 kB memorie totala disponibila pentru platforma Java.

– un procesor pe 16 biti sau pe 32 biti.

– consum de energie redus, cel mai adesea functionand pe baterii

– conectivitate la un tip de retea, cel mai adesea printr-o conexiune wireless intermitenta si cu bandwidth limitat (9600 bps sau mai putin).

Aceasta configuratie J2ME defineste complementul minim necesar de componente si librarii Java pentru dispozitive mici, conectate. Limbajul Java si particularitati ale masinii virtuale, librarii principale, input/output, retelistica si securitate sunt subiectele primare adresate. Aceasta specificatie este rezultatul colaborarii grupului de experti JSR-30 desemnati de JCP, format din mai multi parteneri ai industriei.

Urmatoarele companii au fost implicate in definirea CLDC:

– America Online

– Bull

– Ericsson

– Fujitsu

– Matsushita

– Mitsubishi

– Motorola

– Nokia

– NTT DoCoMo

– Oracle

– Palm Computing

– RIM

– Samsung

– Sharp

– Siemens

– Sony

– Sun Microsystems

– Symbian

Unul din principalele benificii ale tehnologiei Java in spatiul dispozitivelor mici este livrarea dinamica si securizata de aplicatii interactive printr-o gama variata de retele catre dispozitive client. Spre deosebire de trecut, cand majoritatea telefoanelor celulare sau pagere erau livrate cu un set de particularitati standard care nu puteau fi modificate, producatorii de dispozitive erau din ce in ce mai interesati sa gaseasca solutii care sa le permita sa construiasca aparate extensibile care sa suporte un continut bogat, dinamic si interactiv pus la dispozitie de furnizori sau dezvoltatori terti. Prin introducerea telefoanelor mobile capabile sa se conecteze la Internet, aceasta tranzitie era deja in parcurs. Unul din principalele scopuri ale specificatiei CLDC era sa grabeasca aceasta tranzitie prin permiterea folosirii limbajului de programare Java ca platforma standard pentru livrarea securizata de continut dinamic pentru aceste dispozitive extensibile de generatie noua.

Specificatia include doar librarii de nivel inalt care ofereau suficienta putere de programare dezvoltatorilor de aplicatii. De exemplu, API-urile de retelistica incluse in CLDC permiteau programatorului sa foloseasca abstractii de nivel inalt, cum ar fi posibilitatea de a transfera fisiere intregi, aplicatii sau chiar pagini web, fara sa fie necesar ca acesta sa cunoasca detaliile diferitelor protocoale de transmitere a datelor in retea. Apoi, se punea emfaza pe generalitate si portabilitate, adica nu se lua in considerare doar un anumit tip de dispozitiv sau o anumita nisa de piata.

Cerinte hardware

CLDC era intentionat sa ruleze pe o varietate larga de aparate mici, de la telefoane mobile, la celulare, la organizatoare personale, pana la terminale de vanzare si electronice casnice. Capabilitatile hardware ale fiecarui dispozitiv variaza considerabil, si astfel specificatia nu impunea alte cerinte hardware decat legate de memorie. Se presupunea ca masina virtuala, librariile de configuratie, librariile de profil si aplicatiile in sine trebuie toate sa se incadreze intr-un buget de memorie intre 160-512 kilobytes.

Mai specific:

– 128 kilobytes de memorie nevolatila sunt disponibili pentru masina virtuala Java si librariile CLDC

– cel putin 32 kilobytes de memorie volatila sunt disponibili pentru Java runtime si memorarea obiectelor.

Termenul nevolatil este folosit pentru a arata ca memoria trebuie sa retina continutul sau intre opriri si porniri ale telefonului de catre utilizator. Se presupune ca memoria nevolatila este accesata in mod obisnuit in read mode, iar pentru a o scrie este nevoie de setari speciale.

Termenul volatil este folosit pentru a arata ca memoria nu trebuie sa retina continutul sau intre opriri si porniri ale telefonului. Se presupune ca memoria volatila poate fi scrisa sau citita direct, fara alte setari speciale.

In general, specificatia presupunea existenta unui sistem de operare gazda sau a unui kernel disponibil pentru a gestiona hardware-ul subiacent. Acest sistem de operare trebuie sa puna la dispozitie cel putin o entitate planificabila care sa ruleze masina virtuala Java, dar care nu este necesar sa suporte spatii de adresare sau procese separate, nici nu este necesar sa garanteze comportamentul planificarii in timp real sau al latentei.

Cerinte J2ME

CLDC este definit ca o configuratie a J2ME. Acest lucru are anumite implicatii pentru specificatia CLDC:

– o configuratie a J2ME va defini doar complementul minim sau “cel mai mic numitor comun” al tehnologiei Java. Toate caracteristicile incluse intr-o configuratie trebuie sa fie in general aplicabile unei varietati largi de dispozitive. Detaliile specifice unei anumite nise de piata, sau unei categorii de dispozitive trebuiesc definite intr-un profil, nu in CLDC. Acest lucru inseamna ca sfera CLDC este limitata si in general trebuie complementata de profiluri.

– din moment ce scopul configuratiei este de a garanta portabilitate si interoperabilitate intre diverse tipuri de dispozitive restranse din punct de vedere al resurselor, configuratia nu va contine sau defini elemente optionale. Aceasta limitare are un impact semnificativ asupra a ceea ce poate fi inclus in configuratie. Functionalitatea specifica unui anumit domeniu trebuie definita de profiluri nu de CLDC.

Se observa faptul ca absenta elementelor optionale in CLDC nu impiedica punerea in folosinta a diferitelor optimizari la nivel de implementare. Spre exemplu, la nivel de implementare se pot folosi tehnici de executare alternative (compilarea JIT) sau tehnici de reprezentare a claselor, atata timp cat semantica observabila la nivel de utilizator a implementarii ramane aceeasi cu cea definita de specificatia CLDC.

Grupul de experi JSR-30 a decis abordarea si rezolvarea urmatoarelor puncte de interes:

– caracteristici ale limbajului Java si ale masinii virtuale

– librarii nucleu ale Java (java.lang.*, java.util.*)

– input/output

– retelistica

– securitate

– internationalizare

Urmatoarele probleme nu au fost adresate de specificatia CLDC:

– monitorizarea ciclului de viata al aplicatiilor (instalare, lansare, stergere)

– functionalitatea interfata utilizator (UI)

– tratarea evenimentelor

– model aplicational de nivel inalt (interactiunea dintre utilizator si aplicatie)

Acestea urmau a fi adresate de profiluri implementate deasupra CLDC-ului.

Arhitectura de nivel inalt si securitatea

Arhitectura de nivel inalt tipica CLDC-ului este ilustrata in figura 3:

Figura 3: Arhitectura high-level

La centrul implementarii CLDC este masina virtuala Java, care, in afara de diferente specifice pe care le voi mentiona mai tarziu, este in conformitate cu standardul Java. Masina virtuala in mod tipic ruleaza deasupra sistemului de operare gazda care este in afara sferei CLDC.

Deasupra masinii virtuale rezida librariile Java. Aceste librarii se impart in doua categorii:

– cele definite de CLDC

– cele definite de profiluri.

Gestiunea aplicatiilor

Multe dispozitive mici, constranse din punct de vedere al resurselor nu au file system sau un alt mecanism standard pentru memorarea informatiilor descarcate dinamic prin download. Din acest motiv, o implementare CLDC nu necesita memorarea persistenta a claselor Java descarcate pe telefon dintr-o sursa externa. Mai curand, masina virtuala poate doar sa incarce fisierele clasa si sa le arunce dupa incarcare.

Totusi, pe multe dispozitive CLDC este potential benefica abilitatea de a executa aceeasi aplicatie Java de mai multe ori fara sa fie nevoie descarcarea aplicatiei de fiecare data. Acest lucru este cu adevarat important daca aplicatiile sunt descarcate printr-o retea wireless, unde costurile de download pot fi ridicate.

Se presupune ca un dispozitiv care implementeaza CLDC are capabilitati de gestionare a aplicatiilor Java care au fost memorate pe dispozitiv. La nivel inalt, gestiunea aplicatiilor se refera la abilitatea de a:

– inspecta aplicatii Java existente pe dispozitiv

– selecta si lansa aplicatii Java

– sterge aplicatii Java

Datorita variatiilor semnificative in caracteristici a potentialelor dispozitive CLDC, detaliile gestiunii aplicatiilor sunt dependente de implementare si specifice. In consecinta, capabilitatile de gestiune a aplicatiilor sunt adesea programate in limbajul C sau alte limbaje de programare low-level specifice sistemului de operare gazda. Detaliile privind gestiunea aplicatiilor depasesc sfera specificatiei CLDC.

Securitate

Una din marile promisiuni ale platformei Java este abilitatea de a livra in mod dinamic aplicatii si continut interactiv intr-un mod securizat catre dispozitive client prin diferite tipuri de retele.

Din nefericire, cantitatea totala de cod devotata securitatii in J2SE depaseste cu mult bugetul de memorie disponibil masinii virtuale Java care suporta CLDC. Astfel, o serie de compromisuri sunt necesare in definirea modelului de securitate pentru CLDC. Intentia generala a fost de a simplifica lucrurile si de a permite adaugarea de solutii de securitate cuprinzatoare in versiuni ulterioare ale specificatiei CLDC.

Centrul atentiei s-a pastrat pe doua arii principale:

– securitate de nivel jos pentru masina virtuala

– securitate la nivel de aplicatie

Securitate low-level pentru masina virtuala

In aceasta specificatie, securitate low-level pentru masina virtuala inseamna ca o aplicatie Java executata de masina virtuala nu trebuie sa fie capabila sa dauneze dispozitivului pe care ruleaza. In implementarea standard a masinii virtuale Java, aceasta constrangere este garantata de verificatorul de fisiere clasa, care asigura ca bytecode-ul Java si alte elemente memorate in fisiere clasa Java, nu pot contine referinte la zone invalide de memorie sau zone de memorie care sunt in afara memoriei obiectelor Java (heap-ul Java). Rolul verificatorului de fisiere clasa este de a asigura executarea corecta a claselor incarcate in masina virtuala.

Dupa cum voi explica mai tarziu mai in detaliu, specificatia CLDC impune o JVM capabila sa respinga fisiere clasa invalide. Aceasta poate fi garantata folosind tehnologia de verificare definita mai jos.

Securitate la nivel de aplicatie

Chiar si intr-un mediu Java standard, securitatea oferita de verificatorul de fisiere clasa este limitata. Verificatorul poate doar sa garanteze ca un anumit program este un program Java valid, si nimic mai mult. Totusi, exista alte pericole potentiale de securitate, care vor trece neobservate de verificator. De exemplu, accesul la resurse externe cum ar fi file system-ul, imprimante, dispozitive cu infrarosu sau la retea este dincolo de sfera verificatorului.

Pentru a oferi acces controlat la resurse externe pentru aplicatiile Java, J2SE si J2EE pun la dispozitie conceptul de administrator de securitate. Un administrator de securitate este apelat ori de cate ori diverse parti ale aplicatiei Java sau ale Java runtime au nevoie sa acceseze resurse protejate. J2SE ofera un model cuprinzator de securitate constand in notiuni formale de permisiuni, controlori de acces, si politici de securitate.

Din nefericire, modelul de securitate al J2SE consuma prea multa memorie pentru a putea fi inclus pe un dispozitiv CLDC care dispune de doar cateva sute de kilobytes de memorie. De aceea, este nevoie de o solutie mai simpla.

Modelul sandbox (cutie de nisip)

O JVM care suporta CLDC pune la dispozitie un model simplu de securitate de tip sandbox . Prin sandbox, ne referim la faptul ca o aplicatie Java trebuie sa ruleze intr-un mediu inchis in care aplicatia are voie sa acceseze doar acele API-uri care au fost definite de configuratie, profiluri si clase licentiate deschise suportate de dispozitiv.

Mai specific, modelul presupune urmatoarele:

– fisierele clasa Java au fost verificate corespunzator si sunt garantate a fi aplicatii Java valide.

– doar un set limitat, predefinit de API-uri Java sunt disponibile programatorului de aplicatii, dupa cum sunt definite de CLDC, profiluri si clase licentiate deschise.

– descarcarea si gestionarea aplicatiilor Java pe dispozitiv are loc la nivel de cod nativ in interiorul masinii virtuale, si nici un fel de incarcator de clase definit de utilizator este disponibil, pentru a preveni programatorul sa suprascrie mecanismele standard ale masinii virtuale de incarcare a claselor.

– setul de functii native accesibile masinii virtuale este inchis, adica, programatorul de aplicatii nu poate descarca librarii noi care contin functionalitate nativa, si nu poate accesa functii native care nu fac parte din librariile oferite de CLDC, profiluri sau alte clase licentiate deschise.

Profilurile J2ME pot pune la dispozitie solutii de securitate aditionale. Profilurile definesc, de asemenea, ce API-uri aditionale sunt disponibile programatorului de aplicatie.

O cerinta importanta a CLDC este abilitatea de a suporta descarcarea dinamica a aplicatiilor Java pe masina virtuala. O bresa evidenta de securitate ar fi expusa daca aplicatiile descarcate ar putea suprascrie clasele sistem oferite in pachetele java.*, javax.microedition.*, sau alte pachete specifice profilului sau sistemului. O implementare a CLDC se va asigura ca programatorul nu poate suprascrie aceste clase prin nicio metoda. La nivelul de implementare, aceasta poate fi garantata in mai multe moduri, depinzand de suportul pentru preincarcare a claselor sistem. O solutie este de a impune cautarea claselor sistem mereu la inceput. De asemenea, se impune ca programatorului de aplicatii sa nu ii fie permisa manipularea cautarii claselor in niciun mod.

Suport pentru rularea simultana a multiple aplicatii Java

In functie de resursele dispozitivului, un sistem CLDC poate permite executare concurenta a multiple aplicatii Java, sau poate restrictiona sistemul sa permita executarea unei singure aplicatii la un moment dat. Este la latitudinea implementarii sa decida suportul pentru executia concurenta prin folosirea capabilitatilor de multitasking ale sistemului de operare gazda sau prin instantierea de multiple masini virtuale logice pentru a rula aplicatiile Java concurente.

Alte probleme de securitate

Un dispozitiv care suporta CLDC este in mod tipic componenta a unei solutii end-to-end cum e o retea wireless sau o retea de terminale de plata. Aceste retele necesita in mod normal un numar de solutii avansate de securitate pentru a asigura securitatea livrarii datelor si a codului intre masinile server si dispozitivele client. Acestea sunt dependente de implementare si in afara sferei specificatiei CLDC.

Aderenta la specificatia limbajului Java

Scopul general al unei JVM care suporta CLDC este de a fi cat mai in conformitate cu standardul Java pe cat este fezabil limitelor stricte de memorie definite mai sus. Voi prezenta diferentele.

Nu exista suport pentru numere cu virgula mobila (floating point)

Principala diferenta la nivel de limbaj este ca o JVM care suporta CLDC nu are suport pentru virgula mobila. Acesta a fost eliminat pentru ca majoritatea dispozitivelor tinta CLDC nu au suport hardware pentru virgula mobila, si din cauza ca supracostul implementarii software este prea ridicat. Ca urmare, o JVM care suporta CLDC nu va permite folosirea literalilor in virgula mobila, tipurile si valorile cu virgula mobila sau operatiile de acest gen.

Nu exista finalizare

Librariile CLDC nu includ metoda Object.finalize(), si deci o JVM care suporta CLDC nu va suporta finalizarea instantelor de clasa. Nicio aplicatie construita pe o JVM care suporta CLDC nu va impune disponibilitatea finalizarii.

Limitari in tratarea erorilor

In general, CLDC suporta tratarea exceptiilor dupa standardul Java. Totusi, setul de clase de eroare inclus in librariile CLDC este limitat, in consecinta capabilitatile de tratare a erorilor sunt restrictionate. Aceasta din doua motive:

– pe sistemele integrate, revenirea din conditiile de eroare este foarte specifica dispozitivului. In timp ce unele dispozitive integrate pot incerca sa revina din conditii serioase de eroare, multe dispozitive pur si simplu isi reseteaza softul la intalnirea unei erori. Programatorul de aplicatii nu trebuie sa cunoasca mecanismele si conventiile de tratare a erorilor specifice dispozitivului.

– dupa cum este specificat in standardul Java, clasa java.lang.Error si subclasele ei sunt exceptii din care programelor nu li se cere sa revina. Implementarea tratarii erorilor in concordanta totala cu specificatia Java este destul de costisitoare si tratarea tuturor claselor de eroare ar presupune costuri suplimentare semnificative asupra implementarii, avand in vedere constrangerile de memorie.

Se impune doar suport pentru un numar limitat de erori. La intalnirea unei alte erori, implementarea va trata eroarea intr-un mod corespunzator dispozitivului.

Elemente eliminate din cauza schimbarii librariilor sau a preocuparii pentru securitate.

Un numar important de trasaturi au fost eliminate din JVM pentru ca librariile Java incluse in CLDC sunt limitate in mod substantial fata de librariile standard ale J2SE, sau prezenta elementului ar fi pus probleme de securitate in absenta intregului model de securitate standard. Elementele eliminate includ:

– interfata nativa Java (JNI)

– inacarcatoare de clase definite de utilizator

– relfectia

– grupuri de thread-uri si thread-uri daemon.

– finalizarea

– referinte slabe

Aplicatiile scrise pentru CLDC nu trebuie sa se bazeze pe nici unul din elementele de mai sus.

Interfata nativa Java

Felul in care masina virtuala invoca functionalitate nativa este dependent de implementare. Suportul pentru JNI a fost eliminat in principal din doua motive:

1. modelul de securitate limitat al CLDC presupune ca setul de functii native este inchis.

2. implementarea in totalitate a JNI a fost considerata prea costisitoare din punct de vedere al memoriei necesare.

Incarcatoare de clasa definite de utilizator

CLDC impune un incarcator de clase integrat care nu poate fi suprascris, inlocuit sau reconfigurat de catre utilizator. Implementarea incarcarii claselor si orice conditii de eroare intalnite in timpul incarcarii claselor sunt dependente de implementare. Acest lucru face parte din restrictiile impuse de modelul de securitate sandbox.

Reflectia

Elementele de reflectie, adica elementele care permit un program Java sa inspecteze numarul si continutul claselor, obiectelor, metodelor, membrilor, thread-urilor, stivelor de executie si a altor structuri runtime inauntrul masinii virtuale. O aplicatie Java construita pe CLDC nu se va baza pe capabilitati care necesita abilitati de reflectie. In consecinta, nu se suporta serializarea obiectelor, JVMDI (interfata de debug), JVMPI (interfata de profiler) sau alte capabilitati avansate ale J2SE care depind de prezenta reflectiei.

Grupuri de thread-uri sau thread-uri daemon

CLDC necesita implementarea multithreading, dar nu va suporta grupuri de thread-uri sau thread-uri daemon. Operatiile pe thread-uri, cum ar fi pornirea sau oprirea lor pot fi efectuate doar asupra thread-urilor obiect individuale. Daca programatorii de aplicatii doresc operatii pe grupuri de thread-uri, se pot folosi colectii explicite de obiecte la nivel de aplicatie pentru a memora obiectele thread.

Referinte slabe

S-a exclus suportul pentru referinte slabe. Nicio aplicatie construita pentru CLDC nu va impune disponibilitatea referintelor slabe.

Verificarea fisierelor clasa

Ca orice masina virtuala Java standard, o JVM care suporta CLDC trebuie sa fie capabila sa respinga fisiere clasa invalide. Totusi, din moment ce amprenta asupra memoriei statice si dinamice a unui verificator standard este excesiva pentru un dispozitiv tipic CLDC, o solutie mai compacta si eficienta penru verificare a fost specificata. Descrierea se gaseste mai jos.

Preverificare in afara dispozitivului si verificare runtime cu stack map-uri

Verificatorul de fisiere clase standard existent pentru platforma J2SE nu este ideal pentru dispozitive mici, restranse din punct de vedere al resurselor. Verificatorul J2SE ocupa un minimum de 50 kB spatiu de cod binar si cel putin 30-100 kB de RAM dinamic la runtime. In plus, puterea CPU necesara pentru a executa algoritmul iterativ de dataflow al verificatorului conventional poate fi substantiala.

Abordarea verificarii descrisa in aceasta sectiune este semnificativ redusa si mai eficienta pentru un dispozitiv constrans din punct de vedere al resurselor. Implementarea noului verificator din KVM-ul Sun are nevoie doar de 10 kilobytes de cod binar Intel x86 si mai putin de 100 bytes de memorie dinamica RAM la runtime pentru fisiere clasa tipice. Verificatorul executa doar o parcurgere liniara a codului, fara nevoia unui algoritm iterativ de dataflow costisitor.

Noul verificator impune fisierelor clasa Java sa contina un atribut special. Acesta include o unealta de preverificare care insereaza acest atribut in fisiere clasa normale. O clasa transformata este in continuare o clasa valida J2SE, cu atribute aditionale care permit verificarea eficienta la runtime. Aceste atribute sunt ignorate automat de verificatorul conventional, deci solutia este compatibila in sus cu masina virtuala J2SE. Fisierele clasa preprocesate continand atributele aditionale sunt aproximativ cu 5% mai mari decat originalul nemodificat.

Verificarea bytecode la runtime asigura siguranta tipurilor. Clasele care trec de verificator nu pot, spre exemplu, sa violeze sistemul de tipuri al masinii virtuale Java si sa corupa memoria. Spre deosebire de abordari bazate pe semnarea codului, o astfel de garantie nu se bazeaza pe atutenticitatea sau credibilitatea atributului de verificare. Un atribut lipsa, corupt sau incorect cauzeaza respingerea clasei de catre verificator.

Procesul de verificare

Noul verificator de fisiere clasa opereaza in doua faze: 1) preverificarea si 2) verificarea pe dispozitiv. Preverificarea are loc in general in afara dispozitivului tinta, spre exemplu, pe un server de unde aplicatii Java sunt descarcate, sau pe statia de lucru pe care se dezvolta noi aplicatii. Verificarea se face pe dispozitivul care contine masina virtuala. Verificatorul se foloseste de informatia generata de unealta de preverificare.

Definitia procesului de verificare este urmatoarea:

– Faza 1: preverificarea (in afara dispozitivului)

Unealta de preverificare pusa la dispozitie cu noul verificator executa urmatoarele doua operatii:

– toate subrutinele sunt transformate inline si tot bytecode-ul de tipul jsr, jsr_w, ret si wide ret este eliminat. Fiecare metoda care contine aceste instructiuni este inlocuita cu bytecode echivalent semantic care sa nu contina aceste instructiuni.

– adauga atribute speciale stack map in fisiere clasa pentru a facilita verificarea runtime. Formatul si semantica atributului stack map sunt definite mai jos.

– Faza 2: verificarea (pe dispozitiv)

Algoritmul de verificare pe dispozitiv consta din urmatorii pasi:

– in primul rand, verificatorul aloca suficienta memorie pentru retinerea tipurilor tuturor variabilelor locale si elementele operand de pe stiva ale unei anumite metode. Dimensiunea memoriei este determinata de numarul maxim de variabile locale si de adancimea maxima specifiata in atributul Code. Aceasta zona de memorie va fi folosita pentru a retine tipurile derivate in timp ce verificatorul parcurge liniar bytecode-ul. Aceasta este singura bucata de memorie alocata de verificator.

– in al doilea rand, verificatorul intializeaza tipurile derivate sa fie de tipul pointer-ului this pentru metode de instanta, tipuri de argumente si o stiva pentru operanzi goala.

– in al treilea rand, verificatorul itereaza liniar prin fiecare instructiune. Pentru fiecare instructiune se executa:

– daca instructiunea anterioara este ori un salt neconditionat (goto), ori o revenire (ireturn), athrow, tableswitch, sau lookupswitch, nu exista flux de control direct de la instructiunea anterioara. Verificatorul ignora tipurile derivate curente si seteaza tipurile derivate conform inregistrarii stack map corespunzatoare instructiunii curente. Daca instructiunea curenta nu are inregistrare corespunzatoare verificatorul raporteaza o eroare.

– daca instructiunea anterioara nu este un salt neconditionat (goto), ori o revenire (ireturn), athrow, tableswitch, sau lookupswitch, exista flux de control direct de la instructiunea anterioara. Verificatorul verifica daca exista inregistrare stack map corespunzatoare instructiunii curente. Daca exista, verificatorul incearca potrivirea tipurilor derivate cu inregistrarea. Daca tipurile retinute sunt mai putin generale decat tipurile derivate, atunci tipurile derivate sunt setate la tipurile retinute. In caz contrar, verificatorul raporteaza o eroare.

– daca instrunctiunea curenta este in scopul unui handler de exceptii, tipurile derivate sunt potrivite cu inregistrarea stack map corespunzatoare offset-ului bytecode al handler-ului de exceptie. In caz contrar, se raporteaza o eroare.

– verificatorul apoi incearca sa potriveasca tipurile derivate cu ceea ce presupune instructiunea. Intstructiunea iadd, spre exemplu, se asteapta ca primii doi operanzi de pe stiva sa fie intregi. Tipurile derivate sunt apoi modificate in conformitate cu ceea ce face instructiunea. Intstructiunea iadd, spre exemplu, scoate doi intregi de pe stiva si impinge un intreg rezultat pe stiva operanzilor.

– in final, verificatorul incearca sa potriveasca tipurile derivate cu orice inregistrare stack map retinuta pentru orice instructiune succesor care nu urmeaza direct instructiunea curenta.

In final, verificatorul se asigura ca ultima instructiune din metoda e un salt neconditionat (goto), ori o revenire (ireturn), athrow, tableswitch, sau lookupswitch, altfel raporteaza o eroare de verificare.

Formate de fisiere suportate

Se presupune ca o implementare CLDC este capabila sa citeasca fisiere clasa Java standard cu modificarile de preverificare specifiate mai sus. In plus, trebuie sa se suporte fisiere de tip arhiva compresata Java (JAR). Aceasta cerinta a fost adaugata pentru a mentine compatibilitate in sus cu medii Java mai extinse si unelte Java existente, dar cu o amprenta mai mica decat fisiere clasa obisnuite.

In general, conservarea limitelor de transfer este foarte importanta in retelele wireless. Formatul compresat JAR ofera o compresie de 30-50% fata de fisiere clasa obisnuite, fara pierderea de informatii simbolice sau probleme de compatibilitate cu sistemele Java existente.

O aplicatie Java este considerata a fi “reprezentata public” sau “distrubuita public” cand sistemul pe care este retinuta este deschis publicului, si protocoalele si nivelele de transport cu care poate fi accesata sunt standarde deschise. In contrast, un dispozitiv poate face parte dintr-un singur sistem inchis la retea. In acest caz, aplicatia nu mai este reprezentata public.

Ori de cate ori aplicatii Java pentru platforma CLDC sunt reprezentate public, trebuie folosit formatul compresat JAR. Fisierul JAR trebuie sa contina fisiere clasa Java standard. Aditional, arhiva poate sa contina fisiere resursa specifice aplicatiei care pot fi incarcate in masina virtuala prin apel la metoda Class.getResourceAsStream(String name).

Librarii CLDC

Platformele Java J2EE si J2SE pun la dispozitia programatorului un set bogat de librarii pentru dezvoltarea aplicatiilor de antrepriza pentru PC-uri sau masini servere. Din nefericire, aceste librarii au nevoie de cativa megabytes de memorie pentru a putea fi rulate, deci nu sunt potrivite pentru dispozitive mici cu resurse restranse.

Scopul general al proiectarii librariilor pentru CLDC a fost punerea la dispozitie a unui minimum folositor de librarii pentru dezvoltarea practica de aplicatii si definirea profilurilor pentru o varietate mare de aparate mici. Avand in vedere constrangerile stricte de memorie si diferitele particularitati ale dispozitivelor, este practic imposibil gasirea unui set de librarii care sa satisfaca nevoile tuturor. Oricat de jos ar fi trasa linia pentru includerea elementelor in librarie, aceasta va fi inevitabil prea jos pentru unele dispozitive si utilizatori si mult prea sus pentru altii.

In definirea sferei librariilor, grupul de experti JSR-30 s-a pornit de la specificatia standard Java cu un plus de atentie pentru conectivitate. Acest lucru inseamna ca in afara de tipurile de date si sistemul fundamental, librariile CLDC ar trebui sa includa un set extensibil de elemente de retelistica pentru dispozitive conectate.

Compatibilitate

Majoritatea librariilor incluse in CLDC sunt un subset ale editiilor mai extinse (J2SE si J2EE) pentru a asigura compatibilitatea in sus si portabilitatea aplicatiilor. Desi compatibilitatea in sus este un scop foarte de dorit, librariile J2SE si J2EE prezinta dependinte interne puternice, deci subsetarea lor devine dificila in arii importante cum ar fi securitate, input/output, definitii de interfata utilizator, retelistica si memorare a datelor. Aceste dependinte sunt o consecinta naturala a evolutiei si reutilizarii in proiectarea librariilor Java de-a lungul timpului. Din nefericire, aceste dependinte fac foarte dificila includerea unei parti a librariilor fara includerea altora. Din acest motiv unele librarii au fost reproiectate, in special cele din zona retelisticii si a I/O.

Librariile prezente in specificatia CLDC pot fi separate in doua categorii:

– acele clase care sunt un subset ale standardului J2SE

– acele clase care sunt specifice CLDC-ului (dar care pot fi schitate pe J2SE)

Clasele din prima categorie rezida in pachetele java.lang.*, java.util.*, si java.io.*. Aceste clase au fost derivate din J2SE versiunea 1.3.

Clasele din a doua categorie rezida in pachetul javax.microedition.*

Clase mostenite de la J2SE

Regulile pentru configuratiile J2ME impun ca orice clasa care are acelasi nume si acelasi nume de pachet cu o clasa J2SE trebuie sa fie identica sau un subset al clasei J2SE corespunzatoare. Semantica clasei si a metodelor sale incluse in subset nu trebuie modificata. Clasele nu vor adauga metode sau membri cu tipul de acces public sau protected care nu sunt disponibile si in clasele J2SE corespunzatoare.

Clase sistem

Librariile J2SE includ un numar de clase care sunt in stransa legatura cu masina virtuala Java. Similar, un numar de unelte presupun prezenta unor clase sistem. De exemplu, compilatorul Java J2SE (javac) genereaza cod care presupune prezenta anumitor functii ale claselor String si StringBuffer. Urmatoarele clase sistem au fost incluse:

java.lang.Object

java.lang.Class

java.lang.Runtime

java.lang.System

java.lang.Thread

java.lang.Runnable (interfata)

java.lang.String

java.lang.StringBuffer

java.lang.Throwable

Clase tipuri de data

Urmatoarele clase tipuri de data de baza din pachetul java.lang.* sunt suportate. Fiecare din ele este un subset al claselor corespunzatoare J2SE:

java.lang.Boolean

java.lang.Byte

java.lang.Short

java.lang.Integer

java.lang.Long

java.lang.Character

Clase colectie

Urmatoarele clase colectie din pachetul java.lang.* sunt suportate:

java.util.Vector

java.util.Stack

java.util.Hashtable

java.util.Enumeration (interfata)

Clase I/O

Urmatoarele clase din pachetul java.io.* sunt suportate. Clasele Reader, Writer, InputStreamReader si InputStreamWriter sunt necesare pentru suportul pentru internationalizare:

java.io.InputStream

java.io.OutputStream

java.io.ByteArrayInputStream

java.io.ByteArrayOutputStream

java.io.DataInput (interfata)

java.io.DataOutput (interfata)

java.io.DataInputStream

java.io.DataOutputStream

java.io.Reader

java.io.Writer

java.io.InputStreamReader

java.io.OutputStreamWriter

java.io.PrintStream

Clase calendar si timp

CLDC include un subset redus al acestor clase standard J2SE. Este suportata o singura zona de timp. Zone de timp aditionale pot fi incluse la nivel de implementare:

java.util.Calendar

java.util.Date

java.util.TimeZone

Clase utilitare aditionale

Clasa java.util.Random ofera o metoda simpla de a genera numere pseudo-aleatoare utila pentru logica unor aplicatii ca jocurile. Clasa java.lang.Math ofera metodele min, max si abs (pentru tipurile de date int si long) folosite frecvent de clasele librariilor Java.

Clasele exceptie si eroare

Din moment ce librariile incluse in CLDC au intentia de a fi cat mai compatibile cu librariile J2SE, clasele vor arunca exact aceleasi exceptii pe care le arunca cele J2SE. In consecinta, un set comprehensiv de clase de execeptii a fost inclus.

In contrast, dupa cum a fost discutat mai sus, capabilitatile de tratare a erorilor ale CLDC sunt limitate, deci sunt impuse doar suportarea erorilor listate mai jos:

java.lang.Exception

java.lang.ClassNotFoundException

java.lang.IllegalAccessException

java.lang.InstantiationException

java.lang.InterruptedException

java.lang.RuntimeException

java.lang.ArithmeticException

java.lang.ArrayStoreException

java.lang.ClassCastException

java.lang.IllegalArgumentException

java.lang.IllegalThreadStateException

java.lang.NumberFormatException

java.lang.IllegalMonitorStateException

java.lang.IndexOutOfBoundsException

java.lang.ArrayIndexOutOfBoundsException

java.lang.StringIndexOutOfBoundsException

java.lang.NegativeArraySizeException

java.lang.NullPointerException

java.lang.SecurityException

java.util.EmptyStackException

java.util.NoSuchElementException

java.io.EOFException

java.io.IOException

java.io.InterruptedIOException

java.io.UnsupportedEncodingException

java.io.UTFDataFormatException

java.lang.Error

java.lang.VirtualMachineError

java.lang.OutOfMemoryError

Internationalizare

CLDC include suport limitat pentru traducerea caracterelor Unicode din si in secvente de bytes. In J2SE acest lucru se realizeaza folosind obiecte de tip Reader si Writer, iar acelasi mecanism este folosit aici cu ajutorul claselor InputStreamReader si OutputStreamWriter cu constructori identici:

new InputStreamReader(InputStream is);

new InputStreamReader(InputStream is, String name);

new OutputStreamWriter(OutputStream os);

new OutputStreamWriter(OutputStream os, String name);

In cazurile in care parametrul string este prezent acesta reprezinta numele encoding-ului care trebuie folosit. Unde nu este prezent, se foloseste encoding-ul default. Convertori aditionali pot fi pusi la dispozitie de anumite implementari. Daca un convertor pentru un anumit encoding nu este disponibil, se arunca exceptia UnsupportedEncodingException.

CLDC nu include elemente specifice de localizare. Acest lucru inseamna ca solutiile relative la formatarea datelor, timpului, monetare si altele sunt in afara sferei CLDC.

Suport pentru proprietati

CLDC nu implementeaza clasa java.util.Properties componenta a J2SE. Totusi, un set limitat de proprietati poate fi accesat prin metoda System.getProperty(String key).

Profilele pot defini si alte propretati care nu sunt incluse in CLDC.

Clase specifice CLDC

Librariile J2SE si J2EE ofera o functionalitate bogata pentru acces input si output pe memoria persistenta sau sisteme de retea. Pachetul J2SE java.io.* contine aproximativ 60 de clase si interfete si peste 15 clase exceptie. Pachetul J2SE java.net.* contine aproximativ 20 de clase si 10 clase exceptie. Marimea memoriei statica ocupate de aceste fisiere clasa este de aproape 200 de kilobytes. Este foarte dificila introducerea acestora pe un dispozitiv cu un buget de memorie de doar cateva sute de kilobytes. In plus, o buna parte a functionalitatii standard I/O si de conectivitate nu este aplicabila dispozitivelor mici, care au nevoie adesea de suport pentru conexiuni de tip infrarosu sau Bluetooth sau nu au suport pentru TCP/IP.

In general cerintele pentru librariile de conectivitate variaza semnificativ de la un dispozitiv cu resurse restranse la altul. Datorita limitarilor stricte de memorie, producatorii de aparate care suporta un anumit tip de conectivitate sau anumite tipuri de capabilitati I/O, in general, nu doresc sa suporte alte mecanisme. Toate acestea fac proiectarea facilitatilor CLDC foarte dificila, mai ales cand configuratiile CLDC nu au voie sa defineasca elemente optionale.

De asemenea, prezenta mai multor mecanisme si protocoale de retea pot produce probleme programatorului de aplicatii, in special daca acesta are de a face cu protocoale low-level.

Generic Connection framework (GCF)

Cerinta pentru sisteme cu amprenta mica pe dispozitive cu resurse restrictionate pentru J2ME, a dus la generalizarea claselor de retea si de I/O ale J2SE. Scopul general al acestui sistem este de a fi un subset functional precis al claselor J2SE care poate fi pus peste hardware low-level comun sau peste orice implementare J2SE, dar cu extensibilitate, flexibilitate si coerenta mai bune in a suporta noi dispozitive si protocoale.

Ideea generala este ilustrata mai jos. In loc sa se foloseasca o colectie de abstractii total diferite pentru forme de comunicare diferite, se introduce un set de abstractii corelate care sa fie folosite la nivel de programare a aplicatiilor.

Forma generala

Toate conexiunile sunt create apeland o singura metoda statica din clasa sistem Connector. Daca apelul este cu succes, metoda intoarce un obiect care implementeaza una din interfetele generale de conexiune. Sunt un numar de interfete care formeaza o ierarhie care are la radacina interfata Connection. Metoda primeste ca parametru un string sub forma generala:

Connector.open("<protocol>:<address>;<parameters>");

Sintaxa acestor string-uri suporta in general sintaxa Uniform Resource Indicator (URI) dupa cum este definita in standardul RFC2396 al IETF.

HTTP

Connector.open("http://www.fmi.ro");

Sockets

Connector.open("socket://129.144.111.222:9000");

Communication ports

Connector.open("comm:0;baudrate=9600");

Datagrams

Connector.open("datagram://129.144.111.333");

Files

Connector.open("file:/fmi.dat");

Un obiectiv central al proiectarii este sa izoleze pe cat posibil diferentele dintre protocoale intr-un string care sa caracterizeze tipul de conexiune. Acest string este parametrul catre Connector.open(). Un avantaj important al acestei abordari este ca marea parte a codului de aplicatie ramane acelasi indiferent de tipul conexiunii. Aceast lucru este diferit fata de implementarile traditionale, in care abstractiile folosite in interiorul aplicatiilor se modifica semnificativ in momentul schimbarii formei de comunicare.

Determinarea protocoalelor unui program J2ME se face la runtime. La nivelul implementarii, stringul pasat ca parametru (pana la aparatie primului caracter ':' ) cere sistemului sa obtina implementarea de protocol dorita din locatia in care se gasesc toate implementarile de protocol. Acest mecanism de late binding permite unui program sa se adapteze dinamic la runtime diferitelor protocoale.

Generic Connection framework inclus in CLDC nu specifica protocoalele care trebuie suportate si nici nu include implementari pentru protocoale specifice. Deciziile asupra protocoalelor incluse si asupra implementarilor se fac la nivel de profil.

Proiectarea Generic Connection framework

Conexiunile la diferite tipuri de aparate vor manifesta diferite tipuri de comportament. Generic Connection framework reflecta aceste capabilitati diferite, asigurand faptul ca operatiile care sunt din punct de vedere logic aceleasi impart acelasi API.

Noul framework este implementat folosind o ierarhie de interfete Connection care grupeaza la un loc clase de protocoale cu aceeasi semantica. Aceasta ierarhie contine sapte interfete. Aditional exista clasa Connector, o clasa exceptie, o alta interfata si un numar de clase de suvoi (stream) de date pentru citirea si scrierea datelor. La nivel de implementare, un minim de o clasa este nevoie pentru a suporta un anumit protocol. Adesea, fiecare implementare de protocol contine doar niste functii wrapper care apeleaza functiile native ale sistemului de operare subiacent.

Exista sase tipuri de interfete adresate de Generic Connection framework:

un dispozitiv de baza de input serial

un dispozitiv de baza de output serial

un dispozitiv de comunicare orientat pe datagrama

un dispozitiv de comunicare orientat pe circuit

un mecanism de notificare a unui server in legatura cu conexiuni de tip client-server

o conexiune de baza Web server.

Colectia de interfete Connection formeaza o ierarhie care devine progresiv mai capabila cu cat se indeparteaza de radacina. Acest aranjament permite programatorilor de aplicatii sa aleaga nivelul optim de portabilitate intre protocoale pentru codul pe care il scriu.

Figura 4: Ierarhia interfețelor GCF

CLDC 1.1

Specificatia CLDC 1.1 a fost finalizata in luna martie a anului 2003 in cadrul JSR 139. Din cadrul grupului de experti JSR-139 au facut parte 24 de companii din toata lumea:

– aJile Systems

– Aplix Corporation

– France Telecom

– Fujitsu

– Insignia Solutions

– Liberate Technologies

– Mitsubishi

– Motorola

– NEC

– Nokia

– NTT DoCoMo

– OpenTV

– OpenWave Systems

– Oracle

– Panasonic

– Research In Motion (RIM)

– Samsung

– Siemens

– Sony

– Sony Ericsson Mobile Communications

– Sun Microsystems

– Symbian

– Vulcan Machines

– Zucotto Wireless

Membrii grupului de experti JSR-139 erau in general multumiti de specificatia CLDC 1.0, de aceea nu au considerat necesare modificari radicale in noua specificatie. Astfel, CLDC 1.1, este in principal o versiune incrementala, intentionata a fi compatibila inapoi cu CLDC 1.0.

Lista de mai jos sumarizeaza diferentele principale dintre specificatiile CLDC 1.0 (JSR-30) si CLDC 1.1 (JSR-139):

– a fost adaugat suport pentru numere in virgula mobila:

– tot bytecode-ul in virgula mobila este suportat

– au fost adaugate clasele Float si Double

– mai multe metode au fost adaugate la alte clase din librarie pentru a suporta valori in virgula mobila

– suport pentru referinte slabe (weak reference) a fost readaugat

– clasele Calendar, Date si TimeZone au fost reproiectate pentru a fi mai conforme cu J2SE

– cerintele pentru tratarea erorilor au fost clarificate si s-a adaugat o noua clasa de eroare: NoClassDefFoundError

– in CLDC 1.1, obiectele de tip thread au nume ca in J2SE. A fost adaugata metoda Thread.getName(), iar clasa Thread are adaugati cativa constructori mosteniti de la J2SE.

– alte modificari minore si fixuri au fost incluse, cum ar fi introducerea urmatorilor membri si metode:

– Boolean.TRUE, Boolean.FALSE

– Date.toString()

– Random.nextInt(int n)

– String.intern()

– String.equalsIgnoreCase()

– Thread.interrupt()

cerintele de memorie au fost ridicate de la 160 la 192 kilobytes, mai ales datorita noii functionalitati pentru virgula mobila.

Specificatiile MIDP

Mobile Information Device Profile (MIDP)

Mobile Information Device Profile (MIDP) este un element cheie al platformei J2ME. Combinat cu CLDC, ofera un mediu runtime Java standard pentru majoritatea dispozitivelor mobile moderne, de la telefoane celulare la PDA. Specificatia MIDP a fost definita prin Java Community Process si defineste o platforma pentru aplicatii grafice, conectate si optimizate care sunt lansate dinamic si securizat.

MIDP 1.0

Specificatia MIDP 1.0 a fost lansata in septembrie 2000 de catre grupul de experti JSR 37 desemnat de catre JCP, la scurt timp dupa finalizarea CLDC 1.0. Scopul specificatiei era definirea arhitecturii si API-urile asociate necesare deschiderii si permiterii dezvoltarii de aplicatii pentru dispozitive de informatii mobile, sau pe scurt MID-uri.

Specificatia a fost produsa de Mobile Information Device Profile Expert Group (MIDPEG), compus din urmatoarele companii:

America Online

DDI

Ericsson

Espial Group, Inc.

Fujitsu

Hitachi

J-Phone

Matsushita

Mitsubishi

Motorola

NEC

Nokia

NTT DoCoMo

Palm

Research In Motion

Samsung

Sharp

Siemens

Sony

Sun Microsystems

Symbian

Telcordia Technologies

Cerinte

Cerintele listate aici sunt in plus fata de cerintele CLDC. La un nivel mai inalt, specificatia MIDP presupune ca un MID este in general limitat in putere de calcul, memorie, conectivitate si marime a afisajului.

Cerinte hardware

MIDPEG a definit un MID ca fiind un dispozitiv care ar trebui sa aiba urmatoarele caracteristici minimale:

afisaj (display) cu o rezolutie de 96×54 pixeli

cel putin unul din urmatoarele mecanisme de input utilizator: tastatura de telefon ITU-T, tastatura QWERTY sau touchscreen.

128 kilobytes memorie nevolatila pentru componentele MIDP, 8 kilobytes memorie nevolatila pentru date persistente create de aplicatii, 32 kilobytes de memorie volatila pentru heap-ul Java.

conectivitate in doua directii, intermitenta, wireless, limitata

Cerinte software

Pe langa cerintele CLDC sunt impuse urmatoarele:

un mecansim pentru citirea si scrierea memoriei persistente

acces de citire si scriere la reteaua wireless a dispozitivului

un mecanism care sa puna la dispozitie o baza de timp pentru semnarea inregistrarilor scrise in memoria persistenta si pentru unele elemente ale API-ului

o capabilitate minimala de a scrie la un afisaj grafic bit-mapped

un mecanism de captare al input-ului utilizatorului de la unul din mecanismele de input precizate anterior

un mecanism de gestiune a ciclului de viata al aplicatiilor

Scopul specificatiei

MID-urile au o multime larga de capabilitati. Decat sa se incerce abordarea tuturor acestor capabilitati, MIDPEG a hotarat sa limiteze setul de API specifiat, adresand doar acele aspecte absolut necesare pentru a obtine portabilitate maxima. Aceste API-uri sunt:

Aplicatia (definirea semanticii unei aplicatii MIDP si cum este controlata)

Interfata utilizator (UI) (include afisaj si input)

Memorie persistenta

Conectivitate

Timere

Din aceleasi motive, unele arii de functionalitate au fost considerate in afara scopului MIDP. Aceastea includ urmatoarele:

API la nivel de sistem

Livrarea si gestiunea aplicatiilor

Securitate low-level

Securitate la nivel de aplicatie, in plus fata de CLDC

Securitate la nivel de retea (sisteme de criptare a transmisiilor de date)

Arhitectura

Din figura 5, componenta de baza a arhitecturii o reprezinta hardware-ul MID. Deasupra acestui hardware rezida sistemul nativ de software. Acest nivel include sistemul de operare si librariile native folosite de dispozitiv. Incepand cu nivelul urmator, de la stanga la dreapta, se gaseste stratul urmator de software, CLDC. Acest element reprezinta masina virtuala K (KVM) si librariile asociate definite de specificatia CLDC si ofera functionalitatea Java subiacenta pe care API-uri de nivel mai inalt pot fi construite.

Figura 5: Arhitectura aplicațiilor mobile

Doua categorii de API se observa deasupra CLDC:

MIDP API: setul de API definit de specificatie

API specific OEM (Original Equipment Manufacturers): avand in vedere marea diversitate de dispozitive din spatiul MIDP, nu este posibil sa fie adresate cerintele tutoror OEM-urilor. Aceste clase pot fi puse la dispozitie de un OEM pentru a accesa functionalitate specifica unui anumit MID. Aceste aplicatii nu pot fi portate pe alte MID-uri.

Componentele din varful schemei reprezinta tipurile de aplicatii posibile pe un MID:

MIDP: o aplicatie MIDP, sau un MIDlet, foloseste doar API-urile definite de CLDC si MIDP. Acest tip de aplicatie este focusul specificatiei MIDP si se asteapta a fi cel mai comun tip de aplicatie pe un MID.

OEM-specific: o aplicatie OEM-specific depinde de clase care nu fac parte din specificatia MIDP. Aceste aplicatii nu sunt portabile pe toate MID-urile.

Native: o aplicatie nativa este o aplicatie care nu este scrisa in Java si care rezida pe sistemul nativ de software al MID-ului

Timere

Aplicatiile care au nevoie sa intarzie sau sa programeze activitati pentru un timp ulterior pot folosi clasele Timer si TimerTask, care includ functii pentru:

executie singulara (o singura data)

executie repetata la intervale regulate

Conectivitate

MIDP extinde suportul pentru conectivitate definit de CLDC cu functionalitate specifica pentru Generic Connection framework. MIDP suporta un subset al protocolului HTTP, care poate fi implementat folosind atat protocoale de tip IP de genul TCP/IP cat si protocoale non-IP cum ar fi WAP si i-mode, folosind gateway pentru accesul la servere HTTP pe Internet.

HttpConnection

Generic Connection framework din CLDC ofera interfetele de baza pentru acest tip de conexiune. Interfata HttpConnection ofera in plus functionalitate necesara pentru antetele de cerere, de raspuns si pentru alte functii specifice HTTP.

Interfata trebuie sa suporte HTTP 1.1 si fiecare MID trebuie sa fie capabil sa deschida conexiuni folosind schemele de URL “http” definite de RFC2616 Hypertext Transfer Protocol – HTTP/1.1

Memoria persistenta

Specificatia MIDP ofera MIDlet-urilor un mecanism de a inregistra date persistent pentru recuperare ulterioara. Acest sistem de memorie persistenta, numit Record Management System (RMS), este modelat dupa o simpla baza de data orientata pe inregistrare.

Record store

Un record store consta dintr-o colectie de inregistrari care vor ramane persistente pe parcursul mai multor rulari ale unui MIDlet. Platforma este responsabila pentru mentinerea integritatii record store al unui MIDlet pe parcursul utilizarii normale, incluzand restartari, schimbari de baterie, etc.

Un record store poate fi creat in locatii dependente de platforma care sunt ascunse MIDlet-urilor. Spatiul de nume al record store este controlat de suita MIDlet. MIDlet-uri dintr-o suita MIDlet au permisiunea de a crea multiple record store, cu conditia ca toate sa aibe nume diferite. Cand o suita MIDlet este stearsa de pe o platforma, toate record store asociate trebuie de asemenea sterse. Aceste API-uri permit manipularea propriilor record store de catre o suita MIDlet, dar nu permit accesul record store al altor suite MIDlet. MIDlet-uri din aceeasi suita pot accesa acelasi record store direct.

Record-uri

Un record este un array de bytes. Programtorii pot folosi DataInputStream si DataOutputStream ca si ByteArrayInputStream si ByteArrayOutputStream pentru impachetarea si despachetarea diferitelor tipuri de date in si din byte array-uri.

Record-urile sunt identificate in mod unic intr-un record store prin recordId-ul lor, care este o valoare intreaga. Acest recordId este folosit in rol de cheie primara pentru record-uri. Primul record creat intr-un record store va avea recordId-ul 1, si fiecare recordId succesiv va creste cu 1.

Aplicatii

Specificatia MIDP defineste un model de aplicatie care sa permita ca resursele limitate ale dispozitivului sa fie impartite de aplicatii MIDP multiple, sau MIDlet-uri. Se defineste ce este un MIDlet, cum este impachetat, ce mediu runtime este pus la dispozitia MIDlet-ului si cum ar trebui sa se comporte pentru ca dispozitivul sa gestioneze resursele sale. Modelul de aplicatie defineste cum multiple MIDlet-uri formand o suita pot fi impachetate impreuna si pot imparti resurse in contextul unei singure masini virtuale Java.

Suita MIDlet

Elementele unei suite MIDlet sunt:

mediul de executie runtime

impachetarea suitei MIDlet

descriptor-ul aplicatiei

ciclul de viata al aplicatiei

Unul sau mai multe MIDlet-uri pot fi impachetate intr-un singur fisier JAR. Fiecare MIDlet consta intr-o clasa care extinde clasa MIDlet si alte clase necesare. Manifestul din fisierul JAR identifica pentru fiecare MIDlet clasa care implementeaza MIDlet-ul, numele ei si icoana. MIDlet-ul este entitatea care este lansata de software-ul de gestiune al aplicatiilor. O noua instanta a MIDlet-ului este creata de sistemul de gestiune si folosita pentru a directa MIDlet-ul sa porneasca, sa se opreasca si sa se distruga.

Unul sau mai multe MIDlet-uri pot fi impachetate intr-un singur fisier JAR care include:

un manifest care descrie continutul

clase Java folosite de MIDlet-uri

fisiere resursa folosite de MIDlet-uri

Programatorul este responsabil cu crearea si distribuirea componentelor unui fisier JAR intr-un mod cat mai adecvat pentru utilizatorul tinta, dispozitiv, retea, localizare si jurisdictie.

JAR Manifest

Manifestul JAR defineste atribute care sunt folosite de softul de gestiune al aplicatiilor pentru a identifica si instala suita MIDlet si pentru a complet lipsa unor atribute care nu se gasesc in descriptorul aplicatiei. Atributele standard sunt definite pentru folosinta atat in manifest cat si in descriptorul aplicatiei. Atributele care incep cu “MIDlet-” si nu duplica pe cele din descriptor sunt pasate MIDlet-ului la orice solicitare.

Manifestul trebuie sa contina urmatoarele atribute:

MIDlet-Name

MIDlet-Version

MIDlet-Vendor

MIDlet-<n> pentru fiecare MIDlet

MicroEdition-Profile

MicroEdition-Configuration

Manifestul poate contine urmatoarele atribute:

MIDlet-Description

MIDlet-Icon

MIDlet-Info-URL

MIDlet-Data-Size

Clasele MIDlet-ului

Toate clasele Java necesare MIDlet-ului sunt iserate in fisierul JAR folosind structura standard, bazat pe schitarea numelor complet calificate ale claselor in nume de fisiere si directoare. Fiecare punct (.) este convertit la un forward slash (/) si extensia .class este sufixata. De exemplu, o clasa com.sun.microedition.Test este plasata in fisierul JAR cu numele com/sun/microedition/Test.class.

Descriptorul aplicatiei

Descriptorul aplicatiei este folosit de softul de gestiune al aplicatiei pentru gestionarea MIDlet-ului si este folosit de MIDlet in sine pentru atribute specifice de configuratie. Fiecare fisier JAR poate fi acompaniat de un descriptor. Acesta permite dispozitivului sa verifice daca MIDlet-ul este potrivit inainte de a incarca intreg fisierul JAR al suitei MIDlet. Permite de asemenea furnizarea de atribute specifice de configurare (parametri) MIDlet-ului, fara a fi necesara modificarea JAR-ului. Extensia unui fisier descriptor de aplicatie este .jad.

Un set de atribute predefinite este specificat pentru a permite identificarea, descarcarea si instalarea suitei MIDlet. Toate atributele care apar in descriptor sunt case-sensitive si sunt disponibile MIDlet-ului prin apelul la metoda MIDlet.getAppProperty().

Descriptorul aplicatiei trebuie sa contina urmatoarele atribute:

MIDlet-Name

MIDlet-Version

MIDlet-Vendor

MIDlet-Jar-URL

MIDlet-Jar-Size

Descriptorul aplicatiei poate sa contina urmatoarele atribute:

MIDlet-Description

MIDlet-Icon

MIDlet-Info-URL

MIDlet-Data-Size

atribute specifice MIDlet-ului care nu este necesar sa inceapa cu “MIDlet-”

Atributele obligatorii MIDLet-Name, MIDlet-Version si MIDlet-Vendor trebuie sa fie duplicate in fisierele descriptor si manifest. Daca nu sunt identice, JAR-ul nu trebuie instalat. In timp ce duplicarea altor atribute nu este necesara, atributele cu acelasi nume din descriptor le vor suprascrie pe cele corespunzatoare din manifest.

Ciclul de viata al aplicatiilor

Fiecare MIDlet trebuie sa extinda clasa MIDlet. O suita MIDlet nu trebuie sa contina metoda public static void main(). Daca aceasta totusi exista, ea trebuie ignorata. Cand un MIDlet este lansat, o instanta a clasei primare a MIDlet-ului este creata folosind constructorul public fara argumente, si metodele sale sunt apelate pentru a trece MIDlet-ul prin diferitele sale stari. Un MIDlet poate cere schimbari ale starii sau sa notifice sistemul de schimbari ale starii prin metodele sale. Cand un MIDlet si-a terminat executia sau este oprit de sistem, acesta este distrus si toate resursele folosite pot fi eliberate, incluzand orice obiecte create si clasele sale. Un MIDlet nu trebuie sa apeleze System.exit(), acest lucru va arunca o SecurityException.

Interfata utilizator (UI)

Principalele criterii pentru MIDP au fost stabilite luand in considerare dispozitive mobile, telefoane mobile sau PDA. Aceste dispozitive difera fata de sisteme desktop in multe privinte, in special cum utilizatorul interactioneaza cu ele. Avand in vedere abilitatile aparatelor care vor implementa MIDP, grupul MIDPEG a hotarat sa nu subseteze pur si simplu UI-ul Java existent, reprezentat de Abstract Windowing Toolkit (AWT).

Structura API-ul UI al MIDP

UI-ul MIDP este structurat in mod logic in doua componente API: cea high-level si cea low-level.

Componenta high-level este proiectata pentru aplicatii business ale caror componente client ruleaza pe MID-uri. Pentru aceste aplicatii, portabilitatea peste o arie larga este importanta. Pentru a obtine aceasta portabilitate, se pune in folosinta un nivel inalt de abstractie si ofera foarte putin control asupra aspectului si comportamentului. Folosind API-ul high-level, se presupune ca implementarea subiacenta va efectua adaptarile necesare la hardware-ul dispozitivului si stilul UI nativ.

Pe de alta parte, API-ul low-level, ofera foarte putina abstractie. Acest API este proiectat pentru aplicatii care au nevoie de plasarea exacta a elementelor grafice si de control si acces la evenimente de input low-level. Unele aplicatii au de asemenea nevoie de acces la particularitati speciale ale dispozitivului. Un exemplu tipic de acest gen de aplicatie sunt jocurile.

Folosind API-ul low-level o aplicatie poate sa:

aiba control total asupra a ceea ce se deseneaza pe ecran

intercepteze evenimente primtive de genul apasarilor si eliberarilor de taste.

acceseze taste specifice sau alte metode de input.

Aplicatii care folosesc API-ul low-level nu sunt garantate a fi portabile, din moment ce permite accesul la detalii specifice unui anumit dispozitiv. Daca aplicatia nu foloseste aceste particularitati, va fi portabila, de aceea se recomanda aderenta la partile independente de platforma ale API-ului low-level. Acest lucru inseamna ca aplicatia nu trebuie sa foloseasca alte taste decat cele definite in librarii, si nu ar trebui sa depinda de o anumita marime a ecranului. Aplicatia ar trebui sa foloseasca mecanismul game-event in loc sa faca referinta la taste specifice si ar trebui sa obtina informatii despre rezolutia ecranului si sa se adapteze conform. In practica acest lucru este greu de realizat pentru ca astfel nu s-ar folosi toata functionalitatea oferita de un anumit dispozitiv, iar gama larga de dimensiuni a ecranelor fac imposibila crearea unei aplicatii care sa se adapteze la orice dispozitiv.

Ierarhia claselor

Abstractia centrala a UI-ului MIDP este un screen, adica un obiect care incapsuleaza redare grafica specifica dispozitivului. Un singur screen poate fi vizibil la un moment dat, si utilizatorul poate traversa doar elementele de pe acel screen. Acesta se ocupa de toate evenimentele generate de actiunile utilizatorului, doar evenimentele de nivel inalt fiind trimise mai departe aplicatiei.

Exista trei categorii de ecrane (screen):

ecrane care incapsuleaza o componenta complexa UI (exemplu, clasele List sau TextBox). Structura acestor ecrane este predefinita, si aplicatia nu le poate adauga alte componente.

ecrane generice (exemplu, clasa Form) pe care aplicatia le poate popula cu text, imagini sau seturi corelate de componente UI.

ecrane care sunt folosite in contextul API-ului low-level (exemplu, subclase ale clasei Canvas).

Clasa Display are rol de manager de ecrane si este instantiat pentru fiecare MIDlet activ si ofera metode pentru a obtine informatii despre abilitatile ecranului dispozitivului. Un ecran este facut vizibil prin apelul la metoda Display.setCurrent().

Tratarea evenimentelor

Interactiunea cu utilzatorul cauzeaza evenimente si implementarea notifica aplicatia prin callback-uri corespunzatoare. Exista patru tipuri de callback:

comenzi abstracte care fac parte din API-ul high-level

evenimente low-level reprezentate de apasari si eliberari singulare de taste (si evenimente de pointer, daca un pointer este disponibil, ca pe dispozitivele cu touchscreen).

apeluri la metoda paint() a clasei Canvas

apeluri la metoda run() a unui obiect de tip Runnable, cerute de un apel la Display.callSerially().

MIDP 2.0

Specificatia MIDP 2.0 a fost lansata in noiembrie 2002 de catre grupul de experti JSR 118 desemnat de catre JCP. Scopul acestei specificatii era imbunatatirea arhitecturii MIDP si a API-urilor asociate. MIDP 2.0 se bazeaza pe specificatia MIDP 1.0 si este compatibila inapoi cu aceasta pentru ca MIDlet-uri scrise pentru MIDP 1.0 sa poate fi executate in medii MIDP 1.0.

MIDP este proiectat sa opereze deasupra configuratiei CLDC. Desi MIDP 2.0 a fost proiectat luand in considerare doar particularitatile CLDC 1.0, acesta va functiona si deasupra CLDC 1.1. Se astepta ca majoritatea implementarilor MIDP 2.0 sa fie bazate pe CLDC 1.1

Grupul de experti JSR 118 a fost format din urmatoarele companii si persoane:

Companii:

4thpass Inc.

AGEA Corporation

Alcatel

Aplix Corporation

AromaSoft Corp

Baltimore Technologies

CELLon France

Distributed Systems Technology Centre

Elata PLC

Esmertec

Espial Group Inc.

France Telecom / Orange

Fujitsu Limited

German Aerospace Center (DLR), Institue of Communications and Navigation

Hitachi Ltd. / Digital Media Group

In Fusio

J-PhoneEast Co. Ltd

Logica Mobile Networks

Mitsubishi Electric Corp

Mobile Scope AG

Mobilitec

Motorola

NEC Corporation

Nextel Communications Inc.

Nokia

NTT DoCoMo Inc.

Omnitel Pronto Italia S.p.A

One 2 One

Openwave Systems Inc.

Orange (UK)

Palm

Philips Consumer Communications

Philips Semiconductors

Research In Motion (RIM)

Samsung Electronics Co., Ltd.

Sharp Labs

Siemens AG

Siemens ICM

Smart Fusion

Sony Ericsson Mobile Communications

Sun Microsystems Inc.

Symbian Ltd.

Telefonica Moviles Espana

Vaultus Inc

Veloxoft Inc

Vodafone Global Platform & Internet Services

Vodafone Group Services Limited

Vodafone Multimedia

Zucotto Wireless

Persoane:

Fabio Ciucci

Glen Cordrey

Jon Eaves

David Hook

Mynak Jain

Neil Katin

Steve Ma

Ravi Reddy

Wai Kit Tony Fung

Specificatia MIDP 2.0 a introdus noi capabilitati substantiale platformei de baza care permite programatorilor sa dezvolte aplicatii mai puternice si mai utile cu un efort mai mic. Voi prezenta pe scurt aceste noi capabilitati si arata importanta lor in dezvoltarea de aplicatii pentru dispozitive mobile de generatie noua.

Conectivitate securizata

La dezvoltarea MIDP 1.0, autorii specificatiei au fost foarte conservatori in functionalitatea pe care sa o includa in profilul de baza. Lipsa oricarui gen de functii de securitate standard, in particular, s-a dovedit a fi foarte restrictiva. Aceasta a fortat programatorii sa isi creeze propriile mecanisme de securitate si sa le includa in fiecare pachet de aplicatie. In afara marimii fisierelor si a efortului aditional, se reducea interoperabilitatea. Astfel, interoperabilitate, marimea fisierelor redusa si usurinta dezvoltarii au fost temele principale ale MIDP 2.0.

Problema a fost rezolvata prin introducerea suportului pentru WAP Certificate Profile (WAPCERT), bazat pe Intenet X.509 Public Key Infrastructure (PKI) Certificate si pe Certificate Revocation List (CRL) Profile. Indroducerea functionalitatii PKI este utilizata pentru a pune la dispozitie conexiuni securizate si semnaturi digitale pentru pachete de aplicatii MIDP.

Aplicatiilor cu semnatura digitala corespunzatoare li se permit folosirea API-urilor care altfel ar fi restrictionate de modelul de securitate imbunatatit al MIDP 2.0. Aceste interfete restrictionate includ interfata certificatului PKI si alte conexiuni in afara de HTTP si HTTPS. HTTP si HTTPS sunt protejate, dar pot fi utilizate de aplicatii nesemnate prin confirmare explicita. Permisiunile pentru capabilitatile PKI subiacente sunt stabilite folosind un mecanism de semnare si verificare.

O aplicatie nu are permisiune daca originea si integritatea arhivei JAR nu pot fi determinate, un esec de verificare cauzat de acreditari improprii sau de lipsa unei semnaturi. Spre exemplu, o aplicatie MIDP 1.0 ar rula fara permisiune din moment ce semnaturile si certificatele digitale nu erau prezente in specificatie. Aplicatiile fara permisiune au acces la tot continutul pachetelor de interfata grafica, sunet, record store si de nucleu al MIDlet-ului. Doar conexiunile HTTP si HTTPS sunt accesibile cu permisiunea explicita a utilizatorului.

Conectivitate la retea extinsa

MIDP 1.0 oferea doar o singura metoda de baza de conexiune la lumea exterioara, o conexiune HTTP. MIDP 2.0 extinde optiunile de conectare disponibile utilizatorilor cu o serie de capabilitati I/O in retea. O data cu introducerea functionalitatii PKI in specificatie, MIDlet-urile pot stabili conexiuni prin protocoalele HTTPS si SSL/TLS necesare pentru manipularea securizata a informatiilor confidentiale cum ar fi parole sau numere de carti de credit. MIDP 2.0 ofera de aseamenea o serie de abilitati de retelistica low-level pentru socket TCP/IP si datagrame UDP/IP, in afara de conexiuni locale pe porturi seriale.

Desi aceste conexiuni noi sunt utile si importante, cea mai interesanta si originala capabilitate introdusa in specificatie este push registry. Prin crearea unei intrari in descriptorul aplicatiei sau prin clasa PushRegistry, un MIDlet poate inregistra un inbound connection listener. Cand MIDlet-ul nu ruleaza, sistemul de gestiune al aplicatiilor al platformei MIDP asculta pentru o cerere interna, iar in momentul primirii unei cereri, sistemul lanseaza MIDlet-ul asociat si paseaza mai departe conexiunea pentru procesare.

Importanta acestui lucru este ca un MIDlet poate oferi servicii si cand nu ruleaza in mod activ. Este de asemenea important pentru ca ofera programatorilor o metoda mai eficienta de a folosi informatii pe baza de eveniment. Spre exemplu, un MIDlet poate subscrie unui serviciu RSS news feed alert, solicitand sa fie notificat atunci cand se publica noi titluri. La orice moment dupa inregistrare, acel serviciu este actualizat si notifica MIDlet-ul printr-un mesaj. Nu era necesar ca MIDlet-ul sa fie activ, nici nu trebuia sa interogheze in continuu serverul pentru actualizari.

Audio si jocuri

MIDP 1.0 este silentios. Specificatia 2.0 introduce suport de baza pentru sunete si este un subset compatibil inainte al specificatiei Mobile Media API (JSR-135). Mobile Media API a fost proiectat pentru dispozitive mai robuste care solicitau un set mai bogat de controale si capabilitati cum ar fi suport pentru optiuni avansate audio si video. API-ul media suporta generarea de tonuri, secvente de tonuri, si daca aparatul suporta sample audio, fisiere WAV. Desi pe aplicatii desktop sunetul nu prezinta in general interes, tonurile de apel si altele asemenea sunt destul de populare utilizatorilor de telefoane mobile.

Suportul de baza audio este de ajutor mai ales la dezvoltarea de aplicatii folosind noul API pentru jocuri. Aceste controale de interfeta specializate includ o clasa GameCanvas, si clasele Sprite si TiledLayer. Acestea au fost optimizate pentru a utiliza capabilitatile native ale dispozitivelor pentru performante mai bune si pentru reducerea efortului dezvoltarii de jocuri pentru o arie larga de dispozitive. Firmele de telefonie mobila si producatorii de dispozitive au speculat faptul ca suportul pentru jocuri urma sa fie un motor al dezvoltarii pietii si al castigurilor.

Livrarea Over The Air (OTA)

Ideea de la care s-a pornit a fost un tonomat de vanzare pentru aplicatii prin download. Livrarea OTA permite unui consumator sa gaseasca o aplicatie, sa o descarce pe telefon si sa o instaleze, fara cabluri, statii de docare sau computere necesare. Producatorii de MIDlet-uri au creat depozite de aplicatii unde programatorii si-au publicat aplicatiile pentru download, posibil cu un pret modic atasat. Serviciul de livrare se asigura ca aplicatia este destinata folosirii pe un anumit dispozitiv si monitorizeaza rapoartele de stare de la acesta.

Specificatia MIDP initiala nu includea livrarea OTA. A fost introdusa mai tarziu ca practica recomandata intr-un document separat. In specificatia MIDP 2.0, OTA devine obligatorie cu scopul de a stabili un standard concret de securitate si interoperabilitate intre furnizorii de servicii si MID-urile care suporta platforma Java.

Imbunatatiri UI

Specificatia MIDP 2.0 aduce numeroase imbunatatiri ale UI pentru a suporta o extensibilitate mai mare si o portabilitate generala a MIDlet-urilor intre dispozitive mai larga. Cateva din rafinarile de mentionat sunt urmatoarele:

o clasa CustomItem care poate fi subclasata pentru dezvoltarea de widget-uri GUI care nu sunt incluse in API-ul standard

o clasa ItemCommandListener pentru o mai buna interactivitate a elementelor si o clasa Spacer pentru capabilitatati mai precise de incadrare in spatiul ecranului.

elemente din categoria Form au atribute minime si recomandate pentru a se adapta la particularitati diferite de afisaj intre dispozitive.

Specificatiile JSR120 – Wireless Java API

Comunicatii wireless.Prezentare

Comunicatii wireless sunt un domeniu foarte mare, continând toate dispozitivele de la radio si televiziune pâna la pagere, telefoane mobile si comunicatii prin satelit. Acest domeniu se extinde foarte repede si în acelasi timp standardele si protocoalele sunt adoptate, modificate si uneori se renunta la unele. Cealalta parte a lumii wireless care se dezvolta foarte repede este wireless local area network(LAN). Condus de acceptarea standardului IEEE 802.11, retelele wireless locale pentru calculatoare si alte dispozitive se întind foarte repede.

Chiar daca wireless ar parea un caz special de retea conectata prin fire de fapt este mai intuitiva si naturala decât aceasta. În curând ideea de a conecta un laptop într-o retea fizica va fi ciudata si învechita. Ideea ca ai putea intra într-o camera cu telefonul tau mobil si nu ai putea comunica cu celelalte dispozitive din încapere va parea deosebit de primitiva. Viitorul ne va arata ca retelele prin fire sunt un caz special.

Conceptual, comunicatiile wireless pot fi împartite în doua tipuri: locale si largi. Un dispozitiv local este similar cu o telecomanda mica cu care îti descui masina, un telefon la 900 MHz, un emitator radio sau o retea prin Bluetooth. Toate aceste dispozitive opereaza la distante foarte scurte, tipic la doar câtiva metri.

Dispozitivele retelelor wireless largi opereaza eficient la distante mult mai mari. Un pager sau telefon mobil este un bun exemplu: poti vorbi de la telefonul tau cu orice alt telefon mobil de pe planeta. Sfera lor mai mare de actiune presupun o retea terestra mult mai elaborata. Un telefon mobil nu are mai multa putere radio decât un emitator-receptor de jucarie. Ceea ce are în plus este o retea de antene radio asa ca celularul va functiona atâta timp cât este în acoperirea cel putin a unui turn celular. Telefonul celular are acces la servicii printr-o companie care opereaza reteaua terestra.

În timp ce un numar de organizatii ca si International Telecommunication Union încearca sa defineasca standardele pentru lumea wireless, aceasta este înca fragmentata si foarte complexa. Daca azi îti cumperi un telefon mobil din SUA, el va functiona în reteaua Motorola iDen sau Sprint PCS. Daca îl duci în Europa vei vedea ca telefonul tau nu functioneaza cu reteaua GSM , nici cu PDC sau alta retea mobila care este în Japonia.

Pachetele optionale sunt niste componente foarte importante pentru arhitectura J2ME. Ele pot fi privite ca extensii a profilelor. Ele ofera functionalitate în zone de functionalitate relativ înguste de care unele echipamente au nevoie si altele nu, ca si transmitere mesaje, multimedia si servicii de locatie. Cu pachetele optionale acoperind astfel de cerinte, profilele se pot concentra sa ofere functionalitatea care este folosita de toate dispozitivele. Toate pachetele optionale sunt definite de JCP, astfel devenind API standard. Exista un numar mare de pachete optionale, unele pentru CLDC, unele pentru CDC, unele pentru ambele. 

Inovatii

Tehnologia Wireless Java duce lumea mobila intr-o noua era. Aparitia pachetului optional JSR120 aduce o noua fata lucrului cu mesaje in cadrul aplicatiilor J2ME. Cu ajutorul acestuia, programatorii pot scrie cod cu ajutorul caruia se pot trimite mesaje text au multimedia din cadrul aplicatiilor J2ME.

Nevoia pentru un asemenea API, care sa permita interactiunea aplicatiei cu reteaua de telefonie mobila a aparut o data cu dezvoltarea industriei jocurilor si a retelelor sociale (“social networks”). In cazul aplicatiilor de divertisment, cum ar fi cele care interactioneaza cu camera de luat vederi sau microfonul incorporat in mobil, posibilitatea de a trimite prietenilor poze, clipuri video sau audio a devenit in timp o necesitate. Cu ajutorul lui JSR120, acest lucru este posibil. Acesta permite introducerea elementelor multimedia intr-un mesaj scris din interiorul aplicatiei, evitand astfel functiile de stocare si expediere oferite de telefon si reusind expedierea mesajelor intr-un timp foarte scurt.

In cazul jocurilor, unii operatori de telefonie mobila au considerat necesara introducerea facilitatii de a face reclama jocului prin intermediul mesajelor text expediate chiar din aplicatie. Acest lucru nu ii va ajuta pe acestia doar la popularizarea jocurilor, dar si la obtinerea de profit, desi redus, din costul mesajelor text expediate de utilizatori.

Retelele sociale s-au dezvoltat foarte mult in ultimii ani. Au aparut astfel o multime de asemenea retele, fiecare su specificul ei. Asemeni unei mari arii din industria IT, acestea s-au extins si pe platformele mobile, pentru a oferi utilizatorilor acces mobil constant la resursele retelei si o conexiune permanenta cu ceilalti membrii ai retelei. Astfel au fost dezvoltate aplicatii care apeleaza la JSR120 pentru expedierea de mesaje.

Lucrul la JSR120 a inceput in 2001 si a durat aproximativ 2 ani. LA dezvoltarea sa au participat un numar mare de operatori de telefonie mobila, producatori de aparatura si mai multe companii IT :

Aplix Corporation

Cingular Wireless

Logica Mobile Networks

NEC Corporation

One 2 One Personal Communications Ltd

Siemens AG

Sun Microsystems, Inc

Openwave Systems Inc.

Symbian Ltd

Vodafone UK Ltd

Motorola

Nokia Corporation

Telefonica Moviles Espana

Siemens

France Telecom

JSR120 aduce un set de clase care ofera posibilitatea manipularii mesajelor cu destul de multa usurinta :

BinaryMessage 

Connector 

Message 

MessageConnection 

MessageListener 

TextMessage 

Aplicatie – SMS Chat

Introducere

Pentru a demonstra utilitatea functiilor oferite de JSR120, am realizat o aplicatie J2ME care permite schimbul de mesaje scrise intre utilizatori.

Aplicatia apeleaza la :

Message – clasa care permite accesul la orice tip de mesaj receptionat

MessageConnection – ofera fluxul de date prin care sunt expediate si/sau receptionate mesajele text si multimedia. Contine metode pentru expediere si receptionare, metode de tip factory pentru crearea de obiecte de tip Message, si o metoda care calculeaza numarul de segmente de care are nevoie protocolul pentru a expedia un asemenea obiect.

MessageListener – reprezinta un mecanism care permite aplicatiie sa detecteze automat receptionarea unui nou mesaj. Cand un mesaj soseste, metoda notifyIncomingMessage() este apelata automat. Aplicatia trebuie sa preia mesajul respectiv utilizand metoda receive() din clasa MessageConnection. MessageListener nu va apela in mod direct receive(). In loc, va lansa un fir de executie care va prelua mesajul sau va apela o alta metoda din aplicatie care va face acest lucru.

TextMessage – o interfata reprezentand un mesaj text. Acesta este o subinterfata a lui Message, care contine metode pentru setarea si preluarea continutului mesajului : getPayLoadText(), SetPayLoadText(Stirng)

Connector – ofera accesul din aplicatii la o conexiune directa catre retea pentur a putea expedia mesaje

PushRegistry – permite aplicatiilor sa se lanseze automat, fara interactiune din partea utilizatorului. Acesta se ocupa de managementul operatiilor MIDLet-urilor cu activarea serviciilor de retea si a evenimentelor programate.

Implementare

Proiectul este impartit in mai multe clase:

1. clasa App:

public class App extends MIDlet implements MessageListener {

MyCanvas appScreen;

protected void destroyApp(boolean arg0) throws MIDletStateChangeException ;

protected void pauseApp() {

// TODO Auto-generated method stub

}

protected void startApp() throws MIDletStateChangeException;

public void notifyIncomingMessage(MessageConnection arg0);

2. Clasa MyCanvas :

public class MyCanvas extends Canvas implements Runnable, Constants {

App parent;

Menu menu;

SoftKeyBar keyBar;

MyTextBox textBox_name;

MyTextBox textBox_number;

MyTextArea textArea_message;

String username = "";

String systemMessage = "";

boolean running = false;

int state;

Image pending;

Image logo;

long loadingTime;

private String number;

Message msgReceived;

Message[] inbox = new Message[100];

int totalMessages = 0;

Message openMessage;

boolean newMessageReceived = false;

MessageConnection smsConnection;

String[] connections;

public MyCanvas(App p) ;

protected void init() ;

protected void paint(Graphics g) ;

private void drawReadMessage(Graphics g) ;

private void drawWriteMessage(Graphics g;

private void drawSetNumber(Graphics g) ;

public void run() ;

private void deleteMessage() ;

private void updateSetNumber() ;

private void updateSetName() ;

private void updateWriteMessage() ;

private void drawIntro(Graphics g;

private void drawSetName(Graphics g) ;

private void setState(int newState) ;

// /////////////

// SMS RELATED//

// /////////////

public void keyPressed(int keyCode) ;

public void Exit;

public void processMessage() ;

}

3. Clasa MyTextBox

public class MyTextBox {

public static final int ADD = 0;

public static final int REPLACE = 1;

public static final int TYPE_NUMBER = 0;

public static final int TYPE_STRING = 1;

int maxLength;

int posY;

private String value = "";

private long lastEventTime = 0;

private int lastKeyIndex = -1;

private int lastCharIndex = -1;

int behavior = ADD;

int type;

int width;

int height;

public static final String[] keyChars = { " +=*", "10,.-:!)(@/", "ABC2",

"DEF3", "GHI4", "JKL5", "MNO6", "PQRS7", "TUV8", "WXYZ9" };

public MyTextBox(int len, int y, int type) ;

public String Value() ;

public void draw(Graphics g) ;

public void update(int keyCode) ;

}

4. Clasa MyTextArea

public class MyTextArea {

boolean writable = false;

private String value = "";

public static final int ADD = 0;

public static final int REPLACE = 1;

int maxLength = 200;

int posX;

int posY;

private long lastEventTime = 0;

private int lastKeyIndex = -1;

private int lastCharIndex = -1;

int behavior = ADD;

int type;

int width;

int height;

public static final String[] keyChars = { " +=*", "10,.-:!)(@/", "ABC2",

"DEF3", "GHI4", "JKL5", "MNO6", "PQRS7", "TUV8", "WXYZ9" };

public String Value() ;

public MyTextArea(boolean wr, int x, int y, int w,

int h);

public MyTextArea(boolean wr, String content, int x, int y, int w, int h) ;

public void update(int keyCode) ;

public void draw(Graphics g) ;

}

5. Clasa Utils

public class Utils {

private static Font m_font;

private static String m_txt;

private static int m_length;

private static int m_width;

private static int m_position;

private static int m_start;

public static int write(Graphics g, String txt, int x, int y, int width, Font font) ;

private static boolean hasMoreLines() ;

private static String nextLine() ;

private static int next() ;

private static int getNextWord(int startIndex) ;

}

6. Clasa Menu

public class Menu implements MenuConstants {

int selectedIndex = 0;

int fontSize = Font.SIZE_MEDIUM;

int fontFace = Font.FACE_SYSTEM;

public Menu() ;

int posY;

public int getPosY() ;

public void draw(Graphics g) ;

}

7. Clasele Constants, GlobalConstants, MenuConstants, Keys

Interfata aplicatiei

Interfata aplicatiei este realizata cu ajutorul clasei MyCanvas, care mosteneste javax.microedition.lcdui.Canvas si implementeaza o interfata Runnable pentru a permite separarea partii lgice de cea de desenare. Metodele de calcul si tratare a evenimentelor si manipularea datelor cunt apelate din interiorul metodei run() care este suprascrisa si contine o bucla de tip while in cadrul careia sunt modificate datele ce caracterizeaza procesul.

Instructiunile de desenare a obiectelor sunt separate in diverse metode, care in functie de starea aplicatiei, sunt apelate selectiv in cadrul metodei paint(), a clasei Canvas.

Am folsit cateva elemente grafice si unele metode de desenare a primitivelor:

Graphics.drawImage(Image)

Graphics.drawString(String, int, int, int)

Graphics.drawLine(int, int, int, int)

Graphics.drawRect(int, int, int, int)

Graphics.fillRect(int, int, int, int)

Graphics.setClip(int, int, int, int)

Graphics.setColor(int)

Ecranele importante sunt prezentate mai jos :

Ecranul de introducere

Meniul

Ecranul de introducere a textului

4. Ecranul de introducere a numarului de telefon :

Ecranul de introducere a numelui:

Bibliografie

Java (Programming Language) http://en.wikipedia.org/wiki/Java_(programming_language)

Sun Microsystems, Inc. Connected, Limited Device Configuration (JSR-30). Specification Version 1.0a

Sun Microsystems, Inc. Connected, Limited Device Configuration (JSR-139). Specification Version 1.1

Sun Microsystems, Inc. Mobile Information Device Profile (JSR-37). JCP Specification 1.0a

Sun Microsystems, Inc. Mobile Information Device Profile (JSR-118). JCP Specification 2.0

Motorola Mobile Devices Software. Wireless Java API (JSR-120). Specification Version 1.1

L. Victor Allis, H. J. van den Herik, M. P. H. Huntjens. Gomoku and Threat-Space Search