POLITECHNIKA WARSZAWSKAWydział Elektroniki i Technik Informacyjnych
Instytut Radioelektroniki
PRACA DYPLOMOWA – INŻYNIERSKA
Piotr Marek Mazur
MODUŁ WSPÓŁPRACY DETEKTORA UPADKU Z TELEFONEM KOMÓRKOWYM
Kierownik pracy
Dr inż. Marian Kazubek
Ocena ...........................................
...........................................
Podpis Przewodniczącego
Komisji Egzaminu Dyplomowego
WARSZAWA 2008
Moduł współpracy detektora upadku z telefonem komórkowym
Serdecznie podziękowania składam
Panu dr. inż. Marianowi Kazubkowi
za cierpliwość, przychylność oraz pomoc przy
realizacji niniejszej pracy.
2
Piotr Mazur
Specjalność: Elektronika i Informatyka w
Medycynie
Data urodzenia: 30 marzec 1985
Data rozpoczęcia studiów: październik 2004 r.
ŻYCIORYS
Urodziłem się 30 marca 1985 roku w Gdyni. W 1992 roku rozpocząłem naukę w Szkole
Podstawowej nr 18 w Gdyni. W 2000 roku przeprowadziłem się do Warszawy, gdzie
dostałem się do II Liceum Ogólnokształcącego im. Stefana Batorego – klasa o profilu
matematyczno – fizycznym. W 2004 roku zdałem egzamin maturalny, oraz rozpocząłem
studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki Warszawskiej.
Kształcę się na specjalności Elektronika i Informatyka w Medycynie.
..............................................
Piotr Mazur
EGZAMIN DYPLOMOWY
Złożył egzamin dyplomowy w dniu.............................
z wynikiem ....................................................................
Ogólny wynik studiów..................................................
Dodatkowe uwagi i wnioski Komisji.............................
………………………………………………………….
3
Moduł współpracy detektora upadku z telefonem komórkowym
Streszczenie
Praca niniejsza zawiera projekt oprogramowania telefonu komórkowego umożliwiającego
odbiór komunikatów alarmowych z detektora upadku lub innych urządzeń monitorujących.
Aplikacja ma za zadanie nawiązać połączenie bezprzewodowe pomiędzy wymienionym
urządzeniem a telefonem komórkowym. W ramach pracy stworzyłem program na telefon
komórkowy napisany w języku programowania Java 2 Micro Edition. Do zakresu pracy
należało zapoznanie się z technologią Bluetooth oraz stworzenie aplikacji działającej na
telefonie komórkowym.
Module connecting man down detection
device with mobile phone
Summary
The goal of the project was to create a complementary software for the man down
detection module created by Jarosław Leksinski. The implemented application is supposed to
create a connection between this module and a mobile phone. I have created a midlet working
on a mobile phone using Java 2 MicroEdition. The work included gathering knowledge about
Bluetooth technology and creation of an application capable of working on a mobile phone.
4
Piotr Mazur
Spis treści
1. Wstęp
2. Cel pracy
3. Założenia funkcjonalne
4. Przegląd dostępnych na rynku rozwiązań monitoringu pacjenta
5. Łączność bezprzewodowa
5.1 Dostępne rozwiązania
5.2 Transmisja poprzez Bluetooth
5.3 Architektura system
5.4 Warstwy protokołu
5.5 Struktura pakietu
6. Telefon komórkowy jako nośnik oprogramowania
6.1 Charakterystyka
6.2 Systemy operacyjne
6.3 Wybór języka programowania
6.4 Java 2 Micro Edition
7. Projekt modułu oprogramowania telefonu komórkowego
7.1 Założenia projektowe
7.2 Detektor upadku
7.3 Algorytm
7.4 Środowisko programistyczne
7.5 Implementacja
8. Realizacja
9. Podsumowanie
9.1 Spełnienie założeń
9.2 Możliwości rozwoju pracy
10. Bibliografia
5
Moduł współpracy detektora upadku z telefonem komórkowym
1. Wstęp
Realizacja pracy dyplomowej zawiera projekt oprogramowania telefonu komórkowego
umożliwiającego odbiór komunikatów alarmowych z detektora upadku lub innych urządzeń
monitorujących.
Stały monitoring pacjenta jest dzisiaj niezmiernie ważną dziedziną medycyny. Związane
jest to z wieloma czynnikami. Hospitalizowanie osoby tylko częściowo niesprawnej wiąże się
z równie wysokimi kosztami, jak osoby ciężko chorej. Pomijając aspekt czysto ekonomiczny
należy pamiętać, iż przebywanie w szpitalu czy klinice nie należy do najprzyjemniejszych. W
związku z powyższym racjonalne jest umożliwienie pacjentowi jak najszybszego powrotu do
jego codziennego stylu życia. Z pomocą przychodzą nowe technologie, które umożliwiają
monitorowanie pacjenta na odległość. Telemedycyna jest połączeniem szerokiego wachlarza
dziedzin nauki, jak: radiokomunikacja, telekomunikacja, elektronika czy informatyka. Istnieją
na rynku produkty, które stale przesyłają do ośrodków monitorujących poprzez Internet czy z
wykorzystaniem telefonii komórkowej informacje z urządzeń bezpośrednio przyczepionych
do badanych pacjentów. Niniejsza praca inżynierska jest kolejnym tego typu przykładem
urządzenia.
Jeden z wariantów stałego monitoringu polega na wyposażeniu pacjenta w niewielkie
urządzenie, które zbiera wybrane informacje, a następnie łączy się z terminalem
odpowiadającym za przesyłanie danych. Terminalem może być telefon komórkowy bądź
komputer stacjonarny z połączeniem do Internetu. W kwestii samego połączenia pomiędzy
urządzeniem monitorującym a terminalem możliwe są warianty: przewodowe bądź
bezprzewodowe. Biorąc pod uwagę wygodę pacjenta oraz ogólną użyteczność najlepiej
wybrać coraz bardziej rozpowszechniony wariant bezprzewodowy. Przy założeniu, że
monitor jest urządzeniem lekkim i posiada niewielki rozmiar, oraz że łączy się
bezprzewodowo z terminalem odpowiadającym za przesyłanie danych, otrzymujemy
rozwiązanie bardzo wygodne z punktu widzenia pacjenta oraz skuteczne w działaniu z punktu
widzenia zespołu monitorującego.
6
Piotr Mazur
2. Cel pracy
Celem pracy jest napisanie oprogramowania na telefon komórkowy, które umożliwi stały
monitoring pacjenta z wykorzystaniem istniejącego detektora upadku lub innego urządzenia.
Telefon komórkowy ma za zadanie nawiązać połączenie bezprzewodowe z urządzeniem
monitorującym pacjenta. Cały zestaw ma za zadanie zidentyfikować ewentualny upadek
monitorowanej osoby. W momencie, kiedy dojdzie do sytuacji niebezpiecznej dla osoby
monitorowanej, telefon komórkowy wyśle wiadomość informującą o zdarzeniu osobę z listy
kontaktowej.
Aplikacja na telefon komórkowy musi spełniać kilka kryteriów. Pierwszym z nich jest
możliwość instalacji na jak największej ilości dostępnych na rynku aparatów, aby gotowe
rozwiązanie było dostępne dla jak największej grupy ludzi. Wiążą się z tym niskie
wymagania sprzętowe, oraz wybór odpowiedniego środowiska programistycznego,
umożliwiającego napisanie oraz uruchomienie aplikacji na aparatach telefonicznych licznych,
dostępnych na rynku producentów. Ponadto niezmiernie istotna jest prostota interfejsu, aby
mogły z niej korzystać osoby nieznające się na zaawansowanych programach.
7
Moduł współpracy detektora upadku z telefonem komórkowym
3. Założenia funkcjonalne
Projekt pracy zakłada stworzenie systemu do monitoringu pacjenta. Osoba monitorowana
będzie miała stale przy sobie urządzenie, które sprawdzać będzie, czy nastąpił upadek badanej
osoby. W sytuacji, gdy zajdzie takie zdarzenie, dochodzi do wygenerowania sygnału
alarmowego. Wówczas nastąpić musi przesłanie sygnału do terminala, który będzie w stanie
automatycznie przesłać daną informację do odpowiednich osób, zespołu monitorującego
pacjenta albo do najbliższej rodziny, w celu powiadomienia ich o zajściu zdarzenia.
Urządzeniem, które najlepiej nadaje się na pełnienie funkcji terminala, jest telefon
komórkowy. W ostatnich latach to urządzenie stało się na tyle powszechnie, że korzysta z
niego niemal każdy. W kwestii połączenia telefonu komórkowego z monitorem można
wybrać pomiędzy połączeniem bezprzewodowym, a połączeniem przewodowym. Ze względu
na wygodę pacjenta zdecydowałem się na połączenie bezprzewodowe. Z pośród dostępnych
na rynku, i możliwych do zaimplementowania na telefon komórkowy, istnieje połączenie z
wykorzystaniem modułu Bluetooth oraz IrDA, lub połączenie sieciowe WLAN.
W kwestii samego oprogramowania telefonu, należy wybrać taki model, który umożliwi
uruchomienie aplikacji na możliwie jak największej ilości aparatów dostępnych na rynku.
Ponadto niezmiernie istotną kwestią jest umożliwienie współpracy danej aplikacji z wieloma
detektorami, nie tylko upadku. Można to uzyskać poprzez zoptymalizowanie kodu, który
pozwoli na określenie, z którymi urządzeniami poprzez Bluetootha nasz telefon ma się
połączyć, oraz określanie w aplikacji sposobu interpretacji dochodzących sygnałów. Istotny
jest tutaj wybór języka programowania, który w przyszłości umożliwi łatwy rozwój aplikacji i
dodawanie kolejnych funkcjonalności rozbudowujących moduł wysyłania informacji
alarmowych.
Ostatnim kryterium jest prostota działania. Aplikacja powinna być prosta w obsłudze,
przejrzysta, czytelna, zawierać jedynie te opcje, które są niezbędne do poprawnego działania.
8
Piotr Mazur
4. Przegląd dostępnych na rynku rozwiązań monitoringu pacjenta
Telemedycyna jest bardzo silnie rozwijającą się w ostatnich latach dziedziną medycyny.
Istnieje na rynku sporo nowoczesnych systemów monitoringu pacjenta, zarówno offline
(wykonujemy pomiar, a następnie przesyłamy wyniki do centrum diagnostycznego ) jak i
online (jesteśmy stale podłączeni do urządzenia badającego, a nasze wyniki są na bieżąco
wysyłane do centrum diagnostycznego). Krajami najsilniej rozwijającym tę gałąź wiedzy są
Stany Zjednoczone oraz Niemcy.
Do najnowocześniejszych rozwiązań z tej dziedziny należy Vitaphone, który powstał w
niemieckiej firmie Vitaphone GmbH. Projekt skierowany jest do osób powyżej 60 roku życia.
Rysunek 1 Vitaphone Tele-Care-Monitor 3370
Zintegrowany system Vitaphone Tele-Care-Monitor 3370 na bieżąco kontroluje takie
krytyczne dla naszego zdrowia miary jak: EKG, ciśnienie, poziom cukru, saturację krwi.
Zestaw na bieżąco jest podłączony poprzez Bluetooth lub IrDA z telefonem komórkowym, co
w sytuacji zagrożenia stanu zdrowia umożliwia bezpośrednie przesłanie na ten temat
informacji do centrum monitorującego.
W naszym kraju istnieje również sporo gotowych rozwiązań dla pacjentów. Niestety nie
są dotychczas dostępne systemy typu online. Wśród rozwiązań offline zdecydowanie
najbardziej rozpowszechnione są tzw. kardiofony. Program KARDIOFON został
uruchomiony w 1996 roku. Pacjent biorący w nim udział otrzymuje z Centrum Nadzoru
Kardiologicznego rejestrator sygnału EKG. W każdej niepewnej sytuacji może z niego
9
Moduł współpracy detektora upadku z telefonem komórkowym
skorzystać, przesyłając sygnał z rejestratora do CNK, zarówno poprzez telefon analogowy
bądź cyfrowy. W centrum znajduje się centralna baza danych pacjentów, w związku z
powyższym można od razu po otrzymaniu badań prześledzić dotychczasową historię choroby.
Rysunek 2 Kardiofon
Równolegle do tego systemu działa również system TeleEKG firmy PRO-PLUS. Idea jest
dokładne taka sama, co systemu Kardiofon. Ten system również umożliwia przesyłanie
danych poprzez telefon analogowy bądź cyfrowy, dodatkowo możliwe jest przesyłanie
badania z wykorzystaniem portu podczerwieni w telefonie komórkowym.
Rysunek 3 TeleEKG firmy PRO-PLUS
Istnieją na rynku systemy podobne w funkcjonalności do projektowanego przeze mnie,
niemniej jednak nie zdążyły jeszcze na stałe wpisać się do praktyki lekarskiej w naszym
kraju. Wraz z biegiem czasu muszą zyskać na popularności, gdyż systemu zdalnego
monitoringu zdrowia pacjenta są tańsze, dużo bardziej efektywne i wygodne z punktu
widzenia zarówno osoby monitorowanej jak i monitorującej. Przyszłość należy do
telemedycyny.
10
Piotr Mazur
5. Łączność bezprzewodowa
5.1 Dostępne rozwiązania
Istnieje na rynku kilka godnych uwagi sposobów przesyłania sygnałów bezprzewodowo
pomiędzy telefonem komórkowym a innym urządzeniem. Podczas rozwiązywania tej kwestii
szczególnie trzy typy połączeń wymagały dokładniejszego przyjrzenia się. Należą do nich
połączenia poprzez: IrDA, Bluetooth oraz WLAN.
IrDA (Infrared Data Asociation) – standard transmisji danych z wykorzystaniem
podczerwieni. Implementowany jest w większości dostępnych na rynku telefonów
komórkowych oraz komputerów. Ponadto istnieją oddzielne adaptery, które można instalować
przy innych urządzeniach, które mają również brać udział w wymianie danych.
Połączenie pomiędzy dwoma przyrządami jest typu punkt-punkt. Szybkość transmisji
zależy oczywiście od obu adapterów IrDA biorących udział w przepływie danych, niemniej
jednak minimalna szybkość to 9,6 kb/s, co w zupełności wystarczyłoby do monitorowania
pacjenta w projekcie modułu współpracy detektora upadku z telefonem komórkowym.
Istotnym ograniczeniem podczerwieni jest 1 metr zasięgu adapterów, oraz 30° kąt widzenia
pomiędzy dwoma urządzeniami.
Dane przesyłane są w kilku warstwach Jedną z dostępnych opcji przy tej transmisji
danych jest emulacja portu szeregowego lub równoległego (IrCOMM).
WLAN (Wireless Local Area Network) – kolejnym ciekawym i skutecznym
rozwiązaniem byłoby połączenie typu adhoc (bezpośrednie) telefonu komórkowego z
detektorem monitorującym z wbudowaną bezprzewodową kartą sieciową zgodną ze
standardem IEEE802.11. W zależności od standardu, który spełniają obie karty, szybkość
transmisji wacha się w granicach 1MB/s do nawet 540 MB/s. Rozwiązanie tego typu wymaga
11
Moduł współpracy detektora upadku z telefonem komórkowym
jednak dość drogiego sprzętu, zarówno telefonu komórkowego z kartą sieciową WLAN, jak i
wbudowanej karty sieciowej z możliwością konfigurowania ustawień połączeń po stronie
urządzenia monitorującego.
Bluetooth – standard opisujący bezprzewodową komunikację
pomiędzy dowolną ilością urządzeń krótkiego zasięgu. W zależności od wersji standardu
zasięg wynosi od kilku do kilkudziesięciu metrów. Ponieważ transmisja danych odbywa się
poprzez fale radiowe o częstotliwości 2,4GHz, nie stanowi problemu fakt, że np. dwa
urządzenia znajdują się w oddzielnych pomieszczeniach. Szybkość transmisji danych również
zależna jest od standardu modułu Bluetooth wbudowanego w urządzenie, minimalna wartość
to 721 kb/s, maksymalnie do 3Mb/s. Architektura systemu zakłada łączenie się
poszczególnych urządzeń z wykorzystaniem łącza szeregowego
Spośród trzech najbardziej pasujących do spełnienia założeń projektu form komunikacji
bezprzewodowej najbardziej odpowiadające założeniom o wygodzie pacjenta są komunikacja
z wykorzystaniem technologii Bluetooth oraz WLAN. Co do szybkości transmisji danych
WLAN zdecydowanie przewyższa IrDA oraz Bluetooth. Pozostaje jeszcze kwestia
dostępności. Po analizie dostępnych na rynku telefonów komórkowych nie tylko najnowszej
generacji okazało się, iż zdecydowanie najwięcej aparatów wyposażonych jest w Bluetooth.
W związku z powyższym zdecydowałem, że telefon komórkowy będzie łączył się z
urządzeniem monitorującym poprzez tę technologię.
5.2 Transmisja przez Bluetooth
Bezprzewodowa transmisja danych z wykorzystaniem protokołu Bluetooth odbywa się
poprzez fale radiowe w paśmie ISM ( Industrial, Scientific, Medical ) o częstotliwości w
granicach 2,4 GHz. W celu wyeliminowania problemów z połączeniami wynikającymi z
faktu, iż z częstotliwości ISM korzysta wiele innych urządzeń, protokół Bluetooth dzieli
przedział częstotliwości 2.402 GHz – 2.480 GHz na 79 kanałów, każdy o dzerokości 1 MHz.
Podczas transmisji protokół zmienia kanały z częstotliwością 1600 razy na sekundę, co
12
Piotr Mazur
praktycznie wyklucza zakłócenia związane z nadawaniem sygnałów przez inne urządzenia na
częstotliwości 2.45 GHz.
W zależności od mocy adaptera Bluetooth urządzenia są w stanie komunikować się na
odległości od 1 metra do nawet 100 metrów. Ponieważ mamy do czynienia z radiową
transmisją danych, nie jest konieczne, aby oba urządzenia znajdywały się w tym samym
pomieszczeniu, ważne, żeby pozostawały w swoim zasięgu. Odległość pomiędzy
urządzeniami zależy od mocy nadajnika, a ta zależy wprost od klasy mocy. W standardzie
Bluetooth występują 3 klasy mocy:
Klasa mocy Zasięg [m]
Klasa 1 100
Klasa 2 10
Klasa 3 1
Szybkość transmisji zależy od zaimplementowanej w urządzenie wersji Bluetooth.
Przedstawia się ona w następujący sposób:
Wersja Bluetooth Transmisja
1.0 orz 1.0B 721 KB/s
1.1 721 KB/s
1.2 1MB/s
2.0 2.1 MB/s
2.1 2.1 MB/s
3.0 3.0 MB/s
13
Moduł współpracy detektora upadku z telefonem komórkowym
Dwa urządzenia z zaimplementowanymi różnymi wersjami mogą się ze sobą
komunikować, niemniej jednak transmisja danych pomiędzy nimi nie może być szybsza niż
ta, która wynika z wersji Bluetooth zaimplementowanej na urządzeniu ze starszą wersją.
Aby dwa urządzenia mogły się porozumiewać, muszą spełniać te same wymagania
odnośnie profili. Każdy adapter Bluetooth ma wbudowaną obsługę poszczególnych
protokołów:
5.3 Architektura systemu
W kwestii połączeń pomiędzy poszczególnymi urządzeniami, protokół Bluetooth dzieli je
na dwa główne typy: master oraz slave. Każde urządzenie posiada swój własny, 48-bitowy
adres zwany BD_ADDR. Urządzenie typu master jest głównym urządzeniem decydującym o
kolejności obsługi poszczególnych urządzeń typu slave znajdujących się we wspólnej sieci,
zwanej w tym wypadku pikosiecią, i podłączonych właśnie do tego urządzenia typu master.
Jedno urządzenie typu master pozwala na podłączenie się do niego 7 urządzeń typu slave.
Ponadto w pikosieci mogą się również znajdować 255 urządzenia w stanie synchronizacji z
urządzeniem master. W sytuacji, gdy któreś z 7 urządzeń slave przestaje być członkiem
pikosieci, momentalnie jego miejsce może zająć jedno z urządzeń w stanie synchronizacji.
Istotna jest kwestia, iż urządzenie typu slave może się komunikować z urządzeniem typu
master, urządzenie typu master z urządzeniem typu slave. Zabroniona jest komunikacja
pomiędzy dwoma urządzeniami typu slave. Poniżej przedstawiam schemat architektury sieci
Bluetooth.
Rysunek 4 Architektura sieci Bluetooth z pojedynczym połaczeniem master-slave, potrójnym, oraz scatternet
14
Piotr Mazur
Jak widać możliwe jest połączenie dwóch pikosieci poprzez urządzenie slave lub też
master. Stanowi ono wówczas most, zwany też bridge, a tak rozbudowana pikosieć nosi
nazwę scatternet.
5.4 Warstwy protokołu
Standard Bluetooth zawiera inną, nowatorską strukturę warstw, którą widać na poniższym
schemacie.
Najniższa warstwa, fizyczna warstwa radiowa (Radio Layer), jest odpowiedzialna za
odbieranie oraz wysyłanie pakietów informacji. Kolejna warstwa, przepustowa (Baseband
Layer) określa, w jaki sposób urządzenie master kontroluje przedziały czasowe i w jaki
15
Moduł współpracy detektora upadku z telefonem komórkowym
sposób te przedziały są grupowane w ramki. Warstwa zarządzania połaczeniam (Link
Manager Layer) odpowiada za stworzenie, modyfikowanie oraz uwalnianie logicznego
połączenia pomiędzy urządzeniami, oraz aktualizację parametrów danego połączenia.
Wspomniane pierwsze trzy warstwy taktuje się całościowo jako tzw. kontroler Bluetooth.
Stanowi całościowe połączenie fizyczne pomiędzy warstwą odpowiadającą za łączność oraz
wymianę danych z resztą systemu Bluetooth.
Kolejna warstwa, L2CAP (Logical Link Control and Adaptation Protocol) jest warstą
wyższego poziomu. Odpowiada za wysyłanie oraz odbieranie pakietów, czyli danych
wyższego poziomu. Pakiet nie może przekroczyć wielkości 64 kb.
5.5 Struktura pakietu
Komunikacja poprzez Bluetooth polega na wysyłaniu pakietów z danymi pomiędzy
poszczególnymi urządzeniami biorącymi udział w transmisji. Kształt ramki jest ściśle zależny
od wersji Bluetooth’a. Standardowa ramka w wersji 1.1, która jest rozpoznawalna przez
wszystkie kolejne wersje protokołu, przedstawia się następująco:
Wpierw występuje kod dostępu, długi na 72 bity. Zawarte są tutaj informacje, które
identyfikują urządzenie typu master, aby slave wiedział, z którym urządzeniem się
komunikuje. Kod dostępu pozwala na rozróżnienie mastera aż do dwóch połączeń typu bridge
poprzez scatternet.
Nagłówek składa się z kolejnych 54 bitów, 3 razy powtórzona jest informacja zawarta w
18 bitach. Znajdują się tutaj informacje dotyczące urządzenia adresującego (3 bity), typ
transmisji (kolejne 4 bity), po jednym bicie flow (ustawianym przez slave, gdy nie może już
przyjąć więcej danych) acknowledgement (potwierdzenie transmisji) oraz sequence
(ustawiany w celu wykrycia retransmisji). Ostatnie 8 bitów to checksum (suma kontrolna).
Urządzenie odbierające ramkę sprawdza 3 razy zawarte informacje na 18 bitach, jeśli się
16
Piotr Mazur
zgadzają, następuje akceptacja ramki, jeśli nie, w zależności od sumy kontrolnej wystawiane
jest 1 lub 0 i prośba o retransmisję.
Payload przechowuje dane, które zostały wysłane. Może pomieścić do 5 slotów o łącznej
długości 2744 bitów, przy czym jeden slot to minimum 240 bitów pola danych.
5.6 Podsumowanie
Po dokładniejszej analizie technologii Bluetooth zauważam, iż spełnia wymagania
stawiane kwestii rozwiązania komunikacji bezprzewodowej w projekcie pracy inżynierskiej.
Przejrzystość technologii, prosta architektura, łatwość implementacji oraz bezproblemowa
analiza przesyłanych informacji pozwalają na proste wdrożenie tej technologii w projekcie.
Szczególnie na plus tej technologii można zaliczyć transfer odbywający się drogą radiową na
określony w klasie produktu dystans. Ponadto przy założeniu, że terminal będzie spełniać
funkcję master, technologia Bluetooth daje możliwość rozwoju zaimplementowanej aplikacji
do obsługi aż do 7 różnych urządzeń monitorujących pacjenta. W kwestii samego transferu,
który jest niższy niż oferowany przez pozostałe rozwiązania dostępne na rynku, nie stanowi to
większej bariery, gdyż z założenia komunikacja pomiędzy terminalem a monitorem
sprowadza się do wysłania krótkiego komunikatu, jednego pakietu danych, co przy transferze
w pesymistycznym wariancie 721 KB/s, a wielkości najmniejszego pakietu rzędu 64 KB w
zupełności wystarczy.
17
Moduł współpracy detektora upadku z telefonem komórkowym
6. Telefon komórkowy jako nośnik oprogramowania
6.1 Charakterystyka
Od kilku lat na rynku telefonów komórkowych panuje niesamowicie duży wybór
producentów. Do największych z nich należą: Nokia, Siemens, Sony Ericsson, Samsung,
Motorola, Sagem, Apple. To tylko niektórzy z niezliczonej ilości producentów. Ponadto
każdy z nich posiada wiele różnorakich modeli. Najlepszym tego przykładem może być firma
Nokia, która w swojej bieżącej ofercie telefonów pracujących w standardzie GSM (Global
System for Mobile Communications) posiada prawie 100 różnych modeli, a na przestrzeni
ostatnich 10 lat wydała ich na rynek w sumie grubo ponad 200 (dane z www.nokia.com).
Wprawdzie żaden inny producent nie posiada w swojej ofercie aż tak znaczącej liczby
telefonów, niemniej jednak ogólna liczba dostępnych obecnie telefonów komórkowych
szacuje się na poziomie kilku tysięcy.
W zależności od okresu powstania telefonu zmieniają się jego parametry, do jakich
należą: procesor, pamięć wbudowana, pamięć zewnętrzna, rozdzielczość wyświetlacza,
wbudowane opcje dodatkowe. Wszystkie te elementy mają niezmiernie istotny wpływ na to,
czy stworzona aplikacja będzie działała na danym telefonie. Przyjrzyjmy się kilku
popularnym modelom telefonów z przestrzeni ostatnich 8 lat.
Model Nokia 3410 Nokia 6230i HP ipaq 614c Samsung L370 Iphone 3g
Pamięć wew. 0 MB 32 MB 256 MB 40 MB 8 GB / 16 GB
Pamięć zewn. nie dotyczy 512 MB 8 GB 512 MB nie dotyczy
Ilość kolorów 2 65536 65536 256000 256000
Rozdzielczość 96x65 208x208 320x240 176x220 480x320
Bluetooth nie tak tak tak tak
IrDA nie tak nie nie nie
Karta WLAN nie nie tak nie tak
18
Piotr Mazur
Jak widać 8-letnia Nokia 3410 w żaden sposób nie może się równać z tegorocznymi
produktami jak iphone 3g czy HP ipaq 614c. Telefony te różnią się niemal pod każdym
względem, za wyjątkiem elementarnej funkcji, jaką jest możliwość rozmawiania lub
wysyłania sms-ów. Ponadto każdy telefon ma klawiaturę oraz wyświetlacz. Na tej bazie
trzeba stworzyć program, który będzie umożliwiał jak najszerszej ilości telefonów
komórkowych łączenie się z monitorem stanu pacjenta.
6.2 Systemy operacyjne
Przyjrzeliśmy się kilku modelom telefonów z ostatnich kilku lat pod względem
technicznym. Nie jest to jedyny aspekt, z którym trzeba się liczyć tworząc aplikację na telefon
komórkowy. Równie istotny jest system operacyjny, na jakim działa dany model, a te różnią
się w zależności od producentów oraz generacji produktu. Przejdźmy do analizy, na jakim
systemie operacyjnym działają telefony komórkowe.
Do najbardziej popularnych systemów operacyjnych należą: Symbian, Microsoft
Windows Mobile, Android, Nucleus, REX, OSE.
19
Moduł współpracy detektora upadku z telefonem komórkowym
Symbian OS
Jest to system operacyjny stworzony przez konsorcjum takich producentów jak: Nokia,
Sony Ericsson, Motorola, Samsung i wielu innych. W założeniach jest to otwarty system
operacyjny na wielorakiego rodzaju telefony komórkowe, z ogromnymi możliwościami na
rozwój. Posiada szereg wbudowanych bibliotek, rozwiązań interfejsu użytkownika oraz
współpracuje ze wszystkimi producentami telefonów komórkowych wchodzących w skład
konsorcjum. Dzięki otwartej licencji każdy użytkownik, który czuje taką potrzebę, i posiada
niezbędną wiedze, może go ulepszyć do własnych potrzeb.
Obecnie ponad 80% nowych telefonów posiada zaimplementowany właśnie ten system
operacyjny. Aktualna wersja Symbian OS to 9.3, ale poprzez bardzo szybki rozwój systemu
cały czas pojawiają się kolejne uzupełnienia lub rozszerzenia. Pozwala na współpracę z
urządzeniami poprzez Bluetooth’a, co jest niezmiernie istotne z punktu widzenia projektu
pracy dyplomowej. W kwestii programistycznej umożliwia tworzenie aplikacji w dwóch
bardzo powszechnych językach programowania: C++ oraz Javie. Szczególnie ten pierwszy
jest z punktu widzenia Symbian OS bardzo istotny, gdyż cały system operacyjny jest napisany
na bazie C++.
W celu wsparcia programistów konsorcjum zapewnia zintegrowane środowiska
programistyczne Software Development Kit dla: Eclipse, Microsoft, Java, Android, iPhone i
inne. Programista może zatem wybrać środowisko z szeregu dostępnych na rynku, zgodne z
własnymi preferencjami.
20
Piotr Mazur
Microsoft Windows Mobile
Kolejnym, zdobywającym coraz większą część rynku, jest system operacyjny na telefony
komórkowe wyprodukowany przez firmę Microsoft. Posiada obecnie ok. 13% rynku, w tym
jest bardzo rozpowszechniony szczególnie na tzw. smartfonach, czyli telefonach łączących w
sobie funkcję telefonu komórkowego, przeglądarki internetowej czy skrzynki odbiorczej
poczty, a ostatnio nawet GPS-u. Pierwszym systemem operacyjnym z tej rodziny był
PocketPC wydany w 2000 roku, następne wersje przyjęły nazwę Widows Mobile
numerowane od 3.0 aż do 6.1, które jest ostatnią wersją wypuszczoną na rynek.
Ponieważ cała platforma jest niezmiernie zbliżona w swojej funkcjonalności do systemu
operacyjnego, posiada również rozbudowane opcje tworzenia na nie oprogramowania.
Producent Widnows Mobile pozwala na tworzenie aplikacji z wykorzystaniem takich
języków programowania jak: Visual C++, .NET Compact Framework oraz Java. Software
Development Kit dostarczony przez producenta załącza się jako nakładkę do Visual Studio
2005/2008 w przypadku Visual C++ czy .NET, lub do któregokolwiek z SDK
współpracujących z Javą.
Android
Nowy system operacyjny stworzony na telefony komórkowe, bazujący na jądrze Linuxa. Cały
projekt jest kierowany przez Google, natomiast podobnie jak Symbian OS, Android posiada
wolną licencję oraz otwarty kod, zatem każdy może wziąć udział w procesie rozwoju tego
systemu operacyjnego. Jego premiera miała miejsce wraz z wprowadzeniem na rynek 22
października 2008 modelu T-Mobile G1. Jako pierwszy system operacyjny posiada
21
Moduł współpracy detektora upadku z telefonem komórkowym
możliwość działania w trzech wymiarach. Niestety w związku ze świeżością całego projektu
nie istnieją jeszcze odpowiednie SDK poza dostarczonym przez firmę Google, niestety jest
przepełniona błędami i ciężko jest napisać działającą aplikację na ten system operacyjny.
System zawiera obsługę Java Virtual Machne, w związku z tym wszelkie programy napisane
w Javie mogą zostać uruchomione na telefonie korzystającym z tego systemu operacyjnego.
5.3 Wybór języka programowania
Spośród wszystkich dostępnych na rynku języków programowania tylko kilka umożliwia
tworzenie aplikacji na telefon komórkowy. Należą do nich: Java, C++, Visual C++. Każdy z
nich ma oddzielne, przygotowane przez producenta narzędzia, każdy ma określone
wymagania dotyczące telefonów komórkowych. Przyjrzyjmy się im dokładniej.
Java
Najbardziej dostępny język, który umożliwia odpalanie aplikacji na telefonach komórkowych,
gdyż Java Runtime Environment, niezbędny do uruchamiania aplikacji programów
napisanych w Javie, został zaimplementowany na ponad 2,1 miliarda aparatów. Tworzenie
aplikacji na telefony komórkowe wykorzystując język programowania Java firmy SUN
Microsystems niewiele różni się od tworzenia innych aplikacji w tym języku. W celu
stworzenia aplikacji należy zaopatrzyć się w takie narzędzie jak Integrated Development
22
Piotr Mazur
Environment (IDE). Z wielu dostępnych na rynku najbardziej popularne to Netbeans, Eclipse,
JBuilder. Ostatnio nawet firma Microsoft wydała odpowiednik swojego Visual Studio dla
języka programowana J#, który jest bardzo zbliżony w swojej składni do Javy.
Cechą charakterystyczną uruchamiania programów napisanych w Javie jest wykorzystane
Java Virtual Machine. Jest to zestaw oprogramowania, struktur danych, które wykorzystują
maszynę wirtualną. Dzięki niej można uruchomić aplikację niezależnie od środowiska, na
którym stawiamy program. W związku z powyższym programy można uruchamiać na
wspomnianych powyżej systemach operacyjnych: Symbian OS, Windows Mobile oraz
Android.
Aby napisać program w Javie, trzeba przystosować się do wersji tego języka, jaką jest
Java 2 MicroEdition. Jest to wersja języka programowania przystosowana specjalnie do
architektury telefonów komórkowych. Odpowiednio zdefiniowany zbiór bibliotek, z bardzo
ograniczoną funkcjonalnością ma za zadanie ograniczyć zużywanie zasobów pamięci
urządzenia, na którym będzie uruchamiane oprogramowanie wykorzystujące tę platformę
Javy. Tworzone aplikacje, nazywane MIDlet’ami, różnią się od standardowych programów
tym, że działają na bardzo niewielkich zasobach pamięci telefonu. Podczas procesu tworzenia
pakietu na telefon komórkowy można go dostosować do możliwości danego aparatu, poprzez
określenie wersji MIDP (Mobile Information Device Profile). W związku z powyższym
odpowiednio napisana aplikacja może zostać uruchomiona na praktycznie każdym aparacie.
Microsoft Visual C++
Język programowania, który umożliwia stworzenie aplikacji na system operacyjny Windows
Mobile. Do tworzenia aplikacji niezbędne jest wyposażenie się w IDE firmy Microsoft:
Microsoft Visual C++ Studio. Począwszy od wersji 2005 Express Edition są one udostępniane
za darmo, co wzmocniło pozycję tego języka programistycznego.
23
Moduł współpracy detektora upadku z telefonem komórkowym
Aplikacje tworzy się w dokładnie taki sam sposób, jak na zwykły komputer działający na
systemie operacyjnym Windows, np. Windows XP. Trzeba jednak pamiętać o możliwościach
sprzętowych telefonu. Z założenia Windows Mobile uruchamiany jest jedynie na
najnowszych telefonach komórkowych, tzw. smartfonach, które same w sobie są zbliżone w
możliwościach do komputerów sprzed kilku lat.
C++
Jest to najbardziej rozbudowany język programistyczny na świecie, dający sprawnemu
programiście niemal nieograniczone możliwości. Bazuje na nim system operacyjny Symbian
OS, i właśnie na tym systemie operacyjnym można uruchamiać aplikacje napisane w C++.
Najpopularniejszym narzędziem do tworzenia aplikacji na telefon komórkowy z
wykorzystaniem języka C++ jest wspierany przez firmę Nokia Carbide C++. Wersja Express
Edition jest udostępniana do celów niekomercyjnych za darmo.
Aplikacje stworzone z wykorzystaniem Carbide C++ mogą być bezproblemowo uruchamiane
na wszystkich telefonach działających na Symbian OS S60 i wyższe.
Podsumowując dostępne na rynku języki programowania telefonów komórkowych,
szczególnie dwa wydają się szczególnie godne uwagi: C++ oraz Java (szczególnie Java 2
MicroEdition). Oba są niezmiernie popularne, i umożliwiają uruchamianie aplikacji na bardzo
dużej liczbie dostępnych na rynku modeli. Niemniej jednak zdecydowanie bardziej
rozpowszechniona jest Java, z 2,1 miliardów nośników Java Runtime Environment. Istotnym
plusem Javy jest również uruchamianie aplikacji z wykorzystaniem maszyny wirtualnej, która
sprawia, iż aplikacje można uruchamiać na niemal każdej maszynie nie patrząc na jej
możliwości sprzętowe.
24
Piotr Mazur
5.4 Struktura Java 2 MicroEdition
Przyjrzyjmy się dokładniej strukturze J2ME, oraz kwestii tworzenia aplikacji w tym
środowisku programistycznym. Jak już wspomniałem, jest to wersja języka Java
opracowanego przez Sun Microsystems specjalnie na urządzenia mobilne, jak telefon
komórkowy. Rysunek poniżej przedstawia, jak się J2ME ma do standardowej wersji Javy,
oraz do wersji enterprise:
Z punktu widzenia tworzenia aplikacji na telefony komórkowej należy rozróżnić dwa
elementy składowe, które determinują kwestie uruchomienia danej aplikacji na telefonie
komórkowym
CLDC – konfiguracja urządzeń komunikujących się z ograniczeniami (Connected Limited
Device Configuration). CLDC jest konfiguracją opracowaną dla urządzeń o bardzo
ograniczonej mocy procesora i dostępnej ilości pamięci. Są to przede wszystkim telefony
komórkowe i słabe PDA. Obecnie rozróżniamy dwa poziomy CLDC: 1.0 oraz 1.1
MIDP – Mobilna Informacja o Profilu Urządzenia (Mobile Information Device Profile) – jest
to uzupełnienie CLDC o odpowiednie klasy języka J2ME, specjalnie dla niewielkich
urządzeń mobilnych. Dotychczas opracowany dwa poziomy MIDP: 1.0 oraz 2.0.
Oba profile określają nam wymagania stawiane środowisku sprzętowemu, na którym
uruchamiane są aplikacje napisane w J2ME. Aby aplikacja poprawnie chodziła, Java Runtime
Environment zaimplementowana na telefonie komórkowym musi posiadać określony poziom
25
Moduł współpracy detektora upadku z telefonem komórkowym
zarówno CLDC jak i MIDP. Przy tworzeniu aplikacji deweloper sam określa poziom obu
składowych opisujących aplikację.
Programy pisane zgodnie z powyższymi profilami noszą nazwę MIDletów (Mobile
Information Device). Przyjrzyjmy się podstawowym cechom MIDletów. Najważniejszym
aspektem z punktu widzenia programisty jest fakt, iż programy napisane w profilu MIDP 1.0
oraz 2.0 muszą dziedziczyć bo klasie javax.microedition.midlet.*; . Związane jest to z
koncepcja działania aplikacji: menedżer aplikacji potrzebuje narzędzia, które przekazywać
będzie dane o stanie MIDletu, MIDlet z kolei potrzebuje narzędzie do uzyskiwania informacji
o deskryptorze aplikacji.
Gotowa aplikacja dystrybuowana jest zawsze z wykorzystaniem dwóch plików. Pierwszy z
nich to plik z rozszerzeniem .jar ( Java Archive ) – zawiera archiwum, które wcześniej
musiało przejść proces preweryfikacji. Proces ten wykonuje się automatycznie podczas
tworzenia pakietu z wykorzystaniem jednego z wiodących na rynku Integrated Development
Environment, jak np. Eclipse z Java Wireless Toolkit. Drugi plik posiada rozszerzenie .jad
( Java Archive Descriptor ) – opisuje zestaw MIDletów wchodzących w skład aplikacji
(minimum jeden MIDlet, ale aplikacja może działać bazując na większej ich ilości).
MIDlet może przebywać w trzech określonych stanach:
-Aktywny (ang. Active): MIDlet wchodzi w ten stan w momencie uruchomienia, musi
korzystać z pewnych zasobów
- Pauza (ang. Paused): W tym stanie MIDlet uwalnia używane zasoby urządzenia, i
przechodzi w stan uśpienia
- Zniszczony (ang. Destroy): Jest to stan, w którym MIDlet kończy fazę swojej
aktywności. Zamykający się MIDlet musi uwolnić wszelkie wykorzystywane zasoby, a
zmiany w samej aplikacji może zachować z wykorzystaniem menedżera aplikacji.
Poniższy rysunek pokazuje, w jaki sposób MIDlet może przechodzić pomiędzy
poszczególnymi stanami – kierunki strzałek pokazują jedyne możliwe zmiany stanu aplikacji.
26
Piotr Mazur
Program przechodzi pomiędzy poszczególnymi stanami dzięki odpowiednio
zaimplementowanym składowym metodom, obowiązkowo występującym w aplikacjach
napisanych z wykorzystaniem profilu MIDP:
- startApp() – ta metoda sygnalizuje, iż MIDlet wszedł w stan aktywny. Znajdują się
tutaj procedury inicjalizacyjne, które ustawiają i konfigurują środowisko wyświetlacza
urządzenia dla potrzeb MIDlet’a
- destroyApp() – metoda odpowiedzialna za zasygnalizowanie, iż MIDlet zakończył
działanie i przeszedł w stan zniszczenia
- pauseApp() – metoda, która sygnalizuje, iż MIDlet wstrzymał działanie, i przeszedł
w stan pauzy.
Istnieją ponadto jeszcze funkcje, które mogą, ale nie musza wchodzić w skład
MIDlet’a:
27
Moduł współpracy detektora upadku z telefonem komórkowym
- notifyDestroyed() – metoda informująca oprogramowanie zarządzające urządzeniem,
na którym jest uruchomiony MIDlet, o całkowitym wyczyszczeniu zasobów
wykorzystywanych przez aplikację
- notifyPaused() – ponowna funkcjonalność co metody powyżej, tyle, że informuje o
przejściu w stan Pauzy
- resumeRequest() – metoda, która wysyła prośbę do oprogramowania zarządzającego
urzadzeniem o ponowne uruchomienie MIDlet’a, czyli przejście w stan Aktywny.
- getAppProperty() – odbiera MIDletowi zasoby
Zarządzanie wydarzeniami występującymi w MIDlecie to kolejne zagadnienie dotyczące
tworzenia aplikacji z wykorzystaniem języka J2ME. Otóż podczas działania MIDleta na
telefonie komórkowym można obsługiwać zdarzenia, do których zaliczyć możemy:
- Naciśnięcie klawisza z klawiatury w telefonie
- Dotknięcie ekranu dotykowego
- Zmiana w bazie danych telefonu, współdzielonej przez MIDlet
Mechanizm obsługi aplikacji bazuje na modelu słuchacza (ang. Listener). Rozróżniamy trzy
typy interfejsu: CommandListener, ItemStateListener oraz RecordListener.
CommandListener – odpowiada za przekazywanie MIDletu o wszelkich akcjach, które miały
miejsce podczas jego działania, jak wybór komendy z wykorzystaniem klawiatury telefonu.
Obowiązkowo zawierać musi metodę CommandListener(Command c, Displayable s), która
musi być rozszerzana przez obiekt słuchacza.
ItemStateListener – odpowiada za przekazywanie aplikacji informacji o wszelkich zmianach
dotyczących jej wewnętrznego stanu danych, jak i informacji wyświetlanych przez aplikację,
jak np. wyświetlane informacje tekstowe. Implementuje się ten typ interfejsu poprzez
wszelkiego rodzaju pola cyfrowe, tekstowe, wskaźniki czy pola daty.
RecordListener – odpowiada za zmiany w rekordach powiązanych z aplikacją podczas jej
działania. Implementuje się poprzez dodanie takich metod, jak: RecordsAdded(),
28
Piotr Mazur
RecordsDeleted() oraz RecordsChanged() – odpowiednio odpowiedzialne za dodanie rekordu,
jego skasowanie lub zmianę.
Przejdźmy do analizy, w jaki sposób porozumieć trzy typy interfejsu słuchacza z obiektami
naszej aplikacji. Jest to działanie obowiązkowe, aby MIDlet mógł działać. Klasa MIDlet
umożliwia implementację następujących metod, które należy powiązać ze słuchaczem:
setCommandListener() - ustawia nowego słuchacza dla każdego kolejnego polecenia w
trybie Wyświetlania (Displayable), zastępując innego, wcześniej włączonego słuchacza.
setItemStateListener() – ta metoda ustawia nowego słuchacza obiektów, zastępując
poprzedniego.
addRecordStateListener() – dodaje nowego słuchacza rekordów.
Obsługa wyjątków zamyka analizę pisania aplikacji z wykorzystaniem J2ME. Wyjątek jest
takim zdarzeniem, mającym miejsce podczas pracy aplikacji, który zaburza normalny
przepływ instrukcji. MIDlety zachowują standardowy dla języka JAVA sposób obsługi takich
sytuacji. Jeśli w metodzie pojawi się wyjątek, tworzy się obiekt błędu, i wstrzymuje ten błąd
do końca działania systemu. Dany obiekt posiada informacje o wyjątku, w tym jego typ oraz
stan działania aplikacji, w którym nastąpiło pojawienie się wyjątku. Środowisko działania
programu automatycznie stara się znaleźć odpowiednie rozwiązania implementacyjne, które
rozwiążą problem. W terminologii Java takie postępowanie, związane z powstawaniem
obiektu błędu oraz jego rozwiązaniu systemowemu nosi nazwę rzucaniem wyjątkiem.
Podsumowując, Java 2 MicroEdition jest językiem pisania programów bardzo zbliżonym do
swojego pierwowzoru, jakim jest Java. Składnia, obiektowość, styl pisania, nomenklatura,
maszyna wirtualna, na której uruchamiane są aplikacje, to wszystko sprawia, że osoba znająca
się na Java Standard Edition lub Enterprise Edition bez problemów może pisać złożone
programy z wykorzystaniem J2ME. Poprzez dopasowanie swojego profilu do możliwości
działania na mniejszych urządzeniach elektronicznych, jakim jest telefon komórkowy, różni
się trochę w możliwościach, jakie daje programiście, niemniej jednak wciąż daje ogromne
możliwości pisania rozbudowanych, kompletnych i profesjonalnych aplikacji. Biorąc pod
29
Moduł współpracy detektora upadku z telefonem komórkowym
uwagę popularność języka, mnogość informacji, forów dyskusyjnych oraz możliwość
uruchamiania na ogromnej liczbie urządzeń Java 2 Micro Edition jest najlepszym językiem,
jaki można było wybrać w celu stworzenia aplikacji związanej z powyższą pracą dyplomową.
7. Projekt modułu oprogramowania telefonu komórkowego
7.1 Detektor upadku
Urządzenie, które ma za zadanie rozpoznać upadek pacjenta, to detektor upadku
stworzony w ramach pracy dyplomowej inżynierskiej przez Jarosława Leksińskiego w roku
akademickim 2006/2007.
Osoba poddana kontroli powinna powyższe urządzenie stale mieć przy sobie, najlepiej
zamocowane na pasku od spodni lub w inny sposób na wysokości pasa. Urządzenie działa na
baterii 9V typu 6LR61, dając dość długi czas działania, w granicach ___ godzin.
Za detekcję upadku odpowiedzialny jest wbudowany hybrydowy, scalony czujnik
przyśpieszenia, inaczej akcelerometr, firmy analog Devices, model ADXL202. Jest on
połączony z mikrokontrolerem ATmega128. W momencie gwałtownego poruszenia całego
detektora tworzy się impuls, który można przesłać do urządzeń zewnętrznych.
Bezprzewodową komunikację z otoczeniem zapewnia moduł Bluetooth Ezurio blu2i z
30
Piotr Mazur
prędkością transmisji danych 250kb/s, z bardzo dużym zasięgiem, dochodzącym do 300
metrów, co daje osobie monitorowanej dużą swobodę poruszana się.
Wysyłany sygnał w momencie detekcji upadku to ramka _____ . Aplikacja działająca na
telefonie komórkowym, po uprzednim połączeniu się poprzez Bluetootha z detektorem, musi
wyłapać oraz odpowiednio zinterpretować wspomniany pakiet.
7.2 Założenia projektowe
Tworzona aplikacja musi spełniać kilka ważnych kryteriów. Pierwszym z nich jest
możliwość komunikowania się przez Bluetooth’a z urządzeniami zewnętrznymi. Ponieważ
telefon komórkowy, na którym będzie uruchamiana, podłącza się do detektora upadku ( lub
innego urządzenia podobnego typu ), musi umożliwiać połączenie urządzenia typu slave z
urządzeniem typu master (czyli wspomnianego detektora). Kolejnym bardzo istotnym
wymogiem jest odpowiednia obróbka przychodzącego sygnału alarmowego. Podczas
połączenia przez Bluetooth’a słuchacz MIDlet’u musi na bieżąco analizować przychodzące
ramki. W sytuacji, gdy uzyska sygnał o wypadku, następuje automatyczna generacja smsa
pod wskazany numer. W aplikacji niezbędny jest zatem interfejs użytkownika, który
umożliwia wskazanie numeru telefonu, na który trzeba wysłać wiadomość alarmową, oraz
umożliwiający wpisywanie oraz edycję wiadomości alarmowej. Interfejs jest również
odpowiedzialny za możliwość podłączenia lub odłączenia się modułu Bluetooth od detektora.
Obsługa programu musi być czytelna i prosta.
7.3 Ograniczenia
Jednym z ograniczeń jest rozmiar aplikacji. W Rozdziale 6.1 przedstawiłem
charakterystykę kilku telefonów komórkowych z przestrzeni ostatnich lat. Niektóre telefony
mają niewielką ilość pamięci, w związku z tym optymalna aplikacja powinna zajmować
minimalną ilość miejsca. Kolejnym ograniczeniem jest zgodność z profilami CLDC oraz
MIDP. Nowsze profile zapewniają większą funkcjonalność, ale wiąże się to z zawężeniem
potencjalnych odbiorców programu. Optymalna aplikacja nie może zawierać elementów
graficznych wymagających użycia większej ilości kolorów czy wyświetlacza z dużą
rozdzielczością, gdyż nawet niektóre modele telefonów wydawanych dzisiaj mają
ograniczoną paletę barw czy też rozdzielczość.
31
Moduł współpracy detektora upadku z telefonem komórkowym
7.4. Algorytm
Poniższy schemat przedstawia algorytm działania programu:
32
Piotr Mazur
7.5 Środowisko programistyczne
W celu sprawnego, wygodnego za zarazem skutecznego programu stworzyłem sobie
Integrated Development Environment, czyli zintegrowane środowisko programistyczne.
Wspominałem już o IDE podczas rozważań dotyczących języka programowania Java 2
MicroEdition, gdzie mowa była między innymi o dostępnych zintegrowanych środowiskach
programistycznych takich, jak Eclipse, Netbeans, JBuilder czy rozbudowany produkt firmy
Microsoft noszący nazwę Visual Studio. Po dokładnym zweryfikowaniu dostępnych
produktów zdecydowałem się na IDE Eclipse z wtyczką umożliwiającą na tworzenie
programów w języku Java.
Powyższy produkt jest o tyle interesujący, gdyż w momencie rozpoczęcia prac nad projektem
dyplomowym umożliwiał współpracę z Java Wireless Toolkit. Zestaw narzędzi firmy Sun jest
niezbędny, aby stworzony program został skompilowany zgodnie z profilami CLDC oraz
MIDP. Środowisko posiada emulator telefonu komórkowego, umożliwiającego sprawdzenie,
czy dana aplikacja rzeczywiście będzie na telefonie komórkowym działać. Ponadto istnieje
wbudowany optymalizator działania aplikacji, szereg dokumentacji oraz przykłady gotowych
projektów działających na telefonach komórkowych. Bez tego narzędzia nie można
wytworzyć końcowych pakietów aplikacji .jar oraz .jad, które zgrywa się na telefon
komórkowy. Wykorzystując większość dostępnych na rynku środowisk programistycznych
zmuszony byłbym do korzystania z dwóch rozbudowanych programów. Natomiast projekt
33
Moduł współpracy detektora upadku z telefonem komórkowym
Eclipse jako pierwszy zdecydował się na wydanie pakietu Java 2 MicroEdition, który
udostępnia całościową funkcjonalność Sun Java Wireless Toolkit, w tym: emulacja
dowolnego telefonu komórkowego, kompilacja, wytworzenie pakietów .jar i .jad, określenie
poziomu profili CLDC oraz MIDP. W kwestii samego wyboru emulatora telefonu
komórkowego jesteśmy ograniczeni jedynie przez dostępność emulatorów od strony
producentów. Firma Nokia udostępniła w Internecie emulatory wszystkich swoich modeli, a
ponieważ jest zarazem najpopularniejszą firmą na rynku postanowiłem korzystać z emulatora
telefonu Nokia 40SDK.
34
Piotr Mazur
8. Realizacja
8.1 Przegląd pakietów
Projekt stworzony w języku J2ME nosi nazwę Moduł współpracy. Zawarte w nim są trzy
zestawy pakietów: fallmonitor.sms, fallmonitor.memmory, oraz główny fallmonitor. Każdy z
pakietów odpowiedzialny jest za obsługę innych funkcjonalności działania aplikacji.
Główny pakiet zawiera
Pakiet fallmonitor.sms zawiera klasę sms zawartą w pliku sms.java oraz interfejs miss
zawarty w pliku isms.java. Interfejs isms.java zawiera w sobie jedynie obsługę odwołania do
metody zawartej w klasie sms, a mianowicie sendSms.
W klasie sms zaimplementowany został całkowicie moduł odpowiedzialny za wysyłanie
wiadomości tekstowej. W każdym obiekcie klasy znajduje się odwołanie to interfejsu isms,
oraz metoda sendTestSms. Pobiera ona z obiektu
Aby uzyskać przejrzysty obraz całej aplikacji zdecydowałem się podzielić mój projekt na
trzy
35
Moduł współpracy detektora upadku z telefonem komórkowym
9. Bibliografia
http://www.atmeda.org/ - strona American Telemedicine Association
http://www.teleekg.pl – TeleEKG firmy PRO-PLUS
http://www.vitaphone.de/en - Vitaphone
http://www.irda.org – strona IrDA
http://bluetooth.com/bluetooth/ - oficjalna strona Bluetooth
http://www.symbianfoundation.org – oficjalna strona symbian OS
http://www.slashphone.com/uploads/2794/nokia_6780.jpg - zdjęcie symbian OS
http://news.cnet.com/i/bto/20080325/todayscreen_web.jpg zdjęcie Microsoft Windows
mobile
http://www.android.com/ - oficjalna strona systemu
http://www.java.com –oficjalna strona Javy
http://www.sun.com – oficjalna strona Sun Microsystems
http://java.sun.com/docs/books/tutorial/ - tutorial z Javy
http://www.forum.nokia.com/info/sw.nokia.com/id/cae9ea59-eee0-4b98-aaa2-
1b6ecd879222/Carbide_cpp_Introductory_White_Paper_V1_1_en.pdf.html - carbide c++
36
Piotr Mazur
http://www.forum.nokia.com/main/resources/ - oficjalne forum Nokia dla developerów
oprogramowania na telefony komórkowe
http://gazeta-it.pl/200305226042/J2ME-+-CLDC-+-MIDP-czyli-komorkowa-wersja-Javy-
pod-mikroskopem.html – ciekawy artykuł o J2ME
http://www.ibm.com/developerworks/library/wi-midlet2/ - strona IBM dla J2ME
http://java.sun.com/javame/reference/apis/jsr037/javax/microedition/midlet/package-
summary.html - strona opsujaca dokładniej kwintesencję MIDletówe
http://www.eclipse.org – oficjalna strona projektu Eclipse
http://java.sun.com/products/sjwtoolkit/ - strona Java Wireless Toolkit
J2ME Praktyczne projekty – Krzysztof Rychlicki-Kicior
Thinking in Java – Bruce Eckel
37
Top Related