Zestaw narzedzi programistycznych do generowania mobilnych aplikacji

POLSKO-JAPOŃSKA WYŻSZA SZKOŁA TECHNIK
KOMPUTEROWYCH
PRACA MAGISTERSKA
Nr ................
Zestaw narzędzi programistycznych do generowania
mobilnych aplikacji
Student
Nr albumu
Promotor
Specjalność
Katedra
Data zatwierdzenia tematu
Data zakończenia pracy
Szymon Nieradka
4868
prof. dr hab. Kazimierz Subieta
Inżynieria Oprogramowania i Baz Danych
Systemów Informacyjnych
2007.07.30
2009.01.31
Podpis promotora pracy
Podpis kierownika katedry
....................................
....................................
Streszczenie
Praca podejmuje problematykę mobilnych narzędzi prezentujących dane o ustrukturalizowanej 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órkowego 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 przewoź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 poszczegó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 . . . . . . . . . . . . . . . . . . . . . . . . .
5
6
6
2 Kontekst pracy
2.1 Dostępne na rynku rozwiązania . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
8
11
3 Opis narzędzi zastosowanych w pracy
3.1 Język programowania Java . . . . . . . . . . . .
3.2 Technologia tworzenia mobilnej aplikacji . . . .
3.2.1 Wireless Application Protocol . . . . . .
3.2.2 SMS . . . . . . . . . . . . . . . . . . .
3.2.3 Rozwiązania „natywne” . . . . . . . . .
3.2.4 Java Platform Micro Edition . . . . . . .
3.3 Środowisko programistyczne Eclipse . . . . . . .
3.4 Zestaw narzędzi i bibliotek do developmentu JME
3.4.1 Apache Ant . . . . . . . . . . . . . . .
3.4.2 Sun Java Wireless Toolkit . . . . . . . .
3.4.3 Antenna . . . . . . . . . . . . . . . . .
3.4.4 BlueCove . . . . . . . . . . . . . . . . .
3.4.5 Microemulator . . . . . . . . . . . . . .
3.4.6 ProGuard . . . . . . . . . . . . . . . . .
3.5 Język programowania Perl . . . . . . . . . . . .
3.6 VirtualBox . . . . . . . . . . . . . . . . . . . .
3.7 DocBook . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
12
12
13
13
14
14
16
17
17
17
17
18
18
19
19
19
20
.
.
.
.
.
.
.
.
.
21
21
21
22
22
23
23
23
24
26
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
na OS X
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Propozycja rozwiązania
4.1 Założenia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Dane wejściowe . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 Prezentacja . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3 Przenośność . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4 Budowanie . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Propozycja generycznego rozwiązania budowania mobilnej aplikacji
4.2.1 Krok 1: przygotowanie pliku w formacie Przewodas+ . . . .
4.2.2 Krok 2: konwersja danych . . . . . . . . . . . . . . . . . .
4.2.3 Krok 3: kompilacja midletu . . . . . . . . . . . . . . . . .
Strona 2 z 59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Serdecznie witamy wszystkich studentów, których interesują
tematy związane z pisaniem prac magisterskich z prawa i
administracji.
Witaj zmęczony uczniu!
Wszystkie prace magisterskie są tworzone wyłącznie na Twoje
potrzeby i wykorzystywane tylko przez Ciebie. Pamiętaj, aby nie
popełniać plagiatu w swojej pisemnej pracy magisterskiej.
Zamów nam swoją pracę magisterską - pomóż
Pomagamy w pisaniu prac dyplomowych. „Praktykujemy” od
czternastu lat i możemy poszczycić się dużą liczbą zadowolonych
klientów.
Strona internetowa, którą znalazłeś w sieci - Pisanie prac
dyplomowych - pomoże Ci napisać dobre prace magisterskie i
licencjackie. W rzeczywistości ludzie z tej strony pomogą ci
napisać twoją pracę.
Prace magisterskie - nadają się do wszystkiego. Oczywiście
poprawnie napisane prace są do wszystkiego. Nie tylko dla
dobrego samopoczucia, ale także dla dobrej kondycji
psychicznej.
Najlepiej prace dyplomowe czytać i pisać wieczorem przed
pójściem spać - wtedy zostaną najlepiej zapamiętane. Z
poważaniem!
Gwarantujemy fachową i rzetelną pomoc, którą otrzymasz od grona
naszych najlepszych specjalistów
Pisanie prac magisterskich, licencjackich i inżynierskich.
Posiadamy specjalistów z zakresu bankowości, pracy w zakresie
bezpieczeństwa, rachunkowości, finansów, ekonomii, marketingu,
zarządzania, polonistyki, pedagogiki, socjologii, prawa,
administracji, hotelarstwa i turystyki oraz religii.
SPIS RYSUNKÓW
4.2.4 Krok 4: budowanie midletu, możliwości prezentacji . . . . . . . . . .
4.2.5 Krok 5: możliwości prezentacji . . . . . . . . . . . . . . . . . . . . .
4.3 Proces generowania midletu na przykładzie jednego miasta . . . . . . . . . .
5 Prototyp rozwiązania
5.1 Midlet Java . . . . . . . . . . . . . . . . . . . . .
5.2 Aplikacja dla platformy Symbian . . . . . . . . . . .
5.3 Kompresor . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Pojęcia wstępne . . . . . . . . . . . . . . .
5.3.2 Ogólny schemat działania . . . . . . . . . .
5.3.3 Struktura słowa wyjściowego pliku binarnego
5.3.4 Optymalizacja danych . . . . . . . . . . . .
5.3.5 Redukcja rozmiaru danych . . . . . . . . . .
5.4 Dokumentacja projektu . . . . . . . . . . . . . . .
5.5 Strona projektu . . . . . . . . . . . . . . . . . . .
5.5.1 Strona dla programistów . . . . . . . . . . .
5.5.2 Strona dla użytkowników . . . . . . . . . .
26
27
29
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
32
32
34
35
35
36
37
39
42
42
43
43
45
6 Problemy
6.1 Prawa autorskie do danych prezentowanych w aplikacji .
6.2 Wielkość danych do przechowania w aplikacji . . . . . .
6.3 Złożoność algorytmiczna przetwarzania danych . . . . .
6.4 Ograniczenia API JME . . . . . . . . . . . . . . . . . .
6.5 Skala implementacji JSR179 w telefonów komórkowych
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
48
48
48
49
49
50
.
.
.
.
.
.
.
.
.
.
.
.
7 Podsumowanie
52
A Prace cytowane
53
B Dodatki
54
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
1
2
3
4
Propozycja schematu tworzenia mobilnej aplikacji . . . . . . . . .
Przygotowywanie plików w formacie Przewodas+ . . . . . . . . .
Konwersja danych w formacie Przewodas-a do formatu binarnego
Struktura midletu (pliku JAR) . . . . . . . . . . . . . . . . . . .
Strona 3 z 59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
25
26
27
SPIS TABEL
5
6
7
8
9
10
11
12
13
14
15
16
17
Możliwości prezentacji danych . . . . . . . . . . . . . .
Proces przygotowywania midletu na przykładzie rozkładu
Przykładowy widok aplikacji na telefonie Nokia 6310i . .
Przykładowy widok aplikacji na emulatorze Microemu .
Przykładowy widok aplikacji — wersja Symbian . . . .
Schemat blokowy działania kompresora . . . . . . . . .
Redukcja rozmiaru danych . . . . . . . . . . . . . . . .
Dokumentacja formatu pliku Przewodas+ . . . . . . . .
Wizytówka projektu w serwisie Sourceforge . . . . . . .
Strona projektu dla użytkowników . . . . . . . . . . . .
Strona wap projektu MicroBus . . . . . . . . . . . . . .
Struktura pliku w formacie Przewodas . . . . . . . . . .
Wizualizacja przykładowego rozkładu . . . . . . . . . .
. .
dla
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. .
. . . .
miasta
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . .
Szczecina
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
29
30
33
34
35
38
43
44
45
46
47
56
57
Spis tabel
1
2
Podsumowanie technologii tworzenia mobilnych aplikacji . . . . . . . . . . .
Struktura słowa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
39
Kody źródłowe
1
2
3
Lista plików midletu (bez obfuskacji) . . . . . . . . . . . . . . . . . . . . .
Format Przewodas+ opisany notacją Backusa-Naura . . . . . . . . . . . . .
Przykład pliku w formacie Przewodas+ . . . . . . . . . . . . . . . . . . . .
Strona 4 z 59
34
54
56
1 Wstęp
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 przeznaczona 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 zaliczyłbym:
1. Zastosowaną technologię, np:
(a) Midlet Java
(b) Bramka SMS
(c) Serwis WAP
(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
(c) otwarte 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 przygotowanych 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
(c) stron WWW lub WAP prezentujących te same dane
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 dokumentacji 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 przenoś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 celó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 elementem) 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 angielskim (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
2
Kontekst pracy
Problematyka zarysowana w rozdziale 1 na stronie 5 nie jest zagadnieniem nowym. Dostępnych jest wiele rozwiązań różniących się między sobą zastosowaną technologią i podejś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. Podsumowanie 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 rozkł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 przewoźników z poszczególnych miast.
Podsumowanie:
technologia: Rozwiązanie umożliwia prezentację danych na trzy sposoby: midlet Java (dalszy opis koncentruje się na tym przypadku), strony HTML i bot1 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
1
[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 ograniczenia 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 komunikacji 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ładami 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 bezpł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 innych niż określonych przez PKP celach
Timetableme
Timetableme (http://timetableme.wordpress.com/) jest jedynym znalezionym rozwiązaniem które jest platformą to tworzenia aplikacji a nie gotowym jednorazowym produktem. Strona projektu informuje w jaki sposób przygotować własną wersję aplikacji. Rozwiązanie 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 okazuje 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
2.2
Podsumowanie
Podsumowanie
Przedstawione powyżej zestawienie dostępnych na rynku rozwiązań służących prezentowaniu rozkładów jazdy na urządzeniach mobilnych pokazuje, że brakuje rozwiązań spełniających równocześnie następujące warunki:
1. Otwartość kodu — rozwiązanie musi udostępniać kompletne źródła na licencji umożliwiają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 aplikacji
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
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 VirtualBox (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ą1 .
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 argumentem 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
1
[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
3.2.1
Technologia tworzenia mobilnej aplikacji
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ść prezentowanych 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ługi 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 roamingowe jest skutecznym narzędziem tylko w obrębie jednego kraju
3. Konieczność stosowania niewygodnego „szyfrowego” wysyłania zapytań przez użytkowników
4. Ograniczenie wielkości wiadomości SMS do 160 znaków (przy 7 bitach na znak) znacznie utrudnia przekazanie pełnej informacji zwrotnej
Strona 13 z 59
3.2
3.2.3
Technologia tworzenia mobilnej aplikacji
Rozwiązania „natywne”
Przez sformułowanie „rozwiązania natywne” rozumiane jest budowanie aplikacji przeznaczonej 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 wynikają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 operacyjnego. Zazwyczaj konieczne jest tworzenie wielu wersji tej samej aplikacji dla różnych
modeli.
Dodatkowo na niekorzyść stosowanie tej technologii działa konieczność stosowania (najczęś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. Została ona zaprojektowana z myślą o urządzeniach o ograniczonych zasobach (szybkość procesora, 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ść przygotowanej 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 Configuration) 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 aplikacji. 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 platformy 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
Język
wania
programo-
Trudność nauki
Środowisko programistyczne
Koszty narzędzi
Przenośność aplikacji
Format aplikacji
Społeczność programistyczna
Możliwości
Szybkość działania
Możliwość zapisania konfiguracji
Penetracja rynku
3.3
JavaME
Java
Symbian
SMS
Programowanie
n/d
C++
średnia
dostępne
duża
dostępne
darmowe
średnia
WAP
PocketPC
C, C++
średnia
dostępne
WML/
XHTMLMP
mała
dostępne
płatne
mała
n/d
duża
darmowe
duża
płatne
mała
jad/jar
duża
sis
duża
n/d
n/d
wml, xhtml
duża
cab
średnia
wystarczające
średnia
Możliwości
duże
niewystarczające
szybka
n/d
wystarczające
średnia
duże
tak
tak
nie
nie
tak
bliska
100%
bardzo duża
mała
bardzo duża
Rynek
mała
średnia
dostępne
szybka
Środowisko programistyczne Eclipse
Eclipse to platforma do tworzenia aplikacji desktopowych (fat-client, rich-client) napisana w języku programowania Java. Projekt został stworzony przez firmę IBM a następnie przekazany społeczności OpenSource. Od 2003 roku jest on rozwijany przez Fundację 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) rozpowszechniane 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 wykorzystaniem innych środowisk programistycznych (więcej w następnym rozdziale oraz podrozdziale 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, zintegrowanych ś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 pozwoli 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 narzę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ń wymagają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 upraszczają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 ładowania 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 platformy 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
3.4.6
Język programowania Perl
ProGuard
ProGuard jest darmowym optymalizatorem, obfuskatorem1 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 operatora 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 procesory Intel X86. Umożliwia emulację wirtualnego komputera na jednym z systemów operacyjnych 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 rozwią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.
1
[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
3.7
DocBook
DocBook
DocBook to język znaczników przeznaczony do tworzenia dokumentacji technicznej. Pierwotnie 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 & Associates. 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:
1 <book l a n g= ’ p l ’>
2
<b o o k i n f o>
3
<a u t h o r g r o u p>
4
<a u t h o r>Szymon N i e r a d k a</ a u t h o r>
5
</ a u t h o r g r o u p>
6
< t i t l e >MicroBus</ t i t l e >
7
< s u b t i t l e>Jak z r o b i ć MicroBus−a d l a s w o j e g o m i a s t a ?</ s u b t i t l e>
8
< e d i t i o n>$ R e v i s i o n $</ e d i t i o n>
9
</ b o o k i n f o>
10
<c h a p t e r i d=” w s t e p ”>
11
< t i t l e >Wstęp</ t i t l e >
12
<p a r a>w s t ę p</ p a r a>
13
</ c h a p t e r>
Może zostać przekształcony do formatu HTML, WML, XHTML, RTF, PDF, Unix Manpage 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
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 został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 potencjalni 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 wykorzystywanym 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 obrę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. Aktualizowane 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 Przemysł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 stosowanych 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 przystanku (np. dni pracujące, soboty i niedziele)
3. Ze względu na zastosowanie płaskiego pliku a nie np. formatu XML nie można wykorzystywać 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 platformach:
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 stronie 12.
4.1.4
Budowanie
Jak zostało to opisane w rozdziale 3 na stronie 12 podstawowym założeniem przy projektowaniu 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 JDK1 oraz narzędzie Ant (patrz 3.4.1
na stronie 17).
4.2
Propozycja generycznego rozwiązania budowania mobilnej aplikacji
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 niniejszym 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:
1
[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 dostępne warianty notacji
(c) Opis struktury pliku w notacji BNF
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 strukturze wejściowego pliku
4. Konwerter musi umożliwiać pracę w trybie DEBUG w celu szczegółowego przeanalizowania 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ściowych 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 informacji 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 wykorzystywać 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 odpowiedzialne 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 gotowych 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 informacji 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
DAO1 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 technologii. 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 informacji z wykorzystaniem internetu
4. Bot GG1 /Jabber2 — automat udzielający odpowiedzi na zadane pytania za pośrednictwem 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 brakom 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 rozdziale 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.
1
[WIKI] Gadu-Gadu (w skrócie GG lub gg) — komunikator internetowy dla systemu Windows, opracowywany przez firmę GG Network S.A. inspirowany komunikatorem ICQ
2
[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 Przewodas-a do formatu binarnego silnie zorientowanego na minimalizację wielkości wynikowego 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
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ązania 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 funkcjonalnoś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 pakiecie/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 procesowi 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)
1 $ j a r t f d i s t / MicroBus . j a r
2 META−INF /
3 META−INF /MANIFEST .MF
4 m i c r o b u s . png
5 szn /
6 s z n /DB. c l a s s
7 s z n / Data . c l a s s
8 szn / D i r e c t i o n . c l a s s
9 s z n / Main . c l a s s
10 f /
11 f /1
12 f /2
13 f /3
14 f /4
15 f / i
5.2
Aplikacja dla platformy Symbian
Na bazie projektu MicroBus została obroniona Politechnice Szczecińskiej praca inżynierska 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*1 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 przygotowana w postaci pojedynczego archiwum Jar2 .
1
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
2
[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:
1
$ j a v a − j a r conv . j a r <i n p u t f i l e > <o u t p u t 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:
1
$ j a v a −ea −DDEBUG=t r u e − j a r conv . j a r <i n p u t f i l e > <o u t p u t d i r>
Pierwsza z nich (“-ea” lub pełna nazwa “-enableassertions”) to parametr maszyny wirtualnej Java włączający mechanizm asercji1 . Druga (“-DDEBUG=true”) przekazuje w zmiennej środowiskowej “DEBUG” wartość “true”. Dzięki tej instrukcji aplikacja przekieruje strumień 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 blokowego 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 wczytywany 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 przekazanym jako drugi parametr aplikacji (outDir). Aplikacja generuje pliki dwóch rodzajów:
plik ’i’ Plik ’i’ to indeks zawierający:
1
[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ć
(c) lista identyfikatorów przystanków tego kierunku
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 "
5.3.3
ilość plików
< 2 ∗ X/max
(1)
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 zakresie 000 – 2359 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 000 otrzymujemy:
oraz:
000 → 0
(2)
2359 → 23 ∗ 60 + 59 = 1439
(3)
< −2359 : 2359 >→< −1439 : 1439 >→ 2879
(4)
Ponieważ przesunięcie czasu może występować ze znakiem ujemnym potencjalnie potrzebujemy:
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
log2 (2879) ≈ 11.49
(5)
log2 (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
212 = 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
B
7
6
5
4
A
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. 810
b gdzie
zajezdni)
b
— zjazd do
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 zobrazowany 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 Przewodas+ 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):
Sn gdzie n ∈ N; n " 2
(8)
Dla każdego wpisu typu S poza ostatnim w kolejności istnieją dokładnie trzy wpisy typu
Tx . Są one numerowane kolejno T1 , T2 , T3 :
Tx gdzie x ∈ {0, 1, 2}
(9)
tx,i gdzie x ∈ {0, 1, 2}; i ∈ N; i " 0
(10)
Dla każdego wpisu Tx istnieje dodatnia ilość wpisów z godzinami.
Poniżej został przedstawiony przykład danych spełniających powyższe warunki dla 3 przystanków (n = 3).
1
2
3
4
5
6
7
8
9
S
T0
T1
T2
S
T0
T1
T2
S
Pierwszy przystanek
6 :00 6 :10 6 :20 6 :30
7 :00 7 :10 7 :20 7 :30
7 :00 7 :10 7 :20 7 :30
Drugi przystanek
6 :05 6 :15 6 :25 6 :35
7 :05 7 :15 7 :20 7 :35
7 :05 7 :15 7 :25 7 :35
Ostatni przystanek
6 :50 7 :00
7 :50 8 :00
7 :50 8 :00
6 :55 7 :05
7 :55 8 :05
7 :55
W pierwszym kroku następuje uzupełnienie ilości wszystkich wpisów tx,i do maksymalnej
występującej wartości. W tym wypadku oznacza to, że ostatni wiersz (T2 dla S1 ) 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.
1
2
3
4
5
6
7
8
9
S
T0
T1
T2
S
T0
T1
T2
S
Pierwszy przystanek
6 :00 6 :10 6 :20 6 :30
7 :00 7 :10 7 :20 7 :30
7 :00 7 :10 7 :20 7 :30
Drugi przystanek
6 :05 6 :15 6 :25 6 :35
7 :05 7 :15 7 :20 7 :35
7 :05 7 :15 7 :25 7 :35
Ostatni przystanek
6 :50 7 :00
7 :50 8 :00
7 :50 8 :00
6 :55 7 :05
7 :55 8 :05
7 : 5 5 X:XX
W następnej kolejności wykonywana odejmowania dla kolejnych wpisów tx,i dla pierwszego przystanku:
Strona 40 z 59
5.3
Kompresor
tx,i = tx,i − tx,i−1 dla każdego i > 0; x = 0
(11)
tx,i = tx−1,i − tx,i dla każdego i > 0; x > 0
(12)
Dla kolejnych przystanków wykonywana jest analogiczne operacja ale odejmująca wartości
z poprzedniego przystanku:
1
2
3
4
5
6
7
8
9
S
T0
T1
T2
S
T0
T1
T2
S
Pierwszy przystanek
6 :00 0 :10 0 :10 0 :10
1 :00 0 :10 0 :10 0 :10
0 :00 0 :10 0 :10 0 :10
Drugi przystanek
0 :05 0 :05 0 :05 0 :05
0 :05 0 :05 0 :05 0 :05
0 :05 0 :05 0 :05 0 :05
Ostatni przystanek
0 :20 0 :10
0 :20 0 :10
0 :20 0 :10
0 :05 0 :05
0 :05 0 :05
0 : 0 5 X:XX
W ostatnim kroku wykonywana jest operacja wyszukiwania powtórzeń dla poszczególnych
grup tx,i oraz całych wpisów Tx .
W przypadku napotkania powtarzających się więcej niż dwa razy identycznych wpisów
tx,i w ich miejsce generowany jest symbol REPEAT COUNT (oznaczony w poniższym przykładzie symbolem R). Po nim następuje krotność powtórzeń.
W przypadku napotkania identycznych wpisów Tx generowane są oznaczenia THE SAMEAS Tx MINUS 1 lub THE SAME AS ONE LEVEL UP w zależności od sytuacji. Jeśli powtórka nastąpi w ramach tego samego wpisu Sn wygenerowany zostanie pierwszy symbol
(oznaczony na poniższym listningu jako =T0 lub =T1).
jeżeli ∀x > 0, i " 0:
tx,i = tx−1,i
(13)
Jeżeli powtórka nastąpi pomiędzy dwoma sąsiadującymi wpisami Sn dla tych samych
pozycji x generowany jest drugi wpis (THE SAME AS ONE LEVEL UP).
jeżeli ∀x > 0, i " 0:
1
2
3
4
5
6
7
8
9
S
T0
T1
T2
S
T0
T1
T2
S
Sn {tx,i } = Sn−1 {tx,i }
Pierwszy przystanek
6 : 0 0 R3 x 0 : 1 0 0 : 2 0 0 : 1 0
1 : 0 0 R3 x 0 : 1 0 0 : 2 0 0 : 1 0
=T1
Drugi przystanek
R6 x 0 : 0 5
=T0
R5 x 0 : 0 5 X:XX
Ostatni przystanek
Strona 41 z 59
(14)
5.4
5.3.5
Dokumentacja projektu
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 przykł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 (log10 ) 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ą przeznaczone 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 procesie 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 rozdziale 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ź dostosowywać 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 Javadoc1 . W pozostałych przypadkach (język Perl, pliki ANT, pliki tekstowe) komentarze zostały umieszczone zgodnie
ze konwencją danego języka.
5.5
5.5.1
Strona projektu
Strona dla programistów
Aby potencjalni użytkownicy rozwiązania mieli możliwość zapoznania się z projektem niezbędne jest umieszczenie w odpowiednim miejscu w sieci dokumentacji oraz źródeł całego
systemu. Do tego celu został wybrany serwis SourceForge2 będący standardem dla publikacji
1
Javadoc — fragment pakietu JDK odpowiedzialny za generowane dokumentacji, równocześnie technologia dokumentowania kodu języka Java
2
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ż wszystkie elementy rozwiązania zostały udostępnione na licencji LGPL1 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.
1
[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 mobilnych 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 Szczecina (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 komputer 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ł RSS1 z nowościami
1
[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
Serdecznie witamy wszystkich studentów, których interesują
tematy związane z pisaniem prac magisterskich z prawa i
administracji.
Witaj zmęczony uczniu!
Wszystkie prace magisterskie są tworzone wyłącznie na Twoje
potrzeby i wykorzystywane tylko przez Ciebie. Pamiętaj, aby nie
popełniać plagiatu w swojej pisemnej pracy magisterskiej.
Zamów nam swoją pracę magisterską - pomóż
Pomagamy w pisaniu prac dyplomowych. „Praktykujemy” od
czternastu lat i możemy poszczycić się dużą liczbą zadowolonych
klientów.
Strona internetowa, którą znalazłeś w sieci - Pisanie prac
dyplomowych - pomoże Ci napisać dobre prace magisterskie i
licencjackie. W rzeczywistości ludzie z tej strony pomogą ci
napisać twoją pracę.
Prace magisterskie - nadają się do wszystkiego. Oczywiście
poprawnie napisane prace są do wszystkiego. Nie tylko dla
dobrego samopoczucia, ale także dla dobrej kondycji
psychicznej.
Najlepiej prace dyplomowe czytać i pisać wieczorem przed
pójściem spać - wtedy zostaną najlepiej zapamiętane. Z
poważaniem!
Gwarantujemy fachową i rzetelną pomoc, którą otrzymasz od grona
naszych najlepszych specjalistów
Pisanie prac magisterskich, licencjackich i inżynierskich.
Posiadamy specjalistów z zakresu bankowości, pracy w zakresie
bezpieczeństwa, rachunkowości, finansów, ekonomii, marketingu,
zarządzania, polonistyki, pedagogiki, socjologii, prawa,
administracji, hotelarstwa i turystyki oraz religii.
5.5
Strona projektu
demo Wersja demonstracyjna aplikacji ilustrująca zasadę działania rozwiązania bez konieczności pobierania jej na telefon (wersja flash)
Na rysunku 14 przedstawiony jest zrzut ekranu strony http://microbus.pl/ — konkretnie 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
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ć aplikację 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 informacji 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
c (copyright). Każda informacja publikowana w dowolny sposób
często widoczny symbol !
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 autorskich 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ą mobilnej 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 zastosować 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 rozdziale 5.3 na stronie 35, w szczególności rysunek 11 na stronie 43). Głównym zadaniem kompresora jest wykorzystanie charakteru danych wejściowych (czyli danych tekstowych z rozkładami)
w celu maksymalnego zmniejszenia ich rozmiaru.
Strona 48 z 59
6.3
6.3
Złożoność algorytmiczna przetwarzania danych
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żliwie 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ż sekundę 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 wysokopoziomowym 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 plikó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 pakiecie java.util zawierające wiele użytecznych klas a w szczególności struktury danych i algorytmy 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 ogranicza dostępny zakres jego zastosowań. Dodatkowo w JME nie są dostępne typy generyczne1
1
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 algorytmó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. Utrudnia 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 samodzielnie rozpoznawałby przybliżone położenie użytkownika i na tej podstawie dedukował znajdują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 rozwią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 sposobó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 nadajnika 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. Dodatkowo 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ć wyposaż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
J2MET 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ńcowego funkcjonalności musiała zostać zaniechana.
Strona 51 z 59
7 Podsumowanie
7
Podsumowanie
Dokonując porównania założeń pracy oraz propozycji rozwiązania z osiągniętymi efektami 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 portalach (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 systemu 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 promocji 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 Piotra 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 przyszłość.
Strona 52 z 59
A Prace cytowane
A
Prace cytowane
Literatura
[MOB] „Writing Mobile Code: Essential Software Engineering for Building Mobile Applications”, 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, Sorting, Searching”, Robert Sedgewick, Addison Wesley Professional, ISBN: 978-0-20136120-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, Jungwon 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 komunikacyjnych 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
B.1
Dodatki
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 oryginalnego nazywany jest Przewodas+.
Poniżej znajduje się opis struktury pliku w formacie Przewodas+ w notacji BackusaNaura (BNF).
Kod źródłowy 2: Format Przewodas+ opisany notacją Backusa-Naura
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<!−− dowolna i l o ś ć s p a c j i −−>
<ws> : : = ” ” <ws> | ” ”
<!−− c y f r a , l i c z b a
< d i g i t> : : = 0 | 1
<num> : : = < d i g i t> |
<d e s c>
: := a | b
i o p i s −−>
| 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
< d i g i t> <num>
| c | d | e | f | g | i
<!−− l i t e r a ł y −−>
<t a b> : : = ” $\ b a c k s l a s h $ t ”
<s n> : : = ”SN” <t a b>
<op> : : = ”OP” <t a b>
<r n> : : = ”RN” <t a b>
<s>
: : = ”S” <t a b>
<t 0> : : = ”T0” <t a b>
<t 1> : : = ”T1” <t a b>
<t 2> : : = ”T2” <t a b>
<o>
: : = ”O” <t a b>
<!−− w p i s ( y ) z g o d z i n ą i o p c j o n a l n y m o p i s e m −−>
<t−e n t r y>
: : = <num> | <num>x<d e s c>
<t−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>
<!−− s t r u k t u r a o p i s −− k l u c z do o p i s u −−>
<o−e n t r y>
: : = <d e s c> <ws> <num>
<o−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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
Opis formatu danych wejściowych
<!−− s ł o w n i k o p i s ó w d l a t r a s y −−>
<o− l i n e> : : = <o> <o−e n t r i e s>
<!−− l i n i a ( e ) z e 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>
: : = <s n> <num> <t a b> < 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>
<!−− l i n i a ( e ) z e s ł o w n i k i e m o p i s ó w −−>
<op− l i n e>
: : = <op> <num> <t a b> < 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>
<!−− 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>
: : = <r n> <num> <t a b> < a s c i i> <ws> < a s c i i> <EOL>
<!−− numer p r z y s t a n k u −−>
<s− l i n e> : : = <s> <num> <EOL>
<!−− l i s t a g o d z i n na
<t0− l i n e>
: : = <t 0>
<t1− l i n e>
: : = <t 1>
<t2− l i n e>
: : = <t 2>
p r z y s t a n k u ( 3 p o z y c j e ) −−>
<t−e n t r i e s>
<t−e n t r i e s> | <t 1> ”=T0”
<t−e n t r i e s> | <t 2> ”=T0”
| <t 2> ”=T1”
<!−− s t r u k t u r a ( y ) w p i s u ( ów ) na p o j e d y n c z y m p r z y s t a n k u −−>
<s−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>
<s−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>
<!−− p e ł e n o p i s t r a s y z o p c j o n a l n y m s ł o w n i k i e m o p i s ó 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>
56 <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 −−>
59 < 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 rysunku 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+
1
2
3
4
5
6
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 u r s u j e z p o m i n i ę c i e m u l . C u k r o w e j
OP→1 →Kurs be z p o d j a z d u pod SP 66
Strona 56 z 59
B.1
Opis formatu danych wejściowych
7 OP
→2 →Autobus n i s k o p o d ł o g o w y
8 [...]
9 RN→0 →106 GLEBOKIE
10 S →1
11 T0→601 635 xb 705 717 810 946 1058 1158 1258 1400 1506 1606 1706 1811
12 T1→647 823 922 1046 1146 1246 1358 1458 1558 1655 1826 1926
13 T2→=T1
14 S →2
15 [ . . . ]
16 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. Zastosowany 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ę 635 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 odpowiednie identyfikatory w słowniku opisów. W tym przykładzie z literą “b” jest skojarzony opis i numerze 2. Oznacza to, że opisywana powyżej godzina zostanie w pełni
opisana jako 635
b (b – “Autobus niskopodłogowy”).
Strona 58 z 59
Serdecznie witamy wszystkich studentów, których interesują
tematy związane z pisaniem prac magisterskich z prawa i
administracji.
Witaj zmęczony uczniu!
Wszystkie prace magisterskie są tworzone wyłącznie na Twoje
potrzeby i wykorzystywane tylko przez Ciebie. Pamiętaj, aby nie
popełniać plagiatu w swojej pisemnej pracy magisterskiej.
Zamów nam swoją pracę magisterską - pomóż
Pomagamy w pisaniu prac dyplomowych. „Praktykujemy” od
czternastu lat i możemy poszczycić się dużą liczbą zadowolonych
klientów.
Strona internetowa, którą znalazłeś w sieci - Pisanie prac
dyplomowych - pomoże Ci napisać dobre prace magisterskie i
licencjackie. W rzeczywistości ludzie z tej strony pomogą ci
napisać twoją pracę.
Prace magisterskie - nadają się do wszystkiego. Oczywiście
poprawnie napisane prace są do wszystkiego. Nie tylko dla
dobrego samopoczucia, ale także dla dobrej kondycji
psychicznej.
Najlepiej prace dyplomowe czytać i pisać wieczorem przed
pójściem spać - wtedy zostaną najlepiej zapamiętane. Z
poważaniem!
Gwarantujemy fachową i rzetelną pomoc, którą otrzymasz od grona
naszych najlepszych specjalistów
Pisanie prac magisterskich, licencjackich i inżynierskich.
Posiadamy specjalistów z zakresu bankowości, pracy w zakresie
bezpieczeństwa, rachunkowości, finansów, ekonomii, marketingu,
zarządzania, polonistyki, pedagogiki, socjologii, prawa,
administracji, hotelarstwa i turystyki oraz religii.
Skorowidz
*BSD, 19
OpenSource, 11, 16
OS/2, 19
A*, 35
Android, 14
Apache License V2.0, 52
PalmOS, 5, 14
Przewodas, 5, 6, 21, 22, 26, 42, 54, 55
Przewodas+, 24, 26, 30, 35, 36, 42, 50, 54
Bluetooth, 18, 46, 51
BNF, 6, 24, 54
BREW, 14
RIM Blackberry, 14
SUN Microsystems, 12, 19
Sun Microsystems, 14
Symbian, 5, 6, 14, 28, 35
C++, 6, 16
CellID, 50
CLDC, 15, 23, 32
Time Advance, 50
Time of Arrival (TOA), 50
DocBook, 20
Eclipse, 16
WAP, 5, 6, 9, 10, 13, 28
Windows Mobile, 14, 18
GPS, 50, 51
XML, 5, 13, 20, 22
IBM, 16
iPhone OS, 14
Irda, 46
Java, 5, 6, 8–10, 12, 14, 16–19, 22, 23, 26,
27, 31, 32, 36, 43, 48–51
JCP, 15
JME, 12, 14, 15, 17, 18, 21, 22, 31, 49
JSR, 15
Linux, 12, 14, 17–19, 23
MAC OS X, 5, 18, 19, 22
MicroBus, 1, 34
Microsoft Windows, 12, 17–19, 23
Midlet, 5, 6, 8–10, 17, 26, 27, 31, 32, 42,
48–50
MIDP, 6, 10, 15, 23, 32, 48
Observerd Time Difference (OTD), 50
Strona 59 z 59