J2ME - Mobile Information Device Profile (MIDP)
1. Wstęp
Sun'owska wizja sieci bezprzewodowych to łatwy i niezawodny dostęp do informacji
w dowolnym czasie, z dowolnego miejsca i urządzenia. Na podstawie tej ideii powstał:
Mobile Information Device Profile:
Jest to standard, który określa wymagania aplikacji stosowanych w urządzeniach bezprzewodowych,
które wykorzystują platformę J2ME.
Umożliwia on także tworzenie aplikacji przez niezależnych programistów,
które będą działały we wszystkich urządzeniach bezprzewodowych zgodnych z tym standardem.
MIDP (Mobile Information Device Profile) oraz CLDC (Connected Limited Device Configuration)
zapewniają razem pełne środowisko dla aplikacji J2ME (Java 2 Micro Edition)
w przenośnych urządzeniach elektronicznych, takich jak telefony komórkowe i PDA.
Specyfikacja MIDP dotyczy takich zagadnień jak:
- interfejs użytkownika
- zasób pamięci trwałej
- sieć
- cykl życia aplikacji
2. Specyfikacja
Specyfikacja jest wynikiem Java Specification Request (JSR),
definiująca Mobile Information Device Profile (MIDP) dla Java 2 Platform,
Micro Edition (J2METM).
Została stworzona przez Mobile Information Device Profile Expert Group,
w skład którego wchodzą nasepujące firmy: America Online, DDI, Ericsson, Espial Group, Inc.,
Fujitsu, Hitachi, J-Phone, Matsushita, Mitsubishi, Motorola Inc.1, NEC, Nokia 2, NTT DoCoMo,
Palm, Research In Motion, Samsung, Sharp, Siemens, Sony, Sun Microsystems Inc.3, Symbian,
Telcordia Technologies Inc.
2.1. Wymagania
Poniższe wymagania są dodatkowymi wymaganiami do Connected, Limited Device Configuration.
Specyfikacja MIDP bierze pod uwagę ograniczenia elektronicznych urządzeń przenośnych
(moc, pamięć, łączność, rozmiar wyświetlacza).
2.1.1. Wymagania sprzętowe
Minimalne wymagania:
- Wyświetlacz
- Rozmiar ekranu: 96x54
- Głębia koloru: 1 bit
- Kształt pixela (proporcja): w przybliżeniu 1:1
- Wejście
- Jedno lub więcej następujących mechanizmów:
klawiatura telefonu, klawiatura QWERTY, ekran dotykowy
- Pamięć
- 128 kB nieulotnej pamięci dla komponentów MIDP
- 8 kB nieulotnej pamięci dla trwałych danych aplikacji
- 32 kB nieulotnej pamięci dla działania Javy (stos, itp.)
- Sieć
- Dwukierunkowa, bezprzewodowa, możliwa przerywana, z ograniczoną szerokością pasma
2.1.2. Wymagania programowe
Minimalne założenia:
- Minimalne jądro do zarządzania sprzętem (np. obsługa przerwań, wyjątków, minimalne szeregowanie).
Jądro musi zapewnić co najmniej jeden szeregowalny wątek, by uruchomić Virtualną Maszynę Javy.
- Mechanizm czytania i pisania z nieulotnej pamięci aby utrzymać API
- dostęp do czytania i pisania w bezprzewodowej sieci urzadzenia aby utrzymać API
- mechanizm zapewniający zapisywanie znaczników czasowych
w rekordach zapisanych w zasobach pamięci trwałej
- minimalna zdolność do zapisywania w mapie bitowej graficznego wyświetlacza
- mechanizm przechwytujący dane z wejścia z jednego (lub więcej) z trzech urządzeń
- machanizm zarządzający cyklem życia aplikacji urządzenia
2.2. Architektura
Celem tej specyfikacji jest stworzenie otwartego, rozbudowywalnego środowiska aplikacji
dla urządzeń przenośnych. Obrazek poniżej przedstawia poziomy architektury MIDP.
Nie wszystkie poziomy są wymagane.
Najniższy blok (MID) przedstawia poziom sprzętu urządzenia przenośnego.
Na szczycie tego poziomu jest native system software. Warstwa ta zawiera
system operacyjny oraz biblioteki użyte przez urządzenie.
Dalej jest warstwa oprogramownia - CLDC. Blok ten reprezentuje K-Virtual Machine (KVM)
oraz skojarzone biblioteki zdefiniowane przez specyfikację CLDC.
Dwie kategorie API są przedstawione na szczycie CLDC:
- MIDP: Zbiór API zdefiniowanych przez MIDP.
- OEM-specific: obszerne urozmaicenie urządzeń powoduje, że nie jest możliwe objęcie
wszystkich wymagań. Te klasy mogą umożliwić dostęp do specyficznych funkcji danego urządzenia.
Te aplikacje mogą nie zapewniać przenośności z innymi urządzeniami.
Najwyższa warstwa prezentuje możliwe typy aplikacji urządzeń przenośnych:
- MIDP: Aplikacja MIDP lub MIDlet, używa tylko API zdefiniowane przez
specyfikację MIDP i CLDC. Jest głównym typem aplikacji w urządzeniach przenośnych.
- OEM-Specific: Specyficzne aplikacje oparte na klasach, które nie są częścią
specyfikacji MIDP. Aplikacje nie są przenośne.
- Native: rodzima aplikacja, która nie jest napisana w Javie.
2.3. Zakres zdolności
Ponieważ zakres zdolności przenośnych urządzeń jest bardzo duży, specyfikacja skupia się tylko
na zbiorze API - pod względem przenośności:
- Aplikacja (np. definiująca semantykę aplikacji MIDP i sposób w jaki jest kontrolowana)
- Interfejs użytkownika
- Zasób pamięci trwałej
- Sieć
- Układ czasowy
2.3.1. Aplikacja
MIDP definiuje model aplikacji, pozwalający na współdzielenie ograniczonych zasobów urządzenia
przez wiele aplikacji lub MIDletów. MIDP definiuje czym jest MIDlet, jakie środowisko działania jest
dla niego dostępne i jak ono powinno być zachowane, by urządzenie mogło zarządzać jego zasobami.
Aplikacje MIDP muszą używać tylko funkcjonalności opisanej w specyfikacji MIDP.
Elementy zestawu MIDletu:
- środowisko dziłania
- opakowywanie zestawu MIDlet-u (MIDlety są pakowane w pojedynczy plik JAR)
- deskryptor aplikacji (do zarządzania MIDletem)
- cykl życia aplikacji
2.3.2. Interfejs Użytkownika
Wymagania stawiane interfejsowi użytkownika:
- urządzenia i aplikacje powinny być łatwe w obsłudze dla ludzi,
którzy nie są komputerowymi ekspertami
- urządzenia i aplikacje powinny być łatwe w obsłudze w sytuacjach,
kiedy użytkownik np. operuje jedną ręką
- trzaba mieć na uwadze, iż wyświetlacz jest mały
- interfejs aplikacji MIDP, powinien być kompatybilny z rodzimymi aplikacjami,
aby użytkownik połapał się w tym wszystkim
Struktura Interfejsu użytkownika podzielona została na dwie logiczne części API:
- poziom wysoki - mała kontrola nad wyglądem. Aplikacja nie definiuje wyglądu komponentów.
Wszystko (kształt, kolor, nawigacja, skrolling, itp.) jest przedstawiane przez implementację.
Zapewniona przenośność.
- poziom niski- duża kontrola graficznych elementów. Nie jest gwarantowna przenośność
2.3.3. Zasób pamięci trwałej
MIDP zapewnia dla MIDletów mechanzim trwałego zapamiętywania danych oraz późniejszego ich przetwarzania.
Mechanizm ten zwany jest Record Management System (RMS) i wzorowany jest
na prostej, zorientowanej rekordowo bazie danych.
2.3.4. Sieć
MIDP dziedziczy obsługę sieci po Connected, Limited Device Configuration (CLDC).
MIDP popiera protokół HTTP, który może być implementowany zarówno przez protokół IP (np. TCP/IP)
oraz protokół nie-IP (np. WAP, i-mode), by zapewnić dostęp do serwerów HTTP na internecie.
2.3.5. Układ czasowy
Aplikacje, które potrzebują opóźnienia lub przeszeregowania na dłuższy czas mogą skorzystajć z klas
Timer i TimerTask, zawierające funkcje:
- jednorazowego uruchomienia
- ponawianego uruchomienia w regularnych odstępach czasu
3. Pakiety i klasy
Pakiety i klasy wchodzące w skład J2ME - MIDP:
- java.util.Timer - ułatwienie dla wątków w szeregowaniu zadań
- java.util.TimerTask - zadanie które może być szeregowane przez Timer
- javax.microedition.rms - mechanizm obsługi zasobu pamięci trwałej
- javax.microedition.midlet - definicja aplikacji MIDP, interkacji między nimi
oraz środowiska w którym aplikacja działa
- javax.microedition.io - obsługa sieci oparta na CLDC
- javax.microedition.lcdui - interfejs użytkownika dla aplikacji
4. Zastosowanie
Aplikacje zgodne z Mobile Information Device Profile, to tak zwane midlety.
Midlety zyskują na popularności wraz ze zwiększaniem się ilości telefonów komórkowych
i palmtopów ze wsparciem dla Javy.
W sieci znaleźć można całe mnóstwo midletów -
w większości bezpłatnych lub należących do kategorii shareware.
Na przykład w telefonie Nokia 9210 Communicator za pomocą menedżera midletów możemy
instalować nowe aplikacje, uruchamiać je, a także usuwać te, które nie przypadły nam do gustu.
Każdy midlet składa się z dwóch plików - archiwum .jar oraz pliku .jad.
Aby pisać samodzielnie programy w oparciu o tę technologię potrzebne jest narzędzie
J2ME Wireless Toolkit - emulator urządzenia MIDP.
Poniżej przedstawiam zrzuty ekranu ukazujące przykładowe midlety.
Można znałeźć wśród nich ciekawe gry (np. Tetris czy Arkanoid),
programy użytkowe (HTTP Getter), demonstracje i inne.
5. Przykład - Hello World
/*
* Copyright 2000-2001 by Sun Microsystems, Inc.,
* 901 San Antonio Road, Palo Alto, California, 94303, U.S.A.
* All rights reserved.
*/
package examples.helloworld;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HelloWorld extends MIDlet implements CommandListener {
private Command exitCommand;
private TextBox tb;
public HelloWorld() {
exitCommand = new Command("Exit", Command.EXIT, 1);
tb = new TextBox("Hello MIDlet", "Hello, World!", 15, 0);
tb.addCommand(exitCommand);
tb.setCommandListener(this);
}
protected void startApp() {
Display.getDisplay(this).setCurrent(tb);
}
protected void pauseApp() {}
protected void destroyApp(boolean u) {}
public void commandAction(Command c, Displayable d) {
if (c == exitCommand) {
destroyApp(false);
notifyDestroyed();
}
}
}
6. Linki
Imponujący wybór midletów znaleźć można między innymi na następujących stronach: