Programowanie urządzeń mobilnych na platformie Java ME

Transkrypt

1 Programowanie urządzeń mobilnych na platformie Java ME Piotr Kopniak Wprowadzenie Telefon komórkowy jest urządzeniem bardzo popularnym. Przyzwyczailiśmy się już do tego, że każdy człowiek go ma i dzięki niemu możemy się z nim skontaktować. Jednak współczesne telefony oferują nam dużo większą funkcjonalność. Najbardziej zaawansowane z telefonów komórkowych zwane są popularnie smartfonami. Ta nazwa pochodzi od angielskich słów smart phone. Smortfony to nie telefony, a kieszonkowe komputery o mocy obliczeniowej zbliżonej do komputerów biurkowych sprzed kilku lat. Urządzenia tego typu działają najczęściej pod kontrolą systemu operacyjnego będącego uproszczoną wersją systemu stosowanego w standardowych komputerach osobistych oraz wykorzystują oprogramowanie niewiele różniące się od oprogramowania standardowych komputerów osobistych. Jednak najwięcej obecnie używanych na świecie telefonów to tańsze telefony, często wyposażone w klawiatury, których głównym przeznaczeniem jest telefonowanie. Telefony takie możemy nazwać telefonami funkcyjnymi ponieważ występują pod wspólną angielską nazwą featured phone. W telefonach tego typu wszystko jest mniejsze w porównaniu ze smartfonami. Posiadają mniejsze ekrany, mniej pamięci, wolniejsze procesowy i co bardzo ważne mniejsza cenę. Telefony tego typu wykorzystują najczęściej dedykowane systemy operacyjne oraz oprogramowanie. Ze względu na duża liczbę użytkowanych urządzeń, na tego typu telefony ciągle powstaje nowe oprogramowanie. Ze względu na dużą różnorodność producentów telefonów i ich podzespołów tworzone oprogramowanie powinno dawać możliwość uruchamiania na wielu platformach. Idealnym rozwiązaniem jest zastosowania języka programowania, który spełnia te wymogi. Tym językiem jest język Java. Dzięki zastosowaniu środowiska wykorzystującego maszynę wirtualną, na której działają aplikacje, Java spełniają podstawowy wymóg przenośności. Maszyna wirtualna dla programu, który na niej działa wygląda zawsze w ten sam sposób niezależnie od rodzaju systemu operacyjnego, na którym zainstalowano maszynę, dlatego raz napisany program można uruchomić na wielu różnych systemach operacyjnych. Środowisko Java występuje w kilku odmianach. Java SE (Standard Edition) umożliwia tworzenie aplikacji na standardowe komputery osobiste i serwery [1]. Java EE (Enterprise Edition) służy do budowy wielowarstwowych aplikacji dla przedsiębiorstw [2]. Dla urządzeń mobilnych powstała specjalna platforma programistyczna o nazwie Java Micro Edition (Java ME) [3], która zostanie omówiona poniżej. Platforma Java ME Java dla urządzeń mobilnych jest zbiorem specyfikacji i technologii wytwarzania aplikacji. Implementacje specyfikacji mogą być wytwarzane przez różnych producentów, choć najczęściej wykorzystuje się wzorcową implementację stworzona przez firmę Sun, a obecnie rozwijaną przez firmę Oracle.

2 Java ME działa obecnie na ponad 3 milionach telefonów na świecie [3], ponieważ dzięki zastosowaniu maszyny wirtualnej dostarcza elastyczne środowisko uruchomieniowe nie tylko dla aplikacji działających na telefonach, ale także na innych systemach wbudowanych, takich jak: telewizory, dekodery telewizyjne, czytniki Blu-Ray, czytniki książek elektronicznych i drukarki [4]. Twórcy platformy od ponad dekady współpracują nad jej rozwojem z czołowymi przedsiębiorstwami rynku urządzeń mobilnych poprzez program Java Community Process (JCP) [5]. Java ME jest uproszczeniem Javy SE przeznaczonej dla komputerów osobistych i bazuje na dwóch głównych specyfikacjach zwanych konfiguracjami. Pierwsza z nich to Connected Limited Device Configuration (CLDC) przeznaczona dla urządzeń o mniejszych możliwościach, do których można zaliczyć telefony [6] oraz Connected Device Configuration (CDC) opracowana dla urządzeń lepiej wyposażonych takich jak palmtopy i systemy wbudowane [7]. Konfiguracje platformy Java ME Konfiguracja jest specyfikacją definiującą środowisko oprogramowania dla grupy urządzeń, udostępnia podstawowe usługi dla aplikacji. Konfiguracja nie zawiera żadnych klas do zarządzania cyklem życia aplikacji, tworzenia interfejsu użytkownika, zarządzania trwałością danych w urządzeniu, czy bezpiecznego dostępu do informacji na serwerze sieciowym. Te funkcjonalności udostępniają dodatkowe zestawy bibliotek zwane profilami. Konfiguracja CLDC jest konfiguracją dla urządzeń o silnych ograniczeniach: mocy obliczeniowej, pamięci, żywotności baterii i przepustowości sieci. Nie zakłada istnienia ekranu i mechanizmu wprowadzania danych. Zakłada jednak istnienie systemu operacyjnego, niekoniecznie wspierającego współbieżność. Środowisko to zawiera jedynie API najwyższego poziomu dla pisania aplikacji (nie systemów). CLDC nie zajmuje się zarządzaniem cyklem życia aplikacji, nie zakłada istnienia systemu plików i przechowywania trwałego załadowanych aplikacji, ponieważ decydują o tym rozwiązania sprzętowo-systemowe producentów urządzeń. Ze względu na to, że CLDC opiera się na Javie SE jej dokumentacja określa jedynie zmiany wprowadzone do platformy bazowej. Podstawowe biblioteki klas konfiguracji oraz profili muszą wykorzystywać klasy zawarte w platformie Java SE. Klasy zapożyczone z Javy SE nie mogą być modyfikowane poprzez dodawanie nowych pól i metod (działanie metod może być inne). Do pakietów pochodzących z Javy SE nie można dodawać nowych klas. W związku z tym program napisany w środowisku Java ME może być kompilowany i uruchamiany w środowisku Javy SE. CLDC definiuje podzbiór standardowych pakietów Javy SE i dodaje klasy dopasowane do ograniczonych urządzeń. Pakiety zapożyczone z Javy SE to: java.io - pakiet wejścia-wyjścia umożliwiający wymianę danych za pomocą strumieni, java.lang - podstawowy pakiet języka, dołączany do każdego programu, zawierający m.in. klasy podstawowych typów obiektowych takich jak String, java.util pakiet narzędziowy, obsługujący m.in. kolekcje, tablice oraz operacje związane z czasem. Java SE w odmianie ME została pozbawiona takich elementów jak: finalizacja, klonowanie obiektów, dostęp do bibliotek natywnych poprzez JNI (Java Native Interface), modyfikacje Security Managera, grupy wątków, większość klas błędów pochodnych po Error, większość klas kolekcji i pracy z czasem, oraz niektórych strumieni.

3 Ze względu na obszerność pakietów służących do obsługi komunikacji ze światem zewnętrznym Javy SE, tzn. bibliotek wejścia-wyjścia oraz biblioteki komunikacji sieciowej, Java ME wprowadza swoje własne rozwiązanie pakiet javax.microedition.io, czyli - GCF - Generic Connection Framework. GCF zamiast używać wielu abstrakcji do różnych form komunikacji stosuje wspólną abstrakcję niezależnie od tego czy będzie komunikować się z plikiem czy innym komputerem w sieci. Służy do tego klasa Connector zwracająca odpowiednie połączenia w zależności od wybranego protokołu komunikacji. CLDC nie definiuje jednocześnie, żadnej implementacji protokołu. Definicje protokołów odnajdziemy dopiero w profilach. Otwarcie połączenia poprzez CLDC wygląda następująco: Connector.open("<protokół>:<adres>;<parametry>"); Symboliczne porównanie wielkości środowiska Java ME oraz środowisk Java SE i EE, a także dostępne profile rozszerzające konfiguracje przedstawia diagram na rys. 1. Dodatkowe pakiety Dodatkowe pakiety Dodatkowe pakiety (MSA) Personal Dodatkowe pakiety (JTWI, MSA) J2EE J2SE Personal basis Profil JDBC Profil Game Profil Foundation Profil MIDP (1.0) 2.0 Profil IMP (NG) Profil PDA Profil Digital Set Top Box JVM JVM CDC (1.0) 1.1 JVM CLDC (1.0) 1.1 KVM Rys. 1. Platforma Java ME w porównaniu ze środowiskami Java SE i EE Profile platformy Java ME CLDC nie zawiera mechanizmów interakcji z użytkownikiem, obsługi sieci i urządzeń masowych. W związku z tym trudno jest tworzyć aplikacje korzystając tylko z konfiguracji CLDC. W celu stworzenia funkcjonalnej aplikacji stosuje się dodatkowo profile. Profile uzupełniają konfiguracje poprzez dodanie klas zapewniających funkcje specyficzne dla określonego typu urządzenia lub segmentu rynku. Profile opracowane dla platformy CLDC to: Mobile Information Device Profile (MIDP) profil udostępniający funkcje sieciowe, komponenty interfejsu użytkownika i lokalną pamięć trwałą (jest podstawą dla specyfikacji Wireless Java) [8], Personal Digital Assistant (PDA) profil przeznaczony dla notesów elektronicznych, o większych ekranach, pamięci i możliwościach GUI; zawiera API Java do funkcji systemu operacyjnego,

4 Information Module Profile (IMP) profil przeznaczony dla urządzeń nie posiadających ekranu, takich jak automaty z napojami, czy urządzenia przemysłowe, Digital Set Top Box profil przeznaczony dla przystawek telewizji kablowych, zawiera Java 2 I/O API, sieć, grafikę oraz podzbiór biblioteki Java TV API odpowiedni dla tych urządzeń. Profil MIDP MIDP jest podstawowym profilem dla telefonów. Oprogramowanie MIDP działa na maszynie KVM lub HotSpot z CLDC i oferuje dodatkowe usługi dla aplikacji korzystających z API MIDP. Strukturę MIDP w kontekście całego środowiska Javy ME przedstawia rys. 2. Rys. 2. Struktura profilu MIDP Diagram przedstawia profil MIDP umieszczony pomiędzy konfiguracją CLDC i MIDletami, czyli aplikacjami wykorzystującymi konfiguracje CLDC i profil MIDP. Reprezentują go cztery podstawowe bloki funkcyjne: środowisko działania MIDletu, graficzny interfejs użytkownika, funkcje do komunikacji sieciowej i pamięć trwała. Z profilu mogą korzystać także aplikacje nie będące MIDletami, które są oparte na API specyficznym dla danej platformy sprzetowo-systemowej. Profil MIDP określa minimalne wymagania dla urządzeń, na których mają działać MIDlety. Należą do nich: przynajmniej monochromatyczny ekran, urządzenie wejściowe w postaci klawiatury jednoręcznej, dwuręcznej, albo ekranu dotykowego, dwukierunkowa komunikacja sieciowa, system operacyjny zapewniający chronione środowisko uruchomieniowe dla maszyny wirtualnej oraz obsługujący przerwania, wyjątki, planowanie, a także udostępniać jednostkę wykonania dla JVM. System operacyjny nie musi wspierać procesów i dzielenia pamięci, a także nie musi gwarantować ich czasowego wykonania i zachowania. Oprogramowanie urządzenia musi także generować zdarzenia na podstawie interakcji użytkownika oraz konwertować kody zdarzeń na kody zdarzeń MIDP. Platforma, na której mają być uruchamiane aplikacje MIDP musi również zarządzać cyklem życia aplikacji. Profil MIDP rozszerza konfigurację CLDC o następujące pakiety: javax.microedition.lcdui pakiet graficznego interfejsu użytkownika dostarcza zbiór funkcjonalności dla implementacji interfejsu użytkownika aplikacji MIDP, javax.microedition.lcdui.game - zbiór klas umożliwiających tworzenie bogatego oprogramowania do gier na urządzeniach bezprzewodowych, javax.microedition.midlet pakiet cyklu życia aplikacji definiuje aplikację MIDP i interakcję aplikacji z otoczeniem, javax.microedition.io pakiet sieciowy; wsparcie dla sieci oparte na Generic Connection Framework,

5 javax.microedition.pki pakiet klucza publicznego obsługuje certyfikaty do uwierzytelniania przesyłanych informacji, javax.microedition.media pakiet przetwarzania multimediów, javax.microedition.rms pakiet obsługujący utrwalanie danych w magazynach danych przechowujących rekordy binarne. Dodatkowo MIDP rozszerza pakiety CLDC, tzn. pakiet java.lang o funkcję Runtime.exit(), java.util o klasy Timer i TimerTask, pakiet javax.microedition.io o implementację protokołu HTTP. MIDlety Aplikacje Java, które możemy pobrać na telefon z sieci, np. po wysłaniu płatnego SMS-a to działające z profilem MIDP MIDlety. MIDlet to program napisany w języku Java posiadający odpowiednią strukturę. MIDlet musi posiadać niezbędne funkcje, które są wywoływane poprzez Application Management Software (AMS), czyli środowisko sprzętowo programowe telefonu zarządzające cyklem życia aplikacji począwszy od ich pobrania, poprzez instalację i uruchomienie do odinstalowywania. MIDlet składa się z co najmniej jednej klasy dziedziczącej po klasie MIDlet z pakietu javax.microedition.midlet. Cykl życia MIDletu kontrolowany jest przez metody klasy MIDlet, które muszą być implementowane przez każdy MIDlet. Do metod tych należą: metoda startapp() wywoływana przez AMS podczas uruchamiania MIDletu (również po jego uśpieniu), metoda pauseapp() służąca do zatrzymywania MIDletu i zapisywania jego stanu, np. w wyniku odebrania połączenia telefonicznego oraz metoda destroyapp() wywoływana przed jego zniszczeniem, w której najczęściej zwalnia się zasoby zajęte przez MIDlet, np. zamyka się nawiązane połączenia sieciowe. Szkielet MIDletu wygląda następująco: import javax.microedition.midlet.*; public class PiewszyMIDlet extends MIDlet{ PierwszyMIDlet(){ protected void startapp() throws MIDletStateChangeException{ protected void pauseapp(){ protected void destroyapp(boolean unconditional) throws MIDletStateChangeException{ MIDlety można dystrybuować pojedynczo lub jako zestawy. Zarówno pojedynczy MIDlet jak i zestaw MIDletów stanowi jeden pakiet (plik *.jar). MIDlety z jednego zestawu są instalowane jako jedna jednostka i współdzielą zasoby statyczne jak i dynamiczne środowiska urządzenia, a także

6 instancje wszystkich klas Javy, zasobów załadowanych do maszyny wirtualnej i danych zapisanych w pamięci trwałej. Przykładowe MIDlety demonstracyjne dostępne ze środowiskiem programistycznym Java ME Platform SDK przedstawia rys. 3. Rys. 3. Przykładowe MIDlety (od lewej): gra 3D, mapy i demonstracja interfejsu graficznego LWUIT Graficzny interfejs użytkownika MIDlety najczęściej są aplikacjami użytkowymi lub rozrywkowymi komunikującymi się z użytkownikiem poprzez interfejs graficzny. MIDlety wykorzystują ekrany telefonów do wyświetlania grafiki i jednocześnie umożliwiają użytkownikowi interakcję z aplikacją poprzez obsługę zdarzeń klawiatury, ekranu dotykowego i czujników wbudowanych w telefon. Ze względu na to, że MIDlety mogą być uruchamiane na różnych urządzeniach konieczne jest tworzenie uniwersalnego interfejsu użytkownika, który zawsze będzie wyglądał tak samo. Ograniczenia systemowe małych platform wyeliminowały bibliotekę Swing z Javy SE, a podstawowy model AWT Javy SE okazał się zbyt skomplikowany. Dlatego zamiast wyodrębniać komponenty z AWT stworzono specjalnie nowy interfejs przygotowany do małych ekranów i pracy w jednym oknie. Składa się on z małego zestawu klas, jest łatwiejszy do użycia i ma małe wymagania. API graficznego interfejsu użytkownika Javy ME składa się z dwóch części: API wysokiego poziomu - umożliwia tworzenie interfejsu graficznego aplikacji użytkowych składającego się z widoków pochodnych po klasie Screen umożliwiających wyświetlanie formularzy, tekstu, list wyboru i komunikatów; ma małe możliwości kontrolowania wyglądu ponieważ wymaga stosowania gotowych komponentów (jedynym wyjątkiem jest możliwość przygotowania własnego komponentu formularza), API niskiego poziomu - umożliwia niskopoziomową pracę z płótnami klasy Canvas, które reprezentują kontekst graficzny ekranu, czyli są zbiorem pikseli; ma większe możliwości zmiany wyglądu i interakcji z użytkownikiem, ponieważ dostarcza narzędzia do rysowania kształtów podstawowych, tekstu oraz wyświetlania obrazów; programista musi narysować wszystko na ekranie samemu i interpretować wszystkie dane wejściowe pochodzące od użytkownika. Zestaw klas składających się na API graficznego interfejsu użytkownika przedstawia diagram na rys. 4.

7 Rys. 4. Zestaw klas graficznego interfejsu użytkownika profilu MIDP Wyświetlanie grafiki możliwe jest dzięki klasie Display reprezentującej ekran urządzenia. Każdy MIDlet ma dostęp do jednego ekranu. Referencję do obiektu Display można uzyskać w programie poprzez metodę statyczną (MIDlet w przykładzie to aplikacja, która chce uzyskać referencję): Display ekran = Display.getDisplay(MIDlet); Stworzenie aplikacji GUI polega na dodaniu komponentów graficznych (w przypadku API wysokiego poziomu) lub rysowaniu (w przypadku API niskiego poziomu) na widoku pochodnym po klasie Displayable. Widok jest niewidoczny dopóki nie zostanie dodany do obiektu typu Display. Dodanie nowej zawartości ekranu, czyli obiektu klasy dziedziczącej po klasie Displayable (w naszym przypadku - formularza) wygląda następująco: Form formularz = new Form( Formularz testowy ); ekran.setcurrent(formularz); Jak było wspomniane powyżej, dwie podstawowe klasy widoków dziedziczących po Displayable to klasy Screen i Canvas. Klasa Screen to klasa podstawowa, z której dziedziczą widoki API wysokiego poziomu. W programie nie trzeba po niej dziedziczyć ponieważ są już przygotowane klasy widoków potomnych: Alert, Form, List i TextBox. Klasa Screen dodaje do Displayable opcjonalny tytuł i przewijający się tekst, ale nie pozwala na bezpośrednie rysowanie. Klasa Canvas służy do bezpośredniego rysowania podczas tworzenia interfejsu niskiego poziomu. Chcąc wykorzystać ją w programie, należy utworzyć klasę dziedziczącą. Na ekranie możemy rysować dzięki metodzie paint(). Po przesłonięciu metod klasy program może również reagować na zdarzenia naciśnięcia klawiszy i przesunięcia wskaźnika. Przykładowy kod źródłowy MIDletu wykorzystującego API wysokiego poziomu i widok TextBox przedstawiono poniżej:

8 import javax.microedition.midlet.*; import javax.microedition.lcdui.*; public class TextTest extends MIDlet{ protected Display ekran; protected TextBox oknotekst; protected Ticker banner; protected void startapp(){ oknotext = new TextBox( Okno tekstowe, Hello!!, 256, TextBox.ANY); banner = new Ticker( To jest miejsce na twoją reklamę. ); oknotext.setticker(banner); ekran = Display.getDisplay(this); ekran.setcurrent(oknotext); protected void pauseapp(){ protected void destroyapp(){ Wynik działania przedstawionego MIDletu przedstawia rys. 5. Rys. 5. MIDlet wykorzystujący widok typu TextBox

9 Obsługa zdarzeń MIDlety w celu zapewnienia interakcji z użytkownikiem wykorzystują zdarzenia. W API wysokiego poziomu i niskiego poziomu odbywa się to inaczej. W przypadku poziomu wysokiego wykorzystuje się w tym celu komendy. Komendę reprezentuje obiekt typu Command, który współpracuje z obiektem klasy Displayable i zawiera informacje o wykonanej komendzie, a nie o zachowaniu aktywowanym po wywołaniu komendy. O zachowaniu decyduje algorytm zawarty w klasie odbiorcy zdarzeń. Klasa odbiorcy zdarzeń to klasa implementująca interfejs CommandListener. Komendy reprezentowane są na ekranie urządzenia poprzez ich nazwy w dolnych narożnikach ekranu. Na rys. 5 widoczne są dwie komendy: Exit i Qwerty. Jedna z nich służy do zamknięcia MIDletu, a druga do zmiany trybu działania klawiatury urządzenia. Komendy są aktywowane poprzez naciśnięcia przycisków funkcyjnych telefonu znajdujących się najczęściej z prawej i lewej strony pod ekranem urządzenia lub poprzez dotyk w miejscu nazwy komendy na ekranie dotykowym. Poniżej znajduje się fragment MIDletu demonstrujący dodanie komendy i sposób implementacji algorytmu obsługi zdarzenia. public class MojMIDlet extends MIDlet implements CommandListener{ private static final Command wstecz = new Command( Wstecz, Command.BACK, 0);... //implementacja interfejsu w klasie MIDletu Display ekran = Display.getDisplay(this); okno2.addcommand(wstecz); okno2.setcommandlistener(this);... public void commandaction(command c, Displayable d){ if(c==wstecz){ //lub c.getcommandtype()==command.back ekran.setcurrent(okno1); Klasa MIDletu implementuje interfejs CommandListener. W związku z tym musi przesłaniać jego metodę commandaction(). Dzięki implementacji obiekt klasy może być odbiorcą zdarzeń związanych z wywołaniem komendy. Obiekt ten wiązany jest z komendą poprzez wywołanie metody setcommandlistener(this). Algorytm metody commandaction() zawiera sprawdzenie obiektu lub typu komendy, na podstawie którego podejmowane jest odpowiednie działanie. W tym przypadku po wybraniu komendy Wstecz na oknie2 nastąpi ustawienie na ekranie poprzedniego okna okna1.

10 W API niskiego poziomu do obsługi zdarzeń możemy wykorzystać metody klasy Canvas. W klasie dziedziczącej należy je przesłonić. W poniższym przykładzie, którego działanie polega na przesuwaniu trójkątnego obiektu na ekranie na nadpisano dwie metody: keypressed() - metodę odbiorcy zdarzeń reagującą na wciśnięcie klawisza na klawiaturze telefonu, który skojarzony jest z odpowiednia akcja gry (metoda getgameaction()) oraz metodę paint() posiadającą referencję do kontekstu graficznego ekranu i umożliwiająca rysowanie grafiki. Wciśnięcie klawisza powoduje obrót w kierunku ruchu i zmianę współrzędnych obiektu oraz wywołanie metody repaint(), która odświeża obiekty wyświetlane na ekranie i wywołuje metodę paint() rysującą trójkąt obrócony i przesunięty w odpowiednim kierunku. import javax.microedition.lcdui.*; class MojaKanwa extends Canvas{ private int x=0,y=0; private int kierunek; private Image obraz; MojaKanwa(){ try{ obraz = Image.createImage("/kursor.JPG"); catch(exception ex){ public void keypressed(int kodklawisza){ switch(getgameaction(kodklawisza)){ case Canvas.DOWN: y+=5; kierunek=1; repaint(); break; case Canvas.UP: y-=5; kierunek=2; repaint(); break; public void paint(graphics g){ g.drawimage(obraz, x, y, Graphics.TOP Graphics.LEFT); switch(kierunek){ case 1: g.drawregion(obraz, 0, 0, obraz.getwidth(), obraz.getheight(), Sprite.TRANS_ROT180, x, y, 0); break; case 2: break; Wynik działania opisywanego MIDletu przedstawia pierwsza ilustracja na rys. 6. Druga ilustracja demonstruje możliwości graficzne API niskiego poziomu platformy Java ME. Jest to gra wykonana z wykorzystaniem klasy GameCanvas.

11 a) b) Rys. 6. Przykładowe MIDlety wykorzystujące grafikę niskiego poziomu: a) MIDlet animujący ruch trójkątnego obiektu, b) gra. Podsumowanie Mimo dużej ekspansji smartfonów ciągle największą grupą użytkowanych telefonów komórkowych są prostsze i tańsze telefony funkcyjne. Na tego typu urządzenia możemy tworzyć aplikacje przy wykorzystaniu języka Java. Aplikacje Java są uniwersalne ponieważ nie wymagają modyfikacji w celu uruchomienia na różnych platformach sprzętowosystemowych dzięki zastosowaniu maszyny wirtualnej. Bogate biblioteki Javy ME umożliwiają tworzenie zaawansowanych aplikacji mobilnych korzystających np. z baz danych czy komunikacji sieciowej, a dzięki bibliotece Game API programiści mogą w prosty sposób tworzyć różnego rodzaju gry i aplikacje rozrywkowe. [1] Java SE Overview, [2] Java EE Overview, [3] Java ME Overview, [4] About JAVA for Mobil Devices, [5] Java Community Process, [6] Connected Limited Device Configuration (CLDC); JSR 139, [7] Java ME Technology CDC, html [8] Mobile Information Device Profile (MIDP); JSR 118,