Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00070 009757 11018343 na godz. na dobę w sumie
J2ME. Almanach - książka
J2ME. Almanach - książka
Autor: Liczba stron: 544
Wydawca: Helion Język publikacji: polski
ISBN: 83-7361-118-5 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie mobilne >> j2me
Porównaj ceny (książka, ebook, audiobook).
'J2ME. Almanach' to niezastąpione, podręczne kompendium wiedzy dla programistów korzystających z Java 2 Micro Edition (J2ME). J2ME to nowa rodzina specyfikacji powstałych w firmie SUN, opisujących uproszczoną, skondensowaną wersję platformy Java 2, która może być używana do tworzenia aplikacji działających na urządzeniach o bardzo ograniczonych zasobach, takich jak telefony komórkowe, palmtopy czy dwukierunkowe pagery.

W książce znajdziesz:

W książce zawarto znany z innych pozycji serii Almanach wydawnictwa O'Reilly obszerny alfabetyczny spis elementów języka, obejmujący klasy z wielu pakietów J2ME, w tym java.lang, java.io, java.util, java.microediton.io, java.microediton.lcdui, java.microediton.midlet i java.microediton.rms. Gdy zaczniesz pracować z J2ME, 'J2ME. Almanach' na stałe zagości na Twoim biurku i będzie podręcznym źródłem informacji.

Tysiące osób codziennie kupują nowe urządzenia wyposażone w możliwość uruchamiania aplikacji Javy. Jeśli chcesz, by były to także Twoje aplikacje, ta książka dostarczy Ci całej wiedzy potrzebnej do ich stworzenia.

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

IDZ DO IDZ DO PRZYK£ADOWY ROZDZIA£ PRZYK£ADOWY ROZDZIA£ SPIS TREĎCI SPIS TREĎCI J2ME. Almanach KATALOG KSI¥¯EK KATALOG KSI¥¯EK KATALOG ONLINE KATALOG ONLINE ZAMÓW DRUKOWANY KATALOG ZAMÓW DRUKOWANY KATALOG Autor: Kim Topley T³umaczenie: Pawe³ Gonera (rozdz. 0-5), Micha³ Dadan (rozdz. 6-18) ISBN: 83-7361-118-5 Tytu³ orygina³u: J2ME in a Nutshell Format: B5, stron: 544 TWÓJ KOSZYK TWÓJ KOSZYK DODAJ DO KOSZYKA DODAJ DO KOSZYKA CENNIK I INFORMACJE CENNIK I INFORMACJE ZAMÓW INFORMACJE ZAMÓW INFORMACJE O NOWOĎCIACH O NOWOĎCIACH ZAMÓW CENNIK ZAMÓW CENNIK CZYTELNIA CZYTELNIA FRAGMENTY KSI¥¯EK ONLINE FRAGMENTY KSI¥¯EK ONLINE Wydawnictwo Helion ul. Chopina 6 44-100 Gliwice tel. (32)230-98-63 e-mail: helion@helion.pl „J2ME. Almanach” to niezast¹pione, podrêczne kompendium wiedzy dla programistów korzystaj¹cych z Java 2 Micro Edition (J2ME). J2ME to nowa rodzina specyfikacji powsta³ych w firmie SUN, opisuj¹cych uproszczon¹, skondensowan¹ wersjê platformy Java 2, która mo¿e byæ u¿ywana do tworzenia aplikacji dzia³aj¹cych na urz¹dzeniach o bardzo ograniczonych zasobach, takich jak telefony komórkowe, palmtopy czy dwukierunkowe pagery. W ksi¹¿ce znajdziesz: • Wprowadzenie do platformy J2ME i ġrodowisk programistycznych, takich jak Java Wireless Toolkit • Szczegó³owy opis mo¿liwoġci i wymagañ CLDC, MIDP i MIDletów • Dog³êbne omówienie interfejsu u¿ytkownika stosowanego w MIDletach oraz wiele praktycznych wskazówek dotycz¹cych wykorzystania MIDP UI API • Prezentacjê sposobów w jaki u¿ywaæ Generic Connection Framework API w celu korzystania z bezprzewodowego Internetu, a tak¿e API dla przechowywania danych (MDIP Record Management System — RMS) W ksi¹¿ce zawarto znany z innych pozycji serii Almanach wydawnictwa O Reilly obszerny alfabetyczny spis elementów jêzyka, obejmuj¹cy klasy z wielu pakietów J2ME, w tym java.lang, java.io, java.util, java.microediton.io, java.microediton.lcdui, java.microediton.midlet i java.microediton.rms. Gdy zaczniesz pracowaæ z J2ME, „J2ME. Almanach” na sta³e zagoġci na Twoim biurku i bêdzie podrêcznym ĥród³em informacji. Tysi¹ce osób codziennie kupuj¹ nowe urz¹dzenia wyposa¿one w mo¿liwoġæ uruchamiania aplikacji Javy. Jeġli chcesz, by by³y to tak¿e Twoje aplikacje, ta ksi¹¿ka dostarczy Ci ca³ej wiedzy potrzebnej do ich stworzenia. Spis treści Przedmowa..........................................................................................................................7 Część I Wprowadzenie do API platformy Java 2 Micro Edition ......15 Rozdział 1. Wprowadzenie ...........................................................................................17 Czym jest platforma J2ME?...................................................p...................................................p............17 Specyfikacje dla J2ME ...................................................p...................................................p.... .................22 J2ME a inne platformy Java ...................................................p..............................................................23 Rozdział 2. Konfiguracja ograniczonych urządzeń bezprzewodowych ...............25 ...........26 ..................34 .............43 Maszyna wirtualna CLDC...................................................p...................................................p... Biblioteki klas CLDC...................................................p...................................................p..... Uruchamianie w KVM...................................................p...................................................p....... Zaawansowane zagadnienia dotyczące KVM ...................................................p...............................49 Rozdział 3. Profil informacji o urządzeniu przenośnym i MIDlety ....................61 Omówienie MIDP...................................................p...................................................p........... .................61 Platforma języka Java MIDP ...................................................p.............................................................66 MIDlety i zestawy MIDletów ...................................................p...........................................................67 Środowisko i cykl życia MIDletów...................................................p..................................................74 Tworzenie MIDletów ...................................................p...................................................p....... ...............79 Dostarczanie i instalowanie MIDletów ...................................................p...........................................94 4 Spis treści Rozdział 4. Interfejs użytkownika MIDletów ........................................................103 Przegląd interfejsu użytkownika ...................................................p...................................................104 API interfejsu użytkownika wysokiego poziomu ...................................................p.......................108 Rozdział 5. API niskiego poziomu do tworzenia interfejsu użytkownika MIDletów ......................................................163 Klasa Canvas ...................................................p...................................................p............. .....................163 Rysowanie oraz klasa Graphics...................................................p......................................................168 ............169 Atrybuty klasy Graphics ...................................................p...................................................p.. Rysowanie linii i łuków ...................................................p...................................................p.. ..............172 Przesuwanie punktu początkowego Graphics ...................................................p............................179 MIDlet z prostą animacją..............................p...................................................p...................... .............181 Klasa Graphics — obcinanie ...................................................p...........................................................184 Rysowanie tekstu...................................................p...................................................p......... ..................187 ..........................193 Obrazy ...................................................p...................................................p................... Przechwytywanie zdarzeń ...................................................p...................................................p.. .........198 Wielowątkowość i interfejs użytkownika...................................................p.....................................204 Rozdział 6. Bezprzewodowa Java. Obsługa sieci i pamięci nieulotnej ............207 Architektura sieci stosowana na małych urządzeniach ...................................................p.............208 Gniazda ...................................................p...................................................p.................. Datagramy ...................................................p...................................................p................ Połączenia HTTP...................................................p...................................................p.......... Pamięć nieulotna...................................................p...................................................p......... .........................212 ......................217 ..................222 ...................239 Rozdział 7. Konfiguracja CDC i jej profile..............................................................261 ............................261 CDC...................................................p...................................................p...................... Rozdział 8. Narzędzia uruchamiane z linii poleceń..............................................275 cvm: maszyna wirtualna konfiguracji CDC (Connected Device Configuration) ......................275 kdp: KVM Debug Proxy ...................................................p...................................................p..... ..........281 kvm: Kilobyte Virtual Machine ...................................................p......................................................283 midp: środowisko wykonywania aplikacji zgodnych z profilpem MID (MID Profile Execution Environment) ...................................................p....................................287 emulator: emulator z pakietu J2ME Wireless Toolkit...................................................p.................291 preverify: preweryfikator klas KVM ...................................................p.............................................296 MakeMIDPApp: narzędzie konwertujące pliki JAD na PRC ...................................................p....298 MEKeyTool: narzędzie do zarządzania certyfikatami z kluczami publicznymi.......................301 Spis treści 5 Rozdział 9. J2ME — środowiska programistyczne ...............................................305 ...............306 J2ME Wireless Toolkit...................................................p...................................................p.... ................321 MIDP for PalmOS ...................................................p...................................................p.......... ................332 J2ME a Forte For Java...................................................p...................................................p.... Inne zintegrowane środowiska programistyczne ...................................................p.......................338 Część II Opis API...................................................r................................341 Jak korzystać z opisu API ..........................................................................................343 Odnajdywanie potrzebnych pozycji...................................................p..............................................343 Jak czytać opisy klas...................................................p...................................................p.... ..................344 Rozdział 10. Pakiety i klasy J2ME ...........................................................................353 Pakiety J2ME ...................................................p...................................................p............. .....................353 Pakiety J2SE niedostępne w J2ME ...................................................p.................................................354 ..........355 Zawartość pakietów J2ME................................p...................................................p..................... Rozdział 11. java.io .....................................................................................................375 Rozdział 12. java.lang .................................................................................................389 Rozdział 13. java.util...................................................................................................417 Rozdział 14. javax.microedition.io............................................................................431 Rozdział 15. javax.microedition.lcdui ......................................................................445 Rozdział 16. javax.microedition.midlet ....................................................................479 Rozdział 17. javax.microedition.rms.........................................................................483 Rozdział 18. Indeks klas, metod i pól ......................................................................495 Dodatki...................................................r..................................................517 Skorowidz........................................................................................................................519 Narzędzia uruchamiane z linii poleceń Programiści J2ME mają do wyboru wiele graficznych środowisk programistycznych, umożliwiających tworzenie i debugowanie aplikacji. O niektórych z nich już wspomina- liśmy (lub wspomnimy w rozdziale 9.). W pewnych sytuacjach trzeba jednak posługiwać się niskopoziomowymi narzędziami, niedostępnymi z poziomu IDE. W tym rozdziale omówione zostały te narzędzia wywoływane z linii poleceń, które są najczęściej wyko- rzystywane przez programistów. cvm: maszyna wirtualna konfiguracji CDC (Connected Device Configuration) Dostępność Wzorcowa implementacja CDC, wzorcowa implementacja pro filu Foundation Składnia cvm [opcje] [właściwości] plikklasy [argumenty] Opis CVM jest maszyną wirtualną spełniającą wymagania określone w specyfikacji CDC. Ma ona wszystkie cechy, jakie powinna mieć maszyna wirtualna Java 2, a ponadto zawiera garbage collector zoptymalizowany do pracy w środowiskach o niewielkich zasobach 276 Rozdział 8. Narzędzia uruchamiane z linii poleceń pamięciowych. W celu skrócenia czasu potrzebnego na uruchomienie maszyny wirtualnej i ograniczenia jej wymagań odnośnie pamięci, zazwyczaj już na etapie jej kompilowania łączy się z nią podstawowe klasy języka Java, tak samo jak w przypadku maszyny wir- tualnej KVM (patrz rozdział 2.). CVM dostarczana jest w postaci kodu źródłowego i stanowi część wzorcowych imple- mentacji CDC i profilu Foundation, dostępnych na platfo rmy Linux oraz VxWorks. Opcje -version Wyświetla informacje na temat wersji maszyny wirtualnej, po czym kończy jej dzia- łanie. Po wywołaniu tego polecenia na ekranie zazwyczaj pojawia się coś takiego: java version „J2ME Foundation 1.0” Java(TM) 2, Micro Edition (build 1.0fcs-ar) CVM (build .0fcs-ar, native threads) -showversion Wyświetla te same informacje co –version, przy czym maszyna wirtualna nie jest zatrzymywana. Dzięki tej opcji informacje o wersji VM można zwrócić przed uru- chomieniem aplikacji. -fullversion Powoduje zwrócenie mniejszej liczby informacji niż opcja -version. Zazwyczaj wy- gląda to tak: java full version „1.0fcs-ar” Po wyświetleniu tych danych maszyna wirtualna jest zatrzymywana. -Xbootclasspath:list -Xbootclasspath=list Lista katalogów, plików JAR oraz plików ZIP, w których maszyna wirtualna będzie szukać klas uruchomieniowych, które nie zostały z nią zlinkowane na etapie kompi- lacji. Poszczególne elementy na liście powinny być oddzielane dwukropkami (Linux) lub średnikami (VxWorks). -Xbootclasspath/p:list -Xbootclasspath/p=list Umieszcza wskazane katalogi, pliki JAR oraz ZIP na początku istniejącej listy klas uruchomieniowych. Poszczególne elementy na liście powinny być oddzielane dwu- kropkami (Linux) lub średnikami (VxWorks). -Xbootclasspath/a:list -Xbootclasspath/a=list Dołącza wskazane katalogi, pliki JAR oraz ZIP na końcu istniejącej listy klas urucho- mieniowych. Poszczególne elementy na liście powinny być oddzielane dwukropkami (Linux) lub średnikami (VxWorks). cvm: maszyna wirtualna konfiguracji CDC (Connected Device Configuration) 277 -Xssrozmiar Ustawia rozmiar natywnego stosu wątków na rozmiar bajtów. Aby określić rozmiar w kilobajtach lub megabajtach, dołącz do wprowadzanej liczby literę k, K, m lub M. Zauważ, że między znakami -Xss a wprowadzaną liczbą nie może być spacji. Tak więc opcja -Xss1m jest zapisana poprawnie, ale -Xss 1m już nie. -Xmsrozmiar Ustawia rozmiar sterty (ang. heap). Zmiennej rozmiar nadaje się wartość w taki sam sposób, jak w przypadku opcji -Xss. Wartość ta może zostać zaokrąglona przez ma- szynę wirtualną do takiej, jaka będzie dla niej wygod na. -Xgc:opcje_dla_gc Przekazuje opcje dla garbage collectora. Zakres możliwych do stosowania opcji zale- ży od konkretnej implementacji gc. -Xverify:typ Określa zakres weryfikacji klas. Jeżeli nie określono typu lub wprowadzono wartość all, wówczas wszystkie wczytywane klasy podlegają weryfikacji. Chcąc poddawać weryfikacji jedynie klasy wgrywane zdalnie, wprowadź wartość remote, natomiast chcąc wyłączyć mechanizm weryfikacji, wpisz none. Jeżeli ta opcja zostanie pominięta, weryfikowane będą jedynie zdalnie wczytywane klasy. -Xdebug Uaktywnia w maszynie wirtualnej obsługę debugowania JPDA. Tę opcję wykorzystuje się wraz z -Xrunjdwp i można z niej korzystać tylko wtedy, jeżeli maszyna wirtualna została skompilowana w taki sposób, aby obsługiwała JVMDI. Więcej informacji na ten temat znajdziesz w jednym z następnych podrozdziałów, zatytułowanym „De- bugowanie”.. -Xrunnazwa:opcje Wczytuje do maszyny wirtualnej bibliotekę kodu natywnego o podanej nazwie. Ten argument może wystąpić więcej niż jeden raz, co pozwala wczytać większą liczbę bi- bliotek. Na każdej platformie ciąg nazwa zamieniany jest na nazwę biblioteki w inny sposób. W Linuksie stosowany jest wzorzec nazwabibl.so, natomiast w systemie VxWorks — nazwabibl.o. Jeżeli jednak maszyna wirtualna została skompilowana w taki sposób, aby umożliwiała debugowanie aplikacji, stosowane są odpowiednio wzorce nazwa- bibl_g.so oraz nazwabibl _g.o. Między -Xrun a nazwą biblioteki nie mogą pojawić się żadne spacje. Tak więc aby wczytać bibliotekę libjdwp.so (lub libjdwp.o), trzeba wpro- wadzić argument -Xrunjdwp. Zmienne systemowe sun.boot.library.path oraz java.library.path określają lokalizacje, które będą przeszukiwane w po- szukiwaniu bibliotek. Po nazwie biblioteki może opcjonalnie wystąpić grupa opcji, oddzielonych od niej dwukropkiem. Format i znaczenie tych opcji zależą od biblioteki. Jeżeli zawiera ona funkcję JVM_onLoad(), to jest ona wywoływana w chwili wczytywania biblioteki, a jednemu z jej argumentów przypisywany jest ciąg znaków, zawierający wprowa- dzone opcje. W jednym z kolejnych podrozdziałów, zatytułowanym „Debugowanie”, znajdziesz przykład wykorzystania tego mechanizmu. 278 Rozdział 8. Narzędzia uruchamiane z linii poleceń -Xtrace:wartość Włącza w maszynie wirtualnej niskopoziomowe śledzenie przebiegu wykonywania programu. Argument wartość określa, co dokładnie ma być śledzone. Powstaje on poprzez dodanie do siebie wybranych wartości z poniższej tabeli. Ta opcja jest do- stępna tylko wtedy, jeżeli maszyna wirtualna została skompilowana w taki sposób, aby umożliwiała debugowanie. Wartość Co będzie śledzone: 0x0000001 Wykonywanie kodu pośredniego (ang. byte-code) 0x0000002 Wykonywanie metod 0x0000004 Wewnętrzny stan pętli interpretera w chwili wywołan ia każdej metody i powrotu z niej 0x0000008 Szyba ścieżka synchronizacji 0x0000010 Wolna ścieżka synchronizacji 0x0000020 Operacje blokowania i odblokowywania muteksów 0x0000040 Spójne zmiany stanu 0x0000080 Początek i koniec operacji oczyszczania pamięci 0x0000100 Skanowanie zasobów głownych przez garbage collector 0x0000200 Skanowanie obiektów na stercie przez garbage collecto r 0x0000400 Alokacja obiektów 0x0000800 Wewnętrzne dane garbage collectora 0x0001000 Przejścia między bezpiecznymi a niebezpiecznymi stana mi garbage collectora 0x0002000 Wykonywanie statycznych inicjalizatorów klas 0x0004000 Obsługa wyjątków języka Java 0x0008000 Inicjalizacja i niszczenie sterty, globalna inicjali zacja stanu oraz bezpieczne wyjścia 0x0010000 Bariery odczytu i zapisu dla garbage collectora 0x0020000 Tworzenie map garbage collectora dla stosów języka Jav a 0x0040000 Wczytywanie klas 0x0080000 Sprawdzanie klas w wewnętrznych tablicach maszyny w irtualnej 0x0100000 Operacje systemowe na typach 0x0200000 Weryfikacja klas 0x0400000 Obsługa słabych referencji 0x0800000 Usuwanie klas z maszyny wirtualnej 0x1000000 Łączenie klas cvm: maszyna wirtualna konfiguracji CDC (Connected Device Configuration) 279 Zmienne systemowe Za pomocą argumentów mających następującą postać: -Dnazwa=wartość można nadawać wartości zmiennym o określonej nazwie, przechowywanym w tablicy zmiennych systemowych. Można je później odczytywać w k odzie programu: String value = System.getProperty(„name”); Wiele z nich ma specjalne znaczenie dla maszyny wirtualnej i podstawowych bibliotek klas. W szczególności poniższe zmienne systemowe wpływają na sposób wczytywania klas języka Java i bibliotek natywnego kodu: java.class.path Interpretowana jako lista katalogów, plików JAR oraz plików ZIP, z których będą wczytywane klasy aplikacji. Poszczególne wpisy na liście powinny być od siebie od- dzielane dwukropkami (Linux) lub średnikami (VxWorks). Ta zmienna CVM jest od- powiednikiem zmiennej środowiskowej CLASSPATH występującej w J2SE, przy czym jej wartość musi być określona ręcznie, ponieważ CVM nie sprawdza zawartości zmiennej CLASSPATH. W jednym z kolejnych podrozdziałów, o nazwie „Przykłady”, znajdziesz przykład wykorzystania tej zmiennej syst emowej w praktyce. sun.boot.class.path Ta zmienna pełni taką samą rolę jak java.class.path, z tym że określa ona poło- żenie klas systemowych (uruchomieniowych). Jej wartoś ć można określić w wygodny sposób, wprowadzając jedną z opcji -Xbootclasspath. java.library.path Lista katalogów oddzielonych od siebie dwukropkami (Linux) lub średnikami (VxWorks), które będą przeszukiwane w poszukiwaniu bibliotek z natywnym kodem, wykorzy- stywanych przez JNI. sun.boot.class.path Określa kolejność, w jakiej będą przeszukiwane biblioteki w poszukiwaniu klas uru- chomieniowych. Jest to systemowy odpowiednik java.library.path. Debugowanie Jeżeli maszyna wirtualna CVM została skompilowana z włączoną obsługą JVMDI, istnieje możliwość debugowania programu na poziomie kodu źródłowego, podłączając do CVM debugger JPDA. Oczywiście przy założeniu, że maszyna wirtualna została uruchomiona z opcjami -Xdebug oraz -Xrunjdwp. Druga z nich sprawia, że zostanie wczytana biblio- teka zawierająca implementację JDWP. Opcja -Xrunjdwp wymaga podania dodatkowych parametrów, dzięki którym biblioteka wie, jak ma się skonfigurować. Ogólna postać tego argumentu wygląda następująco: -Xrunjdwp:parametr=wartość[,parametr=wartość....] 280 Rozdział 8. Narzędzia uruchamiane z linii poleceń Niżej wymieniono wszystkie możliwe parametry i opisan o ich znaczenie: transport=typ Określa sposób przekazywania informacji, który powinien być wykorzystywany przez maszynę wirtualną w komunikacji z debuggerem. W chwili pisania tej książki obsłu- giwane były jedynie gniazda, a więc jedynym możliwym do wprowadzenia typem był dt_socket. address=wartość Adres, pod którym maszyna wirtualna powinna oczekiwać na połączenia inicjowane przez debugger. Format, w jakim należy wprowadzić wartość, zależy od wartości parametru transport. W przypadku wartości dt_socket trzeba podać numer portu TCP/IP. server=y|n Określa, czy biblioteka JDWP powinna pełnić rolę serwera (wartość y) czy klienta (war- tość n). Jeżeli chcesz odbierać połączenia od debuggera JPDA, powinieneś wprowa- dzić wartość y. suspend=y|n Jeżeli opcja ta ma wartość y, co jest przyjmowane domyślnie, to w chwili inicjalizacji kodu JVMDI maszyna wirtualna jest zatrzymywana do czasu, aż podłączy się do niej jakiś debugger. Normalnie ma to miejsce w momencie uruchamiania maszyny wirtu- alnej, ale inicjalizację mechanizmów debugowania można odroczyć do czasu poja- wienia się nieobsłużonego wyjątku lub wyjątku określonego typu. strict=y|n Określa, czy mechanizmy CVM odpowiedzialne za debugowanie aplikacji mają zacho- wywać się w pełni zgodnie ze specyfikacją JVMDI. Domyślnie opcja ta ma wartość n i raczej nie będziesz z niej często korzystał. onuncaught=y|n Domyślnie debugger inicjalizowany jest przy starcie maszyny wirtualnej. Jeżeli jed- nak nadasz tej opcji wartość y, proces ten zostanie odroczony do chwili pojawienia się nieobsłużonego wyjątku. Pozwala to uniknąć spowolnienia pracy maszyny wirtu- alnej do czasu wystąpienia błędu. onthrow=wartość Ta opcja jest podobna do onuncaught, z tym że odracza ona inicjalizację debuggera do czasu zgłoszenia konkretnego wyjątku (nie ma przy tym znaczenia, czy zostanie on obsłużony, czy nie). Argument wartość zawiera nazwę klasy interesującego nas wyjątku. Uruchomienie debuggera nastąpi gdy tylko zostanie zgłoszony jakiś wyją- tek tej konkretnej klasy. Na przykład aby zainicjalizować debugger w chwili zgłosze- nia wyjątku NullPointerException, napisz: onthrow=java.lang.NullPointerException stdalloc=y|n Gdy ta opcja ma wartość y, stosowane są standardowe metody alokacji pamięci z biblio- teki C. W przeciwnym wypadku maszyna wirtualna korzysta z własnego pakietu alo- kacji pamięci. Jest to zachowanie domyślne. kdp: KVM Debug Proxy launch=wartość 281 Sprawia, że po zainicjalizowaniu debuggera uruchamiana jest aplikacja, której nazwę przekazano w zmiennej wartość. Do aplikacji tej przekazywane są dwa parametry: nazwa (np. dt_socket) i adres połączenia, za pośrednictwem którego debugger komu- nikuje się z maszyną wirtualną. Parametr wartość powinien zawierać ścieżkę bez- względną lub nazwę pliku wykonywalnego, znajdującego się w jednym z katalogów przeszukiwanych przez maszynę wirtualną. Przykłady cvm -Xbootclasspath:../lib/foundation.jar -Djava.class.pa]th=/ home/user/project mojPakiet.mojaKlasa Wczytuje i uruchamia aplikację Javy, zaczynając od metody main() klasy mojPa- kiet.mojaKlasa. Klasy podstawowe, których nie wbudowano w maszynę wirtu- alną, wczytywane są z pliku ../lib/foundation.jar, natomiast klasy aplikacji znajdują się w katalogu /home/user/project. cvm -Xbootclasspath:../lib/foundation.jar -Djava.class.pa]th=/ home/user/project -Djava.library.path=/home/user/nativeco]de/ lib mojPakiet.mojaKlasa Uruchamia tę samą aplikację, przy czym tym razem biblioteki natywne wczytywane są z katalogu /home/user/nativecode/lib. Patrz również • Dokument „The Java 2 Platform, Micro Edition Connected Device Configuration (CDC) 1.0 Porting Guide” w archiwum zawierającym wzorcową implementację CDC lub profilu Foundation „Usuwanie błędów z programów napisanych w Javie w CVM” w rozdziale 7. Znaj- • duje się tam przykład pokazujący, jak uaktywnia się debugowanie JPDA. kdp: KVM Debug Proxy Dostępność Wzorcowa implementacja CLDC Składnia java kdp.KVMDebugProxy [opcje] 282 Opis Rozdział 8. Narzędzia uruchamiane z linii poleceń kdp jest aplikacją napisaną w języku Java, pełniącą funkcję pośrednika między debugge- rem zgodnym z JPDA a maszyną wirtualną, taką jak KVM. W pełni rozbudowane ma- szyny wirtualne, takie jak te dostarczane z J2SE, mają własne, wbudowane implementacje JDWP, pozwalające im bezpośrednio łączyć się z debuggerem. Natomiast ograniczenia zasobów, charakterystyczne dla typowych maszyn wirtualnych CLDC, nie pozwalają na pełną implementację JDWP. kdp, czyli proxy debuggera, umiejscawia się między debu- ggerem a maszyną wirtualną, co pozwala zdjąć „z barków” tej ostatniej niektóre szcze- góły implementacyjne. kdp zazwyczaj uruchamiane jest na komputerze typu desktop, dzięki czemu nie uszczupla ono zasobów platformy docelowej. Komunikuje się z KVM za pomocą gniazd, wykorzy- stując okrojoną wersję JDWP o nazwie KDWP (od KVM Debug Wire Protocol). Opcje -classpath ścieżka Określa położenie kopii plików klas, które zostaną wczytane do debugowanej ma- szyny wirtualnej. Wskazane lokalizacje, czyli nazwy katalogów lub plików JAR, od- dzielane są od siebie separatorem charakterystycznym dla danej platformy. Na przy- kład w systemie Windows jest to średnik, a pod Uniksem dwukropek). Ta opcja jest wymagana tylko wtedy, gdy stosuje się opcję -p. -cp ścieżka Synonim -classpath. -l lokalnyport Numer portu, na którym proxy debuggera oczekuje na połączenia inicjowane przez debugger zgodny z JPDA. -p Jeżeli zostanie wprowadzony ten argument, proxy debuggera będzie obsługiwało ope- racje dotyczące klas lokalnie, zamiast przekazywać je do docelowej maszyny wirtualnej. Argument ten stosuje się w sytuacji, gdy debugujemy za pomocą KVM i chcemy przenieść ciężar przechowywania informacji o poszczególnych klasach z maszyny wirtu- alnej na proxy debuggera. Trzeba też wprowadzić opcję -cp lub -classpath, tak aby proxy mogło wczytać także klasy wykorzystywane przez s amą maszynę wirtualną. -r host port Nazwa lub adres IP hosta, na którym pracuje debugowana maszyna wirtualna, oraz port, na którym oczekuje ona na połączenia pochodzące od proxy debuggera. Numer portu ustawia się za pomocą argumentu -port maszyny KVM. -v szczegółowość Umożliwia wyświetlanie informacji pochodzących z debuggera i określa stopień ich szczegółowości. Argument szczegółowość przyjmuje wartości z zakresu od 1 do 9, gdzie większa wartość oznacza bardziej szczegółowe deb ugowanie. kvm: Kilobyte Virtual Machine 283 Przykłady Aby uruchomić proxy debuggera i podłączyć je do maszyny wirtualnej KVM prowadzą- cej nasłuch na porcie 2000 na tej samej maszynie, wczytać pliki klas ze ścieżki określonej w zmiennej środowiskowej CP oraz oczekiwać na połączenia zainicjowane przez debu- gger na porcie 3000, należy wprowadzić polecenie: java kdp.KVMDebugProxy -l 3000 -p -r localhost 2000 -cp CP Patrz również • kvm Specyfikacja protokołu Debug Wire Protocol dostępna w archiwum ze wzorcową imple- • mentacją CLDC kvm: Kilobyte Virtual Machine Dostępność Wzorcowa implementacja CLDC Składnia kvm [opcje] plikklasy [argumenty] Opis Polecenie kvm stanowi wzorcową implementację maszyny wirtualnej Javy, spełniającą wymagania specyfikacji CLDC. KVM potrafi wczytywać klasy z dowolnego miejsca w strukturze katalogów lokalnego systemu plików bądź z plików JAR. Z myślą o zmniej- szeniu wymagań odnośnie pamięci i skróceniu czasu uruchamiania maszyny wirtualnej, KVM ma już zazwyczaj wkompilowane podstawowe bibliote ki klas. Polecenie kvm dostępne we wzorcowej implementacji CLDC nie umożliwia debugowania kodu. Dostępna jest jednak jego druga wersja, kvm_g. Współpracuje ona z proxy debu- ggera o nazwie kdp. Oferuje ona też zestaw dodatkowych opcji wprowadzanych z linii poleceń, dzięki którym można zażyczyć sobie, aby informacje zbierane przez debugger były kierowane do standardowego strumienia wyjściowego. Istnieje także możliwość skompilowania wersji KVM implementującej menedżera aplikacji (JAM), dzięki któremu można pobierać aplikacje z sieci i instalować je w lokalnym systemie plików. Jednak za- zwyczaj się z tego nie korzysta, ponieważ w większości przypadków stosuje się bardziej zaawansowane rozwiązania, oferowane przez emulatory urządzeń i inne polecenia midp. 284 Opcje Rozdział 8. Narzędzia uruchamiane z linii poleceń Następujące opcje dostępne są dla wszystkich wersji KV M: -version Wyświetla numer wersji wzorcowej implementacji CLDC, po czym kończy pracę ma- szyny wirtualnej. -classpath ścieżka Określa położenie plików klas, które mają być wczytane przez maszynę wirtualną. Na tej liście mogą znaleźć się nazwy katalogów lub plików JAR, oddzielone od siebie sepa- ratorem charakterystycznym dla danej platformy. Na przykład w systemie Windows jest to średnik, a pod Uniksem dwukropek. Omawianej zmiennej można też przypisać wartość zmiennej środowiskowej CLASSPATH. -heapsize rozmiar Ustawia rozmiar sterty (ang. heap), zastępując wartość domyślną dla danej imple- mentacji. Parametr rozmiar może mieć wartość bezwzględną, wyrażoną w bajtach (na przykład 131072), bądź zapisaną skrótowo, np. 512k lub 2M. Nie może ona być mniejsza niż 32K, ani większa niż 64M. -help Wyświetla składnię polecenia i listę wszystkich dostępnych opcji, po czym kończy dzia- łanie maszyny wirtualnej. Jeżeli maszyna wirtualna KVM została skompilowana z obsługą debugowania JPDA, dostępne są następujące, dodatkowe opcje: -debugger Uaktywnia w maszynie wirtualnej debugowanie JDPA. -port numer Określa numer portu, na którym maszyna wirtualna będzie odbierała połączenia pocho- dzące z proxy debuggera KVM. Przy braku jawnego wprowadzenia tej opcji stoso- wany jest port 2800. -suspend Sprawia, że maszyna wirtualna wstrzymuje wykonywanie aplikacji do czasu, aż zosta- nie poproszona przez zdalny debugger o jej wznowienie. Jest to domyślne postępo- wanie w sytuacji, gdy zostanie wprowadzony argument -debugger. -nosuspend Jeżeli wprowadzono argument –debugger, wykonywanie aplikacji nie zostanie wstrzy- mane, a maszyna wirtualna nie będzie czekać na to, aż podłączy się do niej debugger. Jeżeli w maszynę wirtualną wbudowano mechanizm śledzenia wykonywania programu, dostępne są następujące dodatkowe opcje: -traceall Uaktywnia wszystkie opisane poniżej opcje dotyczące śledzenia wykonywania pro- gramu. kvm: Kilobyte Virtual Machine 285 -traceallocation Umożliwia śledzenie przydzielania pamięci. Zapisywane są informacje o rozmiarze każdego zaalokowanego bloku oraz o ilości pozostałej wolnej pamięci. -tracebytecodes Umożliwia śledzenie wykonywania każdej instrukcji kodu pośredniego. Zwracane informacje zawierają nazwę instrukcji, wartości jej operandów oraz nazwę metody, której jest ona częścią. -traceclassloading Śledzi wczytywanie i inicjalizację klas. -traceclassloadingverbose Śledzi wczytywanie i inicjalizację klas oraz dostarcza więcej informacji zwrotnych niż -traceclassloading. -tracedebugger Śledzi operacje debuggera. -traceevents Uaktywnia śledzenie zdarzeń (takich jak poruszenie pisakiem) zgłaszanych przez plat- formę sprzętową. Zapamiętywany jest jedynie rodzaj zdarzenia. -traceexceptions Zapisuje informacje zgromadzone przez debugger za każdym razem, gdy wystąpi jakiś wyjątek. -traceframes Śledzi odkładanie ramek na stos i ich zdejmowanie, czyli zdarzenia zachodzące w chwili wywołania i wyjścia z metody. -tracegc Zapamiętuje czas, kiedy garbage collector rozpoczął i zakończył pracę, a także liczbę bajtów pamięci, którą uwało mu się uwolnić. -tracegcverbose Zwraca te same informacje co -tracegc, a ponadto informuje o obiektach, którym garbage collector się przygląda. -tracemethods Śledzi wejście i wyjście z każdej metody, zapisując n azwę klasy i metody. -tracemethodsverbose Śledzi wejście i wyjście z każdej metody, zapisując rodzaj wywołania (virtual, static, spe- cial, interface, etc.), nazwę klasy, nazwę metody oraz sygnaturę metody. -tracemonitors Śledzi aktywność monitora. Za pomocą monitorów kontroluje się zsynchronizowane metody i bloki kodu. -tracenetworking Śledzi aktywność sieciową. 286 Rozdział 8. Narzędzia uruchamiane z linii poleceń -tracestackchunks Śledzi tworzenie nowych stosów (gdy tworzony jest nowy wątek) oraz odkładanie ramek wykonywania (ang. execution frames) na stos i zdejmowanie ich z niego (podob- nie jak -traceframes). -tracestackmaps Śledzi operacje wykonywane na mapach stosu. Mapy stosu umożliwiają zapisywanie na stosie informacji o bieżących referencjach, które są potem wykorzystywane przez garbage collector. -tracethreading Śledzi zdarzenia odnoszące się do wątków, takie jak: Utworzenie wątku Uruchomienie wątku Przełączanie wątków Zatrzymanie wątku Wstrzymanie wątku Wznowienie wątku -traceverifier Śledzi pracę weryfikatora kodu pośredniego. Jeżeli w maszynę wirtualną wkompilowano menedżera aplikacji KVM JAM, można korzystać z następujących opcji: -jam Umożliwia korzystanie z menedżera aplikacji. Jeżeli wprowadzisz tę opcję, musisz też pamiętać o argumencie classfile, który powinien zawierać adres URL pliku deskryp- tora, opisującego aplikację, która ma zostać wczytana i uruchomiona. Format tego pliku opisany jest w dokumentacji „KVM Porting Guide”, wchodzącej w skład archiwum zawierającego wzorcową implementację CLDC, które można po brać z Internetu. -appsdir katalog Określa katalog lokalny, w którym mają być instalowane aplikacje wczytywane przez JAM. -repeat Wczytuje i wykonuje na okrągło aplikację, której klasę wskazano w linii poleceń, do czasu, aż użytkownik nie przerwie tej „karuzeli”. Przykłady kvm -classpath mojaApl.jar com.mojafirma.MojaApl Wczytuje i uruchamia klasę com.mojafirma.MojaApl, szukając klas w pliku JAR o nazwie mojaApl.jar. midp: środowisko wykonywania aplikacji zgodnych z profilem MID... 287 kvm_g -traceall -classpath mojaApl.jar com.mojafirma.Mo]jaApl Wczytuje i uruchamia klasę com.mojafirma.MojaApl, szukając klas w pliku JAR o nazwie mojaApl.jar. Zostaje uaktywnione zapisywanie wszystkich informacji debu- ggera. Uważaj, bo będzie ich naprawdę dużo. kvm_g -debugger -port 2850 -classpath mojaApl.jar com.mojafirma.MonjaApl Wczytuje klasę com.mojafirma.MojaApl, szukając klas w pliku JAR o nazwie moja- Apl.jar i wstrzymuje jej wykonywanie do czasu, aż na porcie 2850 pojawi się połączenie zainicjowane przez debugger. Patrz również Dokument „KVM Porting Guide”, który znajdziesz w archiwum zawierającym wzor- • cową implementację CLDC midp: środowisko wykonywania aplikacji zgodnych z profilem MID (MID Profile Execution Environment) midp: środowisko wykonywania aplikacji zgodnych z profilem MID... Dostępność Wzorcowa implementacja MIDP Składnia midp [opcje] midp [opcje] [-Xdescriptor nazwapliku] klasa midp [opcje] -Xdescriptor nazwapliku midp [opcje] -autotest URL_deskryptora [nazwa_MIDletu] midp [opcje] -transient URL_deskryptora [nazwa_MIDletu] midp [opcje] -install [-force] URL_deskryptora midp [opcje] -run (numer zestawu | nazwa pod jaką MIDlet zo]stanie zachowany) [nazwa_MIDletu] midp [opcje] -remove (numer zestawu | nazwa pod jaką MIDle]t zostanie zachowany | all) midp [opcje] -list midp [opcje] -storageNames 288 Opis Rozdział 8. Narzędzia uruchamiane z linii poleceń midp jest programem wykonywalnym, zawierającym implementację maszyny wirtualnej KVM, klasy wymagane przez profil MIDP w wersji 1.0, a także implementację podsys- temu zarządzania aplikacjami (Application Management Software). Jest to więc kompletne środowisko, w którym można testować i instalować MIDlety . Zarządzanie MIDletami i ich przechowywanie MIDlet składa się z jednego lub większej liczby plików klas oraz ze skojarzonych z nimi zasobów, przechowywanych w pliku JAR. Można też połączyć kilka MIDletów w tak zwany zestaw. Wszystkie MIDlety wchodzące w skład jednego zestawu zapisane są w tym samym pliku JAR i zarządza się nimi tak, jak gdyby były one pojedynczym MID- letem. Gdy korzystasz z polecenia midp, są one instalowane w symulowanej pamięci nieulotnej jako niepodzielna całość i na tej samej zasadzie odbywa się ich dezinstalacja. Co więcej, są one wykonywane na tej samej kopii maszy ny wirtualnej. Gdy chcesz przeprowadzić jakieś testy, możesz wczytywać MIDlety z lokalnego systemu plików, ale w praktyce prawie zawsze będą one pobierane z sieci lub wgrywane przez połączenie lokalne z jakimś hostem, na przykład komputerem typu desktop. Ponieważ plik JAR zawierający zestaw MIDletów może mieć znaczne rozmiary, z każdym zesta- wem skojarzony jest plik opisu archiwum (JAD), który jest na tyle mały, że można go szybko pobrać z sieci i który zawiera informacje o zestawie, na podstawie których użyt- kownik może zdecydować, czy chce go zainstalować. Oprogramowanie zarządzające aplikacjami (AMS) pracujące na urządzeniu MIDP (takim jak telefon komórkowy) za- zwyczaj najpierw pobiera plik JAD, którego lokalizacja określana jest przez adres URL. Jeżeli użytkownik zdecyduje się zainstalować dany zestaw MIDletów, AMS ściąga plik JAR, którego położenie można odczytać wśród informacji zapisanych w pliku JAD. Następnie zestaw MIDletów zapisywany jest na urządzeniu, co umoż liwia ich wczytywanie. Składnia polecenia midp ma wiele wariantów. Umożliwiają one uruchamianie MIDletów na wiele różnych sposobów i korzystanie z zestawu funkcji zarządzających, obsługiwa- nych przez AMS. Wykonanie MIDletu bez instalowania go na stałe Jeżeli tylko testujesz aplikację, możesz ją wykonać lub wczytać zestaw MIDletów i wy- brać ten z nich, który chcesz uruchomić, bez zapisywania go na stałe do symulowanej pamięci nieulotnej urządzenia. Najprostszym sposobem na uruchomienie wybranego MIDletu jest skorzystanie z tej postaci polecenia midp, w której wymagane jest określe- nie nazwy klasy MIDletu. Na przykład: midp -classpath . ora.ch4.FormExampleMIDlet Ta postać polecenia midp przydaje się do testowania MIDletów, które nie zostały jeszcze spakowane do pliku JAR. Jeżeli MIDlet musi odwoływać się do właściwości aplikacji, midp: środowisko wykonywania aplikacji zgodnych z profilem MID... 289 zapisanych w pliku JAD, możesz wprowadzić argument -Xdescriptor i określić loka- lizację pliku deskryptora, który ma zostać w tym celu użyty. Musi to być nazwa pliku występującego w lokalnym systemie plików: midp -classpath . -Xdescriptor ora\ch4\Chapter4.jad ora.ch4.FormEnxampleMIDlet Aby wywołać zestaw MIDletów i pozwolić użytkownikowi wybrać MIDlet, który ma zostać wykonany, wprowadź nazwę pliku JAD zestawu, ale p omiń nazwę klasy: midp -classpath . -Xdescriptor ora\ch4\Chapter4.jad Ta odmiana polecenia midp wymaga, aby zestaw MIDletów był spakowany w pliku JAR, którego nazwa figuruje w pliku deskryptora aplikacji pod atrybutem MIDlet- Jar-URL. Istnieje również możliwość tymczasowego zainstalowania zestawu MIDletów, wybrania jednego z nich, uruchomienia go, a następnie automatycznego odinstalowania całego zestawu. Służą do tego opcje -transient oraz -autotest. Na przykład: midp -transient http://www.midlethost.acme.com/suite.jad CalendnarMIDlet midp -transient http://www.midlethost.acme.com/suite.jad midp -autotest http://www.midlethost.acme.com/suite.jad CalendanrMIDlet Opcja -transient przeprowadza pojedynczy cykl zainstaluj/wykonaj/usuń, natomiast -autotest powtarza go do czasu, aż nie zostanie on przerwany przez użytkownika. Przydaje się to przy automatycznym testowaniu MIDletów, zwłaszcza tych, które nie wymagają interakcji ze strony użytkownika. Jeżeli w linii poleceń nie wprowadzono nazwy MIDletu, zostanie wyświetlona lista wszystkich aplikacji dostępnych w danym zestawie, z której użytkownik będzie mógł wybrać tę, którą będzie ch ciał uruchomić. Zarządzanie zestawami MIDletów Mechanizm AMS (Oprogramowanie zarządzające aplikacjami), wbudowany w polecenie midp, może być obsługiwany bądź z linii poleceń, bądź za pomocą graficznego interfej- su użytkownika. Poniższe polecenie uruchamia emulator telefonu komórkowego i wy- świetla menu, dzięki któremu użytkownik może poinformować AMS, że chce zainsta- lować zestaw MIDletów za pośrednictwem sieci. midp Informacje wymagane do pobrania i zainstalowania na stałe zestawu MIDletów mogą być też wprowadzone w linii poleceń, co pozwala na uniknięcie interakcji z graficzną postacią AMS: midp -install http://www.midlethost.acme.com/suite.jad midp -install -force http://www.midlethost.acme.com/suite.jad Za pomocą opcji -force można wymusić reinstalację już zainstalowanego zestawu MID- letów, bez usuwania wcześniejszej kopii. Polecenie midp obsługuje możliwość wczytywa- nia zestawów MIDletów z serwerów sieciowych za pośrednictwem mechanizmu OTA (patrz podrozdział „Dostarczanie over-the-air” w rozdziale 3.). Przesyłanie danych od- bywa się w tym przypadku z wykorzystaniem protokołu HTTP. 290 Rozdział 8. Narzędzia uruchamiane z linii poleceń Wprowadzając opcję -list, można uzyskać listę aktualnie zainstalowanych zestawów MIDletów: midp -list To polecenie wyświetla krótkie podsumowanie na temat każdego zainstalowanego zesta- wu MIDletów. Zwracane przez nie dane mogą wyglądać na przykład tak: [1] Name: Chapter4 Vendor: J2ME in a Nutshell Version: 1.0 Storage name: #J2#M#E 0020in 0020a 0020#Nutshell_#Chapter4_ Size: 23K Installed From: http://hostname/path/Chapter4.jad MIDlets: [lista MIDletów w zestawie] Każdy zestaw MIDletów ma nadany własny numer (1 w powyższym przykładzie) oraz nazwę, pod którą zostanie on zachowany, a której format zależy od konkretnej imple- mentacji. Polecenie midp tworzy ją według szablonu nazwaDostawcy_nazwaZesta- wu_, przy czym poprzedza wszystkie wielkie litery symbolem # i zamienia znaki nieal- fanumeryczne na odpowiadające im znaki zapisane w systemie Unicode, poprzedzając je znakiem procenta ( ). Pozwala to przechowywać nazwy bez żadnych przekłamań nawet na tych urządzeniach, które obsługują jedynie 8-bitowe znaki, bądź nie rozróżniają wiel- kich i małych liter. Listę nazw, pod którymi zapisane są wszystkie zestawy MIDletów występujące na urządzeniu, można poznać wydając polece nie: midp -storageNames Po zainstalowaniu zestawu MIDletów uruchamiasz emulator, w którym zostanie wyświe- tlona ich lista. Możesz z niej wybrać ten MIDlet, który ma zostać uruchomiony. W tym celu wprowadź opcję -run wraz z numerem lub nazwą, pod którą przechowywany jest dany zestaw: midp -run 1 midp -run #J2#M#E 0020in 0020a 0020#Nutshell_#Chapter4_ Na podobnej zasadzie, posługując się nazwą lub numerem zestawu, możesz go usunąć: midp -remove 1 midp -remove #J2#M#E 0020in 0020a 0020#Nutshell_#Chapter4_ Opcje Polecenie midp ma trzy opcjonalne argumenty: -classpath ścieżka Określa lokalizację plików klas MIDletów. Ta opcja przydaje się wówczas, gdy chcesz przetestować lokalnie zainstalowane MIDlety, które nie zostały jeszcze spakowane do plików JAR. Poszczególne lokalizacje, które mogą być nazwami katalogów lub na- zwami plików JAR, oddziela się od siebie separatorem specyficznym dla danej plat- formy. Na przykład w systemie Windows jest to średnik , a w Uniksie dwukropek. emulator: emulator z pakietu J2ME Wireless Toolkit 291 -help Wyświetla informacje na temat dostępnych opcji i sposobu ich użycia, po czym kończy działanie polecenia. -version Wyświetla obsługiwane wersje CLDC i MIDP oraz numer wersji pliku wykonywalnego, po czym kończy działanie polecenia. Poza tymi argumentami można stosować wszelkie opcje dostępne dla KVM (patrz wcze- śniejszy podrozdział „kvm: Kilobyte Virtual Machine”), w tym opcje związane z debu- gowaniem, o ile tylko polecenie midp zostało skompilowane w odpowiedni sposób. Patrz również • kvm • emulator emulator: emulator z pakietu J2ME Wireless Toolkit Dostępność J2ME Wireless Toolkit Składnia emulator [opcje] [nazwaklasy] Opis Polecenie emulator zapewnia środowisko, w którym można wykonywać aplikacje i zarzą- dzać nimi. Wchodzi ono w skład pakietu J2ME Wireless Toolkit. Pod względem funk- cjonalności i opcji, które można wprowadzać z linii poleceń, bardzo przypomina polece- nie midp, przy czym umożliwia ono stosowanie „skór” imitujących wygląd różnych urządzeń oraz plików konfiguracyjnych, co pozwala emulować różne urządzenia bez konieczności modyfikowania kodu. Choć można wywoływać emulator z linii poleceń, najczęściej dostęp do niego uzyskuje się pośrednio — poprzez interfejs KToolBar obecny w pakiecie Wireless Toolkit. Opcje Działanie polecenia emulator zależy od przekazanych do niego opcji. Wyróżniamy trzy tryby pracy: 292 Rozdział 8. Narzędzia uruchamiane z linii poleceń • Wyświetlanie informacji po wprowadzeniu opcji -help, -version oraz -Xquery. W tym przypadku argument nazwaklasy nie jest wymagany, a polecenie kończy swą pracę zaraz po zwróceniu żądanych informacji. • Uruchamianie MIDletu pochodzącego z lokalnego systemu plików bądź wczytanego z serwera sieciowego, ale bez instalowania go. W tym trybie pracy stosuje się opcję -classpath wraz z nazwą klasy lub opcję -Xdescriptor, której może, ale nie mu- si, towarzyszyć nazwa klasy. • Korzystanie z dostępnego na emulatorze oprogramowania zarządzającego aplikacjami do instalowania, uruchamiania oraz kasowania zestawów MIDletów bądź wyświe- tlania ich listy. W tym trybie pracy stosuje się opcj ę -Xjam. Poniżej znajduje się omówienie poszczególnych opcji emulatora. -classpath ścieżka Określa lokalizację plików klas MIDletów. Ta opcja przydaje się wówczas, gdy chcesz przetestować lokalnie zainstalowane MIDlety, które nie zostały jeszcze spakowane do plików JAR. Poszczególne lokalizacje, które mogą być nazwami katalogów lub na- zwami plików JAR, oddziela się od siebie separatorem specyficznym dla danej plat- formy. Na przykład w systemie Windows jest to średnik , a w Uniksie dwukropek. -cp ścieżka Synonim -classpath. -help Wyświetla dozwolone argumenty polecenia, po czym końc zy jego działanie. -version Wyświetla numer wersji pakietu J2ME Wireless Toolkit oraz wykorzystywanych przez niego implementacji CLDC i MIDP, po czym kończy wykonywan ie polecenia. -Xdebug Przygotowuje emulator na debugowanie w czasie rzeczywistym. Tę opcję trzeba sto- sować razem z -Xrunjdwp. -Xdevice:nazwa Uruchamia emulator urządzenia o podanej nazwie. Poszczególne urządzenia różnią się między sobą ilością dostępnej pamięci, urządzeniami wejściowymi oraz ekranami, a dla każdego z nich stosowana jest inna „skóra” emulatora. Domyślnie rozpozna- wane są następujące nazwy: DefaultColorPhone Telefon komórkowy z kolorowym wyświetlaczem DefaultGrayPhone Telefon komórkowy z wyświetlaczem pracującym w skali szarości MinimumPhone Podstawowy, dwukolorowy telefon Motorola_i85s Telefon komórkowy Motorola i85s emulator: emulator z pakietu J2ME Wireless Toolkit 293 PalmOS_Device Pseudourządzenie pracujące pod kontrolą systemu Pal mOS RIMJavaHandheld Bezprzewodowy palmtop Research In Motion -Xdescriptor:nazwaPliku Wczytuje zestaw MIDletów po zbadaniu zawartości wskazanego pliku JAD i pozwala użytkownikowi wybrać MIDlet, który ma zostać uruchomiony. Jeżeli zostanie wpro- wadzony opcjonalny argument classname, zakłada się, że określa on jeden z MID- letów w zestawie, który chcemy wywołać. Argument nazwaPliku może być adresem URL bądź ścieżką w lokalnym systemie plików. -Xheapsize:rozmiar Ustawia rozmiar sterty (ang. heap), zastępując wartość domyślną dla danej implementa- cji. Parametr rozmiar może mieć wartość bezwzględną, wyrażoną w bajtach (na przy- kład 131072), bądź zapisaną skrótowo, np. 512k lub 2M. Nie może ona być mniejsza niż 32K, ani większa niż 64M. -Xjam:polecenie Uruchamia emulator i wykonuje za pośrednictwem AMS operację określaną przez argument polecenie. Dozwolone operacje wymieniono w następnym podrozdzi ale. -Xquery Wyświetla właściwości wszystkich urządzeń, które emulator jest w stanie emulować, w tym ich opisy, oraz informacje na temat ich ekranów i urządzeń wejściowych. Jeżeli chcesz zobaczyć przykładowe zwracane wyniki, zajrzyj do jednego z kolejnych punk- tów pt. „Przykłady”. -Xrunjdwp:opcje Jeżeli ten argument używany jest wraz z -Xdebug, określa on sposób, w jaki zdalny debugger będzie się łączył z maszyną wirtualną, a także niezbędny do tego adres. Opcje mogą mieć następujące wartości: transport= transport ,address= adres ,server= y/n gdzie zmiennej transport trzeba przypisać wartość dt_socket, natomiast adres ma postać host:port. Argument server powinien mieć zawsze wartość y. -Xverbose:opcje Określa, na ile szczegółowe mają być informacje zwracane przez debugger. Opcjom można przypisać wartość all lub listę wybranych, oddzielonych od siebie przecin- kami wartości z poniższego zestawu: allocation bytecodes class classverbose events exceptions frames gc gcverbose methods methodsverbose monitors networking stackchunks stackmaps threading verifier 294 Rozdział 8. Narzędzia uruchamiane z linii poleceń Polecenia służące do zarządzania aplikacjami Argument -Xjam pozwala kontrolować oprogramowanie do zarządzania aplikacjami wbu- dowane w emulator. Zaraz za nim umieszcza się dwukropek oraz jedno z poleceń wy- mienionych w tabeli 8.1. Argument -Xjam można też wprowadzić bez żadnych dodat- kowych opcji. Spowoduje to uruchomienie emulatora i wyświetlenie graficznego interfejsu AMS, tak jak zostało to opisane w punkcie „Oprogramowanie do zarządzania aplika- cjami w Wireless Toolkit” w rozdziale 3. Tabela 8.1. Polecenia AMS emulatora wchodzącego w sakład pakietu Wireless Toolkit Polecenie force install=URL_deskryptora list remove=nazwa pod jaką przechowywany jest zestaw MIDletów Opis Gdy to polecenie używane jest wraz z poleceniem install, wymusza ono instalację zestawu MIDletów, nawet jeśli jest on już zainstalowany Instaluje zestaw MIDletów, których plik JAD znajduje się we wskazanej lokalizacji Wyświetla informacje dotyczące zainstalowanych pakie tów MIDletów, w tym numery i nazwy, pod którymi są one przechowywane. Format zapisu tych danych został już omówiony w podrozdziale „Zarządzanie zestawami MIDletów” Usuwa zestaw MIDletów o podanej nazwie remove=numer_zestawu Usuwa zestaw MIDletów o wskazanym numerze remove=all run=nazwa pod jaką przechowywany jest zestaw MIDletów storageNames transient=URL_deskryptora Usuwa wszystkie zainstalowane zestawy MIDletów Wyświetla listę wszystkich MIDletów wchodzących w skła d zestawu o podanej nazwie i pozwala wybrać użytkownik owi ten z nich, który ma zostać uruchomiony Wyświetla nazwy, pod którymi zainstalowane są wszystk ie dostępne na urządzeniu zestawy MIDletów. Nazwy te zostały dokładnie omówione we wcześniejszym podrozdziale, zatytułowanym „Zarządzanie zestawami MIDletów” Tymczasowo instaluje zestaw MIDletów, pozwalając użytkownikowi wybrać i uruchomić jeden z nich, po czym usuwa cały zestaw z urządzenia. Jeżeli zestaw j est już zainstalowany, instalacja jest pomijana, ale trz eba pamiętać, że na końcu zostanie on usunięty Przykłady emulator -cp dir1;dir2;dir3 ora.ch5.AttributesMIDlet Wykonuje MIDlet ora.ch5.AttributesMIDlet, wczytując jego klasy z podanej ścieżki. emulator: emulator z pakietu J2ME Wireless Toolkit 295 emulator -Xdebug -Xrunjdwp:transport=dt-socket,address=2000,] server=y -cp dir1;dir2;dir3 ora.ch5.AttributesMIDlet Wykonuje MIDlet ora.ch5.AttributesMIDlet, wczytując jego klasy z podanej ścieżki i przygotowując maszynę wirtualną na sesję de buggera. emulator -Xdescriptor:http://servername/path/suite.jad Wczytuje zestaw MIDletów, którego plik JAD wskazano w poleceniu, i pozwala użyt- kownikowi wybrać MIDlet, który ma zostać uruchomiony. emulator -Xdescriptor:http://servername/ path/suite.jad ora.ch5.AttributesMIDlet Wczytuje zestaw MIDletów, którego plik JAD wskazano w poleceniu, i uruchamia ten MIDlet, którego plik klasy nazywa się ora.ch5.AttributesMIDlet. emulator -Xquery Wyświetla informacje o wszystkich urządzeniach obsługiwanych przez emulator. Dla każdego z nich zwracane są tego typu dane: # Properties for device DefaultGrayPhone DefaultGrayPhone.description: DefaultGrayPhone DefaultGrayPhone.screen.width: 96 DefaultGrayPhone.screen.height: 128 DefaultGrayPhone.screen.isColor: false DefaultGrayPhone.screen.isTouch: false DefaultGrayPhone.screen.width: 96 DefaultGrayPhone.screen.bitDepth: 8 emulator -Xjam:install=http://servername//path/suite.jad Instaluje poprzez sieć ten zestaw MIDletów, którego plik JAD wskazano w wywołaniu polecenia. Jeżeli jest on już zainstalowany, wywołanie polecenia kończy się błędem. emulator -Xjam:install=http://servername//path/ suite.jad -Xjam:force Instaluje dany zestaw MIDletów, wymuszając przy tym zastąpienie jego wszelkich istniejących kopii. emulator -Xjam:run=#J2#M#E 0020in 0020a 0020#Nutshell_#Chapter5_ Wyświetla listę wszystkich MIDletów występujących w zestawie o wskazanej nazwie i umożliwia użytkownikowi wybranie tego z nich, który ma zostać wykonany. emulator -Xjam:storageNames Wyświetla nazwy, pod którymi przechowywane są wszystkie zainstalowane zestawy MIDletów. emulator -Xjam:remove=1 Usuwa zainstalowany zestaw MIDletów o numerze 1. Patrz również • midp 296 Rozdział 8. Narzędzia uruchamiane z linii poleceń preverify: preweryfikator klas KVM Dostępność Wzorcowa implementacja CLDC, wzorcowa implementacja MIDP , pakiet Wireless Toolkit Składnia preverify [opcje] nazwyklas | nazwykatalogów | nazwypli]kówJAR Opis Jest to preweryfikator klas, badający klasy, które mają zostać wczytane przez maszynę wirtualną zgodną z CLDC, taką jak na przykład KVM. Wszystkie klasy programu trzeba przed uruchomieniem zweryfikować, aby upewnić się, że mają one prawidłową postać i nie będą próbowały omijać reguł języka Java, co mogłoby doprowadzić do złamania systemu bezpieczeństwa. Polecenie preverify przetwarza określony zbiór plików wejściowych, w których zapisane są klasy, i zapisuje wyniki we wskazanej lokalizacji, która musi być inna niż lokalizacja źródłowa. Chcąc wskazać pliki klas, które mają zostać prz etworzone, można podać: • Zbiór nazw klas, w którym położenie każdej klasy określa się względem ścieżki prze- kazanej w argumencie -classpath lub przechowywanej w zmiennej środowiskowej CLASSPATH Nazwę pliku JAR bądź ZIP, zawierającego pliki klas • Nazwę katalogu, który ma być rekurencyjnie przeszukiwany w poszukiwaniu plików • klas, a także plików JAR oraz ZIP Wyniki pracy preweryfikatora zapisywane są w katalogu wskazanym po argumencie -d. Jeżeli taki argument nie zostanie wprowadzony, pliki trafią do katalogu o nazwie output. Zawartość plików JAR i ZIP jest natomiast zapisywana do plików JAR/ZIP o takich samych nazwach co pliki źródłowe, przy czym są one umieszczan e w katalogu output. Opcje @nazwapliku Określa nazwę pliku, z którego wczytywane są argumenty, które zostaną wprowa- dzone w linii poleceń. Plik ten może zawierać tylko jeden wiersz tekstu, w którym będą zapisane dopuszczalne przez program argumenty. Zostaną one przetworzone po odczytaniu pliku. Jeżeli w pliku mają znaleźć się nazwy innych plików i katalo- gów, należy umieścić je w cudzysłowach. Mogą one przy t ym zawierać spacje. preverify: preweryfikator klas KVM 297 -classpath ścieżka Określa położenie plików klas. Mogą to być nazwy katalo gów lub plików JAR, oddzielone od siebie separatorem specyficznym dla danej platformy (na przykład w systemie Win- dows jest to średnik, a w Uniksie dwukropek). Opcja -classpath powinna określać po- łożenie bibliotek podstawowych, jak również klas, które mają być poddane preweryfikacji, chyba że informacje te są już dostępne w zmiennej śro dowiskowej CLASSPATH. -cldc Jeżeli zostanie wprowadzony ten argument, preweryfikator klas będzie sprawdzał, czy nie wykorzystują one tych mechanizmów maszyny wirtualnej, które nie zostały ujęte w specyfikacji CLDC. Oznacza to, że klasy nie mogą korzystać z metod natywnych i operacji na liczbach zmiennoprzecinkowych, ani też finalizować obiektów. Jest to odpowiednik jednoczesnego wprowadzenia argumentów -nofinalize, -nofp oraz -nonative. -d nazwakataloguwyjsciowego Określa nazwę katalogu, do którego mają zostać zapisane klasy już po weryfikacji. Do- myślnie, przy braku tego argumentu, przyjmuje się, że katalog nazywa się output. Jeżeli preweryfikator będzie przetwarzał jakieś pliki JAR lub ZIP, efekty jego pracy również powędrują do tego katalogu. -nofinalize Wprowadzenie tego argumentu sprawia, że preweryfikator będzie sprawdzał, czy klasy nie próbują finalizować obiektów. Jeżeli natomiast zostanie on pominięty, a użyt- kownik nie wprowadzi opcji -cldc, próba finalizacji obiektu spowoduje w trakcie wykonywania programu wygenerowanie błędu. -nofp Wprowadzenie tego argumentu sprawia, że preweryfikator będzie sprawdzał, czy w klasach nie występują odwołania do liczb zmiennoprzecinkowych. Jeżeli natomiast zostanie on pominięty, a użytkownik nie wprowadzi opcji -cldc, próba finalizacji obiektu spowoduje w trakcie wykonywania programu wy generowanie błędu. -nonative Wprowadzenie tego argumentu sprawia, że preweryfikator będzie sprawdzał, czy w klasach nie zadeklarowano metod natywnych. Jeżeli natomiast zostanie on pomi- nięty, a użytkownik nie wprowadzi opcji -cldc, próba finalizacji obiektuspowoduje w trakcie wykonywania programu wygenerowanie błędu. Pamiętaj jednak, że aplikacje napisane specjalnie z myślą o pewnych zmodyfikowanych wersjach KVM mogą korzy- stać z metod natywnych. Zostało to opisane w rozdziale 2., w części zatytułowanej „Współpraca z kodem natywnym”. W tym przypadku opisywany argument nie znaj- duje zastosowania. -verbose Sprawia, że informacje kontrolne kierowane są do stan dardowego strumienia błędów. -verify-verbose Sprawia, że na standardowy strumień błędów kierowane są szczegółowe informacje kontrolne. Wprowadzenie tej opcji może zaowocować zwracaniem naprawdę dużych ilości informacji. 298 Rozdział 8. Narzędzia uruchamiane z linii poleceń Przykłady Chcąc poddać procesowi preweryfikacji pojedynczą klasę o nazwie ora.ch2.KVMPro- perties, znajdującą się względem bieżącego katalogu w lokalizacji tmpclasses\ora\ch2\ KVMProperties.class i zapisać jej zweryfikowaną wersję do pliku o nazwie output\ora\ ch2\KVMProperties.class, trzeba wpisać poniższe polecenie. Podstawowe biblioteki klas znajdują się w tym przykładzie w katalogu c:\j2me\j2me_cldc\bin\common\api\lclasses: preverify -classpath c:\j2me\j2me_cldc\bin\common\api\ lclasses;tmpclasses ora.ch2.KVMProperties Chcąc poddać weryfikacji wszystkie klasy zapisane w tmpclasses\native.jar, zapisać je w pliku native.jar w katalogu bieżącym i upewnić się, że nie występuje w nich finalizo- wanie obiektów ani operacje na liczbach zmiennoprze cinkowych, należy napisać: preverify -classpath c:\j2me\j2me_cldc\bin\common\api\lclasses -nnofp - nofinalize -d . tmpclasses\native.jar Aby zweryfikować wszystkie klasy zapisane w katalogu tmpclasses i jego podkatalogach oraz skierować klasy wynikowe do bieżącego katalogu, w którym ma zostać utworzona taka sama struktura katalogów, należy napisać: preverify -classpath c:\j2me\j2me_cldc\bin\common\api\lclasses -dn . tmpclasses Patrz również • kvm Dokument „KVM Porting Guide”, który znajdziesz w archiwum ze wzorcową imple- • mentacją CLDC MakeMIDPApp: narzędzie konwertujące pliki JAD na PRC Dostępność MIDP for PalmOS Składnia java -cp Converter.jar com.sun.midp.palm.database.MakeMIDPApp [opcje] plikjar Opis Polecenie MakeMIDPApp zamienia zestaw MIDletów, składający się z pliku JAD i JAR, na po- stać nadającą się do zainstalowania na urządzeniach z systemem PalmOS. MakeMIDPApp MakeMIDPApp: narzędzie konwertujące pliki JAD na PRC 299 jest narzędziem napisanym w języku Java, które znajdziesz w pliku INSTALL_DIR \ Converter\Converter.jar, gdzie INSTALL_DIR jest katalogiem, w którym zainstalowałeś oprogramowanie MIDP for PalmOS. Opcje -help Wyświetla składnię polecenia i listę rozpoznawanych p rzez nie opcji. -v Wyświetla szczegółowe informacje. Jeżeli wprowadzisz tę opcję dwukrotnie (np. -v -v), polecenie będzie zwracało jeszcze więcej informacji. -jad plik Wskazuje plik JAD zestawu MIDletów. Ten argument jest opcjonalny, ale jeśli go nie wprowadzisz, to wszelkie właściwości aplikacji zapisane w pliku JAD, które nie zostały też zapisane w manifeście pliku JAR, nie będą dostępne dla aplikacji. Omówienie wła- ściwości aplikacji znajdziesz w rozdziale 3
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

J2ME. Almanach
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: