Zestaw narzedzi programistycznych do generowania mobilnych aplikacji (2)

POLSKO-JAPOŃSKA WYŻSZA SZKOŁA TECHNIK

KOMPUTEROWYCH

PRACA MAGISTERSKA

Nr ................

Zestaw narzędzi programistycznych do generowania

mobilnych aplikacji

Student

Szymon Nieradka

Nr albumu

4868

Promotor

prof. dr hab. Kazimierz Subieta

Specjalność

Inżynieria Oprogramowania i Baz Danych

Katedra

Systemów Informacyjnych

Data zatwierdzenia tematu 2007.07.30
Data zakończenia pracy

2009.01.31

Podpis promotora pracy

Podpis kierownika katedry

....................................

Streszczenie

Praca podejmuje problematykę mobilnych narzędzi prezentujących dane o ustrukturalizo-

wanej postaci na przykładzie rozkładów jazdy komunikacji miejskiej. Dla osób korzystających
z tego typu komunikacji dostępność danych o rozkładach jazdy z poziomu telefonu komórko-
wego stanowi istotną wartość. W szczególności jeśli zaoferujemy do tego dodatkowe usługi
które wykraczają ponad to co oferują (zazwyczaj) statyczne strony z rozkładami jazdy prze-
woźników.

Podstawą pracy jest funkcjonujące od maja 2005 roku rozwiązanie o nazwie MicroBus

mojego autorstwa. Projekt ten został przygotowany przez autora dla mieszkańców Szczecina
i był ściśle do tego miasta dostosowany.

Podstawowym celem pracy jest zmiana ściśle ukierunkowanego rozwiązania na generyczny

framework umożliwiający dowolnym zainteresowanym osobom o podstawowych umiejętno-
ściach programistycznych przygotowanie własnej wersji mobilnej aplikacji.

W pierwszym rozdziale praca wprowadza w tematykę mobilnych rozkładów jazdy, opisuje

szczegółowo cel pracy oraz przyjęte w niej rozwiązania. Przybliżone są także rezultaty pracy.

Drugi rozdział opisuje szczegółowo kontekst pracy poprzez analizę dostępnych na rynku

rozwiązań o różnych modelach biznesowych, użytych technologiach i modelu licencyjnym.
Podsumowanie tej części pracy wskazuje na zestaw cech których kombinacja nie jest dostępna
na rynku.

Trzeci rozdział opisuje wykorzystane w trakcie pracy nad tematem narzędzia włączając

w to narzędzia programistyczne, kontroli wersji oprogramowania, tworzenia dokumentacji,
frameworki oraz narzędzia emulujące i dokonujące wirtualizacji systemu operacyjnego.

Kolejny czwarty rozdział opisuje szczegółowo propozycję generycznego rozwiązania do

budowania mobilnych aplikacji prezentujących rozkłady jazdy. Opisane są wszystkie elementy
będące przedmiotem pracy oraz wyszczególnione świadomie wykonane wyłączenia z zakresu.

Piąty rozdział dokonuje prezentacji wykonanego prototypu rozwiązania opisując poszcze-

gólne elementy systemu.

Ostatni rozdział przedstawia napotkanie w trakcie pracy problemy — głównie techniczne

ale także utrudnienia natury prawnej.

Podziękowania

Pracę dedykuję Agnieszce która cierpliwie znosiła długie godziny poświęcone tej pracy.

Strona 1 z 59

SPIS TREŚCI

Spis treści

1 Wstęp

1.1 Cel pracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 Rozwiązanie przyjęte w pracy . . . . . . . . . . . . . . . . . . . . . . . . .

2 Kontekst pracy

2.1 Dostępne na rynku rozwiązania . . . . . . . . . . . . . . . . . . . . . . . .

2.2 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Opis narzędzi zastosowanych w pracy

3.1 Język programowania Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Technologia tworzenia mobilnej aplikacji . . . . . . . . . . . . . . . . . . . 12

3.2.1 Wireless Application Protocol . . . . . . . . . . . . . . . . . . . . . 13
3.2.2 SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3 Rozwiązania „natywne” . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.4 Java Platform Micro Edition . . . . . . . . . . . . . . . . . . . . . . 14

3.3 Środowisko programistyczne Eclipse . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Zestaw narzędzi i bibliotek do developmentu JME na OS X . . . . . . . . . . 17

3.4.1 Apache Ant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2 Sun Java Wireless Toolkit . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.3 Antenna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.4 BlueCove . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.5 Microemulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.6 ProGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.5 Język programowania Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6 VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.7 DocBook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Propozycja rozwiązania

4.1 Założenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Dane wejściowe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2 Prezentacja . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Przenośność . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.4 Budowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji . . . . . 23

4.2.1 Krok 1: przygotowanie pliku w formacie Przewodas+ . . . . . . . . . 23
4.2.2 Krok 2: konwersja danych . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.3 Krok 3: kompilacja midletu . . . . . . . . . . . . . . . . . . . . . . 26

Strona 2 z 59

SPIS RYSUNKÓW

4.2.4 Krok 4: budowanie midletu, możliwości prezentacji . . . . . . . . . . 26
4.2.5 Krok 5: możliwości prezentacji . . . . . . . . . . . . . . . . . . . . . 27

4.3 Proces generowania midletu na przykładzie jednego miasta . . . . . . . . . . 29

5 Prototyp rozwiązania

5.1 Midlet Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Aplikacja dla platformy Symbian . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Kompresor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.3.1 Pojęcia wstępne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.2 Ogólny schemat działania . . . . . . . . . . . . . . . . . . . . . . . 36
5.3.3 Struktura słowa wyjściowego pliku binarnego . . . . . . . . . . . . . 37
5.3.4 Optymalizacja danych . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.5 Redukcja rozmiaru danych . . . . . . . . . . . . . . . . . . . . . . . 42

5.4 Dokumentacja projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.5 Strona projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.5.1 Strona dla programistów . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5.2 Strona dla użytkowników . . . . . . . . . . . . . . . . . . . . . . . 45

6 Problemy

6.1 Prawa autorskie do danych prezentowanych w aplikacji . . . . . . . . . . . . 48
6.2 Wielkość danych do przechowania w aplikacji . . . . . . . . . . . . . . . . . 48
6.3 Złożoność algorytmiczna przetwarzania danych . . . . . . . . . . . . . . . . 49
6.4 Ograniczenia API JME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.5 Skala implementacji JSR179 w telefonów komórkowych . . . . . . . . . . . 50

7 Podsumowanie

A Prace cytowane

B Dodatki

B.1 Opis formatu danych wejściowych . . . . . . . . . . . . . . . . . . . . . . . 54

B.1.1 Przykład pliku w formacie Przewodas . . . . . . . . . . . . . . . . . 55
B.1.2 Objaśnienia dla przykładu pliku . . . . . . . . . . . . . . . . . . . . 57

Spis rysunków

Propozycja schematu tworzenia mobilnej aplikacji . . . . . . . . . . . . . . . 24

Przygotowywanie plików w formacie Przewodas+ . . . . . . . . . . . . . . . 25

Konwersja danych w formacie Przewodas-a do formatu binarnego . . . . . . 26

Struktura midletu (pliku JAR) . . . . . . . . . . . . . . . . . . . . . . . . . 27

Strona 3 z 59

SPIS TABEL

Możliwości prezentacji danych . . . . . . . . . . . . . . . . . . . . . . . . . 29

Proces przygotowywania midletu na przykładzie rozkładu dla miasta Szczecina 30

Przykładowy widok aplikacji na telefonie Nokia 6310i . . . . . . . . . . . . . 33

Przykładowy widok aplikacji na emulatorze Microemu . . . . . . . . . . . . 34

Przykładowy widok aplikacji — wersja Symbian . . . . . . . . . . . . . . . 35

Schemat blokowy działania kompresora . . . . . . . . . . . . . . . . . . . . 38

Redukcja rozmiaru danych . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Dokumentacja formatu pliku Przewodas+ . . . . . . . . . . . . . . . . . . . 44

Wizytówka projektu w serwisie Sourceforge . . . . . . . . . . . . . . . . . . 45

Strona projektu dla użytkowników . . . . . . . . . . . . . . . . . . . . . . . 46

Strona wap projektu MicroBus . . . . . . . . . . . . . . . . . . . . . . . . . 47

Struktura pliku w formacie Przewodas . . . . . . . . . . . . . . . . . . . . . 56

Wizualizacja przykładowego rozkładu . . . . . . . . . . . . . . . . . . . . . 57

Spis tabel

Podsumowanie technologii tworzenia mobilnych aplikacji . . . . . . . . . . . 16

Struktura słowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Kody źródłowe

Lista plików midletu (bez obfuskacji) . . . . . . . . . . . . . . . . . . . . . 34

Format Przewodas+ opisany notacją Backusa-Naura . . . . . . . . . . . . . 54

Przykład pliku w formacie Przewodas+ . . . . . . . . . . . . . . . . . . . . 56

Strona 4 z 59

1 Wstęp

Mobilne rozkłady jazdy

Problematyka prezentowania rozkładów jazdy za pomocą telefonów komórkowych oraz

innych mobilnych urządzeń nabrała znaczenia w momencie w którym rozwój technologiczny
tych urządzeń umożliwił powstawanie takich rozwiązań. Dwa najistotniejsze elementy rozwoju
urządzeń mobilnych to z całą pewnością wyposażenie urządzeń mobilnych w przeglądarki
WAP

oraz udostępnienie API programistycznego dającego możliwość tworzenia niewielkich

aplikacji.

Aktualnie znanych jest wiele rozwiązań tego typu. Poniższe zestawienie prezentuje kilka

z nich ze wskazaniem na użyte rozwiązanie technologiczne:

1. Ginger (http://www.mpk.poznan.pl/ginger.html) — Midlet Java, wykorzystuje

własny format danych oparty o XML

2. Przewodas (http://szulat.republika.pl/przewodas) — Aplikacja przeznaczo-

na dla urządzeń z systemem operacyjnym PalmOS

3. Rozkład PKP SMS (http://rozklad-pkp.pl/) — Interaktywna bramka SMS która

w odpowiedzi na odpowiednio spreparowane pytanie udziela odpowiedzi

4. Rozkład PKP WAP (http://rozklad-pkp.pl/) — Wersja WAP serwisu z rozkładami

jazdy PKP

Rozwiązania tego typu można dzielić według różnych kryteriów. Do najważniejszych za-

liczyłbym:

1. Zastosowaną technologię, np:

(a) Midlet Java

(b) Bramka SMS

(d) Aplikacja na dedykowany mobilny system operacyjny (Symbian, OS X, PalmOS)

2. Model biznesowy oraz rodzaj licencji:

(a) zamknięte rozwiązanie komercyjne

(b) zamknięte rozwiązanie niekomercyjne

Strona 5 z 59

1.1 Cel pracy

3. Miejsce przechowywania danych:

(a) na serwerze (dla rozwiązań wap i sms)

(b) w aplikacji (dla pozostałych rozwiązań)

1.1 Cel pracy

Najważniejsze punkty których realizacja jest celem niniejszej pracy to:

1. Przygotowanie systemu umożliwiającego w prosty sposób na podstawie przygotowa-

nych danych w formacie Przewodas-a na przygotowanie gotowego do dystrybucji
midletu

2. Opcjonalnie rozszerzenie systemu umożliwiające generowanie na przykład:

(a) dwóch wersji midletu (MIDP 1.0 - stare telefony komórkowe, oraz MIDP 2.0 -

nowe telefony komórkowe)

(b) aplikacji w formacie SIS przeznaczonej do uruchomienia na telefonach z systemem

operacyjnym Symbian

3. Przepisanie aktualnie wykorzystywanego kompresora danych z języka C++ do Javy

(rozwiązanie musi być przenośne oraz proste w instalacji)

4. Refactoring oraz udokumentowanie kodów źródłowych

5. Przygotowanie dokumentacji dla wszystkich elementów systemu a w szczególności do-

kumentacji użytkownika skierowanej do osób które chciałyby wyłącznie korzystać z tego
efektów jego rozwoju

1.2 Rozwiązanie przyjęte w pracy

Wszystkim czynnościom programistycznym realizowanych w ramach pracy przyświecał

podstawowy cel czyli przygotowanie rozwiązanie możliwie jak najbardziej otwartego i prze-
nośnego. W efekcie wszystkie wykorzystywane narzędzia (opisane w rozdziale trzecim) to
produkty o otwartym kodzie które umożliwiają ich nieodpłatne wykorzystywanie także do ce-
lów komercyjnych. Wiodącym językiem programowania był język Java dzięki któremu moż-
liwe było uzyskanie pełnej niezależności od platformy sprzętowej i zastosowanego systemu
operacyjnego.

Także w procesie dokumentowania wyników prac (czego niniejszy dokument jest elemen-

tem) wykorzystywane były standardowe technologie jak np. notacja BNF wykorzystana do
opisu formatu danych.

Strona 6 z 59

1.2 Rozwiązanie przyjęte w pracy

Opisy kodu źródłowego oraz dokumentacja techniczna zostały przygotowane w języku an-

gielskim (lub w niektórych wypadkach dodatkowo w języku polskim) co w założeniu powinno
zwiększyć potencjalne audytorium tych materiałów.

Celem autora jest także (po uzyskaniu zgody promotora) upublicznienie pracy w całości

oraz przetłumaczenie jej najistotniejszych fragmentów na język angielski.

Strona 7 z 59

2 Kontekst pracy

Problematyka zarysowana w rozdziale 1 na stronie 5 nie jest zagadnieniem nowym. Do-

stępnych jest wiele rozwiązań różniących się między sobą zastosowaną technologią i po-
dejściem autorów do własności intelektualnej. Niniejszy rozdział prezentuje kilka wybranych
przedstawicieli poszczególnych grup rozwiązań podając dla każdego z nich krótki opis. Pod-
sumowanie dostępne na końcu rozdziału prezentuje zestaw cech których kombinacja nie jest
dostępna na rynku wyznaczając tym samym kierunek dalszej pracy.

2.1 Dostępne na rynku rozwiązania

Poniższe zestawienie pokazuje przekrój dostępnych na rynku rozwiązań służących do

prezentacji rozkładów jazdy (lub zbliżonych informacji) na urządzeniach przenośnych. Dla
każdego z opisanych rozwiązań można znaleźć kilka odpowiedników o zbliżonym charakterze.

Jazdy.net

Jazdy.net (http://jazdy.net/) to rozwiązanie wyspecjalizowane w prezentacji roz-

kładów jazdy przewoźników głównych polskich aglomeracji. Jest to przykład zamkniętego
rozwiązania nastawionego na zdobycie i utrzymywanie możliwie dużej ilości rozkładów prze-
woźników z poszczególnych miast.

Podsumowanie:

technologia: Rozwiązanie umożliwia prezentację danych na trzy sposoby: midlet Java (dal-

szy opis koncentruje się na tym przypadku), strony HTML i bot

Gadu-Gadu

model biznesowy: Rozwiązanie bezpłatne o zamkniętym kodzie. Autorzy zachęcają do współ-

pracy przy tworzeniu własnych wersji ale sprawują pełną kontrolę nad dystrybucją wersji
aplikacji.

zakres danych: Kilkanaście miast w Polsce; słaba aktualność danych

ograniczenia: :

• zastosowany algorytm kompresji jest mało wydajny; już przy umieszczeniu kilku

linii w aplikacji (średniej wielkości miasto ma około 100 linii) rozmiar aplikacji
przekracza 64kb co uniemożliwia jej instalację na starszych modelach telefonów

[WIKI] Bot to program wykonujący pewne czynności w zastępstwie człowieka. Czasem jego funkcją jest

udawanie ludzkiego zachowania lub wykonywanie zautomatyzowanych czynności. W tym kontekście jest to
automatyczny użytkownik sieci Gadu-Gadu odpowiadający na pytania związane z rozkładami

Strona 8 z 59

2.1 Dostępne na rynku rozwiązania

• rozwiązanie zamknięte; własną wersję rozkładu można przygotować wyłącznie

w porozumieniu z autorami i przy założeniu, że efekt pracy będzie hostowany na
serwerach Jazdy.net

• brak dokumentacji dla osób chcących przygotować własną wersję aplikacji (wynika

z podejścia autorów opisanego powyżej)

• brak narzędzi (j.w.)

MMPK

Rozwiązaniem o podobnym modelu jak Jazdy.net jest aplikacji mMPK (http://www.

mmpk.info/

). Podobnie jak w powyższym przykładzie nie znajdziemy na stronie projektu

informacji i narzędzi umożliwiających samodzielne przygotowanie własnej wersji aplikacji.

Podsumowanie:

technologia: Midlet Java i strony HTML

model biznesowy: Rozwiązanie bezpłatne o zamkniętym kodzie

zakres danych: Kilkanaście miast w Polsce; wysoka aktualność danych

ograniczenia: Ze względu na zbliżony do rozwiązania Jazdy.net modelu biznesowego ograni-

czenia mMPK są bardzo podobne włączając w to także słaby algorytm kompresji (co
może wynikać z generyczności rozwiązania)

PKP

Spółka Polskie Koleje Państwowe S.A. udostępnia rozkład jazdy własnych środków ko-

munikacji za pośrednictwem kilku wymienionych poniżej mediów. Podstawowym źródłem
(i najpełniejszym) źródłem informacji są jak zwykle w takim wypadku strony HTML. Ich
uzupełnienie stanowią rozkłady SMS i WAP. W przypadku SMS komunikacja odbywa się
zgodnie z zasadą „pytanie” - „odpowiedź”. Przykład takiej komunikacji (za stroną http:
//pkp.pl/cop/rozkladsms

) wygląda następująco:

żądanie :

Kutno do torun 1015

odpowiedź :

27.12.2008:Kutno->Torun Glowny
10:31*P 25101*p0*11:46
11:25*P 45101*p0*12:39

Strona 9 z 59

2.1 Dostępne na rynku rozwiązania

Strony WAP (http://pkp.pl/node/297 są uproszczoną wersją głównych stron z rozkła-

dami przewoźnika. Dostęp do nich jest aktywowany czasowo płatną wiadomością SMS.

Podsumowanie:

technologia: Rozkłady jazdy PKP dostępne są: na stronach HTML przewoźnika; za pomocą

usługi SMS; za pomocą usługi WAP

model biznesowy: Płatne rozwiązania komercyjne (jedynie dostęp do stron HTML jest bez-

płatny

zakres danych: Środki komunikacji przewoźnika

ograniczenia: Podstawowym ograniczeniem rozwiązania w kontekście tej pracy jest zamknię-

cie rozwiązania. Ze swojej definicji rozwiązania to nie może być wykorzystywane w in-
nych niż określonych przez PKP celach

Timetableme

Timetableme (http://timetableme.wordpress.com/) jest jedynym znalezionym roz-

wiązaniem które jest platformą to tworzenia aplikacji a nie gotowym jednorazowym produk-
tem. Strona projektu informuje w jaki sposób przygotować własną wersję aplikacji. Rozwiąza-
nie jest bardzo proste w dostosowaniu do własnych potrzeb — autor ocenia, że przygotowanie
własnej wersji aplikacji wymaga mniej niż godziny pracy. Niestety prostota rozwiązanie oka-
zuje się jej słabością w większych rozwiązaniach. Timetableme nie posiada narzędzia do
kompresji danych umieszczanych w aplikacji. Z tego powodu jakiekolwiek zastosowanie na
większą skalę nie jest możliwe. Dla przykładu aplikacja na średniej wielkości miasta w Polsce
miałaby rozmiar około 1MB i miałaby nieakceptowalne czasy odpowiedzi.

Podsumowanie:

technologia: Midlet Java dla profilu MIDP 2.0

model biznesowy: Bezpłatne narzędzie o otwartym kodzie

zakres danych: Platforma specjalizowana w rozkładach jazdy; autor nie hostuje gotowych

rozwiązań ani nie podaje przykładów zastosowań

ograniczenia: Brak narzędzia do kompresji danych

Strona 10 z 59

2.2 Podsumowanie

Przedstawione powyżej zestawienie dostępnych na rynku rozwiązań służących prezento-

waniu rozkładów jazdy na urządzeniach mobilnych pokazuje, że brakuje rozwiązań spełnia-
jących równocześnie następujące warunki:

1. Otwartość kodu — rozwiązanie musi udostępniać kompletne źródła na licencji umożli-

wiającej dalszą modyfikację i redystrybucję bez zgody autora (jedna z licencji OpenSource)

2. Bezpłatność — rozwiązanie musi być dostępnie nieodpłatnie do celów prywatnych

i komercyjnych

3. Dokumentacja rozwiązania musi być wystarczająca do samodzielnego przygotowania

własnej wersji aplikacji

4. Rozwiązanie musi być wyposażone w wydajny kompresor danych umieszczanych w apli-

kacji

5. Rozwiązanie musi być dostosowane do tworzenia wielu wersji językowych

Zakres tych wymagań definiuje w uproszczony sposób cele pracy. Wymagania te zostały

uszczegółowione w rozdziale 4 na stronie 21.

Strona 11 z 59

3 Opis narzędzi zastosowanych w pracy

Jednym z podstawowych celów pracy było przygotowanie kompletu narzędzi dostępnych

dla wszystkich zainteresowanych osób. Narzuca to konieczność stosowania wyłącznie rozwią-
zań multiplatformowych z naciskiem na narzędzie których przygotowanie do pracy (proces
instalacji i konfiguracji) jest bardzo proste.

Całość pracy została przygotowana pod kontrolą systemu operacyjnego MAC OS X 10.4.X

a same narzędzia testowane na zgodność pod systemami operacyjnymi:

1. Microsoft Windows XP Professional EN

2. Linux Ubuntu 8.10 Desktop Edition

Ww. systemy operacyjne były uruchamiane za pomocą narzędzia do wirtualizacji Virtu-

alBox (patrz rozdział 3.6 na stronie 19).

3.1 Język programowania Java

Java

to obiektowy język programowania stworzonym przez firmę SUN Microsystems.

Kod źródłowy programu napisanego w tym języku jest kompilowany do tak zwanego kodu
bajtowego (byte-code) czyli do postaci wykonywanej przez maszynę wirtualną

Podstawowym kryterium dla którego został wybrany ten język była pełna przenośność

przygotowanej w tym języku aplikacji między różnymi platformami. Drugim istotnym ar-
gumentem przemawiającym za tym językiem była możliwość zastosowania go zarówno do
tworzenia pomocniczych narzędzi desktopowych (jak kompresor) jak i tworzenia mobilnej
aplikacji klienckiej. Pełen opis wraz uzasadnieniem znajduje się w następnym rozdziale ( 3.2).

Strona producenta: http://java.sun.com.

3.2 Technologia tworzenia mobilnej aplikacji

Istnieje wiele rozwiązań umożliwiających dostarczenie informacji na urządzenie przenośne.

Do najpopularniejszych należą:

1. Wireless Application Protocol

2. SMS

3. Rozwiązania „natywne”

4. JME

[WIKI] Wirtualna maszyna Javy (ang. Java Virtual Machine, w skrócie JVM) to zależny od platformy

system uruchomieniowy dla programów napisanych w języku Java

Strona 12 z 59

3.2 Technologia tworzenia mobilnej aplikacji

3.2.1 Wireless Application Protocol

Wireless Application Protocol (WAP) to zbiór standardów definiujących protokół aplikacji

bezprzewodowych. Wersja 1.0 tego standardu powstała w 1998 roku a wersja 2.0 w roku
2001. WAP umożliwia dostęp do usług WWW urządzeniom o niewielkiej mocy obliczeniowej,
niewielkiej ilości pamięci oraz ograniczonym połączeniu z siecią internet (głównie telefony
komórkowe).

W wersji 1.0 standardu językiem opisu stron był WML (Wireless Markup Language).

Aplikacje WML to pliki XML o ograniczonej ilości znaczników (względem języka HTML).
W wersji 2.0 WAP standardem opisu stron jest specjalny profil pełnego formatu XHTML
— XHTML Mobile Profile (XHTML-MP). Istnieją rozwiązania umożliwiające generowanie
aplikacji WML lub XHTML-MP w zależności od urządzenia które wysłało żądanie.

Zastosowanie technologii WAP ma tą podstawową zaletę, że zapewnia aktualność prezen-

towanych danych. Przy każdym przeglądaniu danych mamy najświeższe informacje z serwera
je udostępniającego.

Naturalną konsekwencją tego jest niestety konieczność ponoszenia kosztów związanych

z dostępem do internetu za każdym razem gdy użytkownik chciałbym skorzystać z aplikacji.
Nie bez znaczenia jest tutaj także czynnik psychologiczny — powszechne jest przekonanie
o bardzo dużych kosztach połączeń internetowych — oraz stopień rozpowszechnienia tej usłu-
gi w Europie (opisuję sytuację za [WIKI], http://en.wikipedia.org/wiki/Wireless_
Application_Protocol

3.2.2 SMS

W przypadku Short Message Service (SMS) typowy scenariusz sprowadza się do wysłania

przez klienta zapytania w ustalonym formacie (np. ”8 mickiewicza” co oznaczałoby żądanie
otrzymania rozkładu dla linii 8 na przystanku „Adama Mickiewicza”) i otrzymaniu odpowiedzi
także w ustalonym formacie.

Podstawowe wady tego rozwiązania które zdecydowały o odrzuceniu tej technologii:

1. Konieczność ponoszenia kosztów przez obie strony (usługobiorcę i usługodawcę)

2. Konieczność zapewnienia integracji z bramką SMS która ze względu na opłaty roamin-

gowe jest skutecznym narzędziem tylko w obrębie jednego kraju

3. Konieczność stosowania niewygodnego „szyfrowego” wysyłania zapytań przez użyt-

kowników

4. Ograniczenie wielkości wiadomości SMS do 160 znaków (przy 7 bitach na znak) znacz-

nie utrudnia przekazanie pełnej informacji zwrotnej

Strona 13 z 59

3.2 Technologia tworzenia mobilnej aplikacji

3.2.3 Rozwiązania „natywne”

Przez sformułowanie „rozwiązania natywne” rozumiane jest budowanie aplikacji prze-

znaczonej na specyficzny rodzaj systemu operacyjnego urządzenia. Zazwyczaj są to droższe
urządzenia zwane Smartphone-ami. Lista takich systemów operacyjnych (w kolejności wyni-
kającej z udziału w rynku Europejskim):

1. Symbian OS

2. Windows Mobile

3. RIM Blackberry

4. iPhone OS (Mac OS X)

5. PalmOS

6. Linux

7. Android

8. BREW

Programowanie w sposób specyficzny dla platformy umożliwia pełne wykorzystanie moż-

liwości urządzenia. Jest to szczególnie przydatne dla aplikacji multimedialnych i usługowych.
Niestety aplikacja taka będzie pracować wyłącznie pod kontrolą konkretnego systemu ope-
racyjnego. Zazwyczaj konieczne jest tworzenie wielu wersji tej samej aplikacji dla różnych
modeli.

Dodatkowo na niekorzyść stosowanie tej technologii działa konieczność stosowania (naj-

częściej płatnych i nieprzenośnych) narzędzi programistycznych producenta platformy.

3.2.4 Java Platform Micro Edition

Java Platform Micro Edition

(nazywana wcześniej Java 2 Platform ME lub JME)

to specyfikacja firmy Sun Microsystems opisująca uproszczoną wersję platformy Java. Zo-
stała ona zaprojektowana z myślą o urządzeniach o ograniczonych zasobach (szybkość pro-
cesora, pamięć, możliwości komunikacji z użytkownikiem). Zasada działania znana z Javy —
uruchamianie byte-codu w ramach wirtualnej maszyny (zwanej tutaj K Virtual Machine —
KVM) — pozostaje bez zmian. Różnica sprowadza się do zbioru klas udostępnionych przez
wirtualną maszynę.

Dwie podstawowe zalety tej platformy (w kontekście tej pracy) to przenośność przygoto-

wanej aplikacji między różnymi urządzeniami oraz udział urządzeń z obsługą Java w rynku.

Strona 14 z 59

3.2 Technologia tworzenia mobilnej aplikacji

JME

występuje w dwóch podstawowych konfiguracjach: CDC (Connected Device Con-

figuration) i CLDC (Connected Limited Device Configuration). Obie określają zakres
dostępnych w konfiguracji klas przy czym druga z nich jest podzbiorem pierwszej i została
zaprojektowana specjalnie z myślą o najbardziej ograniczonych zasobach. W ramach tych
konfiguracji funkcjonują tak zwane profile.

Dla CLDC wykorzystywany jest profil MIDP (Mobile Information Device Profile). Jest to

rozszerzenia podstawowej konfiguracji CLDC o klasy specyficzne dla Java ME. MIDP 1.0 z 2000
roku zawiera podstawowe operacja wejścia wyjścia oraz możliwość budowania prostych aplika-
cji. MIDP 2.0 z roku 2002 został rozszerzony o multimedia oraz posiada więcej mechanizmów
interakcji z urządzeniem.

Oba profile mogą być wzbogacane o opcjonalne pakiety. Pakiety te są standaryzowane

w ramach JCP (Java Community Process) i są numerowane w formie JSR-XXX (Java
Specification Requests

). Dla przykładu JSR-179 to „Location API for J2ME” (patrz

rozdział 6.5 na stronie 50). Aby mieć możliwość wykorzystywanie tego API niezbędne jest
posiadanie telefonu wspierającego to rozszerzenie.

W swojej najprostszej postaci (rozumianej jako konfigurację CLDC 1.0, profil MIDP 1.0 bez

rozszerzeń) JavaME oferuje bardzo dużą przenośność i zgodność pomiędzy poszczególnymi
platformami. Wykorzystując w swoich rozwiązaniach wyższe profile lub opcjonalne pakiety
należy zweryfikować ich dostępność na docelowych urządzeniach.

Możliwości poszczególnych urządzeń można sprawdzić w bazie firmy SUN:
http://developers.sun.com/mobility/device/device

Podsumowanie

W tabeli 1 na następnej stronie zebrano najważniejsze z opisanych powyżej technologii.

Wybór i uzasadnienie

Na podstawie zebranych informacji jako narzędzie to tworzenia mobilnej aplikacji została

wybrana technologia JME. Przemawiają za nią następujące argumenty:

1. Duży udział urządzeń wspierających tą technologię nawet wśród tanich urządzeń

2. Dostępność darmowych, dopracowanych narzędzi programistycznych (także dla plat-

formy OS X), dokumentacja i duża społeczność programistyczna

3. Wystarczające możliwości interakcji z użytkownikiem i prezentacji danych

4. Duża przenośność binarnej aplikacji

Strona 15 z 59

3.3 Środowisko programistyczne Eclipse

Tabela 1: Podsumowanie technologii tworzenia mobilnych aplikacji

Nazwa technologii

JavaME

Symbian

SMS

WAP

PocketPC

Programowanie

Język programo-
wania

Java

C++

n/d

WML/
XHTML-
MP

C, C++

Trudność nauki

średnia

duża

średnia

mała

średnia

Środowisko

pro-

gramistyczne

dostępne

Koszty narzędzi

darmowe

płatne

n/d

darmowe

płatne

Przenośność apli-
kacji

średnia

mała

duża

mała

Format aplikacji

jad/jar

sis

n/d

wml, xhtml cab

Społeczność pro-
gramistyczna

duża

n/d

duża

średnia

Możliwości

Możliwości

wystarcza-
jące

duże

niewysta-
rczające

wystarcza-
jące

duże

Szybkość działa-
nia

średnia

szybka

n/d

średnia

szybka

Możliwość zapisa-
nia konfiguracji

tak

nie

tak

Rynek

Penetracja rynku

bardzo du-
ża

mała

bliska
100%

bardzo du-
ża

mała

3.3 Środowisko programistyczne Eclipse

Eclipse

to platforma do tworzenia aplikacji desktopowych (fat-client, rich-client) na-

pisana w języku programowania Java. Projekt został stworzony przez firmę IBM a następ-
nie przekazany społeczności OpenSource. Od 2003 roku jest on rozwijany przez Funda-
cję Eclipse do której należy ponad 120 firm w tym IBM, Borland Intel, Motorola,
Nokia, Oracle, SAP

Na tej bazie tej platformy powstało zintegrowane środowisko programistyczne (IDE) roz-

powszechniane wraz z nią (stąd nazwa Eclipse jej często utożsamiana właśnie z IDE).

Wszystkie komponenty rozwiązania napisane w języku Java zostały przygotowane właśnie

w tym narzędziu ale z założeniem, że ich edycja i budowania może odbywać się z wykorzysta-
niem innych środowisk programistycznych (więcej w następnym rozdziale oraz podrozdzia-
le 3.4.1 na następnej stronie).

Strona 16 z 59

3.4 Zestaw narzędzi i bibliotek do developmentu JME na OS X

Strona domowa projektu to http://www.eclipse.org.

3.4 Zestaw narzędzi i bibliotek do developmentu JME na OS X

Tworzenie rozwiązań w technologii JME wymaga kilku dodatków do Java Development

Kit (JDK). Dla systemu Linux oraz Windows możliwe jest pobranie gotowych, zintegrowa-
nych środowisk programistycznych JME. Umożliwiają on edycję kodu, graficzne projektowanie
midletów

(aplikacji mobilnych), uruchamianie i debugowanie aplikacji (w emulatorze i urzą-

dzeniu), optymalizację wielkości aplikacji czy preprocessing.

Niestety takie kompleksowe rozwiązania nie są dostępne dla systemu operacyjnego Mac

OS X. Z tego względu konieczne stało się stworzenie generycznego rozwiązania które po-
zwoli na współpracę nad projektem programistom na różnych platformach bez konieczności
wprowadzania poprawek np. w skryptach budujących.

Poniżej opisane są poszczególne elementy kompletnego, multiplatformowego zestawu na-

rzędzi developerskich JME.

3.4.1 Apache Ant

Apache Ant to narzędzie służące do zautomatyzowania procesu budowy oprogramowania.

Podobne do programu Make ale napisane w języku Java do wykorzystania przede wszystkim
z programami napisanymi w tym języku.

Ant jest w pełni przenośni — umożliwia uruchomienie cyklu budowania oprogramowania

na dowolnym systemie operacyjnym dla którego powstała wirtualna maszyna Java.

Strona domowa: http://ant.apache.org

3.4.2 Sun Java Wireless Toolkit

SUN WTK to zestaw narzędzi programistycznych niezbędnych do tworzenia aplikacji dla

platformy JME. Zawiera emulator, narzędzia do optymalizacji wielkości źródeł, dokumentację
oraz przykłady.

Niestety rozwiązanie to nie jest napisane wyłącznie w Java a dostępne w sieci wersje są

przeznaczone wyłącznie na systemy operacyjne Windows i Linux. Z tego względu w moim
rozwiązaniu wykorzystuję wyłącznie biblioteki Java dołączone do pakietu oprogramowania
oraz dokumentację. Emulator oraz optymalizator nie jest wykorzystywany.

Strona domowa: http://java.sun.com/products/sjwtoolkit/

3.4.3 Antenna

Antenna to biblioteka rozszerzający standardowy zestaw poleceń narzędzia do budowania

oprogramowania Ant (patrz 3.4.1) o polecenia wspomagające tworzenie mobilnych aplikacji
dla platformy JME.

Strona 17 z 59

3.4 Zestaw narzędzi i bibliotek do developmentu JME na OS X

Tworzenie aplikacji mobilnych w Java zawiera niestandardowe względem „zwykłej” (J2SE)

Javy etapy budowania oprogramowania jak:

1. Tworzenie pliku aplikacji w formacie JAR wraz z odpowiednim plikiem MANIFEST.MF

2. Tworzenie pliku opisujące aplikację (JAD)

3. Optymalizacja wielkości aplikacji poprzez usunięcie z wynikowego pliku nieużywanych

części kodu (klas).

4. Preprocesor — umożliwia stworzenie kilku wersji tej samej aplikacji na podstawie za-

łożeń wstępnych. Dzięki temu aplikacja budowana na kilka rodzajów urządzeń wyma-
gających specyficznych fragmentów kodu zawierać wyłącznie niezbędne elementy.

5. Podpisywanie aplikacji

Wszystkie te zadania zostały przygotowane jako tak zwane „taski” narzędzia Ant uprasz-

czając tworzenie aplikacji.

Strona domowa: http://antenna.sourceforge.net/

3.4.4 BlueCove

BlueCove to darmowa implementacja standardu JSR-82 umożliwiająca obsługę urzą-

dzeń Bluetooth z poziomu języka Java. Implementacja ta działa na Linux, MAC OS X
i Windows XP, Vista i Mobile (więcej szczegółów na stronie http://code.google.com/
p/bluecove/wiki/stacks

). Narzędzie to było wykorzystywane do automatycznego łado-

wania aplikacji do urządzenia przenośnego wyposażonego w interfejs Bluetooth.

Strona domowa: http://code.google.com/p/bluecove,

http://www.bluecove.org/

3.4.5 Microemulator

Microemulator to emulator umożliwiający uruchamianie aplikacji napisanych dla platfor-

my JME napisany w języku Java SE. Umożliwia do testowanie mobilnych aplikacji JME bez
konieczności wgrywania kodu na urządzenie mobilne.

Strona domowa: http://www.microemu.org/

Strona 18 z 59

3.5 Język programowania Perl

3.4.6 ProGuard

ProGuard jest darmowym optymalizatorem, obfuskatorem

i weryfikatorem kodu języka

Java

. Usuwa nieużywane fragmenty kodu. Zmienia nazewnictwo klas i zmiennych na możliwie

najkrótsze odpowiedniki.

Dzięki zastosowaniu tego narzędzia wynikowa aplikacja staje się od kilku do kilkunastu

procent mniejsza.

Strona domowa: http://proguard.sourceforge.net/

3.5 Język programowania Perl

Język Perl został wykorzystany jak procesor tekstu transformujący strony HTML opera-

tora komunikacji miejskiej w Szczecinie do formatu Przedodas-a. Ponieważ ta część pracy
i tak musi być wykonana samodzielnie przez programistę kod w tym języku należy traktować
wyłącznie jako przykład implementacji który może być pomocny przy tworzeniu własnego
rozwiązania.

Strona domowa: http://www.perl.org/

3.6 VirtualBox

Sun

xVM VirtualBox to oprogramowanie służąco do wirtualizacji zasobów opartych o pro-

cesory Intel X86. Umożliwia emulację wirtualnego komputera na jednym z systemów opera-
cyjnych Windows, Linux, OS/2 czy *BSD. Na takim komputerze możliwe jest zainstalowanie
praktycznie dowolnego OS działającego na architekturze X86.

W kontekście tej pracy autor wykorzystywał VirtualBox-a to testowania tworzonych roz-

wiązań na dwóch dodatkowych systemach operacyjnych. Na zainstalowanym na fizycznym
komputerze systemie OS X 10.4.X uruchamiane były:

1. Microsoft Windows XP Professional EN

2. Linux Ubuntu 8.10 Desktop Edition

Narzędzie to było wykorzystywane przez autora na etapie projektowanie rozwiązań słu-

żących przyszłym użytkownik systemu.

[WIKI] Zaciemnianie kodu (także obfuskacja, z ang. obfuscation) to technika przekształcania programów,

która zachowuje ich semantykę, ale znacząco utrudnia zrozumienie. Istnieją również narzędzia (obfuskatory)
modyfikujące kod źródłowy, pośredni bądź binarny w celu utrudnienia inżynierii wstecznej programu

Strona 19 z 59

3.7 DocBook

DocBook to język znaczników przeznaczony do tworzenia dokumentacji technicznej. Pier-

wotnie jest zastosowanie koncentrowało się wokół dokumentacji oprogramowania i sprzętu
komputerowego jednak w tej chwili jest wykorzystywany w wielu innych dziedzinach. Język
powstał w roku 1991 jako wspólny projekt HaL Computer Systems oraz O’Reilly & As-
sociates. Obecnie rozwija go DocBook Technical Committee w OASIS (pierwotnie SGML
Open).

W pewnym uproszczeni można przyjąć, że dokument DocBook-a to plik (lub pliki) XML

zawierający treść oraz metadane. W swoim założeniu DocBook separuje treść od formy. Dla
przykładu taki kod:

<a u t h o r>Szymon N i e r a d k a</ a u t h o r>

</ a u t h o r g r o u p>

< t i t l e >MicroBus</ t i t l e >

< s u b t i t l e>Jak z r o b i ć MicroBus

−a d l a swojego m i a s t a ?</ s u b t i t l e>

< e d i t i o n>$ R e v i s i o n $</ e d i t i o n>

< t i t l e >Wstęp</ t i t l e >

w s t ę p

</ c h a p t e r>

Może zostać przekształcony do formatu HTML, WML, XHTML, RTF, PDF, Unix Man-

page i wielu innych. Pozwala to osobie tworzącej dokumentację na skupienie się na jej treści.
Format pliku w jaki dane zostaną zaprezentowane użytkownikom jak i sama forma (czcionki,
kolorystyka itp) są ustalana w dalszym etapie.

Inną istotną zaletą tego formatu jest fakt, że pliki źródłowe to zwykłe pliki tekstowe

z kodowaniem znaków UTF-8. Umożliwia to współpracę nad dokumentacją wielu osobom
na raz za pośrednictwem systemów kontroli wersji takich jak CVS czy SVN.

Strona 20 z 59

4 Propozycja rozwiązania

Poniżej została opisana propozycja wszystkich elementów rozwiązania umożliwiającego

generowanie aplikacji JME prezentującej rozkłady jazdy komunikacji miejskiej. Opisane zo-
stały założenia wstępne przyjęte przy projektowaniu rozwiązania, komponenty systemu oraz
propozycja procesu generowania aplikacji.

4.1 Założenia

W trakcie realizacji prac programistycznych konieczne było przyjęcie założeń wstępnych

które określały ramy pracy.

4.1.1 Dane wejściowe

Autor rozwiązania nie ma możliwości określenia z jakich źródeł pobierać będą dane poten-

cjalni użytkownicy rozwiązania. Krótka analiza stosowanych rozwiązań w zakresie prezentacji
danych o rozkładach jazdy przez przewoźników nasuwa wniosek, że najczęściej wykorzysty-
wanym medium są statyczne strony HTML. Szerszy zakres potencjalnych źródeł danych dla
aplikacji prezentuje poniższa lista.

1. Statyczne lub dynamiczne strony HTML

2. Baza danych w której składowane są rozkłady (dostępnie wyłącznie dla pracowników

działów IT przewoźników)

3. Ręczne wprowadzanie danych (wyłącznie w bardzo niewielkich rozwiązaniach)

W związku z mnogością stosowanych przez przewoźników formatów danych (nawet w ob-

rębie samego kodu HTML) konieczne stało się zastosowanie jednolitego formatu opisu danych
wejściowych. Możliwe było albo stworzenie własnego formatu albo wykorzystanie istniejącego
rozwiązania.

Decyzja o wyborze konkretnego formatu została podyktowana popularnością rozwiązania

i otwartością narzędzi związanych z tym formatem. Jako format przechowywania informacji
o rozkładach został wybrany format Przewodas.

Oryginalny format Przewodas został stworzony przez Szymona Ulatowskiego około 2002

roku na potrzeby aplikacji o tej samej nazwie. Pełna specyfikacja tego formatu znajduje się
w dodatku B.1 na stronie 54.

Najważniejsze zalety tego formatu przemawiające za jego wykorzystaniem:

1. „Produkcyjna” weryfikacja formatu oraz gotowe dane dla wielu miast w Polsce. Ak-

tualizowane na bieżąco rozkłady w tym formacie są prowadzone dla miast: Warszawa,

Strona 21 z 59

4.1 Założenia

Gdańsk, Kraków, Lublin, Poznań, Skierniewice, Szczecin, Górnośląski Okrąg Przemy-
słowy i Wrocław

2. W przypadku niektórych miast dostępne są źródła konwerterów stron z rozkładami do

formatu Przewodasa (najczęściej w języku Perl)

3. Prosta budowa pliku, dane są czytelne i można analizować je w dowolnym edytorze

tekstu

Niestety format ten nie jest wolny od wad. Do najistotniejszych zaliczyłbym:

1. Oryginalny format Przewodas nie obsługuje opisów rozkładów bardzo często stosowa-

nych przez przewoźników (problem rozwiązany za pomocą rozszerzeń do formatu)

2. Możliwość zdefiniowania statycznej ilości (3) rodzajów rozkładów dla każdego przy-

stanku (np. dni pracujące, soboty i niedziele)

3. Ze względu na zastosowanie płaskiego pliku a nie np. formatu XML nie można wyko-

rzystywać gotowych parserów

4.1.2 Prezentacja

W ramach pracy zostanie przygotowany interfejs użytkownika na telefony wyposażone

przez producenta w wirtualną maszynę Java. Interfejs użytkownika zostanie napisany w tak
zwanym High-Level-Api (interfejs wysokiego poziomu). HLA zostało zaprojektowane z myślą
o aplikacjach gdzie bardzo ważna jest przenośność a szczegóły prezentacji mają drugoplanowe
znaczenie. Programista korzystający z tego sposobu tworzenia interfejsu użytkownika w JME
ma do wyboru jedynie kilka podstawowych komponentów takich jak lista, pole edycji czy
tekst. Możliwość ingerencji w sposób prezentowania danych są bardzo ograniczone. Z tego
powodu aplikacja będzie wyglądać odmiennie na różnych urządzeniach zachowując jednak
pełną funkcjonalność.

4.1.3 Przenośność

W przypadku każdego z elementów rozwiązania zakładana jest jego maksymalna przeno-

śność pomiędzy różnymi platformami.

W przypadku rozwiązań developerskich, dokumentacji i innych narzędzi uruchamianych

na komputerze użytkownika systemu przyjęto założenie, że bez dodatkowego nakładu pracy
musi być możliwe uruchomienie wszystkich fragmentów systemu na następujących platfor-
mach:

1. MAC OS X 10.4.X

Strona 22 z 59

4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji

2. Microsoft Windows 2000 lub wyższy

3. Linux 2.6.X

Dla urządzeń mobilnych przyjęto założenie, że muszą posiadać maszynę wirtualną Java

i obsługiwać następujące profile:

1. MIDP 1.0

2. CLDC 1.0

Więcej informacji na temat przenośności rozwiązania znajduje się w rozdziale 3 na stro-

nie 12.

4.1.4 Budowanie

Jak zostało to opisane w rozdziale 3 na stronie 12 podstawowym założeniem przy projek-

towaniu poszczególnych elementów systemu była maksymalna przenośność i prostota rozwią-
zania. Cały proces kompilacji wszystkich komponentów systemu jest możliwy do wykonania
na dowolnych komputerze wyposażonym w środowisko JDK

oraz narzędzie Ant (patrz 3.4.1

na stronie 17).

4.2 Propozycja generycznego rozwiązania budowania mobilnej apli-

kacji

W poniższych punktach został przedstawiony generyczny proces budowania mobilnej

aplikacji będącej tematem pracy. Proces opisuje zarówno elementy wspierane narzędziami
przygotowanymi w ramach pracy jak i elementy wyłączenie opisane w dokumentacji. W ni-
niejszym procesie nie zostały natomiast przedstawione aspekty nietechniczne (np. kwestie
prawne opisane w rozdziale 6.1 na stronie 48).

Schematyczny rysunek pełnego procesu został przedstawiony na diagramie 1 na następnej

stronie.

4.2.1 Krok 1: przygotowanie pliku w formacie Przewodas+

Jak zostało to opisane w rozdziale 4.1.1 na stronie 21 rozwiązanie opisywane w tej pracy

nie wspiera samego procesu tworzenia pliku z danymi wejściowymi. Niemniej aby ułatwić
użytkownikom końcowym przygotowanie właściwego pliku przedstawione zostaną:

1. Dokumentacja formatu zawierająca:

[WIKI] Java Development Kit (JDK) - darmowe oprogramowanie firmy Sun Microsystems udostępniające

środowisko niezbędne do programowania w języku Java

Strona 23 z 59

4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji

Rysunek 1: Propozycja schematu tworzenia mobilnej aplikacji

(a) Ogólny opis formatu i jego pochodzenie

(b) Szczegółowy opis formatu na wybranym przykładzie uwzględniając wszystkie do-

stępne warianty notacji

2. Przykłady gotowych plików i konwerterów (najczęściej napisanych w języku Perl) dla

kilku miast w Polsce

Schemat procesu przygotowywania danych w formacie Przewodas+ został przedstawiony

na rysunku 2 na następnej stronie.

4.2.2 Krok 2: konwersja danych

Pierwszym krokiem dla którego opisywane rozwiązanie daje wsparcie narzędziowe jest

proces konwersji płaskiego pliku tekstowego do skompresowanej postaci binarnej.

Strona 24 z 59

4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji

Rysunek 2: Przygotowywanie plików w formacie Przewodas+

W tym celu zostanie przygotowany konwerter który musi spełniać poniższe wymagania:

1. Proces instalacji i uruchamiania konwertera musi być technicznie mało złożony i nie

może wymagać wielu zasobów sprzętowych

2. Konwerter musi zostać napisany w sposób umożliwiający uruchomienie go na większo-

ści popularnych systemów operacyjnych (więcej w rozdziale 3 na stronie 12)

3. Konwerter musi prezentować czytelne komunikaty o natrafionych problemach w struk-

turze wejściowego pliku

4. Konwerter musi umożliwiać pracę w trybie DEBUG w celu szczegółowego przeanalizo-

wania ewentualnych problemów z danymi wejściowymi

Dodatkowo dane wyjściowe generowane przez konwerter musi cechować:

1. Maksymalna możliwa kompresja danych uwzględniająca charakter danych wejściowych

2. Ze względu na ograniczenia bufora w urządzeniach mobilnych wielkość plików wyjścio-

wych musi być ograniczona do 30kb (konfigurowalny parametr)

3. Konwerter musi dążyć do minimalizowania ilości wygenerowanych plików. Ze względu

na strukturę pliku JAR (kompresja ZIP) każdy plik, nawet zerowej wielkości zajmuje
minimum 400 bajtów.

4. Ideale rozwiązanie zakłada powstanie ceil

(X/L) plików gdzie X to ilość danych wyj-

ściowych a L to limit wielkości pojedynczego pliku

Strona 25 z 59

4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji

5. Dane składowane w plikach wyjściowych muszą być przystosowane do możliwości urzą-

dzeń mobilnych i zakładać optymalną proporcję między wielkością danych i możliwością
ich szybkiego odczytania. Z tego względu należy rozważyć możliwość dodania infor-
macji indeksujących i/lub np. poprzedzenie wszystkich ciągów znaków ich długością

Schemat procesu konwersji danych z formatu Przewodas+ do postaci binarnej został

przedstawiony na rysunku 3.

Rysunek 3: Konwersja danych w formacie Przewodas-a do formatu binarnego

4.2.3 Krok 3: kompilacja midletu

Kompilacja midletu jest krokiem który należy wykonać jednokrotnie a następnie wyko-

rzystywać pliki *.class to tworzenia kolejnych wersji i wariantów aplikacji. Wynika to z faktu,
że w projektowanym rozwiązaniu przyjęto założenie, że poszczególne warstwy midletu od-
powiedzialne za dostęp do danych, logikę aplikacji i prezentację będą wyraźnie oddzielone od
danych. Oznacza to, że w etapie kompilacji przetwarzana są wyłącznie pliki Java a wynikowe
pliki nie stanowią jeszcze w pełni funkcjonalnej aplikacji.

Kolejnym plusem zastosowania takiego podziału jest możliwość wykorzystywania goto-

wych bloków kodu (klas języka Java) to innych celów nie tworzenie midletu. Ułatwia to
przygotowywanie takich rozwiązań a następnie pielęgnację takiego kodu. Więcej na ten temat
znajduje się w następnym rozdziale ( 4.2.5 na następnej stronie).

Kompilacja źródeł midletu w założeniu będzie sprowadzać się do uruchomienia polecania

w konsoli wykorzystując narzędzie Ant.

4.2.4 Krok 4: budowanie midletu, możliwości prezentacji

Jak przedstawia rysunek 4 na następnej stronie midlet składać się będzie się z kilku

niezależnych elementów:

Prezentacja Klasy języka Java odpowiedzialne za prezentację wyników oraz zbieranie in-

formacji od użytkownika

Kontroler Klasy języka Java odpowiedzialne za sterowaniem interakcji z użytkownikiem

oraz logiką prezentowania wyników

Strona 26 z 59

4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji

DAO

Klasa języka Java odpowiedzialne za udostępnienie prostego interfejsu do danych

z rozkładami. Klasa ta musi zostać napisana w taki sposób aby możliwe było jej użycie
w różnych rozwiązaniach (nie tylko w midlecie)

Zasoby Zasoby to pliki inne niż dane binarne z rozkładami. Mogą to być np. ikona aplikacji

manifest.mf Plik manifestu to specjalny plik każdego midletu zawierający między innymi

takie informacje jak nazwa głównej klasy midletu, rozmiar midletu, numer wersji czy
dane autora

Dane binarne To skompresowane pliki z rozkładami

Istotne jest aby budowanie midletu który różni się wyłącznie zawartością danych (np.

aktualizacja rozkładu dla danego miasta) sprowadzała się wyłącznie do wymiany Danych
binarnych oraz pliku manifest.mf. Wymiana tego drugiego jest konieczna ze względu na
zmianę wielkości aplikacji oraz zapewne numeru wersji. Dzięki zastosowaniu takie podejścia
możliwe będzie generowanie kolejnych wersji aplikacji przy pomocy samego polecenia Jar bez
konieczności komplikacji całej aplikacji.

Rysunek 4: Struktura midletu (pliku JAR)

4.2.5 Krok 5: możliwości prezentacji

Dzięki zastosowaniu zunifikowanego sposobu przechowywania danych o rozkładach oraz

stworzeniu analizatora tych danych w przenośnym języku (Java) możliwe jest w prosty sposób
tworzenie wielu wersji prezentacji danych.

Strona 27 z 59

4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji

1. SMS — mając do dyspozycji bramkę SMS możliwe jest stworzenie mechanizmu za

pomocą którego użytkownik zadając pytanie w ustalonym formacie (np. „5bis traugutta
18:00”) otrzymywałby zwrotnie oczekiwaną informację (np. „17:30 18:50a; a - zjazd
do zajezdni”)

2. WAP — nie wszyscy przewoźnicy udostępniają rozkłady za pośrednictwem tej tech-

nologii. Wykorzystując dowolny mechanizm generowania dynamicznych stron WWW
można przygotować wygodną w użyciu wersję WAP z danymi

3. HTML — strony HTML pozostają najwygodniejszym sposobem przekazywania infor-

macji z wykorzystaniem internetu

4. Bot GG

/Jabber

— automat udzielający odpowiedzi na zadane pytania za pośred-

nictwem wybranej sieci Instant Messaging. Schemat komunikacji może być zbliżony
do opisanego powyżej rozwiązania przyjętego w komunikacji SMS jednak dzięki bra-
kom ograniczeń (długość komunikatu, wprowadzanie danych) można dobrać protokół
czytelniejszy i łatwiejszy w obsłudze

5. Symbian — programowanie dla platformy Symbian (jak zostało to opisane w rozdzia-

le 3.2.3 na stronie 14) daje dużo większe możliwości kosztem ograniczonej przenośności.
Aplikacja przygotowana dla tej platformy mogłaby mieć np. możliwość lokalizacji urzą-
dzenia za pomocą modułu GPS (problemy z implementacją tej funkcjonalności zostały
opisane w rozdziale 6.5 na stronie 50)

6. inne

Wizualizacja różnych wariantów prezentacji danych została przedstawiona na rysunku 5

na następnej stronie.

[WIKI] Gadu-Gadu (w skrócie GG lub gg) — komunikator internetowy dla systemu Windows, opraco-

wywany przez firmę GG Network S.A. inspirowany komunikatorem ICQ

[WIKI] Jabber — otwarty, oparty na XML protokół komunikacji oraz powiadamiania o obecności w czasie

rzeczywistym. Głównym jego zastosowaniem jest wymiana wiadomości w komunikatorach internetowych

Strona 28 z 59

4.3 Proces generowania midletu na przykładzie jednego miasta

Rysunek 5: Możliwości prezentacji danych

4.3 Proces generowania midletu na przykładzie jednego miasta

Opisany w powyższym rozdziale proces został zobrazowany na przykładzie Szczecina na

rysunku 6 na następnej stronie. Poniżej znajduje się opis poszczególnych kroków procesu.

1. W pierwszej fazie następuje pobrania danych przewoźnika do dalszej obróbki. W tym

wypadku są to statyczne strony HTML. W sumie jest to około 4 tysięcy plików o cał-
kowitym rozmiarze ponad 50MB.

Strona 29 z 59

4.3 Proces generowania midletu na przykładzie jednego miasta

Rysunek 6: Proces przygotowywania midletu na przykładzie rozkładu dla miasta Szczecina

2. W drugiej fazie następuje transformacja rozkładów do formatu Przewodas+ za pomocą

skryptu napisanego w języku Perl. Dzięki tej operacji wejściowe dane zostają zapisane
w formie pojedynczego płaskiego pliku tekstowego bez zbędnych formatować. Jego
wielkość wynosi około 1MB do 2MB.

3. W trzeciej fazie następuje transformacja zestandaryzowanych danych w formacie Prze-

wodas-a do formatu binarnego silnie zorientowanego na minimalizację wielkości wyni-
kowego pliku. Rozmiar wynikowego pliku jest mniejszy od wejściowego o około 80%
(200kB – 300kB).

Strona 30 z 59

4.3 Proces generowania midletu na przykładzie jednego miasta

4. W ostatniej, czwartej fazie następuje połączenie skompilowanych źródeł midletu Java

z danymi z rozkładami uzyskanymi w poprzednim kroku. W wyniku tego połączenia
otrzymuje się gotową aplikację JME.

Strona 31 z 59

5 Prototyp rozwiązania

Rozdział ten opisuje rezultaty prac programistycznych i dokumentacyjnych. Zaowocowa-

ły one czterema produktami: midletem Java, kompresorem, dokumentacją oraz serwisem
projektu.

5.1 Midlet Java

Najistotniejszym z punktu widzenia użytkownika końcowego elementem całego rozwiąza-

nia jest midlet Java czyli aplikacja na urządzenie mobilne. Podstawowe funkcje realizowane
przez aplikację (wymagania funkcjonalne) to:

1. Wyświetlenie menu głównego aplikacji umożliwiającego wybór określonej pozycji lub

wyjście z aplikacji

2. Umożliwienie wyboru konkretnej linii oraz kierunku

3. Wybór przystanku dla którego rozkład chce poznać użytkownik

4. Prezentacja rozkładu z danego przystanku w układzie:

(a) najbliższe połączenia, np:

10:15 za minutę
10:30 za 16 minut

(b) pełnego rozkładu w danym dniu, np:

10h 5 15 25 35 45 55
11h 5 15 25 35 45 55

5. Możliwość przełączania wariantu rozkładu w zależności od konfiguracji. W większości

rozwiązań dostępne są trzy warianty: poniedziałek–piątek, soboty, niedziele i święta.

Najistotniejsze wymagania niefunkcjonalne realizowane przez aplikację to:

1. Minimalizacja wielkości aplikacji tak aby jej rozmiar nie przekraczał 64kb

2. Możliwość pracy na urządzeniach z profilem CLDC1.0/MIDP1.0

3. Możliwość lokalizacji rozwiązania ([GL])

Strona 32 z 59

5.1 Midlet Java

Przedstawione na rysunku 7 zrzuty ekranów z aplikacją prezentują kilka wybranych funk-

cjonalności aplikacji. Odpowiednio: prezentację najbliższych rozkładów dla wybranej linii
i przystanku; prezentację pełnego rozkładu na cały dzień; ekran wyboru przystanku z listy.

Rysunek 8 na następnej stronie prezentuje kilka innych przykładów jak np. możliwość

wyszukania przystanku wg założonego filtra (wprowadzenie w kryterium wyszukiwania frazy
„pl.” spowoduje wyszukanie wszystkich nazw przystanków zawierających ten ciąg znaków
bez względu na wielkość liter). Ostatni (z prawej) zrzut ekranu na rysunku 8 na następnej
stronie prezentuje jedną z funkcji aplikacji — możliwość przejrzenia wszystkich dostępnych
połączeń z określonego wcześniej przystanku — lista w formacie nazwa przystanku «numery
linii».

Rysunek 7: Przykładowy widok aplikacji na telefonie Nokia 6310i

Na listningu 1 na następnej stronie przedstawiona została przykładowa zawartość pliku

Jar aplikacji. Widać wyraźne rozgraniczenie kodu źródłowego aplikacji (pliki class w pakie-
cie/katalogu szn) z wyszczególnieniem klasy odpowiedzialnej za odczyt danych (DB.class).
Komplet informacji przetwarzanych przez aplikację znajduje się w katalogu f.

Do przygotowania tej listy została wykorzystana aplikacja nie poddana wcześniej proce-

sowi obfuskatoracji. Dzięki temu zachowane zostało oryginalne nazewnictwo klas i pakietów
zamiast kolejnych liter alfabetu.

Strona 33 z 59

5.2 Aplikacja dla platformy Symbian

Rysunek 8: Przykładowy widok aplikacji na emulatorze Microemu

Kod źródłowy 1: Lista plików midletu (bez obfuskacji)

$ j a r t f d i s t / MicroBus . j a r

META−INF/

META−INF/MANIFEST .MF

m i c r o b u s . png

s z n /

s z n /DB. c l a s s

s z n / Data . c l a s s

s z n / D i r e c t i o n . c l a s s

s z n /Main . c l a s s

f /

f /1

f /2

f /3

f /4

f / i

5.2 Aplikacja dla platformy Symbian

Na bazie projektu MicroBus została obroniona Politechnice Szczecińskiej praca inży-

nierska Piotra Kani o temacie „Projekt i implementacja aplikacji wspierającej wyszukiwanie
drogi na trasach komunikacyjnych przeznaczonej dla urządzeń mobilnych”. Cel pracy został
zdefiniowany następująco:

[INZ, Celem pracy jest stworzenie aplikacji, dla urządzeń mobilnych, która

Strona 34 z 59

5.3 Kompresor

będzie znajdywała najkrótsze połączenie pomiędzy dwoma dowolnie zadanymi
przystankami na terenie miasta]

Najważniejszym efektem pracy była aplikacja na platformę Symbian 9.1. Aplikacja ta

wykorzystuje algorytm A*

do odnalezienia najkrótszej drogi. Przykładowe ekrany aplikacji

zawierające menu główne, ekran wyszukanej optymalnie trasy oraz prezentację listy środków
komunikacji zawiera rysunek 9.

Rysunek 9: Przykładowy widok aplikacji — wersja Symbian

5.3 Kompresor

Głównym zadaniem kompresora jest wczytanie danych z pliku tekstowego w formacie

Przewodas+

(patrz rozdział B.1 na stronie 54), następnie kompresja danych i zapisanie ich

w plikach wyjściowych.

5.3.1 Pojęcia wstępne

Kompresor jest aplikacją konsolową napisaną w języku Java. Aplikacja została przygoto-

wana w postaci pojedynczego archiwum Jar

Algorytm A* — algorytm przeszukiwania grafu, odnajdujący najkrótszą ścieżkę pomiędzy dwoma danymi

wierzchołkami grafu. Wykorzystuje heurystykę. Przy przeszukiwaniu grafu najpierw sprawdza najbardziej
obiecujące, jeszcze nie odkryte wierzchołki. Algorytm opisany pierwotnie w 1968 roku przez Petera Harta,
Nilsa Nilssona oraz Bertram Raphael

[WIKI]

Java ARchive — narzędzie oraz format pliku; służy do tworzenia pojedynczego pliku (archiwum

Jar) z wielu plików i katalogów

Strona 35 z 59

5.3 Kompresor

Sposób uruchamiania aplikacji wraz z wymaganymi parametrami został przedstawiony na

poniższym listningu:

$ j a v a −j a r conv . j a r <output d i r>

Poszczególne elementy oznaczają:

java -jar uruchomienie maszyny wirtualnej Java z parametrem “-jar” oznaczającym, że

następnym argumentem będzie nazwa pliku z archiwum Jar

conv.jar archiwum Jar z aplikacją (kompresorem)

input file> nazwa pliku wejściowego z danymi w formacie Przewodas+

output dir> nazwa katalogu do którego zostaną zapisane binarne pliki wyjściowe

Dodatkowo aplikacja posiada możliwość uruchomienia w trybie DEBUG. Oznacza to

konieczność umieszczenia dwóch dodatkowych opcji:

$ j a v a −ea −DDEBUG=t r u e −j a r conv . j a r <output d i r>

Pierwsza z nich (“-ea” lub pełna nazwa “-enableassertions”) to parametr maszyny wirtu-

alnej Java włączający mechanizm asercji

. Druga (“-DDEBUG=true”) przekazuje w zmien-

nej środowiskowej “DEBUG” wartość “true”. Dzięki tej instrukcji aplikacja przekieruje stru-
mień komunikatów diagnostycznych do pliku “conv.log”.

5.3.2 Ogólny schemat działania

Zasadniczy schemat działania kompresora został przedstawiony w formie schematu blo-

kowego na rysunku 10 na stronie 38. Aplikacja w pierwszej kolejności otwiera plik wejściowy
w formacie Przewodas+ (inFile) i zaczyna przetwarzanie tego pliku. Najpierw wczytywa-
ny jest słownik nazw przystanków (read SN) a następnie opisów (read OP). Ostatnią fazą
przetwarzania pliku jest wczytanie wszystkich najbardziej skomplikowanych składniowo sekcji
RN (read RN). Wszystkie wymienione powyżej dane trafiają do kolekcji specjalnie do tego
przygotowanych obiektów.

Po wczytaniu zawartości pliku wejściowego rozpoczyna się proces optymalizacji. Został

on omówiony w rozdziale 5.3.4 na stronie 39.

Ostatnim krokiem aplikacji jest stworzenie binarnych plików wyjściowych w folderze prze-

kazanym jako drugi parametr aplikacji (outDir). Aplikacja generuje pliki dwóch rodzajów:

plik ’i’ Plik ’i’ to indeks zawierający:

[WIKI] Asercja to fragment kodu zwracający prawdę lub fałsz. Umieszczany jest w miejscach w których

programista zakłada, że zostanie zwrócona prawda. W przeciwnym wypadku działanie programu zostanie
przerwane

Strona 36 z 59

5.3 Kompresor

1. słownik nazw przystanków
2. słownik opisów
3. listę kierunków, dla każdego kierunku w pliku indeksu przechowywane są nastę-

pujące informacje:

(a) nazwa kierunku

(b) numer pliku w którym znajduje się rozkład, wielkość danych (w bajtach)

i offset (pozycja) od której należy zacząć czytać

pliki ’1’, ’2’, . . . Pliki których nazwa to kolejne liczby naturalne zawierają szczegółowe

informacje na temat kierunków wymienionych w pliku indeksu. Ilość plików zależy
od ilości danych wyjściowych (X) i wielkości maksymalne pojedynczego pliku (max
– w kompresorze przyjęto wielkość 30 000 bajtów). Ponieważ jednak format pliku
wyjściowego nie przewiduje możliwości dzielenie pojedynczego kierunku na kilka plików
w określonych wypadkach wielkość ta może być maksymalnie dwukrotnie większa.

X/max

ilość plików

2 ∗ X/max

(1)

5.3.3 Struktura słowa wyjściowego pliku binarnego

Pojedynczy wpis w binarnym pliku tworzonym przez kompresor zawsze składa się z dwóch

bajtów. Jego strukturę wyjaśnia tabela 2 na stronie 39 oraz poniższy opis.

W pojedynczym słownie muszą być przechowywane informacje o pełnej godzinie w zakre-

sie

–

oraz o przesunięciu czasu względem poprzedniej wartości. Potencjalnie mogą

z całego uprzednio podanego zakresu wraz z uwzględnieniem wartości ujemnych.

Przyjmując, że godzinę czas w obrębie doby zapamiętujemy jako przesunięcie w monitach

względem godziny

otrzymujemy:

→ 0

(2)

oraz:

→ 23 ∗ 60 + 59 = 1439

(3)

Ponieważ przesunięcie czasu może występować ze znakiem ujemnym potencjalnie potrze-

bujemy:

−23

: 23

→< −1439 : 1439 >→ 2879

(4)

kombinacji. Dla takiej liczby kombinacji potrzebujemy następującej ilości bitów:

Strona 37 z 59

5.3 Kompresor

Rysunek 10: Schemat blokowy działania kompresora

log

(2879) ≈ 11.49

(5)

log

(2879) = 12

(6)

Aby pełniej wykorzystać możliwości jakie dają 12 bitów pozostała przestrzeń została

wykorzystana do przechowywania znaków specjalnych.

Strona 38 z 59

5.3 Kompresor

= 4096

(7)

Oznacza to, że cała przestrzeń od liczby 2880 do 4095 może zostać wykorzystana na

różne oznaczenia. W kompresorze zostały wykorzystane następujące stałe (ich opis znajduje
się w rozdziale 5.3.4):

2880-2999 — nie są używane

3000 — BAD BIT

3001 — THE SAME AS ONE LEVEL UP

3002 — THE SAME AS Tx MINUS 1

3003-3009 — nie są używane

3010-4095 — REPEAT COUNT

Tabela 2: Struktura słowa

7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

Znaczenie kolejnych bitów zostało opisane w poniższym zestawieniu:

A0-A7 B0-B3 12 bitów przeznaczonych do przechowywania informacji o czasie lub jego

przesunięciu oraz na znaki specjalne (jeśli wartość tych bitów jest " 3000)

B4-B6 3 bity służące przechowywaniu informacji o opisie (np. 8

gdzie

— zjazd do

zajezdni)

B7 Ostatni bit nie jest używany. W przyszłości może zostać wykorzystany np. do oznaczenia

pojazdów niskopodłogowych itp.

5.3.4 Optymalizacja danych

Aby zobrazować algorytm kompresji danych zastosowany w aplikacji zostanie on zobrazo-

wany w postaci formalnej a poszczególne kroki zostaną dodatkowo omówione na przykładzie.

Dla lepszego zrozumienia algorytmu należy zapoznać się z dokumentacją formatu Przewo-

das+ w rozdziale B.1 na stronie 54. Przedstawione w przykładach fragmentu plików odnoszą
się właśnie do tego formatu (choć w uproszczony sposób).

Strona 39 z 59

5.3 Kompresor

Na wejściu mamy n wpisów typu S (przystanków):

gdzie n ∈ N; n " 2

(8)

Dla każdego wpisu typu S poza ostatnim w kolejności istnieją dokładnie trzy wpisy typu

. Są one numerowane kolejno T

, T

gdzie x ∈ {0, 1, 2}

(9)

Dla każdego wpisu T

istnieje dodatnia ilość wpisów z godzinami.

x,i

gdzie x ∈ {0, 1, 2}; i ∈ N; i " 0

(10)

Poniżej został przedstawiony przykład danych spełniających powyższe warunki dla 3 przy-

stanków (n

= 3).

P i e r w s z y p r z y s t a n e k

T0 6 : 0 0 6 : 1 0 6 : 2 0 6 : 3 0 6 : 5 0 7 : 0 0

T1 7 : 0 0 7 : 1 0 7 : 2 0 7 : 3 0 7 : 5 0 8 : 0 0

T2 7 : 0 0 7 : 1 0 7 : 2 0 7 : 3 0 7 : 5 0 8 : 0 0

Drugi p r z y s t a n e k

T0 6 : 0 5 6 : 1 5 6 : 2 5 6 : 3 5 6 : 5 5 7 : 0 5

T1 7 : 0 5 7 : 1 5 7 : 2 0 7 : 3 5 7 : 5 5 8 : 0 5

T2 7 : 0 5 7 : 1 5 7 : 2 5 7 : 3 5 7 : 5 5

O s t a t n i p r z y s t a n e k

W pierwszym kroku następuje uzupełnienie ilości wszystkich wpisów t

x,i

do maksymalnej

występującej wartości. W tym wypadku oznacza to, że ostatni wiersz (T

dla S

) musiał

zostać uzupełniony wartością —X:XX—. Przez ten symbol oznaczany jest pojedyncze słowo
o wartości 3000. Zgodnie z przyjętą powyżej nomenklaturą oznacza ono nieistniejący wpis,
tak zwany BAD BIT.

P i e r w s z y p r z y s t a n e k

T0 6 : 0 0 6 : 1 0 6 : 2 0 6 : 3 0 6 : 5 0 7 : 0 0

T1 7 : 0 0 7 : 1 0 7 : 2 0 7 : 3 0 7 : 5 0 8 : 0 0

T2 7 : 0 0 7 : 1 0 7 : 2 0 7 : 3 0 7 : 5 0 8 : 0 0

Drugi p r z y s t a n e k

T0 6 : 0 5 6 : 1 5 6 : 2 5 6 : 3 5 6 : 5 5 7 : 0 5

T1 7 : 0 5 7 : 1 5 7 : 2 0 7 : 3 5 7 : 5 5 8 : 0 5

T2 7 : 0 5 7 : 1 5 7 : 2 5 7 : 3 5 7 : 5 5 X:XX

O s t a t n i p r z y s t a n e k

W następnej kolejności wykonywana odejmowania dla kolejnych wpisów t

x,i

dla pierwsze-

go przystanku:

Strona 40 z 59

5.3 Kompresor

x,i

= t

x,i

− t

x,i

−1

dla każdego i > 0; x = 0

(11)

Dla kolejnych przystanków wykonywana jest analogiczne operacja ale odejmująca wartości

z poprzedniego przystanku:

x,i

= t

−1,i

− t

x,i

dla każdego i > 0; x > 0

(12)

P i e r w s z y p r z y s t a n e k

T0 6 : 0 0 0 : 1 0 0 : 1 0 0 : 1 0 0 : 2 0 0 : 1 0

T1 1 : 0 0 0 : 1 0 0 : 1 0 0 : 1 0 0 : 2 0 0 : 1 0

T2 0 : 0 0 0 : 1 0 0 : 1 0 0 : 1 0 0 : 2 0 0 : 1 0

Drugi p r z y s t a n e k

T0 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5

T1 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5

T2 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5 0 : 0 5 X:XX

O s t a t n i p r z y s t a n e k

W ostatnim kroku wykonywana jest operacja wyszukiwania powtórzeń dla poszczególnych

grup t

x,i

oraz całych wpisów T

W przypadku napotkania powtarzających się więcej niż dwa razy identycznych wpisów

x,i

w ich miejsce generowany jest symbol REPEAT COUNT (oznaczony w poniższym przy-

kładzie symbolem R). Po nim następuje krotność powtórzeń.

W przypadku napotkania identycznych wpisów T

generowane są oznaczenia THE SAME-

AS Tx MINUS 1 lub THE SAME AS ONE LEVEL UP w zależności od sytuacji. Jeśli po-

wtórka nastąpi w ramach tego samego wpisu S

wygenerowany zostanie pierwszy symbol

(oznaczony na poniższym listningu jako =T0 lub =T1).

jeżeli ∀x > 0, i " 0:

x,i

= t

−1,i

(13)

Jeżeli powtórka nastąpi pomiędzy dwoma sąsiadującymi wpisami S

dla tych samych

pozycji x generowany jest drugi wpis (THE SAME AS ONE LEVEL UP).

jeżeli ∀x > 0, i " 0:

x,i

} = S

−1

x,i

}

(14)

P i e r w s z y p r z y s t a n e k

T0 6 : 0 0 R3 x 0 : 1 0 0 : 2 0 0 : 1 0

T1 1 : 0 0 R3 x 0 : 1 0 0 : 2 0 0 : 1 0

T2 =T1

Drugi p r z y s t a n e k

T0 R6 x 0 : 0 5

T1 =T0

T2 R5 x 0 : 0 5 X:XX

O s t a t n i p r z y s t a n e k

Strona 41 z 59

5.4 Dokumentacja projektu

5.3.5 Redukcja rozmiaru danych

Dzięki zastosowanym mechanizmom optymalizacji danych udaje się uzyskać znaczący

stopień kompresji plików wynikowych. Analizy wydajności algorytmu dokonywana na przy-
kładzie kilku dostępnych plików z rozkładami w formacie Przewodas+ (dla Szczecina) lub
pierwotnym formacie Przewodas (dla innych miast). Poniżej został przedstawiony przykład
dla miasta Szczecina.

(1) wielkość stron WWW z rozkładami jazdy dla Szczecina: 50 626 209 bajtów (7 861 557

bajtów po spakowaniu narzędziem Jar)

(2) wielkość wygenerowanego pliku w formacie Przedowas+ (czyste dane tekstowe bez grafik

i kodu HTML): 1 071 248 bajtów (223 547 bajtów po spakowaniu narzędziem Jar)

(3) sumaryczna wielkość plików wygenerowanych przez kompresor: 88 609 bajtów (31 267

bajtów po spakowaniu narzędziem Jar)

(4) wielkość pojedynczego archiwum Jar z plikami wygenerowanymi przez kompresor: 31 267

bajtów

Opisany przykład został przedstawiony na wykresie 11 na następnej stronie. Oś Y wykresu

została przedstawiona w postaci logarytmicznej (log

) dla większej czytelności. Na wykresie

kolorem czerwonym oznaczono wielkości dla plików niespakowanych a zielonym dla plików
spakowanych narzędziem Jar.

5.4 Dokumentacja projektu

Dokumentacja projektu składa się z kilku części. Poszczególne jej elementy są przezna-

czone dla różnych odbiorców. Trzy najważniejsze składowe dokumentacji to:

1. Dokumentacja sposobu przygotowywania aplikacji — jest przeznaczona dla wszystkich

osób chcących przygotować własną wersję aplikacji. Zawiera ona przewodnik po pro-
cesie przygotowywania midletu z wyjaśnieniem wszystkich niezbędnych kroków. Jej
częścią jest także dokumentacja formatu Przedowas+.
Dokumentacja ta jest integralną częścią strony dla programistów opisanej w rozdzia-
le 5.5.1 na następnej stronie. Znajduje się w części WIKI.

2. Dokumentacja kodu — jest przeznaczona dla programistów chcących bądź dostoso-

wywać midlet do własnych potrzeb bądź dla osób chcących wziąć udział w rozwoju
projektu.

Strona 42 z 59

5.5 Strona projektu

Rysunek 11: Redukcja rozmiaru danych

Dokumentacja ta jest integralną częścią kodu. W przypadku języka Java odpowiednie
zapisy są umieszczone z wykorzystaniem technologii Javadoc

. W pozostałych przypad-

kach (język Perl, pliki ANT, pliki tekstowe) komentarze zostały umieszczone zgodnie
ze konwencją danego języka.

5.5 Strona projektu

5.5.1 Strona dla programistów

Aby potencjalni użytkownicy rozwiązania mieli możliwość zapoznania się z projektem nie-

zbędne jest umieszczenie w odpowiednim miejscu w sieci dokumentacji oraz źródeł całego
systemu. Do tego celu został wybrany serwis SourceForge

będący standardem dla publikacji

Javadoc — fragment pakietu JDK odpowiedzialny za generowane dokumentacji, równocześnie techno-

logia dokumentowania kodu języka Java

SourceForge — darmowe repozytorium kodów źródłowych wykorzystywany przez bardzo wiele projektów

OpenSource

Strona 43 z 59

5.5 Strona projektu

Rysunek 12: Dokumentacja formatu pliku Przewodas+

projektów o otwartym kodzie (otwarta licencja jest wymogiem serwisu). Ponieważ wszyst-
kie elementy rozwiązania zostały udostępnione na licencji LGPL

nie było przeciwwskazań.

Adresem projektu jest url http://sourceforge.net/projects/microbus/.

Serwis SourceForge udostępnia programistom skupionym wokół projektów między innymi

takie funkcjonalności (zostały wymienione tyle te funkcje które są używane przez projekt):

1. wiki

2. serwer SVN

3. serwer HTTP

4. forum

Zrzut ekranu z wizytówką projektu znajduje się na rysunku 13 na następnej stronie.

[WIKI] GNU Lesser General Public License (pomniejsza ogólna powszechna licencja GNU) — licencja

wolnego oprogramowania

Strona 44 z 59

5.5 Strona projektu

Rysunek 13: Wizytówka projektu w serwisie Sourceforge

5.5.2 Strona dla użytkowników

Ponieważ celem głównym projektu jest stworzenie narzędzi do przygotowywania mo-

bilnych aplikacji bez wskazywania na konkretne rozwiązanie poniższą stronę www należy
traktować jako przykład.

Strona http://microbus.pl/ jest stroną użytkowników aplikacji dla mieszkańców Szcze-

cina (głównie) oraz innych miast (np. Piotrkowa Trybunalskiego czy Radomia). Najważniejsze
moduły jakie powinna mieć tego typu strona służąca dystrybucji gotowej aplikacji to:

pobierz Umożliwia użytkownikom aplikacji pobranie najnowszej wersji programu na kompu-

ter skąd istnieje możliwość instalacji aplikacji na telefonie komórkowym

forum Umożliwia użytkownikom wymianę uwag na temat działania programu, zgłaszanie

błędów i rozbieżności w danych

artykuły Zawierają opisy funkcjonowania aplikacji, informacje o ew. kosztach korzystania

z aplikacji czy metodach instalacji dla różnych modeli telefonów

nowości+RSS Umożliwia użytkownikom bieżące śledzenie zmian w aplikacji dla wybranej

przez siebie wersji. Strona udostępnia kanał RSS

z nowościami

[WIKI] Really Simple Syndication — jest to rodzina formatów sieciowych, opartych na języku XML

służących do publikacji często zmieniających się treści, takich jak wpisy blogów, wiadomości

Strona 45 z 59

5.5 Strona projektu

demo Wersja demonstracyjna aplikacji ilustrująca zasadę działania rozwiązania bez koniecz-

ności pobierania jej na telefon (wersja flash)

Na rysunku 14 przedstawiony jest zrzut ekranu strony http://microbus.pl/ — kon-

kretnie modułu forum.

Rysunek 14: Strona projektu dla użytkowników

Serwis WAP

Analogicznie dla strony www przy dystrybucji aplikacji bardzo pożądana jest strona wap.

Dla wielu użytkowników instalacja aplikacji za pośrednictwem sieci to jedyna możliwość (np.
jeśli telefon nie jest wyposażony ani w interfejs Bluetooth ani w Irda).

Strona 46 z 59

5.5 Strona projektu

Rysunek 15: Strona wap projektu MicroBus

Strona 47 z 59

6 Problemy

Poniżej zaprezentowane zostały najistotniejsze problemy napotkanie podczas realizacji

prac programistycznych oraz rozwoju projektu.

6.1 Prawa autorskie do danych prezentowanych w aplikacji

Jednym z najistotniejszych problemów przed którym stoi osoba chcąca przygotować apli-

kację mobilną z rozkładami jazdy nie problem techniczny. Są nimi prawa autorskie do danych
prezentowanych w aplikacji. Zgodnie z obowiązującym w Unii Europejskiej oraz większości
krajów świata prawem autorskim ([LAW]) sam fakt udostępnienia przez dany podmiot in-
formacji do publicznej wiadomości nie oznacza możliwości dalsze publikacji tych informacji
bez zgody właściciela. Co istotne do ochrony wartości niematerialnych nie jest niezbędny
często widoczny symbol c

! (copyright). Każda informacja publikowana w dowolny sposób

w celu dalszego powielania wymaga pisemnej zgody właściciela chyba, że wraz z ’wartością’
rozpowszechniane są zapisy (np. licencja) dopuszczająca takie użycie.

We wszystkich znanych mi przypadkach przewoźnicy albo nie informują o prawach autor-

skich i możliwości redystrybucji informacji albo wprost tego zakazują. Oznacza to, że przed
podjęciem jakichkolwiek prac technicznych niezbędne jest dopełnienie formalności prawnych
— tj. uzyskanie pisemnej zgody przewoźnika na publikację rozkładów jazdy za pomocą mo-
bilnej aplikacji.

6.2 Wielkość danych do przechowania w aplikacji

Istotnym problemem przy tworzeniu oprogramowania okazały się ograniczenia wielu urzą-

dzeń mobilnych związane z wielkością aplikacji Java (midletu). Dla wielu urządzeń (jak
precyzuje to profil MIDP 1.0) maksymalna wielkość pliku z aplikacją Java to zaledwie 64kb.
Nowsze urządzenia (wspierające MIDP 2.0) znoszą to ograniczenie (lub powiększają limit do
128kb w przypadku niektórych modeli) ale problematyka wielkości wynikowego pliku aplikacji
pozostaje ze względu np. na duże koszty pobierania takiej aplikacji z internetu.

W rozdziale 2.1 na stronie 10 prezentowany jest przykład który obrazuje, że gdyby za-

stosować rozwiązanie Timetableme które nie kompresuje w żaden sposób przechowywanych
wewnątrz aplikacji danych (poza naturalną kompresją plików Jar) wynikowa wielkość aplikacji
sięgałaby około 1MB. Aplikacja mobilna tej wielkości byłaby trudna w dystrybucji (dla wielu
osób koszt jej pobrania byłby nieakceptowalny) i prawdopodobnie byłyby poważne trudności
z uruchomieniem jej na większości starszych urządzeń.

Rozwiązaniem tego problemu było stworzenie kompresora (szczegółowy opis w rozdzia-

le 5.3 na stronie 35, w szczególności rysunek 11 na stronie 43). Głównym zadaniem kompreso-
ra jest wykorzystanie charakteru danych wejściowych (czyli danych tekstowych z rozkładami)
w celu maksymalnego zmniejszenia ich rozmiaru.

Strona 48 z 59

6.3 Złożoność algorytmiczna przetwarzania danych

Opisane w powyższej sekcji problematyka wielkości danych przetwarzanych przez aplikację

ma także swoje odbicie w złożoności zastosowanego algorytmu kompresji. W uproszczeniu
(szczegółowy opis znajduje się w rozdziale 5.3 na stronie 35) można napisać, że im bardziej
skomplikowany algorytm kompresji tym mniejszy rozmiar pliku wynikowego ale dłuższy czas
przetwarzania go (dekompresji) na urządzeniu mobilnym. O ile w przypadku kompresora
pracującego w pełnym środowisku czas przetwarzania danych ma znaczenie drugorzędne
o tyle w przypadku aplikacji mobilnej pracującej na urządzeniu o ograniczonych zasobach
prędkość przetwarzania na bardzo duże znaczenie.

W praktyce w trakcie implementacji kompresora konieczne był taki dobór mechanizmów

kompresji dla których złożoność algorytmiczna operacji odwrotnej (dekompresji) była możli-
wie najmniejsza. Założonym celem było, aby wszystkie podstawowe operacje odczytu porcji
danych (czyli np. odczyt rozkładu jazdy na zadanym przystanku) nie trwały dłużej niż se-
kundę na referencyjnym urządzeniu (wyznacznikiem był telefon Nokia 6310i).

W kilku wypadkach konieczne było umieszczenie w danych aplikacji nadmiarowych danych

które radykalnie poprawiały szybkość wczytywania informacji. Na przykład wszystkie ciągi
znaków są poprzedzone dwubajtowym słowem zawierającym długość następującego po nich
napisu. Pozwala to na wczytanie całej porcji danych bez konieczności wczytywania ich bajt
po bajcie w oczekiwaniu na znak końcowy.

6.4 Ograniczenia API JME

Ograniczenia związane z prezentacją wyników w mobilnych aplikacjach tworzonych w wy-

sokopoziomowym API języka Java w technologii JME zostały opisane w rozdziale 3.2 na
stronie 12 oraz 4.1.2 na stronie 22. Dodatkową trudnością przy implementacji midletu były
ograniczenia API oraz zastosowany języka Java w wersji 1.3.

Ograniczenia API w pierwszej kolejności odnosiły się operacji wczytywania danych z pli-

ków binarnych. JME udostępnia bardzo ograniczony zakres operacji. Dla porównania — pakiet
java.io w pełnej wersji 5 J2SE zawiera aż 48 klas, ten sam pakiet dla JME zawiera zaledwie
11 klas. Powoduje to konieczność ręcznego implementowania wielu operacji.

Jeszcze istotniejsze przy budowie algorytmu dekompresji danych okazały się braki w pa-

kiecie java.util zawierające wiele użytecznych klas a w szczególności struktury danych i algo-
rytmy na nich pracujące. W pełnej wersji API (J2SE) dostępnych jest 47 klas pomocniczych.
W JME zaledwie 9 z czego dostępne są zaledwie trzy kontenery: Vector, Stack i Hashtable.
Implementacja tego ostatniego ma duże wymagania obliczeniowe co w praktyce bardzo ogra-
nicza dostępny zakres jego zastosowań. Dodatkowo w JME nie są dostępne typy generyczne

Typy generyczne to element tzw. programowania uogólnionego pozwalającego na pisanie kodu programu

bez wcześniejszej znajomości typów danych na których ten kod będzie pracował. W C++ programowanie
uogólnione umożliwiają szablony (templates). W Java czy C# właśnie typy generyczne

Strona 49 z 59

6.5 Skala implementacji JSR179 w telefonów komórkowych

które pojawiły się dopiero w Java 5.

Wszystko to powoduje, że niezbędne jest implementowanie nawet najprostszych algo-

rytmów jak sortowanie czy filtrowanie. Ograniczony zakres dostępnych kontenerów zmusza
w większości wypadków do korzystania z typu Vector wypełnianego typem Object. Utrud-
nia to programowanie, sprawie, że kod staje się mało czytelny i zmusza to tworzenia kodu
którego implementacji spodziewalibyśmy się w bibliotekach systemowych.

6.5 Skala implementacji JSR179 w telefonów komórkowych

Jednym z celów projektu było stworzenie mechanizmu dzięki któremu Midlet samodziel-

nie rozpoznawałby przybliżone położenie użytkownika i na tej podstawie dedukował znajdu-
jące się w jego pobliżu przystanki.

W tym celu niezbędne było posiadanie dwóch informacji:

1. Dane geolokacyjne wszystkich przystanków danego rozkładu

2. Przybliżona pozycja geograficzna telefonu

Uzyskanie pierwszej informacji przynajmniej do celów testowych nie przedstawia dużych

trudności. Po odpowiednim rozszerzeniu formatu danych Przewodas+ informacje o każdym
przystanku można by rozszerzyć o długość i szerokość geograficzną. W produkcyjnym roz-
wiązaniu można by wykorzystać dane z systemu Google Maps w którym wcześniej koniecznie
byłoby zaznaczenie wszystkich przystanków (dla niektórych miast takich jak Warszawa jest
już to zrobione i na bieżąco aktualizowane).

Zdobycie informacji na temat pozycji telefonu komórkowego jest możliwe na kilka sposo-

bów. Nie wchodząc w szczegóły technologiczne należy wymienić trzy najważniejsze techniki:

1. Na podstawie CellID oraz Time Advance

2. Na podstawie Observerd Time Difference (OTD) lub Time of Arrival (TOA)

3. Na podstawie modułu GPS

Najprostsza technika opiera się o tak zwane CellID które jest unikalnym numerem nadaj-

nika GSM do którego podłączony jest aparat. Znając ten identyfikator możemy wykorzystując
bazę danych wiążących go z pozycją geograficzną określić przybliżone położenie. Dodatko-
wo mierząc Time Advance czyli czas potrzebny na przebycie fali radiowej od urządzenia
do nadajnika możemy przybliżyć rozwiązanie — zamiast okręgu wskazującego przybliżone
położenie otrzymujemy pierścień kołowy.

Druga technika wykorzystuje fakt, iż w danym momencie urządzenie mobile jest zazwyczaj

w zasięgu kilka nadajników. Posiadając informacje o ich położeniu oraz przybliżoną odległość
od każdego z nich (czyli stosując techniki zbliżone do opisanych powyżej) możemy dokonać
znacznie dokładniejszych szacunków.

Strona 50 z 59

6.5 Skala implementacji JSR179 w telefonów komórkowych

Dokładność obliczeń w obu powyższych metrach jest wprost proporcjonalna do gęstości

nadajników GSM w danej lokalizacji. Posługując się wynikami prac [LG, GSM] można przyjąć,
że możliwa jest do osiągnięcia precyzja między kilkanaście a kilkaset metrów która do tych
zastosować jest wystarczająca.

Ostatnie rozwiązanie bazuje na module GPS w które urządzenie mobile musi być wypo-

sażona bądź dostępne za pośrednictwem komunikacji Bluetooth. Precyzja takiego pomiaru
wynosi około 10 metrów.

Zagadnienia lokalizacji urządzenia mobilnego zostały zestandaryzowane w ramach Java

Community Process pod numerem JSR-179. Pełna nazwa standardu to „Location API for
J2ME

T M

” a data jego publikacji przypadła na listopad 2003. Mimo względnie długiego

czasu od opublikowania specyfikacji (ponad 5 lat) nadal bardzo niewiele modeli telefonów
wspiera ten standard. Przeglądając listę modeli urządzeń mobilnych na stronach producenta
języka Java (http://developers.sun.com/mobility/device/device) widać wyraźnie,
że JSR-179 wspiera drobny odsetek dostępnych na rynku urządzeń i są to wyłącznie droższe,
lepiej wyposażone urządzenia.

Z tego względu kwestia implementacji ciekawej z punktu widzenia użytkownika końco-

wego funkcjonalności musiała zostać zaniechana.

Strona 51 z 59

7 Podsumowanie

Dokonując porównania założeń pracy oraz propozycji rozwiązania z osiągniętymi efek-

tami skłaniam się ku tezie, że większość podstawowych celów została osiągnięta. Udało
się przygotować w określonym czasie zestaw narzędzi pomocnych w wytworzeniu własnej
mobilnej aplikacji z rozkładami jazdy. Dla osób zainteresowanych projektem dostępna jest
dokumentacja użytkownika i programisty. Informacje te utrzymywane są przyjaznych por-
talach (osobnych dla użytkowników i programistów). Programiści chcący wspierać rozwój
rozwiązania mogą współpracować nad udokumentowanym kodem za pośrednictwem syste-
mu kontroli wersji. Wszystkie komponenty systemu dostępne są na otwartej licencji Apache
License V2.0

Podstawowym niedociągnięciem ostatnich kilkunastu miesięcy był brak skutecznej promo-

cji rozwiązania. W ramach projektu w serwisie Sourceforge zarejestrowanych jest (wyłączając
autora) czterech programistów jednak ich aktywność w projekcie jest znikoma. Dotychczas
największym sukcesem w promocji aplikacji pozostaje praca inżynierska obroniona przez Pio-
tra Kanię na Politechnice Szczecińskiej ([INZ]) oraz przygotowanie niezależnie od autora
wersji aplikacji dla Piotrkowa Trybunalskiego.

Zdecydowanie dalsze udoskonalanie rozwiązania połączone z budowaniem społeczności

programistów zainteresowanych rozwojem systemu uznaję za najważniejsze cele na przy-
szłość.

Strona 52 z 59

A Prace cytowane

Literatura

[MOB] „Writing Mobile Code: Essential Software Engineering for Building Mobile Applica-

tions”, Ivo Salmre, Addison Wesley Professional, ISBN: 978-0-321-26931-7

[WJ] „Learning Wireless Java”, Qusay Mahmoud, O’Reilly Media, ISBN: 978-0-596-00243-5

[ALGH] „Algorithms in Java, Third Edition, Parts 1-4: Fundamentals, Data Structures, Sor-

ting, Searching”, Robert Sedgewick, Addison Wesley Professional, ISBN: 978-0-201-
36120-9

[BNF] „Visualizing Data, 1st Edition”, Ben Fry, O’Reilly Media ISBN: 978-0-596-51455-6

[GL] „Considerations of globalization solutions in J2ME”, Hu Jiong, Tong Jie (http://

www.ibm.com/developerworks/java/library/wi-global/index.html

)

[RMS] „J2ME record management store”, Soma Ghosh, (http://www.ibm.com/

developerworks/java/library/wi-rms/

)

[LG] „Location Based Services for Mobiles: Technologies and Standards”, Shu Wang, Jun-

gwon Min, Byung K. Yi, LG Electronics Mobile Research USA.

[GSM] „Are GSM phones THE solution for localization?”, Alex Varshavsky, Mike Y. Chen,

Eyal de Lara, Jon Froehlich, Dirk Haehnel, Jeffrey Hightower, Anthony LaMarca, Fred
Potter, Timothy Sohn, Karen Tang, Ian Smith.

[WIKI] Większość definicji zawartych w przypisach pochodzi ze stron Wikipedii (http://

pl.wikipedia.org/wiki/

[LAW] „Złodziejstwo intelektualne. Prawo autorskie w Internecie”, Mariusz Agnosiewicz,

(http://www.racjonalista.pl/kk.php/s,3636)

[INZ] „Projekt i implementacja aplikacji wspierającej wyszukiwanie drogi na trasach ko-

munikacyjnych przeznaczonej dla urządzeń mobilnych”, Piotr Kania, praca inżynierska
napisana w Katedrze Technik Programowania Politechniki Szczecińskiej pod kierunkiem
dr inż. Piotra Błaszyńskiego.

Strona 53 z 59

B Dodatki

B.1 Opis formatu danych wejściowych

Oryginalny format Przewodas został stworzony przez Szymona Ulatowskiego około 2002

roku na potrzeby aplikacji o tej samej nazwie. Opis projektu oraz opis formatu znajdują się
na stronie projektu:

http://szulat.republika.pl/przewodas/#dane
Na potrzeby projektu format ten został rozszerzony o możliwość definiowania opisów dla

poszczególnych godzin w rozkładzie. W dokumencie format ten w odróżnieniu od oryginal-
nego nazywany jest Przewodas+.

Poniżej znajduje się opis struktury pliku w formacie Przewodas+ w notacji Backusa-

Naura (BNF).

Kod źródłowy 2: Format Przewodas+ opisany notacją Backusa-Naura

−− dowolna i l o ś ć s p a c j i −−>

<ws>

: : = ” ” <ws> |

” ”

3
4

−− c y f r a , l i c z b a i o p i s −−>

< d i g i t>

: : = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9

| < d i g i t> <num>

: : = a | b | c | d | e | f | g | i

8
9

−− l i t e r a ł y −−>

<t a b> : : = ” $

\ b a c k s l a s h $ t ”

<s n>

: : = ”SN” <tab>

<op>

: : = ”OP” <tab>

<r n>

: : = ”RN” <tab>

<s>

: : = ”S” <tab>

<t 0>

: : = ”T0” <tab>

<t 1>

: : = ”T1” <tab>

<t 2>

: : = ”T2” <tab>

<o>

: : = ”O” <tab>

19
20

−− wpis ( y ) z g o d z i n ą i opcjonalnym opisem −−>

−e n t r y>

: : = <num> | <num>x<desc>

−e n t r i e s> : : = <t−e n t r y> | <t−e n t r y> <ws> <t−e n t r i e s> <EOL>

23
24

−− s t r u k t u r a o p i s −− k l u c z do o p i s u −−>

−e n t r y>

: : = <d e s c> <ws> <num>

−e n t r i e s> : : = <o−e n t r y> | <o−e n t r y> <ws> <o−e n t r i e s> <EOL>

Strona 54 z 59

B.1 Opis formatu danych wejściowych

−− s ł o w n i k opisów d l a t r a s y −−>

−l i n e> : : = <o> <o−e n t r i e s>

30
31

−− l i n i a ( e ) ze s ł o w n i k i e m nazw p r z y s t a n k ó w −−>

<sn

−l i n e>

: : = <sn> <num> <tab> < a s c i i> <EOL>

<sn

−l i n e s>

: : = <sn−l i n e> | <sn−l i n e> <sn−l i n e s>

34
35

−− l i n i a ( e ) ze s ł o w n i k i e m opisów −−>

<op

−l i n e>

: : = <op> <num> <tab> < a s c i i> <EOL>

<op

−l i n e s>

: : = <op−l i n e> | <op−l i n e> <op−l i n e s>

38
39

−− t r a s a wraz z numere l i n i i i nazwą ( k i e r u n k i e m ) −−>

<rn

−l i n e>

: : = <rn> <num> <tab> < a s c i i> <ws> < a s c i i> <EOL>

41
42

−− numer p r z y s t a n k u −−>

−l i n e> : : = <s> <num> <EOL>

44
45

−− l i s t a g o d z i n na p r z y s t a n k u (3 p o z y c j e ) −−>

<t0

−l i n e>

: : = <t0> <t−e n t r i e s>

<t1

−l i n e>

: : = <t1> <t−e n t r i e s> | <t1> ”=T0”

<t2

−l i n e>

: : = <t2> <t−e n t r i e s> | <t2> ”=T0”

| <t2> ”=T1”

49
50

−− s t r u k t u r a ( y ) wpisu (ów) na pojedynczym p r z y s t a n k u −−>

−e n t r y>

: : = <s−l i n e> <t0−l i n e> <t1−l i n e> <t2−l i n e>

−e n t r i e s> : : = <s−e n t r y> | <s−e n t r y> <s−e n t r i e s>

53
54

−− p e ł e n o p i s t r a s y z opcjonalnym s ł o w n i k i e m opisów −−>

<rn

−s e c t i o n>

: : = <rn−l i n e> <s−e n t r i e s> <s−l i n e> | <rn−l i n e> <s−

e n t r i e s> <s−l i n e> <o−l i n e>

<rn

−s e c t i o n s>

: : = <rn−s e c t i o n> | <rn−s e c t i o n> <rn−s e c t i o n s>

57
58

−− s t r u k t u r a p l i k u −−>

< f i l e >

: : = <sn−l i n e s> <op−l i n e s> <rn−s e c t i o n s>

Struktura zależności między poszczególnymi symbolami została zobrazowana na rysun-

ku 16 na następnej stronie.

B.1.1 Przykład pliku w formacie Przewodas

Poniżej znajduje się fragment poprawnego gramatycznie pliku z danymi wejściowymi dla

aplikacji w formacie Przewodas. Przyjęto następujące oznaczenia:

1. “(” — oznacza pojedynczą spację

Strona 55 z 59

B.1 Opis formatu danych wejściowych

Rysunek 16: Struktura pliku w formacie Przewodas

2. “→” — oznacza tabulację

. . . — oznacza blok pliku będący kontynuacją powyższej sekwencji zgodnie z gramatyką

Kod źródłowy 3: Przykład pliku w formacie Przewodas+

SN→0 → S i e n k i e w i c z a

SN→1 → B i a ł o s z e w s k i e g o

SN→2 →Tuwima

[ . . . ]

OP→0 → K ur s u je z pominięciem u l . Cukrowej

OP→1 →Kurs bez podjazdu pod SP 66

Strona 56 z 59

B.1 Opis formatu danych wejściowych

OP→2 →Autobus niskopodłogowy

[ . . . ]

RN→0 →106 GLEBOKIE

S →1

T0→601 635 xb 705 717 810 946 1058 1158 1258 1400 1506 1606 1706 1811

T1→647 823 922 1046 1146 1246 1358 1458 1558 1655 1826 1926

T2→=T1

S →2

[ . . . ]

O →a 0 b 2

Rysunek 17: Wizualizacja przykładowego rozkładu

B.1.2 Objaśnienia dla przykładu pliku

W przedstawionym w rozdziale B.1.1 na stronie 55 przykładzie pliku odnajdujemy kolejno

sekcje:

SN Sekcja SN definiuje słownik nazw przystanków. Wiąże kolejne numery z opisem. W tym

przykładzie liczba 1 jest skojarzona z opisem “Białoszewskiego”.

Strona 57 z 59

B.1 Opis formatu danych wejściowych

OP Sekcja OP definiuje słownik opisów stosowanych przy pozycjach na rozkładzie. Zasto-

sowany mechanizm jest identyczny jak w przypadku sekcji SN.

RN Sekcja RN definiuje numer linii (tutaj 106) oraz nazwę kierunku (GLEBOKIE). Najczę-

ściej spotykaną sytuacją jest to, że każda linia posiada dwa kierunki (z punktu A do B
i z B do A). W taki wypadku dla linii X powstałyby dwa kierunki (“X A” i “X B”).

S Sekcja S wskazuje numer przystanku (wg opisanego w słowniku numeru)

Tx Poszczególne sekcje T0, T1 i T2 opisują kursowanie komunikacji w trzech wariantach.

Najczęściej spotykane warianty to rozkłady dla dni roboczych (T0), sobót (T1) i świąt
(T2). Za symbolem Tx znajduje się lista godzin w notacji HHMM z opcjonalnym
opisem poprzedzonym literą “x”. Np. 635xb oznacza godzinę 6

z którą skojarzony

jest opis o symbolu “b”.

O Sekcja O odpowiada za tłumaczenie symboli opisów użytych w danym rozkładzie na od-

powiednie identyfikatory w słowniku opisów. W tym przykładzie z literą “b” jest sko-
jarzony opis i numerze 2. Oznacza to, że opisywana powyżej godzina zostanie w pełni
opisana jako 6

(

– “Autobus niskopodłogowy”).

Strona 58 z 59