Wybór Javy jako języka do programowania urządzeń przenośnych jest niejako naturalny. Przy tak dużej dynamice rynku (praktycznie co miesiąc pojawiają się nowe modele telefonów) przenośność oferowana przez Javę ma kolosalne znaczenie. Dodatkowym atutem są zapewniane przez Javę mechanizmy zarządzania pamięcią.
Ze względu na liczne ograniczenia wynikające ze specyfiki urządzeń oraz dostępnego API projektowanie aplikacji na telefony komórkowe nie jest proste. Wpływają na to m.in. takie czynniki, jak niewielkie wyświetlacze aparatów, mała wielkość pamięci dla aplikacji, brak obsługi liczb zmiennoprzecinkowych, JNI (Java Native Interface) oraz funkcji graficznych. Rezygnując częściowo z przenośności programów, można stosować oferowane przez producentów telefonów rozszerzenia standardowego API, które eliminują niektóre z wymienionych niedogodności.
Odrobina teorii
Midlety to aplikacje uruchamiane na urządzeniach przenośnych, napisane przy użyciu technologii J2ME (Java 2 Microedition). Na J2ME składają się następujące elementy:
–
znajdująca się na urządzeniu przenośnym maszyna wirtualna KVM (Kilobyte Virtual Machine), będąca okrojoną wersją JVM (Java Virtual Machine), wykonująca wygenerowany pseudokod (bytecode);
–
konfiguracje, czyli klasy podstawowe, które wraz z KVM pozwalają uruchamiać aplikacje na poszczególnych urządzeniach. Interesująca nas konfiguracja, przeznaczona m.in. na telefony komórkowe, to CLDC (ang. Connected Limited Device Configuration);
–
profile będące zbiorem bibliotek obsługujących interfejs użytkownika, zdarzenia, wyjątki itp. W tym artykule opisuję tworzenie programów przy użyciu profilu MIDP (Mobile Information Device Profile) 1.0.
Do tworzenia midletów potrzebny będzie implementacja profilów MIDP 1.0 oraz J2SDK (Java 2 Software Development Kit) – oba narzędzia można pobrać ze strony WWW firmy Sun (www.sun.com). Wygodnie będzie też posłużyć się jakimś środowiskiem programistycznym – np. Sun One Studio 4 ze zintegrowanym J2ME Wireless Toolkit.
Pisząc midlety, trzeba pamiętać, że kompilacja nie jest ostatnim etapem tworzenia aplikacji. Wygenerowane po kompilacji pliki muszą jeszcze przejść przez weryfikację (ang. preverification) polegającą na sprawdzeniu, czy w skompilowanych programach nie ma odwołań do funkcji nieobsługiwanych przez KVM, oraz dodaniu do pliku wynikowego informacji pozwalających na uruchomienie programu na maszynie KVM. Z otrzymanych w ten sposób plików oraz zasobów tworzy się pakiet midletów (ang. MID-let Suite), umożliwiający instalację programu na urządzeniu przenośnym.
Każdemu pakietowi może towarzyszyć plik opisu aplikacji (ang. application descriptor) o rozszerzeniu.jad. Pliki JAD są używane przez oprogramowanie zarządzające oprogramowaniem telefonu komórkowego do weryfikacji, czy dany midlet jest przystosowany do działania na konkretnym telefonie. Wspomniane zbiory mogą także zawierać zewnętrzne parametry konfiguracyjne.
Jak działa midlet?
Funkcjonowanie midletu kontrolowane jest przez tzw. Application Management Service (AMS). Jest on odpowiedzialny za umożliwienie instalacji i deinstalacji programu, a także za zarządzanie aplikacją w czasie jej działania. Polega to na tworzeniu nowej instancji midletu oraz zarządzaniu jego stanami. Midlet może się znajdować w jednym z trzech stanów –
Active, Paused
lub
Destroyed
(patrz: rysunek poniżej).
Sercem każdego midletu jest klasa wyprowadzona z abstrakcyjnej klasy midlet. Dziedziczenie z tej klasy umożliwia kontrolę aplikacji przez AMS dzięki wymuszeniu implementacji metod startApp(), pauseApp() oraz destroyApp(). Od strony obsługi interfejsu użytkownika MIDP udostępnia dwa rodzaje interfejsu programistycznego, tj. API nisko- i wysokopoziomowe.
API wysokopoziomowe zaprojektowano w sposób mający zapewnić jak największą przenośność programów między urządzeniami. Obsługa takich operacji, jak rysowanie, przewijanie ekranu czy nawigacja, zapewniona jest przez implementację MIDP na danym urządzeniu. Wada takiego rozwiązania to brak kontroli prezentowania informacji – wszystko jest wyświetlane zgodnie ze standardowym interfejsem telefonu. Klasą bazową dla klas wysokopoziomowego API interfejsu użytkownika jest Screen.
Z kolei API niskopoziomowe daje w zasadzie całkowitą kontrolę sposobu wyświetlania informacji. W tym przypadku zapewnienie przenośności pomiędzy różnymi urządzeniami spoczywa jednak na barkach programisty (największy problem stanowią w tym przypadku rozbieżności wynikające z rodzaju zainstalowanych wyświetlaczy, różniących się wielkością, proporcjami, liczbą dostępnych kolorów itp.). Bazą dla klas używających niskopoziomowego API interfejsu użytkownika jest klasa Canvas .
Każdy midlet zawiera jeden obiekt reprezentujący wyświetlacz urządzenia. Dostęp do niego można uzyskać poprzez wywołanie funkcji getDisplay(). Na wyświetlaczu mogą być umieszczane tylko obiekty pochodne od klasy Displayable .
