usluge s lokacijski oznaÄenim sadrÅ¾ajem - FER-a - SveuÄiliÅ¡te u ...

usluge s lokacijski oznaÄenim sadrÅ¾ajem - FER-a - SveuÄiliÅ¡te u ... usluge s lokacijski oznaÄenim sadrÅ¾ajem - FER-a - SveuÄiliÅ¡te u ...

from tel.fer.hr More from this publisher

06.04.2015 Views

SVEUČILIŠTE U ZAGREBU FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA DIPLOMSKI RAD br. 3117 USLUGE S LOKACIJSKI OZNAČENIM SADRŽAJEM Matej Gjurković Zagreb, srpanj 2009.

SVEUČILIŠTE U ZAGREBU

FAKULTET ELEKTROTEHNIKE I RAČUNARSTVA

DIPLOMSKI RAD br. 3117

USLUGE S LOKACIJSKI OZNAČENIM

SADRŽAJEM

Matej Gjurković

Zagreb, srpanj 2009.

Mentor rada: doc. dr. sc. Mario Kušek

Voditelj rada: doc. dr. sc. Mario Kušek

iii

Sadržaj

Uvod........................................................................................................................................... 1

1. Usluge s lokacijski označenim sadržajem.......................................................................... 2

1.1. Pozicioniranje pokretnog uređaja............................................................................... 2

1.2. Lokacijsko označavanje ............................................................................................. 4

1.3. Lokacijsko kodiranje .................................................................................................. 6

2. Java na malim uređajima.................................................................................................... 9

2.1. Izvođenje Javinih aplikacija na malim uređajima ...................................................... 9

2.2. Programska okolina J2ME ....................................................................................... 10

2.2.1. Connected Device Configuration..................................................................... 11

2.2.2. Connected Limited Device Configuration ....................................................... 12

2.3. MIDlet ...................................................................................................................... 13

3. Ostale korištene tehnologije............................................................................................. 16

3.1. Servleti ..................................................................................................................... 16

3.1.1. SIP servlet ........................................................................................................ 17

3.2. SailFin ...................................................................................................................... 19

3.3. IMS Location Server ................................................................................................ 22

4. Realizacija usluge............................................................................................................. 24

4.1. Programsko sučelje usluge Flickr ............................................................................ 25

4.2. Programsko sučelje Google Static Maps.................................................................. 30

4.3. Implementacija ......................................................................................................... 31

5. Korištenje usluge.............................................................................................................. 45

6. Zaključak.......................................................................................................................... 50

Literatura .................................................................................................................................. 51

Dodatak A: Instalacija programske podrške ............................................................................ 52

Uvod

Napretkom pokretnih mreža i uređaja, kao i razvojem tehnologija pozicioniranja iste su

postale pristupačnije širem broju korisnika i omogućile razvoj novih, inovativnih usluga.

Bogate komunikacijske i višemedijske mogućnosti pokretnih uređaja s jedne strane i pokretne

mreže nove generacije s druge strane omogućile su stvaranje, prijenos i prikazivanje bogatog

višemedijskog sadržaja u pokretu. Informacije dodane sadržaju koje ga pobliže opisuju čine

podlogu za stvaranje brojnih kontekstno zasnovanih usluga.

Posebno zanimljiva kategorija takvih usluga su usluge s lokacijski označenim sadržajem koje

omogućuju stvaranje i isporuku informacijskog sadržaja na temelju konteksta lokacije

korisnika. Korisnici koji stvaraju sadržaj uglavnom ga žele podijeliti s drugim ljudima. Ta

potreba je vrlo brzo uočena što je potaknulo stvaranje brojnih društvenih usluga i usluga za

razmjenu višemedijskog sadržaja. Lokacijsko označavanje sadržaja je postalo sastavni dio

takvih usluga.

Cilj ovog rada je bio obraditi temu usluga s lokacijski označenim sadržajem, proučiti

tehnologije koje se koriste u takvim uslugama te potom pokazati izvedivost usluge u

praktičnom dijelu rada.

U prvom poglavlju rada je pojašnjeno što su to usluge s označenim sadržajem, koji su načini

dohvaćanja lokacije i kako se pomoću nje označuje ili pretražuje sadržaj. Drugo poglavlje je u

potpunosti posvećeno J2ME (Java 2 Micro Edition) [1] tehnologiji koja omogućava razvoj i

izvođenje klijentskih aplikacija na malim uređajima. Treće poglavlje obrađuje tehnologije

korištene za izradu dijela usluge koji omogućuje lociranje korisnika od strane mreže

korištenjem protokola SIP (Session Initiation Protocol) [2]. Zadnja dva poglavlja pružaju uvid

u implementaciju konkretne usluge s lokacijski označenim sadržajem razvijene u sklopu rada

te sve informacije potrebne za uspješno korištenje usluge.

1. Usluge s lokacijski označenim sadržajem

Usluge s lokacijski označenim sadržajem su usluge koje se služe lokacijom korisnika kao

kontekstom za stvaranje i isporuku sadržaja. U nastavku rada će biti detaljnije pojašnjeni

načini dobivanja lokacije te postupci lokacijskog označavanja sadržaja i lokacijskog kodiranja

koji zajedno čine osnovnu usluga s lokacijski označenim sadržajem.

1.1. Pozicioniranje pokretnog uređaja

Osnovna informacija potrebna za pružanje lokacijskih usluga je pozicija korisnika odnosno

njegovog pokretnog uređaja. Postoji više metoda pozicioniranja koje se koriste s obzirom na

trenutnu lokaciju korisnika i mogućnosti koje posjeduje njegov pokretni uređaj [3]. Općenito

se metode za pozicioniranje mogu podijeliti na:

• mrežno-zasnovano pozicioniranje,

• pozicioniranje uz pomoć pokretnog uređaja i

• hibridno pozicioniranje.

Mrežno-zasnovano pozicioniranje

Mrežno-zasnovano pozicioniranje je temeljeno na proračunima vezanima uz mjerenje snage

signala koje bazne stanice primaju, kutu dolaznog signala odnosno vremenu potrebnom za

propagiranje signala. Osnovne metode pozicioniranja koje se koriste su:

• metode zasnovane na identifikaciji ćelije (Cell-ID),

• vrijeme dolaska signala (TOA – Time of Arrival) i

• kut dolaznog signala (AOA – Angle of Arrival).

Identifikacija ćelije koristi oznaku ćelije kao osnovnu lokacijsku informaciju u pokretnoj

mreži. Metode zasnovane na njima pronalaze korisnika unutar određene ćelije što direktno

znači da preciznost ovisi o veličini ćelije u kojoj se korisnik nalazi odnosno o gustoći baznih

stanica. Zbog te činjenice osnovna metoda (Cell Global Identity) je izrazito neprecizna jer u

slučaju ruralnih područja polumjer ćelije može iznositi i tridesetak kilometara. Preciznost

metode može se poboljšati tako da se ćelija podijeli u više sektora koristeći usmjerene antene.

Vrijeme dolaznog signala (TOA) je metoda koja za određivanje pozicije pokretne stanice

koristi kašnjenje signala na nekoliko susjednih baznih stanica, a kojih mora biti minimalno tri.

Za korištenje metode je potrebno nadograditi mrežu s pokretnim lokacijskim centrom (MLC-

Mobile Location Centre) te opremiti bazne stanice s lokacijskom mjernom jedinicom (LMU –

Location Measurement Unit). LMU se koristi za mjerenje dolaska signala. Na temelju

izmjerenih vrijednosti u MLC-u se izračunava sjecište kružnica određenih kašnjenjem koje

predstavlja lokaciju pokretne stanice. Preciznost TOA je mnogo bolja od Cell-ID metode pa

se pokretna stanica može detektirati s pogreškom od 50-200 metara.

Kut dolaznog signala (AOA) je metoda zasnovana na određivanju smjera propagacije signala

dobivenog od pokretne stanice. Smjer se određuje koristeći razliku kašnjenja dobivenu

pomoću TDOA (Time Difference Of Arrival) na susjednim baznim stanicama za svaku u nizu

antena bazne stanice. TDOA metoda je zapravo TOA koja koristi razliku, a ne apsolutnu

vrijednost kašnjenja. AOA metodom se može postići pogreška do 100 metara.

Pozicioniranje uz pomoć pokretnog uređaja

Pozicioniranje pokretnog uređaja je moguće i bez pokretne mreže tj. uporabom GPS-a

(Global Positioning System). GPS mreža je sastavljena od 31 satelita koje je u orbitu na visinu

od 20,163 km postavilo američko ministarstvo obrane originalno za svoje potrebe, a koja je

danas stavljena na uporabu svima koji je žele koristiti.

Pozicija se određuje triangulacijom temeljenom na vremenu potrebnom da signal dođe od

satelita do pokretnog uređaja. Dakle, potrebno je da GPS prijemnik hvata signal od bar tri

satelita.

Pozicioniranje uz pomoć GPS-a je vrlo precizno s pogreškom koja iznosi od 4-40 metara no

postoje i neke mane. Prva mana je potreba za čistim horizontom za nesmetano primanje

signala što izaziva probleme u klancima ili gradovima s visokim neboderima, uskim

prometnicama i raznim preprekama. Drugi problem je potreba za popriličnom procesorskom

snagom za obradu informacija dobivenih od satelita što automatski znači i veću potrošnju

energije na pokretnim uređajima.

Hibridno pozicioniranje

Hibridna rješenja koriste kombinaciju mrežno-zasnovanog pozicioniranja i pozicioniranja

zasnovanog na pokretnom uređaju. Tri osnovna hibridna rješenja su:

• CGI + TA (Cell Global Identity+ Timing Advance);

• E-OTD (Enhaced Observed Time Difference);

• A-GPS (Assisted GPS).

CGI-TA je poboljšana verzija osnovne metode CGI u kojoj se koristi činjenica da kašnjenje

signala ovisi o udaljenosti pokretnog uređaja od bazne stranice. Pomoću toga fizikalni kanal

GSM-a omogućuje razlikovanje udaljenosti pokretnog uređaja od bazne stanice u prstenima

širine 550 metara čime se povećava preciznost, prvenstveno u ruralnim područjima. Kao i kod

CGI metode veća preciznost se može postići sektorizacijom ćelije.

Kod metode E-OTD se koristi triangulacija slično kao kod TDOA metode no u ovom slučaju

pokretni uređaj mjeri vrijeme potrebno signalu da dođe s bazne stanice i onda izmjereno

vrijeme šalje natrag do bazne stanice koje to i vrijeme kad je signal odaslan šalje MLC-u koji

izračunava lokaciju korisnika. Greška metode je od 50-125 metara.

A-GPS donekle rješava problem velikog utroška energije i procesorske snage na pokretnom

uređaju jer zahtjevno računanje prepušta MLC-u. Lociranje je moguće čak i ako nisu

dostupna tri satelita nužna za GPS lociranje jer MLC u tom slučaju koristi informaciju o

lokaciji bazne stanice.

1.2. Lokacijsko označavanje

Lokacijsko označavanje (geotagging) [4] je proces kojim se dodaju lokacijske informacije

različitim medijima poput fotografija, videa, internetskih stranica ili RSS (Really Simple

Syndication) izvora podataka. Lokacijske informacije služe za predočavanje smještaja

pridijeljenih medija u prostoru. Najčešće korišteni lokacijski podaci su geografska širina i

dužina, smjer, visina te nazivi mjesta (adresa).

Postoji više standarada označavanja zbog raznolikosti medija, a neki od njih su:

1. označavanje JPEG fotografija pomoću formata EXIF (Exchangeable image file

format) ili XMP (Extensible Metadata Platform),

2. standardi korišteni u uslugama zasnovanim na webu (ICMB, RDF, MicroFormat),

3. standardi korišteni u sustavima zasnovanim na oznakama (tag based systems) i

4. standardi korišteni u web-dnevnicima.

1) EXIF je najčešće korišten format za oblikovanje meta podataka o fotografijama u formatu

JPEG. Podaci zapisani unutar njega nisu vidljivi na fotografiji no moguće ih je čitati ili

zapisivati pomoću posebnih programa. Danas u sve više uređaja poput fotoaparata i skenera

postoji programska podrška koja omogućava upis podataka o lokaciji u EXIF formatu.

Tipičan EXIF zapis lokacijskih podataka izgleda ovako:

GPSVersionID = 2 2 0 0

- Tag 0x0000 (4 bytes, int8u[4]):

dump: 02 02 00 00

GPSLatitudeRef = N

- Tag 0x0001 (2 bytes, string[2]):

dump: 4e 00 [ASCII "N\0"]

GPSLatitude = 57 38 56.83 (57/1 38/1 5683/100)

- Tag 0x0002 (24 bytes, rational64u[3]):

dump: 00 00 00 39 00 00 00 01 00 00 00 26 00 00 00 01

dump: 00 00 16 33 00 00 00 64

GPSLongitudeRef = W

- Tag 0x0003 (2 bytes, string[2]):

dump: 57 00 [ASCII "W\0"]

GPSLongitude = 10 24 26.79 (10/1 24/1 2679/100)

- Tag 0x0004 (24 bytes, rational64u[3]):

dump: 00 00 00 0a 00 00 00 01 00 00 00 18 00 00 00 01

dump: 00 00 0a 77 00 00 00 64

Program bi ovako zapisane podatke mogao prikazani na sljedeći način:

GPSLatitude : 57.64911

GPSLongitude : 10.40744

2) Postoji više standarada za lokacijsko označavanje u web-zasnovanim uslugama, a izbor

standarda koji će se koristiti ovisi o namjeni. Svima je zajedničko da su dizajnirani tako da bi

se programski mogle detektirati lokacijske informacije zapisane pomoću njih.

Metoda ICMB koju koristi standard GeoURL koristi se za lokacijsko označavanje

standardnih web-stranica kodiranih u HTML-u koristeći oznaku ICMB koja sadrži geografske

koordinate:

Metoda RDF koju je definirala W3 grupa sadrži meta podatke o lokaciji unutar RDF oznaka,

kao što se može vidjeti na sljedećem primjeru:

50.123 12.345

Microformat također omogućava programsko prepoznavanje lokacijskih informacija unutar

HTML stranica. Zapis lokacije pomoću Microformata izgleda ovako:

50.123456;

-12.345678

3) U sustavima zasnovanim na oznakama još uvijek ne postoje industrijski standardi no

većina takvih sustava koristi način označavanja predložen od strane web-stranice

Geobloggers. Označavanje temeljeno na oznakama je pogodno za korištenje kod označavanja

medija koji nisu producirani na uređajima koji imaju automatsko zapisivanje meta podataka

poput npr. fotoaparata koji automatski zapisuju u EXIF meta podatke o lokaciji nakon

slikanja. Tako je moguće npr. snimiti fotografije na pokretnom telefonu ili standardnom

fotoaparatu i poslije ručno upisati lokaciju na kojima su te fotografije snimljene ili programski

proslijediti podatke o lokaciji sustavu. Zbog toga je lokacijsko označavanje temeljeno na

oznakama standardna mogućnost većine najpopularnijih usluga za razmjenu fotografija poput

Flickra, Panoramia ili društvenih mreža poput del.icio.us.

Takvi sustavi koriste takozvane strojne oznake (machine tags) koji geografske koordinate

zapisuju u formatu WGS84 koji izgleda ovako:

geotagged

geo:lat=50.12345

geo:lon=12.34567

4) Lokacijsko označavanje u web-dnevnicima postaje sve popularnije u zadnje vrijeme.

Napretkom tehnologije GPS ona postaje pristupačnija širem krugu korisnika. Sve češće

korištenje GPS-a omogućuje korisnicima da sa svojih pokretnih uređaja vode web-dnevnike

Ideja je da se omogući označavanje lokacije s koje je napisan neki unos. Glavna prednost

lokacijskog označavanja dnevnika je da korisnici mogu pretraživati postojeće dnevnike po

lokacijama koje ih zanimaju te ih prikazivati na interaktivnim kartama. Način označavanja je

sličan prethodno navedenima, tj. koriste se lokacijske oznake.

1.3. Lokacijsko kodiranje

Lokacijsko kodiranje (geocoding) [5] je proces saznavanja geografskih koordinata na temelju

različitih podataka o lokaciji poput adresa ili poštanskih brojeva. Postoji i suprotni proces u

kojem se od geografskih koordinata saznaje adresa koji se naziva obrnuto lokacijsko

kodiranje (reverse geocoding). Primjenjuju se u mnogobrojnim lokacijski zasnovanim

uslugama, poput npr. saznavanja adresa benzinskih postaja najbližih trenutnoj lokaciji.

Postoji više metoda lokacijskog kodiranja zbog različitih namjena, zahtjeva za preciznosti,

odnosno zbog nemogućnosti primjene jedne metode s obzirom na postojeće podatke o

određenim lokacijama. Primjerice, preciznost će biti vrlo bitna u slučaju da je potrebno brzo

pronaći mjesto curenja plina iz plinovoda dok ona nije presudna kod prikaza označenih

fotografija. Također nisu ni sve lokacije jednako dobro pokrivene mrežom ulica pa metode

koje se koriste za gusto naseljena područja poput gradova nisu jednako primjenjive i za slabo

naseljena područja.

Svim metodama je zajedničko da je će biti preciznije ako se pruži što točnija adresa lokacije

za koju se traže geografske koordinate. Npr. Zagrebačka ulica br. 3 postoji u više gradova pa

ako se želi pronaći tu adresu u Velikoj Gorici mora se navesti i ime grada jer je inače moguće

da se ne dobije očekivani rezultat. Analogno tome, neke ulice i gradovi postoje u više država

pa je uputno navesti sve te podatke.

Jedna od češće korištenih i jednostavnijih metoda je interpolacija adresa. Metoda koristi

podatke geografskog informacijskog sustava (GIS) u kojem je mreža ulica označena

geografskim koordinatnim sustavom. Ulice su podijeljene na segmente po grupama kućnih

brojeva kojima su dodijeljeni određeni rasponi koordinata. Proces saznavanja koordinata se

vrši na način da se od ulaznog podatka, adrese, uzme naziv ulice koji se uspoređuje s

nazivima ulica u mreži ulica te kućni broj koji se uspoređuje s pojedinim segmentima ulice.

Kad se pronađe segment tražene lokacije, interpolacijom položaja se dobiju geografske

koordinate.

Primjerice, ako jedan segment Ilice (ulica u Zagrebu) ima raspon adresa od 100 do 200 te

uzmemo u obzir da su parne adrese na južnoj strani ulice, a neparne na sjevernoj i ako tražimo

poziciju s adresom Ilica 151, koordinate dobivene interpolacijom adresa će smjestiti objekt s

traženom adresom otprilike na sredinu segmenta sa sjeverne strane ulice.

Metoda ima određene nedostatke koji izviru iz sljedećih pretpostavki koje direktno utječu na

preciznost određivanja lokacije:

• svi su parni brojevi s jedne strane ulice, a neparni s druge - u realnosti to često nije

slučaj,

• sve parcele su jednake veličine – u realnosti to skoro nikad nije točno,

• postoje sve adrese iz maksimalnog raspona – npr. za zadnji segment ulice se računa

da ima adrese od 500-600 no zadnja adresa koja se koristi je 512 te će se

interpolirati kriva pozicija,

• objekti su točkasto tijelo male površine – u realnosti je moguć slučaj npr. stadiona

koji ima jednu adresu ali je jedan njegov kraj poprilično udaljen od drugog.

Iz gore navedenog se može primjetiti da je metoda nedovoljno precizna za korištenje u

aplikacijama na temelju kojih se donosi odluka o npr. spašavanju života unesrećenih ljudi,

gdje i neznatno kašnjenje uzrokovano nepreciznošću može uzrokovati teške posljedice no za

većinu drugih namjena je pogodna.

Osim interpolacije adresa koriste se i druge metode poput npr. korištenja centralnih točaka

parcela koje postoje u informacijskom sustavu u slučaju da je preciznost manje bitna ili

preciznija podjela prometnica po segmentima koje odgovoraju tzv. kilometarskim oznakama

na prometnicama za slučaj usluga za dojavu prometnih nesreća koje koriste ekipe hitne

pomoći i vatrogasci.

Postoje neki problemi u korištenju lokacijskog kodiranja koji proizlaze iz određenih namjena.

Primjerice, u slučaju karata na kojima su pokazana mjesta zločina nepreciznost u određivanju

lokacije može prouzročiti neugodnost ljudima koji sa samim zločinom nisu imali veze, a

mjesto zločina je prikazano na njihovoj adresi.

Danas postoji mnoštvo usluga za lokacijsko kodiranje, no s obzirom da se većina lokacijsko

zasnovanih usluga nalazi na webu valja spomenuti Yahoo! GeoPlanet API i Google Maps API

Geocoding Service koji se najviše koriste u takvim uslugama.

2. Java na malim uređajima

Posljedica naglog razvoja mobilnih tehnologija u posljednje vrijeme je nastanak mnoštva

različitih malih uređaja prilagođenim svim vrstama korisnika i usluga. Upravo zbog te

raznolikosti malih uređaja, njihovih mogućnosti i operacijskih sustava i činjenice da je

neovisna o platformi Java je postala vodeći programski jezik za razvoj aplikacija za male

uređaje. Pošto mali uređaji imaju ograničenu procesorsku moć, ograničenu količinu memorije

te ograničenja ulazno-izlaznih jedinica, bilo je potrebno prilagoditi Java platformu da se može

izvoditi na takvim uređajima. Reducirana verzija Jave za male uređaje je Java 2 Micro

Edition (J2ME). Pod pojmom mali uređaji podrazumijevamo širok spektar uređaja s različitim

mogućnostima, među kojima su npr. pokretni telefoni, ručna računala (PDA), pametni telefoni

(engl. smart phones) i dr. S obzirom na raznolikost uređaja bilo je potrebno prilagoditi J2ME

programsku okolinu, što se postiglo definirajući različite konfiguracije, profile i dodatne

pakete koji su prilagođeni određenoj vrsti uređaja.

2.1. Izvođenje Javinih aplikacija na malim uređajima

Da bi se bolje razumjelo kako se Java izvodi na malim uređajima potrebno je prvo objasniti

proces nastanka Java koda i izvođenja na Java 2 Standard Edition (J2SE) platformi. Kao

vizualna pomoć može poslužiti Sl. 2.1.

Sl. 2.1 Razvoj i izvođenje programa u Javi

Vidimo da se prvo napiše izvorni kod u nekom uređivaču teksta. Prevodilac (engl. compiler)

prevodi taj kod u međukod koji se u Javinom svijetu zove bajt-kod (engl. bytecode). Važnost

međukoda je u činjenici da je prevodilac puno složeniji od pokretača aplikacija. Pošto se

prevođenje odvija samo jednom dobiva se na brzini izvođenja aplikacija. Također, takav

međukod je neovisan o platformi te se zbog toga može izvoditi na različitim operacijskim

sustavima.

Javin pokretač aplikacija (engl. Java Application Launcher) pokreće okolinu za izvršavanje

aplikacija (engl. Java Runtime Environment, skraćeno JRE). JRE se sastoji od Javinog

virtualnog stroja (engl. Java Virtual Machine), jezgrenih klasa i pratećih datoteka i pruža

minimalnu okolinu potrebnu za izvođenje aplikacija. Zadaća pokretača aplikacija je da učita

specificirane klase te poziva odgovarajuću metodu main koja pokreće aplikaciju. Prilikom

učitavanja klasa Java virtualni stroj vrši verifikaciju međukoda.

Upravo je u verifikaciji međukoda glavna razlika između izvođenja aplikacija na malom

uređaju. Na Sl. 2.2 je prikazan proces razvoja Java aplikacije za mali uređaj. Može se

primijetiti da se procesorski najzahtjevniji dio obavlja na osobnom računalu na kojem se

razvija aplikacija. J2ME virtualni stroj vrši samo daleko jednostavnije, linearno pregledavanje

međukoda prilikom učitavanja klasa.

Sl. 2.2 Razvoj i izvođenje Javinih programa na malim uređajima

2.2. Programska okolina J2ME

Programsku okolinu J2ME čine konfiguracije, profili i dodatni paketi. J2ME konfiguracije su

specifikacije koje definiraju programsku okolinu za skup uređaja sa zajedničkim

karakteristikama poput:

• vrste i brzine procesora,

• vrste i količine memorije i

• vrsta mrežnih konekcija dostupnih malom uređaju.

Konfiguracija predstavlja minimalnu platformu za pojedinu skupinu uređaja, a sastoji se od

kombinacije Java virtualnog stroja i osnovnih biblioteka funkcija koje čine osnovu za razvoj

aplikacija namijenjenih nekoj vrsti uređaja.

U nastavku su detaljnije opisane konfiguracije Connected Device Configuration (CDC) [6] i

Connected Limited Device Configuration (CLDC) [7], te profili koji su dodani tim

konfiguracijama. Profili dodaju specifične biblioteke funkcija konfiguraciji ovisno o

konkretnoj vrsti uređaja i njegovoj namjeni.

2.2.1. Connected Device Configuration

Konfiguracija CDC je definirana u JSR-36 i namijenjena je grupi jačih malih uređaja koji

imaju jači procesor, više memorije i bolji izbor konekcija. Ciljani uređaji kojima je

namijenjen CDC moraju imati 32-bitni procesor, najmanje 2MB RAM-a i 2.5MB ROM-a

raspoloživih za Java okolinu. Radi se o uređajima poput pametnih telefona, PDA uređaja,

telematičkih sustava ugrađenih u vozila, kućne elektronike i dr.

Java virtualni stroj je sličan onom iz J2SE platforme, no svojim zahtjevima prema resursima,

performansama i pouzdanošću prilagođen malim uređajima.

CDC ima bogatu biblioteku klasa koju minimalno čine:

• java.lang – sadrži klase potrebne za funkcioniranje Java virtualnog stroja,

• java.util – podskup općenitih metoda i sučelja iz J2SE ekvivalentnog paketa,

• java.net – sadrži klase i sučelja za rukovanje TCP/IP i HTTP protokolima,

• java.io – sadrži standardne klase za rukovanje ulazno-izlaznim jedinicama,

• java.text – sadrži minimalne klase potrebne za lokalizaciju i internacionalizaciju

aplikacije i

• java.security – sadrži osnovne klase i sučelja za implementaciju sigurnosti.

CDC podržava tri glavna profila i mnoštvo opcionalnih.

Tri glavna profila su:

• Foundation – biblioteka klasa zasnovanih na J2SE, ne sadrži podršku za GUI,

• Personal Basis – sadrži Foundation profil uz dodatak podrške za lagane (engl.

lightweight) komponente i Xlete koji su slični Java appletima no koji su dizajnirani

za izradu aplikacija za digitalnu televiziju,

• Personal – osim Personal Basis profila sadrži i punu podršku za GUI i applete.

Opcionalni paketi uvode dodatne funkcionalnosti koje se ne pojavljuju u osnovnim profilima

poput podrške za RMI (Remote Method Invocation) i JDBC (Java Database Connectivity).

2.2.2. Connected Limited Device Configuration

Konfiguracija CLDC je definirana u JSR-30 i JSR-139 i namijenjena je grupi slabijih malih

uređaja koje karakterizira česti gubitak veze s mrežom, ograničena količina memorije, spori

procesori i jako ograničene ulazno-izlazne jedinice. To su uređaji poput pokretnih telefona,

pagera i manje naprednih ručnih računala. Minimalni uvjeti koje moraju zadovoljavati su:

• 16 ili 32-bitni procesor brzine najmanje 16MHz,

• 160KB na raspolaganju za Java virtualni stroj i njegove pripadajuće biblioteke, od

kojih su 32KB izbrisive (engl. volatile) memorije, a ostalih 128KB neizbrisive

(engl. non-volatile) ,

• 192KB ukupno memorije dostupno Java okolini,

• mogućnost spajanja na mrežu.

Konfiguracija CLDC se sastoji od virtualnog stroja nazvanog Kilobytes Virtual

Machine(KVM) veličine između 40 i 80KB, biblioteka osnovnih klasa iz J2SE, te dodatnih

klasa koje ne postoje u J2SE. Može se reći da je CLDC konfiguracija podskup CDC

konfiguracije, a sadrži sljedeće biblioteke klasa:

• java.io – sadrži podskup osnovnih klasa iz ekvivalentnog J2SE paketa;

• java.lang – sadrži klase potrebne za funkcioniranje Java virtualnog stroja;

• java.util – podskup općenitih metoda i sučelja iz J2SE ekvivalentnog paketa ;

• javax.microedition.io – klase za rukovanje ulazno-izlaznim jedinicama specifično

napravljene za CLDC konfiguraciju.

Za konfiguraciju CLDC postoji mnoštvo API-ja i profila, no detaljnije će biti opisan

najpopularniji među njima – Mobile Information Device Profile (MIDP) [8].

Trenutna verzija MIDP 2.0 definiran u JSR-118 je zamijenila MIDP 1.0 koji je bio definiran u

JSR-37, dodajući mu nove funkcionalnosti poput poboljšanog korisničkog sučelja, podrške za

multimediju i igre te bolju podršku za mrežne konekcije i sigurnost. MIDP podržavaju svi

noviji pokretni uređaji pa postoji široka baza korisnika aplikacija zasnovanih na njemu.

Razvijateljima aplikacija nudi mogućnosti manipuliranja kamerom, GPS-om, konekcijama

preko GPRS/EDGE tehnologije te uz prije navedeno ne čudi što je upravo on danas

najpopularniji profil.

Uvjeti koje uređaj mora zadovoljavati da bi se na njemu mogle izvršavati MIDP aplikacije su:

• ekran veličine 96x52 piksela,

• dubina prikaza boja od 1 bita,

• mora postojati tipkovnica ili ekran osjetljiv na dodir,

• 128KB za MIDP aplikacije,

• 8KB za trajno pohranjene podatke aplikacija,

• 32KB memorije za izvršavanje i

• dvosmjerna bežična mreža.

MIDP se osim osnovnih CLDC paketa sastoji i od niže navedenih:

• javax.microedition.lcdui – klase i sučelja za upravljanje prikazom,

• javax.microedition.rms – Record Management System (RMS) koji služi za trajno

pohranjivanje podataka,

• javax.microedition.midlet – klase i sučelja namijenjene stvaranju MIDP aplikacija.

2.3. MIDlet

MIDlet (skraćeno od Mobile Information Device Application) je aplikacija koja se izvodi na

uređajima koji podržavaju CLDC i MIDP. Jedan ili više MIDleta pakiranih u jedan JAR (Java

Archive) čine MIDlet Suite.

Razvojni ciklus MIDleta sastoji se od pet ili šest faza. To su redom:

• pisanje koda – nužno je prvo proučiti dokumentaciju i naučiti se služiti

bibliotekama dostupnim za razvoj MIDleta,

• prevođenje koda u međukod – prevođenje vrši prevodilac (javac), rezultat

prevođenja su .class datoteke,

• predprovjera koda – traže se reference na klase koje MIDP ne podržava; cilj je

smanjiti opterećenje KVM prilikom izvršavanja MIDleta jer on mora samo linearno

provjeriti kod što ne traži puno resursa,

• pakiranje u JAR – izvršne datoteke se pakiraju u jednu zajedničku datoteku u ZIP

formatu,

• stvaranje JAD datoteke – tekstualna datoteka koja služi za opis aplikacije,

• potpisivanje MIDleta – uvedeno od verzije MIDP 2.0; olakšava definiranje

sigurnosne politike izvršavanja MIDleta na malom uređaju, a korisniku olakšava

korištenje jer ne mora svaki put iznova odobravati pristup zaštićenim API-jima.

Svaki MIDlet nasljeđuje klasu javax.microedition.midlet.MIDlet koja definira tri apstraktne

metode i koje definiraju njegov životni ciklus (Sl. 2.3):

• pauseApp - MIDlet je inicijaliziran, no ne smije koristiti zajedničke resurse,

• startApp – normalno fukncioniranje MIDleta,

• destroyApp – završetak rada, oslobađanje svih resursa.

Sl. 2.3 Životni ciklus MIDleta

MIDlet se izvodi u okolini koju kontrolira aplikacijski upravitelj (engl. application manager).

Aplikacijski upravitelj je zadužen za instalaciju, izvršavanje, pauziranje i uništavanje MIDleta

te omogućavanje pristupa pojedinim MIDletima do izvršnih datoteka Javinog virtualnog

stroja odnosno CLDC-a. Također je zadužen i za dojavljivanje MIDletu ako se dogodi neki

događaj na što se onda u njemu pokreću određene metode.

Jedan takav događaj je i samo pokretanje MIDleta nakon kojeg će se pokrenuti metoda

startApp koja tipično pokreće početni prikaz za odabir opcija korisniku. Ako korisniku npr.

zazvoni pokretni telefon, aplikacijski upravitelj će pozvati metodu pauseApp koja će

zaustaviti izvršavanje MIDleta. Moguća je situacija da MIDlet više nije potreban ili da nekoj

prioritetnijoj aplikaciji treba memorijski prostor – ukoliko se to dogodi, aplikacijski upravitelj

će pozvati metodu destroyApp čime će životni ciklus MIDleta biti završen.

MIDlet se distribuira na uređaj u JAR datoteci koja sadrži sve izvršne (.class) datoteke i ostale

za aplikaciju potrebne datoteke poput npr. slika i konfiguracijskih datoteka, no u pravilu

dolazi i sa JAD (Java Definition) datotekom koja opisuje MIDlet.

Da bi JAR datoteka bila izvršna, uz gore navedene datoteke, dolazi i posebna manifest

datoteka koja između ostalog govori koja je glavna izvršna datoteka. Manifest datoteka se

sastoji od više parova ime-vrijednost kojih ima devet, ali samo je šest obavezno. Ovako

izgleda jedna takva datoteka (manifest.mf):

Manifest-Version: 1.0

MIDlet-Vendor: Midlet Suite Vendor //isporučitelj

MIDlet-Version: 1.0.0 //verzija

MIDlet-1: TestMIDlet,,hr.tel.fer.primjer.midlet. TestMIDlet //paket

MicroEdition-Configuration: CLDC-1.1 //vrsta konfiguracije

MIDlet-Name: TestMIDlet Midlet Suite //ime

MicroEdition-Profile: MIDP-2.0 //vrsta profila

JAD datoteka se koristi za prosljeđivanje parametara MIDletu bez modificiranja JAR datoteke

i za pružanje dodatnih informacija o JAR datoteci aplikacijskom upravitelju koje mu između

ostaloga govore može li se MIDlet pokrenuti na dotičnom uređaju.

Struktura unutar JAD-a je slična kao kod manifest datoteke, a neka polja poput imena, verzije

i isporučitelja moraju odgovarati onima iz manifest datoteke.

Jedna takva datoteka (TestMIDlet.jad) izgleda ovako:

MIDlet-1: TestMIDlet,,hr.tel.fer.primjer.midlet.TestMIDlet t //paket

MIDlet-Jar-Size: 4306 //veličina JAR datoteke

MIDlet-Jar-URL: TestMIDlet.jar

MIDlet-Name: TestMIDlet Midlet Suite

MIDlet-Vendor: Midlet Suite Vendor

MIDlet-Version: 1.0.0

MicroEdition-Configuration: CLDC-1.1

MicroEdition-Profile: MIDP-2.0

Polje MIDlet-Jar-URL je zanimljivo jer omogućava da se na malom uređaju pokrene samo

JAD datoteka, a da se JAR naknadno skine preko mreže.

3. Ostale korištene tehnologije

3.1. Servleti

Servleti [9] su komponente napisane u Javi koje se izvode na poslužiteljskoj strani i koje

dinamički obrađuju zahtjeve klijenata i stvaraju odgovarajuće odgovore na te zahtjeve.

Ubrzo nakon što se web počeo koristiti za usluge, prepoznata je potreba za stvaranje

dinamičkog sadržaja. Jedan od prvih pokušaja u ostvarivanju tog cilja su bili Java-appleti koji

su se izvodili na klijentskoj strani i omogućavali interakciju s korisnicima. Otprilike u isto

vrijeme su se počele koristiti CGI (Common Gateway Interface) skripte koje su se izvodile na

poslužiteljskoj strani i omogućavale dinamičko generiranje sadržaja. Iako vrlo popularne,

imale su mnogo nedostataka poput ovisnosti o platformi te loše skalabilnosti. Da bi se riješili

ti problemi razvijeni su servleti koji pružaju dinamički sadržaj, a mogu su se izvoditi na

različitim platformama.

Kao i svaki drugi Java kod, da bi se mogao izvršavati servlet se mora prevesti u međukod.

Servleti se izvršavaju na aplikacijskom poslužitelju koju učitava i pokreće datoteke servleta.

Dio aplikacijskog poslužitelja koji upravlja životnim vijekom servleta, prihvaća zahtjeve od

klijenata i šalje odgovore generirane u servletu naziva se servlet kontejner.

Servlet kontejner može biti ugrađen u poslužitelj ili instaliran kao njegova dodatna

komponenta, a izvoditi se može unutar istog procesa kao poslužitelj, drugog procesa unutar

računala ili na nekom drugom računalu.

Svaki servlet mora implementirati sučelje Servlet iz paketa javax.servlet. Sučelje propisuje

metode koje definiraju životni vijek servleta, a koji se odvija u sljedećim koracima :

1. Servlet se instancira i učitava u kontejner prilikom pokretanja kontejnera;

2. Kontejner poziva init() metodu koja inicijalizira servlet. Metoda init() se pokreće

samo jednom, a nužna je da bi servlet mogao početi primati zahtjeve;

3. Normalni rad servleta. Servlet može primati zahtjeve koji se poslužuju u zasebnim

nitima. Servletu zahtjeve prosljeđuje kontejner koji prilikom dolaska zahtjeva poziva

metodu service() koja služi za razvrstavanje zahtjeva po tipu i koja zove

odgovarajuće metode zadužene za obradu tih zahtjeva. Za implementaciju tih metoda

je zadužen programer, a ukoliko to ne učini, pozvat će se metode nadklase što će

rezultirati slanjem poruke o grešci klijentu koji je poslao zahtjev;

4. Životni vijek servleta završava pozivanjem metode destroy() od strane kontejnera.

Metoda destroy() se kao i metoda init() poziva samo jednom.

Ilustraciju životnog ciklusa servleta možete vidjet na Sl. 3.1.

Sl. 3.1 Životni ciklus servleta

Tehnologija servleta je u početku razvijana za HTTP. Prvotna specifikacija servleta naglašava

da servlet kontejner mora podržavati protokol HTTP. Pošto se u ovom radu koriste SIP

servleti koji su slični HTTP servletima, objasnit će se njihov način rada, a eventualne razlike

između njih će biti spomenute.

3.1.1. SIP servlet

SIP servlet [10] je komponenta temeljena na Javi kojom upravlja SIP servlet kontejner i koja

se koristi SIP signalizacijom. SIP kontejner prihvaća zahtjeve klijenata te ih prosljeđuje do

servleta koji generira odgovore i opet preko SIP kontejnera šalje natrag klijentima.

SIP specifikacija zahtjeva da SIP elementi podržavaju TCP i UDP transportne protokole, no

mogu podržavati i TLS, SCTP i ostale protokole za ugrađenim sigurnosnim mehanizmima.

SIP servlet kontejner osluškuje SIP promet na svojim priključnicama (engl. socket) koje

koriste gore navedene protokole te dobivene zahtjeve prosljeđuje servletu.

SIP Servlet API, slično kao i HTTP Servlet API, nadograđuje generički servlet API

javax.servlet, a nalazi se u javax.servlet.sip.

Glavnu razliku HTTP i SIP aplikacija čini činjenica da se SIP aplikacije mogu ponašati i kao

klijent i kao poslužitelj odnosno primati, ali i generirati zahtjeve, za razliku od HTTP

aplikacija koje su isključivo u klijent-poslužitelj odnosu.

SIP Servlet API između ostalog mora podržavati sljedeće mogućnosti:

• primanje odgovora i zahtjeva,

• slanje zahtjeva i odgovora – dodatno slanje višestrukih odgovora i

• preusmjeravanje zahtjeva uz mogućnost odabira više odredišnih destinacija.

SIP aplikacije se pokreću ako se dogodi događaj na koji su one registrirane. Ti događaji mogu

biti zahtjevi ili odgovori koje kontejner predaje aplikaciji preko service() metode koja se

nalazi u javax.servlet.Servlet sučelju. Metoda service() ustanovljuje radi li se o zahtjevu ili

odgovoru te ih na temelju toga prosljeđuje do doRequest(SipServletRequest request) ili do

doResponse(SIPServletResponse response) metode kako je prikazano na Sl. 3.2. Metode

doRequest i doResponse na temelju vrste zahtjeva ili odgovora pozivaju metodu koja je

zadužena za obradu tih događaja i koju je programer dužan implementirati. Metoda doRequest

prima objekt SipServletRequest koji predstavlja zahtjev, a za odgovor, odnosno objekt tipa

SipServletResponse se mora pobrinuti programer zbog zahtjeva komunikacije jedan na više.

Sl. 3.2 Obrada događaja kod SIP servleta

3.2. SailFin

SailFin [11] je aplikacijski poslužitelj nastao spajanjem Ericssonove tehnolgije SIP Servlets i

Sunovog aplikacijskog poslužitelja GlassFish.

Sun GlassFish Enterprise Server [12] je aplikacijski poslužitelj otvorenog koda koji se razvija

pod nadzorom Sun Microsystema za platformu Java Enterprise Edition. Projekt je pokrenut

kada su Sun i Oracle donirali kod na kojem je temeljen razvoj GlassFisha. GlassFish je kao

besplatan softver pod dvije licence, CDDL i GPL. On kao poslužitelja web-aplikacija koristi

inačicu Apache Tomcata s dodatnom komponentom Grizzly koja je zadužena za skalabilnost i

brzinu izvođenja, dok je sustav za perzistenciju podatka preuzet od sustava Oracle TopLink.

Glavni cilj projekta SailFin je napraviti kontejner za SIP servlete koji će implementirati JSR-

289 Java Specification Request (JSR) je dokument koji Java Community Process (JCP)

podnosi Program Management Officeu (PMO), a u kojem se predlaže nova specifikacija ili

znatno poboljšanje stare specifikacije. JSR-289 definira poboljšanja specifikacije SIP Servlet

API-ja u skladu sa zahtjevima industrije te definira model međudjelovanja SIP Servleta s Java

EE (Enterprise Edition) komponentama.

U trenutnoj verziji SailFina je implementiran JSR-116 u kojem je definiran osnovni SIP

Servlet API, a na implementaciji JSR-289 se još uvijek radi.

SailFin omogućuje izvođenje konvergiranih aplikacija pošto njegov kontejner osim SIP

servleta podržava i HTTP servlete. Pod pojmom konvergiranih aplikacija se misli na one

aplikacije koje korištenjem više protokola omogućavaju telekomunikacijske usluge. Jedna

takva usluga bi na primjer mogla biti mogućnost pozivanja zaposlenika prilikom kupovine u

web-dućanu pritiskom na poveznicu u svrhu dobivanja dodatnih informacija o proizvodu.

Da bi se aplikacije mogle izvoditi moraju se poštivati određena pravila smještaja tih aplikacija

unutar strukture direktorija SailFina. Unutar direktorija SIP aplikacije mora postojati

direktorij WEB-INF unutar kojeg se nalazi konfiguracijska datoteka sip.xml. Izvršne datoteke

se smještaju u direktorij WEB-INF/classes, a sve ostale klase i biblioteke klasa koje aplikacija

koristi se smještaju u direktorij WEB-INF/lib.

Kako bi kontejner znao koji servlet treba pozvati nakon prispjelog zahtjeva, servleti se moraju

mapirati. Mapiranje se vrši unutar sip.xml.

Zahtjevi se razvrstavaju na temelju:

• vrste zahtjeva,

• razlikovanja početnih i naknadnih zahtjeva, te početnih i naknadnih odgovora i

• korištenja logičkih operatora među poljima zaglavlja.

Glavni dijelovi zahtjeva su:

• method – definira metodu zahtjeva,

• uri – URI zahtjeva,

• from – sadržaj From polja zaglavlja i

• to – sadržaj To polja zaglavlja.

Glavni dijelovi se mogu sastoji od više unutarnjih dijelova. Npr. from može biti SIP URI koji

se sastoji od scheme, user, host i port dijelova.

Logički uvjeti koji se mogu koristiti nad tim poljima zaglavlja i njihovim dijelovima su:

• equal – uspoređuje varijablu s nekim znakovnim nizom,

• exists – provjerava postoji li neka varijabla,

• contains – provjerava sadrži li neka varijabla određeni znakovni niz,

• subdomain-of – provjerava je li neki znakovni niz poddomena određenog URI-ja,

• and – provjerava jesu li svi uvjeti zadovoljeni,

• or – provjerava je li neki od svih uvjeta zadovoljen i

• not – negira vrijednost.

Važno je napomenuti da SIP kontejner poziva servlete po određenim pravilima. Prvo pravilo

je da se pozivaju svi servleti koji su mapirani na određenu vrstu zahtjeva ako oni

zadovoljavaju uvjete. Drugo pravilo je da se pozivaju onim redom kojim su navedeni u

konfiguracijskoj datototeci ako ih ima više koji zadovoljavaju uvjete.

Primjer jedne konfiguracijske datoteke izgleda ovako:

SIP Primjer

primjer SIP konfiguracijske datoteke

SIPServlet1

primjer.SIPServlet1

SIPServlet2

primjer.SIPServlet2

SIPServlet1

request.method

MESSAGE

request.method

INVITE

SIPServlet2

request.method

INVITE

U ovom primjeru može se vidjeti kako u praksi izgleda mapiranje. Elementi display-name i

description služe za definiranje imena servleta koje će se pokazati i njegov opis. Unutar

elementa servlet navodi se ime stvarnog servleta i njegova glavna klasa s punom putanjom do

nje. Unutar elementa servlet-name potrebno je navesti točno ime servleta koje se mora slagati

s onim koje je navedeno prije u elementu servlet, dok se unutar pattern elementa navodi

uvjete koje zahtjev mora ispuniti da bi se pokrenuo dotični servlet. U ovom slučaju će se

zahtjevi doći do servleta SIPServlet1 ako su oni tipa MESSAGE ili INVITE, a do SIPServlet2

ako su oni tipa INVITE. Na ovom primjeru se može vidjeti i kako se primjenjuje pravilo

pozivanja servleta u slučaju da više njih ima zadovoljava postavljene uvjete. Ako npr. dođe

INVITE zahtjev morat će se pozvati oba servleta jer oba zadovoljavaju uvjet, no pozivat će se

onim redom kojim su navedeni u konfiguracijskoj datoteci. Pošto je SIPServlet1 naveden prvi,

u ovom slučaju će se prvo on pozvati, a tek nakon njega SIPServlet2.

3.3. IMS Location Server

IMS Location Server (ILS) je SIP aplikacijski poslužitelj razvijen u Ericsson Nikoli Tesli

[13]. Njegova uloga u IMS-u je da služi kao spona sa sustavom za pozicioniranje. ILS nije

odgovoran za pronalaženje krajnje lokacije korisnika, već za saznavanje lokacije korisnika

slanjem zahtjeva do raspoloživog sustava za pozicioniranje.

Drugi aplikacijski poslužitelji kojima trebaju lokacijski podaci ne trebaju tako izravno

komunicirati sa sustavom za pozicioniranje već za njih to čini ILS koji zbog svojih ugrađenih

funkcionalnosti ne ovisi o pojedinim pružateljima usluga. ILS je prema tome omogućitelj

usluge (engl. service enabler).

ILS se trenutno sastoji od dva glavna dijela:

• Location Retrieval Function (LRF) – koristi se za dohvat lokacijskih informacija

preko SIP sučelja

• Position Manager – simulator sustava za pozicioniranje

Lokacijske informacije se prenose preko SUBSCRIBE/NOTIFY SIP komunikacijskog

mehanizma. IMS aplikacijski poslužitelji, klijenti i ostali IMS entiteti lokaciju korisnika

mogu zatražiti na više načina slanjem SUBSCRIBE zahtjeva ILS-u te primiti lokaciju:

• jednokratno – nakon primanja zahtjeva ILS šalje trenutnu lokaciju korisnika; Expire

polje u zaglavlju zahtjeva se postavlja na 0,

• periodično – nakon primanja zahtjeva ILS periodički šalje lokaciju korisnika;

Expire polje se postavlja na broj sekundi koje predstavljaju interval između slanja

lokacije korisnika i

• uvjetno periodično – nakon primanja zahtjeva ILS periodički šalje lokaciju

korisnika ako je ispunjen određeni uvjet određen filterom; Expire polje se također

postavlja na broj sekundi koje predstavljaju interval između slanja lokacije

korisnika.

Prema preporuci IETF-a ILS koristi protokolno nezavisni format za prijenos lokacijskih

informacija - Presence Information Data Format (PIDF) zasnovan na XML-u. PIDF koristi

Geography Markup Language (GML) kao osnovni format zapisa lokacijskih informacija.

Position Manager unutar LIS-a služi kao emulator sustava za pozicioniranje. Lokacija

korisnika se može mijenjati pomoću miša, a moguće je dodavanje i brisanje korisnika te

dodavanje različitih karata. Pri dodavanju karte je osim same karte u nekom slikovnom

formatu potrebno definirati koordinatama gornju lijevu i donju desnu točku karte u posebnoj

XML datoteci s ekstenzijom .map u direktoriju maps. Kako Position Manager izgleda, može

se vidjeti na Sl. 3.3.

Sl. 3.3 Grafičko sučelje Position Managera

4. Realizacija usluge

U sklopu diplomskog rada je bilo potrebno napraviti uslugu s lokacijski označenim sadržajem

te je stoga osmišljena usluga koja omogućuje mobilno korištenje usluga za pohranu

fotografija na webu s mogućnošću lokacijskog označavanja Flickra. Korisniku je omogućeno

snimanje fotografija na pokretnom uređaju neovisno gdje se zatekne i slanje tih fotografija na

Flickr s podacima o lokacijama na kojima su snimljene te pregledavanje tuđih fotografija

snimljenih blizu svoje ili neke druge lokacije. Osim tih glavnih mogućnosti, implementirane

su i brojne druge koje će biti objašnjene u nastavku rada.

Sl. 4.1 Arhitektura usluge

Arhitektura usluge je prikazana na Sl. 4.1. Klijentska aplikacija (FlickLoc) saznanje lokaciju

korisnika na dva načina – od pokretne mreže ili putem GPS-a. Prvim načinom kontaktira

putem protokola SIP poslužiteljsku aplikaciju (Location Servlet) na SailFinu koja preko IMS

Location Servera saznaje korisnikovu lokaciju te ju vraća klijentu. Drugi način je direktno

preko GPS prijemnika implementiranog na pokretnom uređaju za one uređaje koji posjeduju

GPS prijemnik, a ne posjeduju mogućnost korištenja protokola SIP. Na temelju tako dobivene

lokacije moguće je označiti fotografiju te ju poslati na Flickr ili pretraživati fotografije u

svojoj blizini korištenjem Flickr API-ja. U slučaju pretraživanja fotografija omogućen je

prikaz lokacija fotografija na mapi koja se dohvati preko Google Static Maps API-ja.

U nastavku rada će prvo biti pojašnjeno što su i kako se koriste Flickr API [14] i Google

Static Maps API [15] radi lakšeg razumijevanja konkretne implementacije usluge koja će

potom biti detaljnije pojašnjena.

4.1. Programsko sučelje usluge Flickr

Flickr kao i većina sličnih usluga ima svoje programsko sučelje (API - Application

Programming Interface) koje je dostupno svima koji žele raditi aplikacije, a koriste podatke s

Flickra – prvenstveno fotografije ali i druge brojne mogućnosti koje Flickr posjeduje. Flickr

API se sastoji od skupa metoda koje se mogu pozivati te različitih priključnih točaka. Metode

se pozivaju slanjem upita na priključne točke u točno određenom formatu. Odgovor na njih se

šalje pozivatelju u nekom od definiranih formata koji su stavljeni na izbor. Metode su

mnogobrojne, a i svakodnevno se dodaju nove te će njihov broj u budućnosti biti sve veći.

Preduvjet da bi se koristio API je posjedovanje aplikacijskog ključa koji Flickru omogućava

praćenje poziva prema API-ju. Korištenje API-ja je slobodno za privatne, umjetničke i ostale

nekomercijalne svrhe pa se stoga aplikacijski ključ za takve aplikacije dobije vrlo lagano.

Nešto duži i neizvjesniji proces je prijava za korištenje Flickr API-ja u komercijalne svrhe jer

se prijava detaljno provjerava i odobrava ili ne odobrava na temelju opisa aplikacije.

Za korištenje Flickr API-ja najvažnije je poznavati:

• autentikaciju korisnika,

• formate zahtjeva i dogovora i

• postupak slanja fotografija.

Autentikacija korisnika

Vrlo važan dio API-ja je autentikacija. Mnoštvo metoda koristi privatne podatke korisnika i

nužno je da se nedvosmisleno utvrdi identitet korisnika. Postoje načini autentikacije za:

• web aplikacije,

• desktop aplikacije i

• mobilne aplikacije.

Detaljnije će biti opisan treći način – autentikacija za mobilne aplikacije.

Prvi korak je posjedovanje aplikacijskog ključa koji se mora ispravno konfigurirati. Obavezna

polja su naziv i opis aplikacije, a neobavezna polaj su logo i URL aplikacije. Navedene

informacije će se prikazati korisniku kada aplikacija zatraži pristup njihovim privatnim

podacima. Sljedeće je potrebno izabrati Mobile Application kao način autentikacije te odabrati

dozvole koje će aplikacija posjedovati. Tri su mogućnosti:

• read – aplikaciji se omogućava jedino čitanje podataka, npr. preuzimanje

fotografija ili informacija o vlasniku ili fotografijama,

• write – aplikaciji se dodatno omogućava i pisanje podataka, npr. postavljanje

fotografija, promjenu imena vlasnika itd.,

• delete – aplikaciji se dodatno omogućava i brisanje podataka.

Nakon ispravne konfiguracije dobije se tzv. autentikacijski URL koji je oblika

http://www.flickr.com/auth-123456.

Aplikacija bi trebala prikazati korisniku dobiveni autentikacijski URL te ga zatražiti da ga

posjeti. Korisniku će se tada u pregledniku pojaviti zahtjev kojim se traži pristup njegovim

privatnim podacima. Ako korisnik pristane prikazat će mu se deveteroznamenkasti broj koji

se u Flickr terminologiji naziva mini-token, a izgleda primjerice ovako: 123-456-789.

Prikazani mini-token korisnik treba unesti u za to predviđeno polje u aplikaciji i tu prestaje

njegov angažman oko autorizacije.

Mini-token služi samo za jednokratno dobivanje trajnog tokena koji se dalje koristi za

autentikaciju pri pozivu metoda. Trajni token se dobiva pozivom metode

flickr.auth.getFullToken koja zahtijeva potpis. Način generiranja potpisa je definiran, a

zahtijeva aplikacijski ključ, dijeljenu tajnu (shared secret) dobivenu zajedno s aplikacijskim

ključem i token. U slučaju getFullToken metode mjesto tokena koristi se mini-token.

Prvi korak u generiranju potpisa je da se svi argumenti abecedno poredaju. Pretpostavimo da

aplikacijski ključ ima vrijednost 9a0554259914a86fb9e7eb014e4e5d52, dijeljena tajna

000005fab4534d05, a mini-token 123-456-789. Poredani argumenti će izgledati ovako:

• method = flickr.auth.getFullToken,

• api_key = 9a0554259914a86fb9e7eb014e4e5d52 i

• mini_token = 123-456-789.

Od tako poredanih argumenata se napravi niz ispred kojeg se stavi dijeljena tajna. Takav niz

bi trebao izgledati ovako:

000005fab4534d05api_key9a0554259914a86fb9e7eb014e4e5d52methodflickr.au

th.getFullTokenmini_token123-456-789

Potpis se dobije generiranjem MD5 sume ovog niza znakova i predstavlja novi argument kod

poziva metode koji se dodaje na kraj liste argumenata koja onda izgleda ovako:

• method = flickr.auth.getFullToken,

• api_key = 9a0554259914a86fb9e7eb014e4e5d52,

• mini_token = 123-456-789 i

• api_sig = fddd34ac63af89b1b73b144aef8ef3d5.

Ako se ispravno generira potpis i navedu argumenti odgovor na getFullToken metodu će biti

sljedećeg oblika:

45-76598454353455

read

Aplikacija bi trebala trajno sačuvati dobiveni token jer se on koristi pri svakom slijedećem

pozivu metode koja zahtjeva autentikaciju. Primjerice, ako želimo pozvati metodu

flickr.favorites.getList lista argumenata za generiranje potpisa će izgledati ovako:

• method = flickr.favorites.getList,

• api_key = 9a0554259914a86fb9e7eb014e4e5d52 i

• auth_token = 45-76598454353455.

Daljnji postupak generiranja potpisa je isti kao u prethodnom slučaju.

Formati zahtjeva i odgovora

Flickr API omogućava više različitih formata zahtjeva i odgovora osiguravajući priključne

točke za svaki od njih, a to su:

• REST (Representational State Transfer),

• XML-RPC (XML - Remote Procedure Calling) i

• SOAP (Simple Object Access Protocol).

Formati odgovora su predefirano isti oni u kojima je bio prenešen zahtjev, no omogućen je i

proizvoljan izbor preko parametra format koji se u tom slučaju treba uključiti u popis

argumenata. Formati odgovora na raspolaganju za korištenje osim gore navedenih su:

• JSON (JavaScript Object Notation) ili

• PHP.

Format REST je najjednostavniji za uporabu pa je dobar primjer toga kako izgledaju i kako se

upućuju zahtjevi prema Flickr API-ju i kako izgledaju odgovori na njih.

REST zahtjev je zapravo obični HTTP GET ili POST zahtjev. Primjerice, URL zahtjeva bi

izgledao ovako za metodu flickr.test.echo:

http://api.flickr.com/services/rest/?method=flickr.test.echo&parameter=value.

Iz URL-a se vidi da je priključna točka za REST zahtjeve na adresi

http://api.flickr.com/services/rest/.

REST odgovor je XML dokument koji u slučaju ispravnog poziva metode izgleda ovako:

[xml-payload-here]

Ako se dogodi pogreška odgovor će izgledati ovako:

Postupak slanja fotografija

Slanje fotografija na Flickr je specifično jer se šalju i binarni podaci osim argumenata. Sve

fotografije se preko HTTP POST zahtjeva šalju na istu pristupnu točku s URL-om:

http://api.flickr.com/services/upload/. Metoda zahtjeva autenticiranje s dozvolom za pisanje.

U nastavku su navedeni parametri metode. S iznimkom parametra photo svi ostali su

opcionalni i ako su odabrani koriste se pri generiranju potpisa. Argumenti su sljedeći:

• photo – fotografija koja se šalje,

• title – naziv fotografije,

• description – opis fotografije,

• tags – popis oznaka odvojenih zarezom,

• is_public, is_friend, is_family – koriste se za određivanje tko smije vidjeti

fotografije, vrijednosti 0 za ne i 1 za da,

• safety_level – 1 za siguran, 2 za umjereno siguran i 3 za ograničen pristup,

• content_type – 1 za fotografiju, 2 za screenshot i 3 za ostalo i

• hidden – 1 da se može pretraživati, 2 da se ne može.

Primjer jednog POST zahtjeva kojim se šalje na Flickr slika test.jpg pohranjena na disku na

izgleda ovako:

POST /services/upload/ HTTP/1.1

Content-Type: multipart/form-data; boundary=---------------------------7d44e178b0434

Host: api.flickr.com

Content-Length: 35261

-----------------------------7d44e178b0434

Content-Disposition: form-data; name="api_key"

3632623532453245

-----------------------------7d44e178b0434

Content-Disposition: form-data; name="auth_token"

436436545

-----------------------------7d44e178b0434

Content-Disposition: form-data; name="api_sig"

43732850932746573245

-----------------------------7d44e178b0434

Content-Disposition: form-data; name="photo"; filename="C:\test.jpg"

Content-Type: image/jpeg

{RAW JFIF DATA}

-----------------------------7d44e178b0434--

Dodavanje nekog od opcionalnih parametra se vrši umetanjem slijedećeg koda unutar

zaglavlja POST zahtjeva:

Content-Disposition: form-data; name="ime_parametra"

vrijednost_parametra

Važno je pripaziti da je boundary ispravno izgeneriran (na slučajan način) i da se ne

pojavljuje unutar poslanih podataka, da se za kraj linije koristi '\r\n' i da podaci fotografije

budu zapisani odnosno poslani u čistom (raw) formatu.

Ako je fotografija uspješno poslana poslužitelj će vratiti identifikator fotografije zapisan

pomoću XML-a u tijelu RESP odgovora:

1234

U slučaju pogreške, vratit će se RESP odgovor s kodom pogreške.

4.2. Programsko sučelje Google Static Maps

Programsko sučelje Google Static Maps omogućava korištenje Googleovih karata kada nije

moguće koristiti JavaScript ili neki drugi način dinamičkog učitavanja. API se poziva preko

standardnog HTTP zahtjeva navodeći određene parametre na temelju kojih se izgenerira karta

i koja se u obliku slike vraća pozivatelju API-ja. Preduvjet za korištenje API-ja je

posjedovanje aplikacijskog ključa kojim Google prati promet pojedinog korisnika. Svaki

korisnik može najviše 1000 puta zatražiti kartu unutar 24 sata.

Zahtjev upućen API-ju mora biti sljedećeg oblika:

http://maps.google.com/staticmap?parameters

API propisuje sljedeće parametre:

• center (obavezan ako nema oznaka) – definira središnju točku karte pomoću

zarezom odvojenih geografskih koordinata,

• zoom (obavezan ako nema oznaka) – vrijednost od 0 do 19, redom od najmanje

detaljne do najdetaljnije karte,

• size (obavezan) – željena veličina karte u pikselima (x, y),

• format (neobavezan) – format slike, može biti JPEG, PNG ili ako se ne navede

parametar GIF,

• maptype (neobavezan) – vrsta karte, moguće je izabrati karte prilagođene za prikaz

na pokretnim telefonima (mobile), satelitske (satellite), terenske (terrain) karte ili

kombinaciju prikaza (hybrid),

• markers (neobavezan) – popis lokacija koje se žele označiti na karti,

• path (neobavezan) – navode se koordinate točaka koje se na karti žele spojiti

linijom,

• span (neobavezan) – pomoću koordinata dviju točaka definira se pravokutnik

zemljine površine koji se želi prikazati,

• frame (neobavezan) – služi za uokviravanje slike plavim obrubom,

• h1 (neobavezan) – služi za odabir jezika za prikaz natpisa na karti,

• key (obavezan) – aplikacijski ključ i

• senzor (obavezan) – ako se koristi uređaj koji može služiti kao senzor obavezno je

staviti parametar na true, inače je false.

4.3. Implementacija

Preduvjet za korištenje većine mogućnosti usluge je točna lokacija na kojoj se korisnik nalazi.

Stoga će prvo biti pojašnjen način dobivanja lokacije putem SIP-a jer u njemu osim klijentske

aplikacije sudjeluje i poslužitelj, a nakon toga i način dobivanja lokacije putem GPS. Potom

će detaljnije biti opisana implementacija klijentske aplikacije.

Dohvaćanje lokacije putem protokola SIP

Slijedni dijagram na Sl. 4.2 prikazuje izmjenu poruka između pojedinih entiteta.

Sl. 4.2 Slijedni dijagram SIP komunikacije

Komunikacija među entitetima realiziranim u usluzi zasniva se tek na malom podskupu

mogućnosti protokola SIP. Zbog jednostavnosti usluge nije bilo potrebno koristiti ništa osim

zahtjeva MESSAGE i SUBSCRIBE, obrade zahtjeva NOTIFY poslanih od strane IMS Location

Servera te slanja i primanja odgovora. Sljedeći primjeri poruka koje se šalju će pojasniti kako

je realizirana komunikacija.

Upit klijentske aplikacije za lokacijom se prenosi SIP-ovim zahtjevom tipa MESSAGE:

MESSAGE sip:127.0.0.1:6080 SIP/2.0

Content-Length: 0

From: ;tag=1982152035

Max-Forwards: 70

Cseq: 1 MESSAGE

Event: geolocation

To:

Content-Type: text/plain

Via: SIP/2.0/UDP

192.168.1.2:5060;branch=z9hG4bKebf8eb1d4eeabb1cdcd2a96f0db5820f;receiv

ed=127.0.0.1

Call-Id: 78196c28baa627397d234a03753634b6@192.168.1.2

Zahtjev se šalje poslužitelju SailFin koji se nalazi na adresi 127.0.0.1:6080 i na kojem se

izvršava SIP aplikacija koja obrađuje zahtjeve što se vidi iz prve linije zahtjeva. Da bi

poslužiteljska aplikacija znala da se radi o zahtjevu za lokacijom postavlja se polje zaglavlja

Event na ključnu riječ geolocation. Osim toga, vrlo je bitno i polje From koje sadrži

korisnikov SIP URI na temelju kojeg će se pronaći njegova lokacija posredstvom ILS-a.

Kada zahtjev dođe do poslužitelja, on prepoznaje da se radi o zahtjevu za lokacijom korisnika,

te konstruira novi SIP-ov zahtjev tipa SUBSCRIBE koji se šalje ILS-u. Taj zahtjev također

ima polje Event postavljeno na geolocation da bi ILS mogao prepoznati kao zahtjev za

lokacijom. Nakon što je prepoznao zahtjev, treba mu i korisnikov SIP URI na temelju kojeg

će pronaći njegovu lokaciju, a koji se mora nalaziti u polju To zaglavlja SUBSCRIBE poruke.

Zahtjev izgleda ovako:

SUBSCRIBE sip:127.0.0.1:6090 SIP/2.0

Max-Forwards: 70

From: ;tag=fsuck844-1

Expires: 0

Cseq: 1 SUBSCRIBE

Contact:

Event: geolocation

To:

Call-Id: 5.28.254.69_1_5472694183377990708

Kako je navedeno u poglavlju o ILS-u, polje Expire se postavlja na vrijednost 0, jer se tako

lokaciju korisniku dostavlja samo jednom.

ILS nakon SUBSCRIBE zahtjeva šalje dvije NOTIFY poruke kao što se može vidjeti u

slijednom dijagramu. Prva NOTIFY poruka sadrži pending status jer ILS prvo provjerava

postoji li korisnik s navedenim URI-jem i traži njegovu lokaciju. Poruka izgleda ovako:

NOTIFY sip:5.28.254.69:6080;fid=server_1 SIP/2.0

Content-Length: 0

Max-Forwards: 69

From: ;tag=643a35df

Expires: 0

Cseq: 1 NOTIFY

Contact: "Location Server"

Event: geolocation

To: ;tag=fsuck844-1

Subscription-State: Pending

Call-Id: 5.28.254.69_1_5472694183377990708

Via: SIP/2.0/UDP

127.0.0.1:6090;branch=z9hG4bK9772bd67897c4b15ba21005490a6a4c2

Nakon što nađe lokaciju korisnika šalje drugu NOTIFY poruku u kojoj se nalaze podaci o

lokaciji korisnika zapisani u PIDF odnosno GML formatu.

NOTIFY sip:5.28.254.69:6080;fid=server_1 SIP/2.0

Content-Length: 499

Max-Forwards: 69

From: ;tag=643a35df

Expires: 0

Cseq: 2 NOTIFY

Contact: "Location Server"

Event: geolocation

To: ;tag=fsuck844-1

Content-Type: application/pidf+xml

Subscription-State: terminated;reason=expired

Call-Id: 5.28.254.69_1_5472694183377990708

Via: SIP/2.0/UDP

127.0.0.1:6090;branch=z9hG4bKb4b47f0eb0eb144c6f96c00f75d38675

45.802499999999995

15.9425manual

Iz gore navedenog primjera druge poruke NOTIFY može se vidjeti kako se prenose

informacije o lokaciji. Geografske koordinate korisnika nalaze se unutar taga .

Poslužitelj izvlači podatke o lokaciji iz primljenog zahtjeva te konstruira odgovor koji sadrži

te podatke i koji se šalje na adresu korisnika. Kako taj odgovor izgleda vidi se iz sljedećeg:

SIP/2.0 200 OK

From: ;tag=629134088

Cseq: 1 MESSAGE

Longitude: 15.9425

To:

Server: Glassfish_SIP_1.0.0

Latitude: 45.802499999999995

Call-Id: e10ee021ef75202baa3116618ad650fa@192.168.1.2

Via: SIP/2.0/UDP

192.168.1.2:5060;branch=z9hG4bK5c3cdbc865fb28e17e0b705af9999c31;receiv

ed=127.0.0.1

Dohvaćanje lokacije putem GPS-a

Dohvaćanje lokacije putem GPS-a je realizirano korištenjem Location API-ja definiranog u

JSR-179. Location API je opcionalni paket (javax.microedition.location) koji omogućuje

dohvaćanje lokacije putem bilo koje osnovne metode dohvaćanja lokacija, a koje su navedene

u poglavlju 1.1 ovog rada.

Osnovno ograničenje u izboru metoda dohvaćanja lokacije su same mogućnosti mobilnog

uređaja na kojima se aplikacija izvodi. Ograničenja je moguće provesti i aplikacijski navodeći

kriterije koje metoda mora zadovoljavati poput preciznosti, vremena odziva, potrebom za

određivanjem brzine ili visine i dr.

Pošto za aplikaciju realiziranu u radu gore navedeno nije bilo nužno, kreiranje kriterija je vrlo

jednostavno:

Criteria criteria = new Criteria();

Aplikacija tada dohvaća instancu LocationProvidera koja sadrži podatke tražene u kriteriju:

LocationProvider provider = LocationProvider.getInstance( criteria );

Vrijeme čekanja na lokaciju (10 s) se ograničava na sljedeći način:

Location location = provider.getLocation( 10 );

Zadnji korak je dohvaćanje koordinata trenutne lokacije:

Coordinates coordinates = location.getQualifiedCoordinates();

double latitude = coordinates.getLatitude();

double longitude = coordinates.getLongitude();

Klijentska aplikacija – paketi i klase

Klijentska aplikacija se sastoji od sljedećih paketa i klasa:

• hr.fer.tel.diplomski.flickloc.display – klase zadužene za prikaz:

o ConnectionForm – izbor konekcija (SIP/GPS) te upis SIP podataka,

o DisplayForm – postavke prikaza, izbor tipa karte te postavljanje broja slika,

o DisplayPhotoList – odabir mogućnosti prikaza fotografija,

o FlickrForm – upis tokena za autentikaciju,

o InfoForm – forma koja prikazuje uvećanu fotografiju s detaljima o njoj,

o InitialList – početni izbornik (snimanje nove fotografije, pregled te postavke),

o InputPhotoData – forma za unos podataka o snimljenoj fotografiji,

o MapCanvas – zaslon na kojem se prikazuju Googleove karte,

o PhotoCanvas – zaslon na kojem se vidi ono što prikazuje kamera uređaja,

o PhotoForm – forma za pokretanje kamere te prikaz snimljene fotografije,

o SettingsList – izbornik postavki,

o TagForm – forma za unos oznaka za pretraživanje fotografije te podatke o

adresi lokacije u čijoj blizini se žele pregledati fotografije,

• hr.fer.tel.diplomski.flickloc.main

o FlicLoc – glavna klasa koja nasljeđuje MIDlet i sadrži metode za postavljanje

oznaka temeljene na informacijama o fotografijama,

• hr.fer.tel.diplomski.flickloc.properties – klase koje služe za opis fotografija:

o ImageMarker – sadrži fotografije i podatke o oznakama te posjeduje metode za

dohvat fotografija,

o ImageProperties – sadrži informacije o fotografiji poput vlasnika, lokacije,

tipa fotografije, oznaka, opisa, URL-a itd.,

o MapProperties – opisuje kartu (visina, širina, središnja točka, razina uvećanja i

dr.) i stanje u kojem se trenutno nalazi (početno, odabran prikaz fotografije);

o SIPProperties – predefinirane vrijednosti SIP postavki,

• hr.fer.tel.diplomski.flickloc.util – klase u kojima su implementirane osnovne

funkcionalnosti koje aplikacija koristi:

o FileConnector – sadrži metode za spremanje, učitavanje te brisanje datoteka,

o FlickrManager – sadrži metode za komunikaciju s Flickrom (autentikacija,

slanje fotografija, dohvaćanje fotografija, pretragu i dr.),

o GoogleMaps – sadrži metode za dohvaćanje Googleovih karata te ostalu

komunikaciju s Googleom (lokacijsko kodiranje),

o GPSLocationEnabler – dohvaća lokaciju preko GPS-a,

o HTTPConnector – sadrži metode za konstruiranje i slanje zahtjeva GET i

POST,

o ImageUtil – sadrži metodu za kreiranje umanjenih slika,

o MD5 – služi za generiranje MD5 sažetka poruke,

o RecordManager – sadrži metode za pohranu, brisanje i dohvaćanje podatka iz

RMS baze podataka i

o SIPLocationEnabler – služi za dohvaćanje lokacije preko protokola SIP.

Klijentska aplikacija – način rada

Rad aplikacije će radi jednostavnosti biti objašnjen kroz sljedeće slučajeve uporabe u kojima

se koristi većina osnovnih operacija od kojih su sačinjene funkcionalnosti koje aplikacija

nudi:

1. korisnik se preko aplikacije autenticira s Flickrom, snimi fotografiju te je pošalje na

Flickr i sačuva lokalno u memoriju mobilnog uređaja,

2. korisnik izabere pregledavanje fotografija koje su snimljene u njegovoj blizini,

odabere jednu te ju sačuva.

Napomena: detaljniji opis uporabe će biti naveden u sljedećem poglavlju dok će se u ovom

naglasak staviti na tehničku stranu rada aplikacije.

1. Da bi se autenticirao korisnik treba otvoriti Flickr postavke. Kad uđe u njih pojavi se URL

koji mora posjetiti i preko kojeg dobije mini-token koji se upiše kao na Sl. 4.3.

Sl. 4.3 Postavke Flickr računa

Nakon spremanja postavki preko FlickrManagera se šalje zahtjev za autentikacijom:

GET/services/rest/?method=flickr.auth.getFullToken&api_key=b8d84838dd0

342b92ecb89141dd17050&mini_token=217-812-

334&api_sig=024572c208b4b200ae99fb3ae546a689

HTTP/1.1\r\n

Odgovor s Flickra u formatu RESP glasi ovako:

72157620145514165-b9e0603bb75c7581

delete

Odgovor se parsira te se u lokalnu bazu podataka pohrani korisničko ime i token koji će se

koristi pri pozivima metoda Flickr API-ja koje zahtijevaju autentikaciju. Koristi se RMS

(Record Management System) kao lokalna baza kojoj se pristupa preko RecordManagera.

Kad je obavio autenticiranje korisnik može snimiti fotografiju i poslati ju na Flickr. Nakon

izbora snimanja nove fotografije korisniku se prikazuje zaslon (PhotoCanvas) na kojem je

prikazano ono što kamera u tom trenutku „vidi“. Snimanje fotografija je omogućeno

korištenjem Mobile Media API-ja (MMAPI) definiranog specifikacijom JSR-135. MMAPI

osim fotografija ima podršku za video i zvuk. Uporaba kamere je relativno jednostavna. Prvi

korak je instanciranje playera:

mPlayer = Manager.createPlayer("capture://video");

Da bi player mogao koristi podatke kamere nužna je sljedeća linija:

mPlayer.realize();

Video dobiven preko kamere se može prikazati na objektu tipa Form ili tipa Cavnas kao na

Sl. 4.4. Da bi to bilo moguće potrebno je dohvatiti objekt tipa VideoControl kojim se upravlja

kamerom te ga inicijalizirati, postaviti parametre prikaza te ga učiniti vidljivim.

videoControl = (VideoControl) mPlayer.getControl("VideoControl");

videoControl.initDisplayMode(VideoControl.USE_DIRECT_VIDEO, this);

videoControl.setDisplayLocation( xPos, yPos );

videoControl.setDisplaySize( width, height);

videoControl.setVisible( true );

Slikanje fotografije u JPEG formatu se odvija na sljedeći način:

byte[] raw = mVideoControl.getSnapshot( "encoding=jpeg" );

Sl. 4.4 Prikaz kamere

Nakon snimanja fotografije otvara se forma za unos podataka kao što je prikazano na Sl. 4.5.

Sl. 4.5 Forma za unos podataka o fotografiji

Kad korisnik odabere da se slika pošalje i sačuva pokrenut će se GPSLocationEnabler ili

SIPLocationEnabler (ovisno je li u postavkama odabran SIP ili GPS) koji će dohvatiti

lokaciju. Lokacija će se pridodati unesenim oznakama sa strane korisnika i to na način da

bude u formatu strojnih oznaka:

tags += " geotagged geo:lat=" + latitude.substring( 0, 9 ) + "

geo:lon=" + longitude.substring( 0, 9 );

Fotografija se zajedno s podacima o njoj predaje FlickManageru koji će je poslati na Flickr.

Zahtjev tipa POST se konstruira pomoću HTTPConnectora. Polje zaglavlja Content-Type

mora biti postavljeno na vrijednost multipart/form-data. Tijelo poruke izgleda ovako: