System informacji gie*dowej na urz*dzenia mobilne

LABORATORIUM ARCHITEKTURY SYSTEMÓW KOMPUTEROWYCH
WYDZIAŁ ELEKTYCZNY
POLITECHNIKA POZNAŃSKA
System informacji giełdowej na
urządzenia mobilne
Inżynierska praca dyplomowa
Projekt zespołowy
Łukasz STACHOWIAK
Tomasz SOBKOWIAK
Promotor:
dr inż. Krzysztof BUCHOLC
Poznań 2009
System informacji giełdowej na urządzenia mobilne
Spis treści
WSTĘP ........................................................................................................................................... 4
1.
SYSTEM MOBILE STOCK MONITOR ....................................................................................... 4
2.
ARCHITEKTURA SYSTEMU MOBILE STOCK MONITOR ........................................................... 5
2.1.
Ogólny schemat............................................................................................................. 5
3.
BUDOWA SERWERA .............................................................................................................. 6
4.
APLIKACJA DLA PLATFORMY JAVA MICRO EDITION.............................................................. 7
4.1.
Wstęp ............................................................................................................................ 7
4.2.
Wprowadzanie do platformy Java Micro Edition .......................................................... 7
4.3.
Konfiguracje .................................................................................................................. 8
4.4.
Profile ............................................................................................................................ 9
4.5.
Konfiguracja Connected Limited Device Configuration .............................................. 10
4.6.
Profil Mobile Information Device Profile .................................................................... 11
4.7.
Szkielet budowy oraz cykl życia MIDletu .................................................................... 13
4.8.
Zapis danych w systemie Record Management System ............................................. 15
4.9.
Biblioteki dodatkowe .................................................................................................. 16
4.9.1.
J2ME Web Services ............................................................................................. 16
4.9.2.
OpenBaseMovil-db.............................................................................................. 17
4.9.3.
Lightweight UI Toolkit ......................................................................................... 18
4.9.4.
kXML .................................................................................................................... 19
4.10.
5.
Implementacja aplikacji .......................................................................................... 19
4.10.1.
Inicjalizacja aplikacji ............................................................................................ 19
4.10.2.
Baza danych......................................................................................................... 20
4.10.3.
Menu główne oraz struktura formularzy ............................................................ 22
Serwis WWW....................................................................................................................... 23
5.1. Funkcjonalność serwisu ................................................................................................... 23
ZAKOŃCZENIE.............................................................................................................................. 24
BIBLIOGRAFIA .............................................................................................................................. 25
3
System informacji giełdowej na urządzenia mobilne
WSTĘP
1. SYSTEM MOBILE STOCK MONITOR
4
System informacji giełdowej na urządzenia mobilne
2. ARCHITEKTURA SYSTEMU MOBILE STOCK MONITOR
2.1. Ogólny schemat
System Mobile Stock Monitor zbudowany w architekturze rozproszonej typu klientserwer. Ogólny schemat przedstawia poniższy rysunek.
Głównym elementem systemu jest Serwer MSM którego zadaniem jest
udostępnianie danych klientom mobilnym. Dane udostępniane przez serwer są
wcześniej pobierane z zewnętrznego źródła i zapisywane w bazie danych MSM.
5
System informacji giełdowej na urządzenia mobilne
3. BUDOWA SERWERA
6
System informacji giełdowej na urządzenia mobilne
4. APLIKACJA DLA PLATFORMY JAVA MICRO EDITION
Autorem rozdziału jest Łukasz Stachowiak
4.1. Wstęp
Zostanie napisany po zakończeniu pisania pracy.
4.2. Wprowadzanie do platformy Java Micro Edition
Początkowo język Oak stworzony przez Sun Microsystems na początku lat 90,
przeznaczony dla urządzeń mobilnych nie odniósł sukcesu. Pomimo tego, że był on
stworzony z myślą o tym by jak najbardziej ograniczyć liczbę błędów możliwych do
popełnienia przez programistę (co było udręką programistów C++) nie udało się
sprzedać żadnego urządzenia wyposażonego w obsługę tego języka. Po zmianie nazwy
na Java i kierunku rozwoju, język ten stał się najpopularniejszym językiem
programowania doby Internetu. Sukces zawdzięcza z pewnością obsłudze obiektowego
paradygmatu programowania, przenośności, łatwości w programowaniu rozproszonym,
bezpieczeństwu i niezawodności. Firma Sun po kilku latach ponownie rozpoczęła prace
nad obsługa urządzeń przenośnych co poskutkowało wydaniem PersonalJava (znanym
także pod nazwą pJava). Ostateczne uformowanie wszystkich edycji Javy nastąpiło w
1999 roku kiedy to Sun ogłosił istnienie trzech platform Java:

Java Enterprise Edition (Java EE) – dla aplikacji biznesowych

Java Standard Edition (Java SE) – dla aplikacji desktopowych

Java Micro Edition (Java ME) – dla urządzeń o ograniczonych zasobach
Platforma Java Micro Edition (Java ME) jest zbiorem technologii oraz specyfikacji
do tworzenia aplikacji dla urządzeń o ograniczonych zasobach takich jak telefony
komórkowe, urządzenia wbudowane, palmtopy. Platforma ta z czasem stała się
podstawową w tworzeniu gier oraz programów użytkowych na tych urządzeniach.
Językiem programowania na tej platformie jest oczywiście obiektowy język Java.
Ponieważ zbiór urządzeń przenośnych jest bardzo duży i co za tym idzie
możliwości każdego z nich są odmienne ze względu na liczbę posiadanej pamięci, moc
procesora, dostępne inne peryferia (np. ekran, głośnik) twórcy postanowili utworzyć
zbiór specyfikacji tworzących zbiór platform. Taka specyfikacja nazywana jest
konfiguracją
i
definiuje
ona
platformę
dla
określonego
zbioru
urządzeń
elektronicznych. Taka konfiguracja jest rozszerzana przez profile które dodają
7
System informacji giełdowej na urządzenia mobilne
określone możliwości w celu wyspecjalizowania platformy dla konkretnej grupy
urządzeń. Ponad to taka platforma może zostać wzbogacona o pakiety opcjonalne
nadające specyficzne możliwości lub obsługę konkretnych technologii. Na rysunku 5.1
przedstawiono schemat architektury platformy Java ME.
Rysunek 4.1. Architektura platform Java wraz z wyszczególnioną platformą Micro
Edition[2].
Taka architektura może wydawać się skomplikowana jednak firma Sun dość
intensywnie prowadziła rozmowy z producentami urządzeń aby objęła ona jak
największą ich liczbę. Skutkiem tego stało się praktycznie wprowadzenie nowego
standardu – większość nowych urządzeń przenośnych posiada w sobie obsługę
platformy Java ME.
4.3. Konfiguracje
Konfiguracja jest podstawą platformy, specyfikuje ona minimalne cechy grupy
urządzeń które obejmuje i tworzy spójne środowisko dla programistów. Środowisko
oprogramowania rodziny urządzeń, jest charakteryzowane przez następujące cechy:
8
System informacji giełdowej na urządzenia mobilne
 typ i ilość dostępnej pamięci
 typ i prędkość procesora
 typ połączenia sieciowego jakie udostępnia urządzenie
Java ME została podzielona na dwie główne konfiguracje:

Connected limited device configuration (CLDC) – przeznaczona jest dla
urządzeń takich jak telefony komórkowe, posiadających bardzo ograniczone
zasoby pamięciowe oraz moc procesora. Konfiguracja ta zostanie szerzej
opisana w jednym z następnych podrozdziałów.

Connected device configuration (CDC) – przeznaczona jest dla bardziej
rozbudowanych urządzeń na których możliwe jest uruchomienie bardziej
rozbudowanych programów. Przyjęto wymaganie co najmniej 2 MB pamięci
podręcznej aby możliwa była obsługa tej konfiguracji przez urządzenie. CDC
najczęściej przeznaczone jest dla urządzeń typu PDA.
Każda konfiguracja składa się z maszyny wirtualnej oraz zestawu podstawowych klas.
Ze względu na ograniczone zasoby urządzeń maszyna wirtualna Java ME nie może
zapewnić pełnej funkcjonalności którą posiada maszyna wirtualna Java SE. Dlatego jej
specyfikacja składa się z elementów języka Java oraz maszyny wirtualnej Java SE z
której nie musi posiadać. Np. w pierwszej wersji CLCD nie wymagana była obsługa
liczb zmienno przecinkowych i nie została ona zaimplementowana.
4.4. Profile
Profile rozszerzają konfigurację tak aby dopasować całą platformę do wymagań
konkretnej grupy urządzeń (jak np. telefony komórkowe). Wprowadzają nowe pakiety
klas dodające obsługę np. urządzeń wejścia wyjścia, ekranu, mediów, pamięci trwałej
itd. Profili zostało zdefiniowanych znacznie więcej niż konfiguracji, co więcej
wszystkie z nich zostały opracowane w ramach inicjatywy Java Community Process
(JCP). Program ten ma na celu zebranie grupy specjalistów w danej dziedzinie i
opracowanie spójnej specyfikacji dla danego problemu[4]. Dzięki takiemu podejściu
wszystkie stworzone profile, w których opracowywaniu brały udział firmy produkujące
docelowe urządzenia, są powszechnie zaakceptowane i mogą być obsługiwane przez
znacznie większą liczbę urządzeń.
Do najbardziej popularnych profili należą:
9
System informacji giełdowej na urządzenia mobilne

Mobile Information Device Profile

PDA

Foundation

Personal i Personal Basis
4.5.Konfiguracja Connected Limited Device Configuration
Przed przystąpieniem do pracy nad aplikacją koniecznie jest zapoznanie się ze
środowiskiem w jakim ta aplikacja będzie pracować. Dlatego w tym i w kolejnych
podrozdziałach zostaną omówione szczegóły konfiguracji CLDC, profilu MIDP a
następnie kilku podstawowych bibliotek z których autor korzystał w trakcie
implementacji.
Aplikacja Mobile Stock Monitor oparta jest o konfigurację Connected Limited Device
Configuration w wersji 1.1 która jest najczęściej spotykaną konfiguracją na
urządzeniach przenośnych. Ta konfiguracja posiada następujące wymagania sprzętowe:

160 kb pamięci nieulotnej dla maszyny wirtualnej oraz bibliotek podstawowych

32 kb pamięci podręcznej do uruchomienia aplikacji

16 lub 32 bitowy procesor
Obejmuje następujące elementy:

język Java

maszynę wirtualną (KVM)

biblioteki podstawowe (pakiety klas java.lang.* oraz java.util.*)

obsługę wejścia/wyjścia (pakiet klas java.io.*)

bezpieczeństwo

obsługę sieci

internacjonalizacja
Ze względu na niezwykle małe rozmiary maszyna wirtualna Java ME nazwana została
kilobajtową maszyną wirtualną (ang. kilobyte virtual machine) jednak przyjętą nazwą
stosowaną dla niej jest skrót KVM (z ang. kilobyte virtual machine).
Biblioteki wchodzące w skład specyfikacji to w większości biblioteki pochodzące ze
standardowej wersji Javy w wersji 1.3. Jednak ta lista została w znaczący sposób
10
System informacji giełdowej na urządzenia mobilne
ograniczona, nie tylko ze względu na oszczędność zasobów ale także bezpieczeństwo
oraz „oczyszczenie” języka z niezalecanych w użytku już klas oraz metod (oznaczone
jako przedawnione – ang. deprecated). W tej konfiguracji brakuje następujących
elementów:

refleksja – brak pakietu java.lang.reflect oraz metod w pakiecie
java.lang.Class związanych z refleksją

brak metod finalizujących finalize()

brak interfejsu Java Native Interface umożliwiającego uruchamianie kodu
napisanego w innym języku programowania niż Java

ograniczona została liczba typów wyjątków oraz błędów

zmniejszono liczbę metod w obsłudze wątków oraz uniemożliwiono tworzenie
ich grup a także wątków demonów

brak możliwości definiowania własnych klas ładujących
CLDC wprowadza dodatkowo jedną bibliotekę nazwaną Generic Connection
Framework której przeznaczeniem jest obsługa połączeń sieciowych. Ta biblioteka
jednak nie posiada implementacji obsługi żadnego protokołu sieciowego. Stanowi
jedynie interfejs na bazie którego należy tworzyć połączenia sieciowe. Konkretną
implementacją poszczególnych protokołów sieciowych zajmuje się rozszerzający
konfigurację
profil.
Biblioteka
ta
została
zdefiniowana
w
pakiecie
javax.microedition.io [3].
Wybór konfiguracji CLDC w wersji 1.1 dla tworzonej aplikacji ogranicza w niewielkim
zakresie liczbę urządzeń dla których może być ona przeznaczona. Jednak wybór ten był
jednak konieczny ze względu na brak obsługi liczb zmienno przecinkowych w wersji
1.0 tej konfiguracji. Bez tego typu operacji zarówno nie byłoby możliwe wierne
oddanie notowań giełdowych oraz aplikacja stała by się uboższa ze względu na
wymaganie ich obsługi przez biblioteki zewnętrze które także zostały użyte podczas
implementacji.
4.6. Profil Mobile Information Device Profile
Profil MIDP w wersji 2.0 jest najpopularniejszym profilem używanym w
urządzeniach przenośnych. Jego implementacja znajduje się na praktycznie każdym
modelu wydawanym modelu telefonu komórkowego. Profil ten w wystarczający sposób
11
System informacji giełdowej na urządzenia mobilne
rozszerza konfigurację CLDC zapewniając bardzo rozwinięte środowisko do tworzenia
aplikacji użytkowych oraz gier. Głównymi elementami wprowadzanymi przez MIDP
są:

obsługa protokołów sieciowych TCP, UDP, HTTP a także połączeń
szyfrowanych SSL

tworzenie interfejsu użytkownika

obsługa klawiatury

obsługa zdarzeń

wprowadzanie wielu kontrolek ułatwiających tworzenie gier

odtwarzanie dźwięków

obsługa dodatkowych urządzeń jak np. wbudowany aparat fotograficzny

utrwalanie danych w pamięci stałej

obsługa ekranów dotykowych
Zwiększona liczba bibliotek odbija się na wymaganiach sprzętowych narzucanych
urządzeniom. Wymagane jest dodatkowo:

256 kb pamięci trwałej

8 kb dodatkowej pamięci trwałej na zapis danych

128 kb pamięci podręcznej
Oraz urządzenie powinno dodatkowo posiadać:

ekran wielkości 96 na 54 piksele o co najmniej 1 bitowej głębi kolorów

urządzenie wejściowe typu klawiatura lub ekran dotykowy

połączenie sieciowe

możliwość odgrywania dźwięków

mechanizm zapisu oraz odczytu danych z pamięci trwałej

oraz obsługę innych elementów jak format PNG, kodowanie UTF-8. Ich lista
została zawarta w dokumencie [5]
Aplikacje MIDP nazywane są MIDletami i są rozprowadzane w plikach typu jar (java
archive). Możliwe jest także umieszczanie wielu MIDletów w jednym pliku jar
nazywanym zestawem MIDletów (ang. MIDlet Suits). Taki zestaw jest traktowany jako
całość i nie można usuwać pojedynczo MIDletów wchodzących w jego skład [5].
12
System informacji giełdowej na urządzenia mobilne
4.7.Szkielet budowy oraz cykl życia MIDletu
Profil MIDP narzuca określony szkielet budowy MIDletu a także definiuje cykl
życia aplikacji tego typu. Każdy MIDlet musi posiadać jedną klasę dziedziczącą po
abstrakcyjnej klasie basowej javax.microedition.midlet.MIDlet. Taka
klasa staje się główną w aplikacji i to od niej zaczyna się jej działanie. Abstrakcyjna
klasa MIDlet zawiera w sobie metody konieczne obsługi przejść między
poszczególnymi stanami cyklu życia, dodatkowo wymusza implementację kilku metod.
Najprostszy szkielet MIDletu przedstawia się następująco:
public class SzkieletMIDletu extends MIDlet {
protected void startApp() throws
MIDletStateChangeException {
}
protected void pauseApp() {
}
protected void destroyApp(boolean
unconditional)
throws MIDletStateChangeException {
}
}
Dodatkowo wymagane jest przez klasę posiadanie konstruktora bezargumentowego.
Jeśli taki nie zostanie zdefiniowany zostanie automatycznie utworzony podczas
kompilacji. Metody startApp, pauseApp, destroyApp są ściśle związane z
cyklem życia aplikacji. W urządzeniach typu telefon komórkowy konieczna jest obsługa
zdarzeń typu odebranie połączenia telefonicznego, aplikacja w takim momencie nie
może blokować nadchodzącej rozmowy lecz musi w poprawny sposób zostać
wstrzymana, a po zakończeniu rozmowy ponownie przywrócona do poprzedniego
stanu. Dlatego wydzielono trzy możliwe stany w jakich może znajdować się aplikacja:
zatrzymany, aktywny, zniszczony. Diagram poniżej przedstawia przejścia pomiędzy
poszczególnymi stanami.
13
System informacji giełdowej na urządzenia mobilne
Rysunek 4.2. Diagram przejść między poszczególnymi stanami aplikacji typu MIDlet.
Jak przedstawiono powyżej metody których implementacja jest wymuszana są
wywoływane przed przejściem w kolejny stan zgodnie z diagramem. Programista może
dzięki temu wykonać niezbędne czynności aby aplikacja bezpiecznie przygotowała się
do zmiany stanu.
Bardziej szczegółowego omówienia wymaga metoda destroyApp odpowiedzialna za
zwalnianie zasobów podczas zamykania aplikacji. Posiada on jeden parametr
uncoditional typu logicznego który decyduje czy operacja zamykania aplikacji
może zostać przerwana i pozostać w swoim aktualnym stanie czy zamknięcie aplikacji
jest nieuniknione. W pierwszym przypadku wartość tego parametru to false, może to
zostać wykorzystane np. by dać szanse użytkownikowi na zapisanie wyników pracy,
jeśli takiej możliwości nie ma i MIDlet musi zostać natychmiast zamknięty wartość
parametru to true.
Należy także zwrócić uwagę na wyjątek typu MIDletStateChangeException
który może zostać zgłoszony przez metody startApp oraz destryApp. Jest on
generowany w przypadku gdy zmiana stanu nie jest z jakiś powodów możliwa [1].
14
System informacji giełdowej na urządzenia mobilne
4.8.Zapis danych w systemie Record Management System
Profil MIDP wprowadza uniwersalny system zapisu i odczytu danych który
zapewnia przenośność między różnego typu urządzeniami. System ten jest oparty o
prostą rekordową bazę danych i nazwany został Record Management System (RMS).
W RMS dane utrwalane są w zbiorach rekordów. Taki zbiór jest przechowywany w
pamięci trwałej nawet po wyłączeniu aplikacja i jest dostępny przy każdym jej
uruchomieniu. Za integralność danych zawartych w rekordach odpowiada system
operacyjny danego urządzenia. Musi on zapewnić trwałość tych danych nawet podczas
takich sytuacji jak restart systemu czy jego wyłączenie spowodowane rozładowaniem
baterii.
Zbiory rekordów są tworzone w niezależny od platformy sposób. Każdy MIDlet może
ich utworzyć dowolną liczbę, jedynym warunkiem jest nadawanie każdemu unikalnej
nazwy w obrębie zestawu MIDletów. Nazwa może być dowolnym ciągiem znaków
Unicode (wielkość liter ma znaczenie) o maksymalnej długości 32 znaki. Możliwe jest
także nadawanie uprawnień zbiorom tak aby mogły być współdzielone przez większa
liczbę MIDletów. Ponad to zbiory są oznaczane znacznikami czasu który reprezentuje
datę ostatniej modyfikacji na nim wykonanej. Przy każdej operacji zwiększana jest
także jego wersja która jest reprezentowana przez liczbę całkowitą. Takie dodatkowe
oznaczenia ułatwiają w niektórych przypadkach synchronizację danych. Kiedy MIDlet
jest usuwany z pamięci telefonu wszystkie jego zbiory są także usuwane.
Każdy przechowywany rekord jest tablicą bajtów. Programista pragnący zapisać jakąś
daną musi najpierw zamienić ją na tablicę bajtów i dopiero wtedy będzie możliwego jej
zapisanie w systemie RMS. Rekordy w obrębie zbioru są automatycznie indeksowane.
Pierwszy rekord zapisywany posiada identyfikator 1 i dla każdego kolejnego
wprowadzanego rekordu ta wartość jest inkrementowana.
Dla programisty korzystającego z RMS najważniejszą klasą jest RecordStore która
odpowiada za zarządzanie wszystkimi danymi zapisywanymi w pamięci trwałej. Klasa
ta posiada wiele użytecznych metod z których do najważniejszych należą:

openRecordStore – tworzy nowy zbiór rekordów

addRecord – dodaje rekord do zbioru

setRecord – modyfikuje dany rekord
15
System informacji giełdowej na urządzenia mobilne

getRecord – pobiera wybrany rekord, metoda zwraca tablicę bajtów

enumarateRecords – metoda zwraca obiekt typu RecordEnumeration
pomocna przy przeglądaniu rekordów danego zbioru
Rekordy przeglądane za pomocą klasy RecordEnumeration można dodatkowo
filtrować
i
sortować.
Wystarczy
przypisać
obiekt
implementujący
interfejs
RecordFilter dla filtru oraz RecordComparator dla sortowania, daje to
możliwość przeglądania tylko wybranych rekordów w odpowiednim porządku [5].
Pomimo sporych możliwości Record Management System jest dla programisty dość
niewygodny w użyciu. Główną tego przyczyną jest zapis danych w postaci tablicy
bajtów, rodzi to dodatkowe problemy w konwersjach takiej tablicy na konkretne typy
danych. RMS jest jednak elementem profilu MIDP bez którego nie można stworzyć
funkcjonalnej aplikacji. W aplikacji która jest przedmiotem tego rozdziału RMS został
użyty do zapisu danych konfiguracyjnych oraz informacji o użytkowniku. Do
przechowywania większych zbiorów danych wykorzystana została biblioteka
OpenBaseMovil-db, która została utworzona właśnie na bazie RMS. Będzie ona
dokładniej omówiona w dalszej części rozdziału.
4.9.Biblioteki dodatkowe
Praktycznie wszystkie tworzone w dzisiejszych czasach aplikacje na wszelkie
możliwe platformy korzystają z zewnętrznych bibliotek aby zwiększyć bezpieczeństwo
oraz przyspieszyć proces ich tworzenia. Biblioteki takie są sprawdzonym i
uniwersalnym rozwiązaniem które może zostać zastosowane w bardzo szerokim
spektrum. Dlatego także w aplikacji Mobile Stock Monitor postanowiono skorzystać z
kilku sprawdzonych rozwiązań aby nie tylko przyspieszyć proces powstawania aplikacji
ale także zwiększyć funkcjonalność i zapewnić większą przenośność. Poszczególne
dodatkowe biblioteki zostaną omówione w kolejnych podpunktach.
4.9.1. J2ME Web Services
Specyfikacja J2ME Web Services została opracowana przez grupę ekspertów w
ramach inicjatywy Java Community Process. Jej celem było zdefiniowanie
opcjonalnego pakietu bibliotek odpowiedzialnych za przetwarzanie dokumentów XML
oraz poprawną komunikację z serwisami sieciowymi komunikującymi się poprzez
protokoły oparte o XML a w szczególności SOAP. Implementacja tej specyfikacji jest
16
System informacji giełdowej na urządzenia mobilne
przeznaczona zarówno dla konfiguracji CLDC jak i CDC i jej implementacja na
urządzeniu jest wymagana do poprawnego działania aplikacji Mobile Stock Monitor
[6].
4.9.2. OpenBaseMovil-db
System Record Management System pomimo dobrej idei aby stworzyć uniwersalne
rozwiązanie dla zapisu danych na urządzeniach przenośnych zostało w znaczący sposób
zepsute przez producentów konkretnych urządzeń. Nie każdy model urządzenia
obsługiwał system RMS w ten sam sposób. Np. pojawiały się problemy w
ograniczeniami na wielkość zbioru, lub ich liczbę. Tego typu różnice w znaczący
sposób utrudniają stworzenie uniwersalnej aplikacji zarządzającej dużym zbiorem
danych i niszczą idee niezależnych od platformy rozwiązań javowych. Twórcy
biblioteki OpenBaseMovil-db wyszli naprzeciw tym nieścisłością i stworzyli
uniwersalną relacyjną bazę danych niezależną od modelu urządzenia i ograniczeń przez
nie narzucanych. Biblioteka ta umożliwia tworzenie wielu baz danych, tabel, indeksów
czy wierszy w tabeli i jest ograniczona jedynie przez liczbę dostępnej przestrzeni w
pamięci trwałej. Nie zaimplementowano obsługi języka zapytań SQL jednak obiektowy
dostęp do danych został znacznie bardziej poszerzony w stosunku do systemu RMS.
Wprowadzono także podstawowe typy danych jakie mogą być przechowywane w
kolumnach:

BLOB

Boolean

Date

Image

Int

Long

Short

String
Zwalnia to programistę z kłopotliwej kontroli typów czy serializacji/deserializacji
obiektów podczas operacji na danych. Dla wbudowanych typów zaimplementowany już
zostały metody wyszukujące oraz sortujące. Ciekawą możliwością jest wyszukiwanie
wierszy w tabeli które posiadają odpowiednie (podane) wartości w większej liczbie
kolumn [7].
17
System informacji giełdowej na urządzenia mobilne
Inne możliwości oraz przykłady użycia tej biblioteki zostaną opisane w części
rozdziału poświęconej implementacji.
4.9.3. Lightweight UI Toolkit
Innym wyzwaniem stawianym przed programistami platformy Java ME jest
interfejs użytkownika. Pomimo jednakowego zestawu bibliotek standardowych
zawartych w profilu dla wszystkich urządzeń utworzona aplikacja może wyglądać i
zachowywać się zupełnie inaczej na różnych urządzeniach. Co więcej dość uboga liczba
kontrolek
zmusza
często
programistów
do
pisania
własnych,
trudnych
do
zaimplementowania rozwiązań. Tego typu problemy rozwiązuje biblioteka do tworzenia
bogatego interfejsu użytkownika Lightweight UI Toolkit (LWUIT). Jest to darmowe
rozwiązanie rozprowadzane na licencji GPL 1 zapewniające identyczny wygląd oraz
zachowanie aplikacji na każdym urządzeniu przenośnym. LWUIT zostało stworzone na
wzór biblioteki Java SE do tworzenia interfejsu użytkownika Swing, ten model
zapewnia łatwe przejście dla programistów mający doświadczenie wcześniej wyłącznie
z programowaniem aplikacji desktopowych na programowanie aplikacji na urządzenia
mobilne.
Do głównych cech biblioteki należą:

interfejsy klas podobne do Swingowych

duży zestaw gotowych komponentów

możliwość rozmieszczania komponentów w wielu rodzajach układów

łatwa zmiana styli komponentów (tzw. Look and Feel)

możliwość tworzenia motywów dla aplikacji

obsługa wielu czcionek

obsługa ekranów dotykowych

łatwe tworzenie animacji oraz efektów przejść między ekranami

internacjonalizacja

integracja z SVG

możliwość wyświetlania animacji 3D
Dodatkowo pomimo bogatego zestawu gotowych komponentów tworzenie własnych
jest znacznie prostsze niż w przypadków biblioteki standardowej.
1
[9]
18
Żadna klasa
System informacji giełdowej na urządzenia mobilne
komponentu w bibliotece LWUIT nie jest oznaczona słowem kluczowy final 2 co
oznacza, że programista może w łatwy sposób dziedziczyć jej zachowanie w własnych
podklasach i zmieniać jego wygląd oraz zachowanie dostosowując je do własnych
potrzeb. MIDlety tworzone za pomocą tej biblioteki charakteryzują się także wysoką
responsywnością, ponieważ komponenty rysowane są na osobnym wątku co nie
zatrzymuje aplikacji.
Razem z biblioteką rozpowszechniany jest także specjalny edytor zasobów, który
umożliwia tworzenie pakietów zasobów dla aplikacji LWUIT. Do takiego pakietu
możemy dołączyć czcionki, obrazy, animacje, tłumaczenia tekstów na poszczególne
języki a także gotowe motywy których tworzenie jest także jedną z funkcjonalności
programu.
LWUIT wymaga środowiska CLDC 1.1/MIDP 2.0 oraz 272 kb pamięci trwałej dla
zestawu bibliotek [8].
4.9.4. kXML
Niektóre komunikaty odbierane z serwera są w postaci dokumentów XML. Aby je
przetworzyć w poprawny sposób wykorzystywana jest biblioteka kXML. Jej niezwykle
małe rozmiary (składa się z zaledwie 3 klas) oraz możliwości wystarczające do
przetwarzania mało skomplikowanych wiadomości XML w bardzo dobry sposób
wpasowują ją do zastosowań w aplikacjach Java ME. Przykłady użycia biblioteki
zostaną opisane w podrozdziale dotyczącym implementacji [11].
4.10. Implementacja aplikacji
W następnych podrozdziałach autor przedstawi szczegółowy opis implementacji
najważniejszych części programu.
4.10.1.
Inicjalizacja aplikacji
Główną klasa aplikacji jest MSMClient która to jest podklasą klasy MIDlet. Z tego
względu jest ona zmuszona implementować metodę startApp od jakiej rozpoczyna się
uruchomienie aplikacji. Metoda ta wykonuje podstawowe operacje. W pierwszej
kolejności inicjalizowany jest ekran poprzez wywołanie metody Display.init() w której
jako parametr podawany jest obiekt MIDletu. Następnie wczytuje się główny motyw
graficzny.
2
Klasy języka Java oznaczone słowem kluczowym final nie mogą podlegać dziedziczeniu [10].
19
System informacji giełdowej na urządzenia mobilne
Resources r = Resources.open(THEME_FILE);
UIManager.getInstance().
setThemeProps(r.getTheme(r.getThemeResourceNames()[0]));
W pierwszej linii następuje wczytanie zasobu znajdującego się w katalogu
wskazywanym przez stałą 3 THEME_FILE a w kolejnej jego wczytanie oraz
zastosowanie jako głównej. W jednym zbiorze może znajdować się więcej niż jeden
motyw dlatego metoda getThemeResourceNames zwraca tablicę w której następuje
odwołanie do pierwszego elementu.
Po tej operacji możliwe jest wyświetlenie okna z informacją dla użytkownika,
o wczytywaniu aplikacji, co realizuje następujący kod:
4.10.2.
Baza danych
Biblioteka OpenBaseMovil-db umożliwia utworzenia na bazie systemu zapisu RMS
imitacji bazy danych w środowisku Java ME. Baza danych zastosowana w aplikacji
składa się z dwóch tabel, które przedstawione są na poniższym schemacie.
Rysunek 4.3. Diagram przedstawiający tabele dostępne w bazie danych
W tabeli stockcorps przechowywane są informacje na temat spółek giełdowych, które
może obserwować użytkownik. Poszczególne kolumny przechowują następujące
informacje:

Id – całkowitoliczbowy identyfikator spółki

shortname – nazwa skrócona spółki (3 znaki)
Przyjęło się tak nazywać zmienne oznaczone jako statyczne oraz finalne jednocześnie, pomimo tego, że
w języku Java nie istnieje taki byt jak stała.
3
20
System informacji giełdowej na urządzenia mobilne

name – pełna nazwa spółki (maksimum 30 znaków)

observed – wartość boolowska określająca czy użytkownik obserwuje daną
spółkę
Drugą tabelą jest stockquotes przechowująca informację na temat notowań spółek:

stock_id – identyfikator spółki

price – cena akcji

change – zmiana w stosunku do poprzedniej wartości (procentowo)

total – obrót (w tyś. zł.)

date – data kiedy spółka posiadała takie notowania

last_result – pole pomocnicze oznaczające czy dane w tym rekordzie są
najbardziej aktualne
Pola price oraz
OpenBaseMovil-db
change przechowywane
niestety
nie
jako liczby całkowite.
umożliwia
Biblioteka
przechowywania
liczb
zmiennoprzecinkowych dlatego te wartości przed zapisem są mnożone przez 100 i
zapisywane jako całkowite.
Za tworzenie i zarządzenie bazą danych odpowiada obiekt klasa typu singleton 4
MSMDb przechowywana w pakiecie msm.j2meclient.data. Struktura bazy
tworzona jest jednokrotnie podczas pierwszego uruchomienia aplikacji na urządzeniu.
Za tę operację odpowiada metoda createDB:
dbh = Database.connect(DATABASE_NAME);
if (dbh.getVersionMajor() == (short) 0) {
dbh.drop();
dbh = Database.create(DATABASE_NAME);
dbh.setVersionMajor((short) 1);
createTables(dbh);
}
W pierwszej kolejności wykonywane jest łączenie z bazą danych, która gdy nie istnieje
jest automatycznie tworzona. Aby stwierdzić czy baza wcześniej nie została utworzona
wykorzystywana jest informacja o wersji bazy. W przypadku gdy jej wartość jest równa
4
Klasy typu singleton mogą posiadać tylko jedną instancję[wstawić literature].
21
System informacji giełdowej na urządzenia mobilne
zero, oznacza to, że nie została wcześniej utworzona i wykonywane jest usuwanie
informacji, przypisanie wersji równej jeden, a następnie w metodzie createTables
tworzenie struktury.
Przykładowe utworzenie tabeli stockcorps wygląda następująco:
Table stockCorpTable = new Table("stockcorps");
stockCorpTable.addColumn("id", Constants.FT_LONG);
stockCorpTable.addColumn("shortname", Constants.FT_STRING,
5);
stockCorpTable.addColumn("name", Constants.FT_STRING, 30);
stockCorpTable.addColumn("observed", Constants.FT_BOOLEAN);
W pierwszej kolejności tworzony jest obiekt typu Table a następnie za pomocą metody
addColumn dodawane są kolumny. Informacja potrzebna do stworzenia kolumny to jej
nazwa, oraz typ danych jaki będzie przechowywać. Nazwy typów danych jakie mogą
być przechowywane zdefiniowane zostały jako stałe w klasie Constants biblioteki
OpenBaseMovil-db. Biblioteka ta aby możliwe było wyszukiwanie danych wymusza na
programiście zdefiniowanie indeksów na poszczególnych kolumnach. Przykładowo
indeks na polu id tworzy się następująco:
stockCorpTable.createIndex("id_index", "id");
Dzięki temu możliwe jest teraz wyszukiwanie po wartościach w polu id.
Po zakończeniu tworzenia tabeli zostaje ona zapisana w wywołaniu metody na obiekcie
bazy danych createTable której parametrem jest tworzona tabela.
Podczas pierwszego uruchomienia dodawane do bazy są także informacje o wszystkich
spółkach dostępnych. Proces ten ze względu na dużą ich liczbę może trwać do 2-3
minut.
4.10.3.
Menu główne oraz struktura formularzy
22
System informacji giełdowej na urządzenia mobilne
5.
Serwis WWW
Autorem rozdziału jest Łukasz Stachowiak
5.1.
Funkcjonalność serwisu
W dzisiejszych czasach praktycznie każda aplikacja posiada własną stronę
WWW. Zadaniem takiej strony jest przedstawienie możliwości aplikacji oraz
dodatkowa funkcjonalność zależna od charakteru produktu. Dla systemu Mobile Stock
Monitor serwis WWW przedstawiony w tym rozdziale pełni rolę uzupełnienia aby cała
platforma tworzyła całość. Do zadań serwisu należy: rejestracja nowych użytkowników,
zarządzanie profilem, wybór obserwowanych spółek.
5.2.
Platforma Java Enterprise Edition
Serwis WWW został zbudowany na platformie Java Enterprise Edition 5 (Java
EE). Platforma ta definiuje środowisko do tworzenia aplikacji działających w sieci
której głównymi elementami są Enterprise JavaBeans, serwlety oraz JavaServer Pages
(JSP). Te trzy elementy tworzą razem kompletne rozwiązanie dla tworzenia aplikacji.
Gotowe aplikacje Java EE uruchamiane są na serwerze aplikacyjnym zgodnym z tą
platformą. Do najważniejszych cech wyróżniających tę platformę są: bezpieczeństwo,
transakcyjność, współbieżność, trwałość, obsługa obiektów rozproszonych.
23
System informacji giełdowej na urządzenia mobilne
ZAKOŃCZENIE
24
System informacji giełdowej na urządzenia mobilne
BIBLIOGRAFIA
[1.] Kim Topley, J2ME Almanach, Helion, Gliwice 2003
[2.] Oficjalna strona platformy Java Micro Edition http://java.sun.com/javame/index.jsp
[3.] Specyfikacja CLDC 1.1 http://jcp.org/en/jsr/detail?id=139
[4.] Strona główna programu Java Community Process http://jcp.org/en/home/index
[5.] Specyfikacja MIDP 2.0 http://jcp.org/en/jsr/detail?id=118
[6.] Specyfikacja J2ME Web Services http://jcp.org/en/jsr/detail?id=172
[7.] Oficjalna strona biblioteki OpenBaseMovil http://www.openbasemovil.org/
[8.] Oficjalna strona biblioteki Lightweight UI Toolkit https://lwuit.dev.java.net/
[9.] Licencja GPL http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
[10.]
Cay S. Horstmann, Gary Cornell, Java 2 Podstawy, Helion, Gliwice 2003
[11.]
Oficjalna strona biblioteki kXML http://kxml.objectweb.org/
25