Agregátor geolokačních služeb - Ondřej Machulda

electricianpathInternet και Εφαρμογές Web

13 Δεκ 2013 (πριν από 3 χρόνια και 8 μήνες)

247 εμφανίσεις

České vysoké učení technické v Praze
Fakulta elektrotechnická
Katedra počítačů
Bakalářská práce
Agregátor geolokačních sociálních sítí
Ondřej Machulda
Vedoucí práce:Ing.Ondřej Macek
Studijní program:Softwarové technologie a management,Bakalářský
Obor:Softwarové inženýrství
5.ledna 2012
iv
v
Poděkování
Rád bych vřele poděkoval Ing.Ondřeji Mackovi za to,že se ujmul vedení mé bakalářské
práce a za rady a pomoc v průběhu realizace aplikace i během psaní práce.Veliký dík také
náleží mým přátelům a kamarádům Kateřině Kebzové,Janu Kryšpínovi,Adamu Kudrnovi,
Mgr.et Mgr.Ivaně Macháčkové a Bc.Radku Ondrouškovi,kteří mi pomáhali s testováním
a připomínkováním aplikace či korekturou textu bakalářské práce.
vi
vii
Prohlášení
Prohlašuji,že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené
v přiloženém seznamu.
Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č.121/2000
Sb.,o právu autorském,o právech souvisejících s právem autorským a o změně některých
zákonů (autorský zákon).
Ve Zdibech dne 5.1.2012.............................................................
viii
Abstract
In connection with the expansion of mobile devices with the Internet connection availability
and the ability to determine their own position,a number of services using this features were
founded – so called „location based services“.Some of these services enable users to search
in different places in their vicinity,to establish „check-in“ there,enabling then sharing with
other friends.
Aggregator of geolocation based social networks combines similar functionality of services
Foursquare,Gowalla,Facebook and Google Places into one web application – offering a single
search in the databases of places across these services including merging the same places from
different services and aggregation of some of the social features:check-in to multiple services
at once or retrieving the last position of friends using these services.
Abstrakt
V souvislosti s rozšířením mobilních zařízení disponujících připojením k Internetu a schop-
ností určení vlastní polohy vznikla v posledních letech řada služeb,využívajících tuto fun-
kcionalitu – tzv.geolokační služby.Část těchto služeb umožňuje uživatelům vyhledávat ve
svém okolí různá místa (body zájmu) a provádět v nich „check-in“ (ohlášení),které je pak
možno sdílet s dalšími přáteli.
Agregátor geolokačních sociálních sítí slučuje obdobnou funkcionalitu služeb Foursquare,
Gowalla,Facebook a Google Places do jedné webové aplikace – nabízí možnost jednot-
ného vyhledávání v databázích míst napříč těmito službami včetně slučování stejných míst z
různých služeb a také agregaci některých sociálních vlastností jednotlivých služeb:provedení
hromadného check-inu a načtení poslední polohy přátel.
ix
x
Obsah
1 Úvod 1
1.1 Kontext a motivace výběru tématu........................1
1.2 Cíle práce......................................2
1.3 Podobná existující řešení..............................3
1.3.1 Look4square.................................3
1.3.2 4sqmap...................................4
1.3.3 Fourwhere..................................4
1.3.4 Footfeed...................................4
2 Analýza 5
2.1 Funkční požadavky.................................5
2.1.1 Zobrazení POI na mapě..........................5
2.1.2 Detailní informace o POI.........................6
2.1.3 Sociální funkce...............................6
2.2 Nefunkční požadavky................................6
2.3 Další požadavky ze zadání.............................7
2.4 Případy užití....................................7
2.4.1 Aktéři....................................7
2.4.2 Use case...................................7
2.5 Matice funkčních požadavků a use case......................10
3 Použité technologie 11
3.1 PHP & Zend Framework..............................11
3.2 Javascript & jQuery................................12
3.2.1 jQuery UI..................................12
3.2.2 jQuery pluginy...............................13
3.3 Google Maps API..................................14
3.4 Google Geocoding API...............................18
3.5 OAuth........................................18
3.5.1 OAuth vs.Open ID............................19
3.5.2 Proces autorizace pomocí OAuth.....................19
4 Geolokační služby a jejich API 23
4.1 Foursquare.....................................23
4.2 Gowalla.......................................29
xi
xii OBSAH
4.3 Facebook......................................33
4.4 Google Places....................................37
5 Realizace 41
5.1 Architektura a struktura aplikace.........................41
5.1.1 Models....................................41
5.1.2 Controllers.................................42
5.1.3 Views....................................44
5.2 Implementace a její specifické části........................45
5.2.1 AJAX....................................45
5.2.2 Adapter a Wrapper LBS..........................45
5.2.3 Konfigurace použitých LBS a priorizace dat z nich...........46
5.2.4 Model agregovaného POI.........................46
5.2.5 Slučování podobných bodů........................47
5.2.6 OAuth autorizace..............................48
5.2.7 Vyhledávací formulář............................49
5.2.8 Vyhledávání POI..............................49
5.2.9 Určení kvality POI.............................50
5.2.10 Zobrazení mapy...............................50
5.2.11 Načítání fotografií v detailu POI.....................51
5.2.12 Možnost odebrání bodů ze sloučeného POI...............51
5.3 Nasazení aplikace..................................52
6 Testování 53
6.1 Unit testy......................................53
6.2 Uživatelské testování................................54
7 Závěr 55
7.1 Známé problémy..................................55
7.2 Další pokračování & možná rozšíření aplikace..................55
7.2.1 Přizpůsobení licencím...........................55
7.2.2 Algoritmus slučování POI.........................56
7.2.3 Algoritmus slučování přátel........................56
7.2.4 Využití cachování..............................56
7.2.5 Mobilní aplikace/mobilní web......................56
7.2.6 Priorizace jednotlivých parametrů POI..................57
7.3 Zhodnocení splnění cílů práce...........................57
Literatura 60
A Seznam použitých zkratek 61
B Instalační příručka 63
OBSAH xiii
C Uživatelská příručka 65
C.1 Hlavní stránka...................................65
C.2 Informační okno bodu v mapě...........................67
C.3 Detail bodu.....................................67
C.4 Poslední check-iny přátel..............................68
D Ukázka struktury JSON 71
D.1 Foursquare.....................................71
D.1.1 Vyhledání nejbližších venues........................71
D.2 Gowalla.......................................73
D.2.1 Vyhledání nejbližších spots........................73
D.3 Facebook......................................75
D.3.1 Vyhledání nejbližších objektů.......................75
D.3.2 Načtení jednoho objektu..........................75
D.4 Google Places....................................77
D.4.1 Vyhledání nejbližších míst.........................77
D.4.2 Načtení jednoho místa...........................78
E Obsah přiloženého CD 79
xiv OBSAH
Seznam obrázků
1.1 Služba Look4square................................3
1.2 Služba 4sqmap...................................4
3.1 Tipsy plugin – zobrazení větší náhledové fotografie...............14
3.2 bxSlider plugin – možnost postupného posouvání mezi více fotografiemi....14
3.3 Marker a otevřené info window..........................17
3.4 Ukázka použití knihovny MarkerWithLabel...................17
3.5 Automatické dokončování adresy.........................18
3.6 Sekvenční diagram OAuth autorizace.......................20
4.1 Model části Foursquare API endpointů......................26
5.1 Diagram modelů LBS služeb............................42
5.2 Diagram datových modelů.............................43
5.3 Diagram controllerů................................44
5.4 Reverzní geocoding v detailu POI.........................47
5.5 Ukázka sloučených bodů..............................48
5.6 Možnost odebrání chybně sloučeného POI....................52
6.1 Code coverage....................................54
C.1 Hlavní stránka aplikace...............................65
C.2 Otevřené informační okno bodu v mapě.....................67
C.3 Zobrazení detailu bodu...............................68
C.4 Zobrazení posledních check-inů přátel.......................69
xv
xvi SEZNAM OBRÁZKŮ
Seznam tabulek
2.1 Matice funkčních požadavků a use case......................10
xvii
xviii SEZNAM TABULEK
Kapitola 1
Úvod
1.1 Kontext a motivace výběru tématu
Geolokační služby (angl.LBS – location-based services) jsou všechny takové služby,které
pracují s geografickou polohou nějaké entity [29] – tyto služby se obecně dělí na location-
tracking (sledující polohu) a location-aware (se znalostí aktuální polohy) [26].Jako jednoduchý
příklad location-tracking LBS služby lze uvést např.vyhledávání polohy balíků při zásilkové
přepravě.
Location-aware jsou pak služby,které na základě aktuální polohy (geolokace) uživatele
zjistí nějaký druh informací o jeho okolí a umožní uživateli s těmito informacemi dále pra-
covat.I zde lze uvést jednoduchý příklad:vyhledávání objektů na mapě – prostřednictvím
mapové aplikace na „chytrém mobilním telefonu“ (smartphone) mohou uživatelé zobrazit a
vyhledávat místa ve svém okolí – restaurace,firmy,divadla aj.
A právě v souvislosti s rozšířením přenosných zařízení s připojením k Internetu a schop-
ností určení vlastní polohy dochází v posledních letech ke vzniku celé řady location-aware
geolokačních služeb,využívajících právě tyto vlastnosti.Mnoho takových služeb pak přidává
také sociální rozměr – nejen,že umožňují uživateli pracovat s jeho aktuální polohou,ale
nějakým způsobem pracují i s polohou dalších uživatelů této služby („přátel“).
Za nejvýznamnější [25,28] službu tohoto druhu lze označit Foursquare [6] – prostřed-
nictvím aplikace či webu určeného pro mobilní telefony umožňuje uživatelům vyhledat místa
(objekty) v okolí a v místě kde se uživatel nachází provést check-in („ohlášení“).Poslední
check-in je pak zobrazen v rámci přátel (kontaktů) daného uživatele na této službě – ostatní
tak mohou vidět,na jakém místě či v jakém objektu se tento uživatel nachází.Služba je také
obohacena o různé gamifikační
1
prvky (body,odznáčky,žebříčky...).Uživatelé mají rovněž
možnost k jednotlivým místům přidávat tipy (doporučení) a fotografie,které mohou zase
využít jiní uživatelé.Další podrobnosti o této službě popisuje kapitola 4.1.
Podobnou službou je Gowalla [15].Rovněž je zčásti založena na sdílení check-inů mezi
přáteli a zčásti na informacích navázaných na konkrétní místa (fotografie,tipy aj.).I Gowalla
poskytuje aplikace pro mobilní telefony;check-iny přátel a jednotlivá místa lze také jako
1
Gamifikace je obohacení základní funkcionality neherních aplikací o různé herní prvky za účelem vyššího
zapojení uživatelů do používání aplikace – viz [27].
1
2 KAPITOLA 1.ÚVOD
u Foursquare prohlížet pomocí webu.Avšak check-iny je třeba provádět jedině pomocí ap-
likace;mobilní web není k dispozici.Více o službě Gowalla uvádí kapitola 4.2.
Facebook Places [3] je svým způsobem doplněk k základní funkcionalitě Facebooku.
Stránky (Pages) a další objekty na Facebooku mohou mít zadanou adresu (a od toho
odvozenou polohu);uživatelé pak mají možnost buďto prostřednictvím aplikace Facebook
pro mobilní telefony nebo prostřednictvím webu připojit ke svému „statusu“ informaci,že
se právě v tomto místě nacházejí (čímž zde fakticky také provedou check-in).Dále službu
Facebook Places popisuje kapitola 4.3.
Google Places [9] je primárně databáze míst,kterou Google mj.využívá v rámci svých
map (ať již webových nebo mobilních).Check-in v těchto místech provedený aplikací Google
Maps lze sdílet v rámci služeb Google Latitude či Google+,žádné gamifikační prvky však
nejsou přítomny.Služba Google Places je podrobně rozebrána v kapitole 4.4.
K dalším službám podobného typu patří například:
 SCVNGR
2
– primárně herní platforma pro mobilní telefony;rozšířená téměř výhradně
v USA.Uživatelé provádí check-iny a další úkoly v jednotlivých místech za účelemzisku
bodů a odznáčků.Databáze míst je však čerpána primárně z Google Places.
 TripAdvisor
3
– celosvětově rozšířená služba zaměřená primárně na cestovatele;ob-
sahuje uživatelské recenze,doporučení a hodnocení míst jako hotely,restaurace,kul-
turní a přírodní památky aj.
 Yelp
4
– rovněž jako SCVNGR takřka pouze v USA rozšířená služba na vyhledávání
a recenze podniků (restaurace,obchody apod.).
Průnikem funkcionality jednotlivých služeb je tak databáze míst s polohou – POI (angl.
Point Of Interest).Každá z těchto služeb však obvykle udržuje vlastní databázi POI –
důsledkem je,že se informace vážící k tomu samému fyzickému místu (objektu,podniku
aj.) mohou nacházet odděleně ve více službách.
Dalším společným prvkem služeb jsou často sociální funkce – check-iny a jejich sdílení
mezi přáteli v rámci příslušné sociální sítě.I tyto informace jsou ale napříč službami oddělené.
1.2 Cíle práce
Cílem práce je vytvořit agregátor nejvýznamnějších geolokačních služeb pracujících s místy
zájmu (POI) – Foursquare,Gowalla,Facebook a Google Places.
Funkcionalitu by měly tvořit dvě oblasti:
 Agregace databází míst – načítání POI z jednotlivých služeb vážících se k okolí
určených souřadnic;v případě,že mezi POI z jednotlivých služeb budou takové,které
reprezentují ten samý objekt,pak bod sloučit do jednoho;načtení kompletních infor-
mací o daném bodu (či bodu sloučeném z více jednotlivých).
2
<http://scvngr.com/>
3
<http://www.tripadvisor.com/>
4
<http://www.yelp.com/>
1.3.PODOBNÁ EXISTUJÍCÍ ŘEŠENÍ 3
 Agregace sociálních služeb – hromadný check-in ve více službách najednou;načtení
polohy posledního check-inu přátel z každé služby.
Přínosem výsledné aplikace by tak pro uživatele mělo být rozšíření databáze míst při
hledání díky kombinací více databází najednou,zjištění širších detailů o jednom POI v
případě bodu sloučeného z více služeb,možnost pohodlnější interakce se sociálními službami
prostřednictvím hromadného check-inu a možnosti zjištění poslední polohy přátel z více
sociálních sítí – například pokud různí přátelé používají pro sdílení check-inů jinou službu,
nebude třeba kontrolovat každou službu zvlášť.
1.3 Podobná existující řešení
Na Internetu se dá najít značné množství služeb či aplikací pro mobilní telefony,které jsou v
některém směru podobné plánované aplikaci.Avšak zpravidla jsou zaměřeny pouze na jednu
službu,či integrují pouze jednu úzkou oblast funkcionality napříč službami.Následuje popis
několika existujících služeb podobných plánované aplikaci.
1.3.1 Look4square
Jednoduchá služba Look4square [18] od českého autora Martina Hasmanna vznikla začátkem
roku 2010.Jak název napovídá,je zaměřena pouze na Foursquare,a jejím cílem je umožnit
uživateli najít a na mapě zobrazit body z databáze Foursquare v okolí určených souřadnic.
Služba pouze vypíše body v okolí určených souřadnic a umístí na mapu jejich polohy.
Nenapojuje žádnou další funkci Foursquare ani neumožňuje zobrazit detail konkrétního POI
(uživatel je odkázán přímo na výpis detailu bodu na Foursquare).
Obrázek 1.1:Služba Look4square
Pro mou aplikaci jsem se ve službě Look4square částečně inspiroval jejím jednoduchým
layoutem – rozložením hlavní strany.
4 KAPITOLA 1.ÚVOD
1.3.2 4sqmap
Další ze služeb napojených pouze na Foursquare je 4sqmap [1].Na základě dat z Foursquare
poskytuje mapy bodů,umožňuje jejich další třídění a vyhledávání,po přihlášení uživatele
také generuje řadu statistik o historii jeho check-inů v rámci Foursquare.
Služba umožňuje rovněž zobrazení přátel a jejich posledních check-inů na mapě.Tím se
podobá plánované funkcionalitě mé aplikace,avšak jak bylo řečeno,služba 4sqmap využívá
pouze data z Foursquare.
Obrázek 1.2:Služba 4sqmap
1.3.3 Fourwhere
Fourwhere [23] by měla být služba načítající body z Foursquare a kombinující je s daty ze
služeb Gowalla a Yelp.Od léta roku 2011 však služba nefunguje – nenačítá žádná data.
1.3.4 Footfeed
Footfeed [22] je služba zaměřená na agregaci check-inů – uživatel tak může buďto prostřed-
nictvím webu nebo aplikace pro Android/iPhone provést najednou check-in ve více POI
reprezentujících to samé místo napříč několika službami.Aby uživatel mohl provést hro-
madný check-in,snaží se služba najít a sloučit stejná místa v jednotlivých službách auto-
maticky.Za tímto účelem má však také uživateli tvořenou databázi již asociovaných míst,
do které mohou uživatelé navrhovat i sloučení automaticky nesloučených bodů.
I v případě sloučeného bodu ale služba nijak dále neagreguje dostupné informace o
tomto POI z jednotlivých služeb (fotografie,adresu,telefon...) ani žádnou další funkcionalitu.
Slučování bodů tak slouží čistě k provedení hromadného check-inu v nich.
Kapitola 2
Analýza
V rámci analýzy a přípravy aplikace – agregátoru (zkráceně nazývané GSAA– angl.GeoSo-
cialApp aggregator) byly vzaty v potaz výše zmíněné cíle a byly formulovány jak konkrétní
požadavky na funkcionalitu,tak i další nefunkční a jiné požadavky.
Dle funkčních požadavků byly navrhnuty jednotlivé případy užití včetně jejich přesného
scénáře.Matice funkčních požadavků a use case uvedená v závěru této kapitoly pak ukazuje,
které use case pokrývají které funkční požadavky.
2.1 Funkční požadavky
Funkční požadavky definují,co bude výsledná aplikace umožňovat;popisují tak jednotlivé
plánované funkce aplikace.Každý požadavek by měl popisovat pouze jednu samostatnou
a měřitelnou funkcionalitu.
Pro přehlednost jsou funkční požadavky rozděleny do tří částí – požadavky týkající se
jednak zobrazení POI na mapě,dále načtení detailních informací o POI a nakonec sociálních
funkcí.Každý požadavek má přidělené své číslo.
2.1.1 Zobrazení POI na mapě
F1:Načítání POI z jednotlivých služeb
Aplikace umožní načítat místa zájmu (POI) ze služeb Foursquare,Gowalla,Google
a Facebook v okolí určených souřadnic.
F2:Načtení aktuální polohy uživatele
Aplikace umožní načíst aktuální polohu uživatele prostřednictvím webového prohlížeče
klienta.
F3:Ruční zadání souřadnic
Aplikace také umožní ruční zadání souřadnic,v okolí kterých má proběhnout vyh-
ledávání.
F4:Slučování POI
Aplikace bude v rámci možností slučovat POI načtené z jednotlivých služeb reprezen-
tující ten samý objekt.
5
6 KAPITOLA 2.ANALÝZA
F5:Vynesení POI na mapu
Aplikace bude POI vynášet na mapu.
F6:Posunutí mapy
V případě posunutí zobrazené části mapy obnoví aplikace body v okolí nového středu
mapy.
F7:Filtrování výpisu POI
Aplikace umožní filtrovat výpis a zobrazení POI dle kategorie a názvu.
F8:Řazení POI
Aplikace umožní seřadit výpis POI dle abecedy,vzdálenosti od souřadnic a relevance
(kvality).
2.1.2 Detailní informace o POI
F9:Načtení detailu POI
Aplikace umožní zobrazit detail vybraného POI s agregovanými údaji z jednotlivých
služeb (v případě sloučeného bodu).
F10:Odkaz původní POI
Aplikace bude zobrazovat,z jakých služeb byl POI načten a pod jakými názvy je
v každé službě evidován,bude také nabízet možnost otevřít detail POI v dané službě.
F11:Zobrazení původu dat o POI
Aplikace bude zobrazovat,z jakých služeb byla která data o POI načtena.
2.1.3 Sociální funkce
F12:Přihlášení uživatele
Aplikace umožní přihlášení uživatele u služeb Foursquare,Gowalla,Google a Facebook.
F13:Zobrazení posledních check-inů přátel
Aplikace umožní zobrazit na mapě poslední známé souřadnice (polohu check-inu) kon-
taktů (přátel) z autorizovaných služeb.
F14:Hromadný check-in
Aplikace umožní provést v určeném POI hromadný check-in (ohlášení) v autorizo-
vaných službách.
2.2 Nefunkční požadavky
Nefunkčními požadavky se rozumí omezující podmínky,které jsou kladeny na systém,nikoliv
na jeho funkcionalitu.Jedná se často o omezení týkající se technologií,kvality a podobně.
Pro agregátor jsou stanoveny tyto nefunkční požadavky:
N1:Aplikace bude implementována v programovacímjazyce PHP verze 5 za užití objektově
orientovaného programování a Zend Frameworku.
2.3.DALŠÍ POŽADAVKY ZE ZADÁNÍ 7
N2:Pro zobrazení uživatelského rozhraní bude na straně klienta využíván webový prohlížeč.
N3:Klientská část aplikace bude funkční v posledních stabilních verzích prohlížečů Mozilla
Firefox,Chrome a Safari.
N4:Aplikace nebude pro svůj provoz potřebovat databázi na straně serveru.
N5:Aplikace nebude vyžadovat přihlášení uživatele ani nutně autorizaci v jednotlivých
službách (pak nebude dostupná některá funkcionalita).
N6:Odkazy otevírané v rámci aktuálního okna (prostřednictvím tzv.„lightboxu“
1
) bude
možné otevřít i v samostatném okně.
2.3 Další požadavky ze zadání
Zde jsou uvedeny další požadavky,které nezapadají přímo do požadavků nefunkčních,ale
vyplývají ze zadání bakalářské práce.
 Zdrojový kód aplikace bude dokumentován.
 Aplikace bude otestována pomocí unit testů.
 Aplikace bude nasazena na veřejně dostupný server.
2.4 Případy užití
2.4.1 Aktéři
Během práce s aplikací bude uživatel vystupovat v jedné z těchto dvou rolí,tj.zde figurují
pouze dva aktéři:
 Neautorizovaný uživatel,který může provádět UC1-6.Toto je výchozí role pro nově
příchozího uživatele.
 Autorizovaný uživatel,což je původně neautorizovaný uživatel,který provedl UC6
(autorizaci) alespoň pro jednu službu.Tento aktér rozšiřuje neautorizovaného uživatele
o UC7 a UC8.
2.4.2 Use case
Zde jsou uvedeny případu užití (use case),které byly připraveny v rámci analýzy a návrhu ap-
likace.V případě,že došlo během implementace k odchylkám od tohoto stavu,je to uvedeno
v poznámce u příslušného use case.
1
Viz <http://en.wikipedia.org/wiki/Lightbox_(JavaScript)>
8 KAPITOLA 2.ANALÝZA
UC1:zobrazit mapu POI
1.Případ užití začíná,když uživatel zobrazí stránku s mapou.
2.Aplikace načte údaje o poloze uživatele.
3.Aplikace přemístí střed mapy na zjištěné souřadnice.
4.Aplikace načte POI v okolí tohoto středu mapy,sloučí POI odpovídající tomu samému
místu a body vynese na mapu.
5.Aplikace vypíše seznam zobrazených bodů vedle mapy.
Poznámka Na základě připomínek z uživatelského testování (viz 6.2) se ukázalo,že au-
tomatické zjišťování polohy již při prvním načtení stránky není zcela očekávané chování a
uživatele může rušit.Proto se po otevření načte mapa na stanovených výchozích souřadnicích
(Praha,Karlovo náměstí),a načtení polohy uživatele je možné na požádání – kliknutím na
tlačítko „Get my location“.
Alternativní scénář
2.Uživatel zadá polohu do formuláře ručně.
Dále pokračuje hlavní scénář od bodu 3.
UC2:hledat v mapě
1.Případ užití začíná,když uživatel táhnutím „přesune mapu“ (přesune její střed).
2.Aplikace zobrazí POI v okolí nového středu mapy.
3.Aplikace vypíše seznam aktuálně zobrazených bodů vedle mapy.
UC3:filtrovat načtené POI
1.Případ užití začíná,když uživatel zadá do formuláře řetězec názvu POI,který chce
filtrovat,a/nebo vybere kategorii,a/nebo vybere služby,ze kterých chce POI načítat
a formulář odešle.
2.Aplikace načte POI odpovídající podmínkám filtru a vynese je na mapu.
3.Aplikace vypíše seznam aktuálně zobrazených bodů vedle mapy.
Poznámka Filtrování dle kategorií nebylo nakonec implementováno – zdůvodnění viz 5.2.8.
UC4:řadit načtené POI
1.Případ užití začíná,když uživatel změní nastavení pro řazení seznamu POI.
2.Aplikace seřadí seznam POI vedle mapy dle vybraného pořadí.
2.4.PŘÍPADY UŽITÍ 9
UC5:zobrazit detail POI
1.Případ užití začíná,když klikne na odkaz pro zobrazení detailních informací o POI.
2.Aplikace zobrazí stránku s agregovanými informacemi o dotyčnémPOI,včetně možnosti
provést v tomto bodu agregovaný check-in (viz UC8).
UC6:přihlásit se k LBS službě
1.Případ užití začíná,když uživatel klikne na odkaz k přihlášení do dotyčné služby.
2.Uživateli je zobrazena autorizační stránka této služby,kde musí potvrdit přístup pro
aplikaci GSAA.
3.Uživatel potvrdí přístup k datům pro aplikaci.
4.Uživateli je zobrazena původní stránka,na které klikl na odkaz s přihlášením.
5.Aplikace zobrazí potvrzení o přihlášení k dotyčné službě.
Alternativní scénář
3.Uživatel přístup k datům pro aplikaci odmítne.
4.Uživateli je zobrazena původní stránka na které klikl na odkaz s přihlášením.
5.Aplikace zobrazí informaci o neuskutečněné autorizaci u této služby.
UC7:zobrazit polohu přátel
Předpoklady:Uživatel je autorizován alespoň u jedné služby (viz UC6).
1.Případ užití začíná,když uživatel zobrazí stránku s přehledem přátel (kontaktů) v
autorizovaných službách.
2.Aplikace načte z autorizovaných služeb informace o posledních check-inech přátel.
3.Aplikace sloučí přátele z jednotlivých služeb vystupující pod stejným jménem.
4.Aplikace na mapě zobrazí poslední zjištěnou polohu jednotlivých přátel.
UC8:provést hromadný check-in
Předpoklady:uživatel je autorizován alespoň u jedné služby (viz UC6).
1.Případ užití začíná,když uživatel klikne na odkaz k check-inu v zobrazeném detailu
POI (viz UC5).
2.Aplikace zobrazí formulář s výběrem služeb,ve kterých může uživatel provést check-in,
a s políčkem pro zadání zprávy,kterou chce uživatel při check-inu zveřejnit.
10 KAPITOLA 2.ANALÝZA
3.U neautorizovaných služeb nabídne aplikace možnost nejprve provést přihlášení (UC6).
4.Uživatel vybere,ve kterých službách chce check-in provést,a případně napíše zprávu
k check-inu.
5.Aplikace provede check-in v zadaných službách.
6.Aplikace zobrazí potvrzení o provedeném check-inu v každé službě.
2.5 Matice funkčních požadavků a use case
Tabulka 2.1 ukazuje,jak jednotlivé use case pokrývají specifikované funkční požadavky.Lze
tak ověřit,že jsme navrženými případy užití pokryli všechny funkční požadavky aplikace.
UC1
UC2
UC3
UC4
UC5
UC6
UC7
UC8
F1
X
F2
X
F3
X
F4
X
F5
X
F6
X
F7
X
F8
X
F9
X
F10
X
F11
X
F12
X
F13
X
F14
X
Tabulka 2.1:Matice funkčních požadavků a use case
Kapitola 3
Použité technologie
Tato kapitola obecně popisuje klíčové technologie,které byly při implementaci aplikace
použity – ať již na straně serveru,tak v klientské části.
3.1 PHP & Zend Framework
Jako implementační platforma serverové části aplikace byly zvoleny PHP a Zend Framework.
Jazyk PHP
1
je dnes nejrozšířenějším jazykem pro vývoj serverových částí webových
aplikací.Jedná se o skriptovací jazyk původně vytvořený Rasmusem Lerdorfem v roce 1995
za účelem snazší tvorby jednoduchých webových stránek s dynamickými prvky.Postupně se
však jazyk stával stále populárnější a byl používán i pro rozsáhlejší aplikace.Během let PHP
a technologie okolo něj vyspěly v plnohodnotnou platformu a moderní programovací jazyk –
aktuálně PHP řady 5.3.
Zend Framework
2
(ZF) je moderní,plně objektově orientovaný framework
3
pro PHP
5 určený k vývoji webových aplikací.Jeho hlavními vlastnostmi jsou mj.široká škála vyspělých
komponent (viz dokumentace [19]),které jsou navíc vysoce modulární (stačí využívat pouze
potřebné komponenty,jednotlivé komponenty je dokonce možné využívat zcela samostatně),
podpora MVC
4
architektury,pokročilý cachovací systém,flexibilita pro vlastní úpravy a
rozšíření či rozsáhlá a kvalitní vývojářská dokumentace.V době psaní práce je aktuální sta-
bilní verze frameworku 1.11.11,vývoj je však již primárně soustředěn hlavně na řadu 2,která
bude implementovat řadu nových vlastností a jejíž první stabilní verze se očekává v polovině
roku 2012.Vývoj řady 2 je momentálně velice progresivní a ačkoliv již vycházejí beta verze
ZF řady 2,nejsou dosud určeny pro produkční využití.Navíc v rámci vývoje ZF2 dochází
často k rozsáhlým a zpětně nekompatibilním změnám ve frameworku,které by znamenaly
časté přepisování i již hotových částí aplikace.Řada 1 je však nadále aktuální,stabilní a
odladěná,a není tedy důvod jí nevyužít.
1
<http://php.net/>
2
<http://framework.zend.com/>
3
Jako framework se označuje ucelená sada znovupoužitelných knihoven,tříd aj.,implementujících obecnou
funkcionalitu v nějaké oblasti.Využití frameworku zpravidla usnadňuje a zrychluje vývoj aplikací.
4
Model-View-Controller – třívrstvá architektura aplikace,oddělující prezentační datovou vrstvu a ap-
likační vrstvu
11
12 KAPITOLA 3.POUŽITÉ TECHNOLOGIE
Hlavnímdůvody pro využití kombinace technologií PHP & ZF pramení z jejich vlastností
popsaných výše – jednak možnost vývoje na otevřené
5
a ověřené platformě,což zahrnuje i
případnou možnost snadného nasazení aplikace na absolutní majoritě hostingů,neboť PHP
je pro sdílené hostingy de-facto standardem.Dalším důvodem je podpora vývoje udržitel-
ného,přehledného a znovupoužitelného kódu (oddělením aplikace do vrstev využitím MVC
architektury,čistotou návrhu samotného ZF aj.).
Vzhledem k široké práci s API třetích stran,které bude aplikace GSAA využívat,je
také kritická dobrá podpora práce s nimi.Pro PHP toto není problém,komponenta ZF
Zend_Http_Client navíc práci s API (resp.obecně s HTTP požadavky) dále usnadňuje.
Důležitá je také podpora práce s datovým formátem JSON,který jednak využívají API
třetích stran pro přenos dat,se kterými bude aplikace pracovat,zároveň budou ve formátu
JSON přenášena data ke klientské části mé aplikace.Pro tento účel je zase vhodná ZF
komponenta Zend_Json.
Protože ZF je celkově vytvářen s tím,aby zjednodušil vývoj podobně komplexních we-
bových aplikací,bude vývoj aplikace v mnoha „rutinních“ činnostech usnadněn a bude se
tak možné soustředit skutečně na vývoj relevantních a specifických částí aplikace.Pokrýt
výše uvedené požadavky na platformu by bylo patrně z větší části možné i použitím jiných
technologií,nicméně vzhledem k tomu,že práce je primárně zaměřena na prozkoumání API
různých služeb a osobní zkušenosti jsou nejvyšší s platformou PHP&ZF,bylo by nadbytečné
provádět vývoj za použití jiných technologií.
3.2 Javascript & jQuery
Nemalá část aplikační logiky (dynamické prvky,mapy,načítání dat ze serverové části aplikace
atd.) bude implementována na straně klienta.Za tímto účelem bude využito skriptovacího
interpretovaného jazyka JavaScript,který je pro toto použití fakticky jediným standardem
použitelným napříč současnými prohlížeči.Všechny prohlížeče specifikované v nefunkčním
požadavku N3 pak JavaScript podporují na vysoké úrovni včetně velmi dobrého výkonu
interpretů tohoto jazyka.
Podobně jako ZF je frameworkempro PHP,je jQuery
6
frameworkempro jazyk JavaScript.
JQuery doplňuje některé vlastnosti jazyka JavaScript,zjednodušuje řadu rutinních činností
a zvyšuje kompatibilitu a přenositelnost skriptů mezi prohlížeči.Důležitá pro mou aplikaci
je například výtečná podpora AJAXu a souvisejících technologií.
Vzhledem k tomu,že jQuery je dnes nejpoužívanější JavaScript framework,existuje pro
něj veliké množství pluginů,implementujících již nějakou specifičtější funkcionalitu.Seznam
použitých pluginů v aplikaci GSAA a krátký popis každého z nich obsahuje kapitola 3.2.2.
3.2.1 jQuery UI
JQuery UI
7
je oficiální nadstavba jQuery,poskytující „abstrakci nad nízko-úrovňovou inter-
akcí a animacemi,pokročilé efekty a widgety“.V praxi to znamená,že poskytuje komplexní
5
PHP i Zend Framework jsou volně šiřitelné a open-source technologie.
6
<http://jquery.com/>
7
<http://jqueryui.com/>
3.2.JAVASCRIPT & JQUERY 13
výbavu prvků uživatelského rozhraní (například tlačítka,dialogová okna,posuvníky,záložky
alias „taby“ a další) a prostředky pro práci s nimi (animace,přesuny,řazení,grafická témata
aj.) – více viz oficiální dokumentace na webu projektu.
V aplikaci GSAA je jQuery UI použito pro zobrazení odesílacích tlačítek a dalších prvků
formulářů.
JQuery i jQuery UI jsou dostupné
8
pod svobodnými licencemi MIT i GPL;v mém
projektu je používámpod licencí MIT,dle které je možno software libovolně šířit a upravovat
při podmínce zachování a uvedení licence.
3.2.2 jQuery pluginy
Fancybox
Knihovna Fancybox [21] od Janise Skarnelise je jednou z implementací tzv.„lightboxu“,čímž
se rozumí modální dialog (resp.okno),zobrazující se pomocí JavaScriptu ve vrstvě nad
aktuální stránkou.Tento dialog umožňuje zobrazovat různý obsah – obrázky,fotogalerie,
formuláře,videa aj.Výhodou oproti konvenčnímu zobrazování tohoto obsahu v novémokně je
vyšší uživatelská příjemnost,nevtíravost a v neposlední řadě také možnost načítat v lightboxu
webové stránky či jejich fragmenty asynchronně prostřednictvím technologie AJAX.
Fancybox je v aplikaci využit pro zobrazení oken s detailem POI a okna s mapou check-
inů přátel.V obou případech je obsah okna načítán přes AJAX.
V aplikaci je použitý nedávno vydaný Fancybox řady 2.Tento je k dispozici pod li-
cencí Creative Commons Attribution-NonCommercial 3.0
9
,která umožňuje šířit a upravovat
knihovnu za podmínek uvedení autora a jejího nekomerčního využití.
Tipsy
Tipsy [24] je jednoduchý plugin od Jasona Frame,umožnující zobrazování formátovaných
„tooltipů“.Na rozdíl od výchozí bublinkové nápovědy,která je k dispozici v prohlížečích,je
při použití Tipsy možno ovládat polohu tooltipu,určit událost,při které je tooltip zobrazen
a skryt,a pro použití v mé aplikaci nejdůležitější – umístit do něj HTML obsah.
Plugin Tipsy je použit pro zobrazení většího náhledu fotografií (včetně data jejich pořízení
a popisku) při zobrazení detailu POI.Tooltip se zobrazí při kliknutí na malý náhled fotografie
(událost click) – viz obrázek 3.1,skryje se při opuštění náhledu kurzorem myši (událost
mouseover).
Tipsy je k dispozici pod svobodnou licencí MIT
10
(stejně jako jQuery samotné).
bxSlider
BxSlider [20] plugin od Stevena Wanderskiho je jeden z tzv.„content slider“ pluginů.Tyto
jsou používány k zobrazení širšího obsahu v menším bloku pomocí jeho postupného posou-
vání.Konkrétně v mé aplikaci na stránce detailu POI pro zobrazení většího množství fo-
tografií – pokud je u POI načteno více jak 5 fotografií,nevešly by se jejich náhledy v okně
8
<http://jquery.org/license/>
9
<http://creativecommons.org/licenses/by-nc/3.0/>
10
<http://www.opensource.org/licenses/MIT>
14 KAPITOLA 3.POUŽITÉ TECHNOLOGIE
Obrázek 3.1:Tipsy plugin – zobrazení větší náhledové fotografie
vedle sebe;pokud by byly pod sebou,zabíraly by zase příliš mnoho místa.Proto je jich
zobrazeno prvních 5 a další jsou k zobrazení „posunuty“ po kliknutí na ovládací šipky vlevo
a vpravo.Ukázku zobrazuje obrázek 3.2.
Problémem tohoto pluginu byla chyba,která bránila posunutí na poslední sadu fotografií
– fotografie jsou totiž vždy posouvány o 5 dalších a v případě,že jejich celkový počet nebyl
násobek pěti,bylo jich v poslední sadě méně než pět.S tím ale plugin nepočítal,a mylně
již nezobrazoval šipku k posunutí na tyto fotografie.Při analyzování chyby jsem na webu
projektu narazil na velkou řadu hlášení podobných chyb od uživatelů pluginu,která však
byla bez odezvy od původního autora pluginu.Proto jsemse pokusil chybu v pluginu opravit
svépomocí,což se také nakonec podařilo.
Stejně jako jQuery i Tipsy je bxSlider šířen pod licencí MIT.
Obrázek 3.2:bxSlider plugin – možnost postupného posouvání mezi více fotografiemi
3.3 Google Maps API
Google Maps API [13] je rodina mapových služeb od firmy Google,která nabízí jejich využití
na jakékoliv volně dostupné stránce.
Konkrétně Google Maps JavaScript API v3,které v aplikaci používám,slouží ke vkládání
map do webových stránek prostřednictvím JavaScriptu.Knihovna tohoto API nabízí velmi
3.3.GOOGLE MAPS API 15
širokou a pokročilou nabídku funkcí a nástrojů k manipulaci s mapami včetně přidávání
vlastního obsahu na ně.
JavaScript API nabízí Google vývojářůmod roku 2005,aktuální verze 3 dostupná od roku
2009 nahrazuje původní dřívější široce používané API verze 2;je však částečně předělané a
zobrazení map je přizpůsobené i mobilním zařízením jako Android nebo iPhone telefony.
Přesný popis vložení a zprovoznění map popisuje dokumentace či tutoriál
11
na vývo-
jářských stránkách map.
Protože mapy jsou středobodem klientské části aplikace,níže následuje popis některých
možností a využité funkcionality map.Kompletní popis všech možností nabízí referenční
dokumentace
12
.
Možnosti mapy Při vytváření mapy (případně i u již vytvořené mapy) je možné přizpů-
sobit zobrazenou mapu různými parametry,např.:
 zoom – výchozí přiblížení mapy,0 je nejmenší,maximální přiblížení se liší dle dostup-
nosti dat v dané lokalitě;
 mapTypeId – výchozí typ zobrazené mapy,je možné využít běžnou mapu ulic,satelitní
mapu,terénní mapu či mapu hybridní (kombinace mapy ulic a satelitní);
 center – výchozí souřadnice mapy,zabalené v objektu google.maps.LatLng;
 zobrazení/skrytí ovládacích prvků:panControl (ovládání posunu),zoomControl (ovládání
přiblížení tlačítky),scaleControl (ovládání přiblížení mapy posuvníkem),mapTypeControl
(přepínání typu zobrazené mapy),streetViewControl (zobrazení StreetView) aj.;jed-
notlivé ovládací prvky lze také dále přizpůsobovat,například přenastavit pozici,kde
jsou zobrazeny atd.
Příklad vytvoření mapy v JavaScriptu (předpokládáme načtení knihovny map a vytvoření
HTML elementu <div> s id „map“ – viz tutoriál na webu map):
//nastavení možností mapy
var mapOptions = {
zoom:14,//výchozí přiblížení mapy
center:new google.maps.LatLng(50.087811,14.42046),//výchozí souřadnice
mapTypeId:google.maps.MapTypeId.ROADMAP,//výchozí typ zobrazené mapy
streetViewControl:false//vypnutí ovládacích prvků StreetView
};
//inicializace mapy v elemenu#map se zadanými možnostmi,instance mapy se
nachází v proměnné"map"
map = new google.maps.Map(
document.getElementById(’map’),
mapOptions
);
Podobně jsou mapy s různými možnostmi inicializovány na několika místech v aplikaci –
popis jejich využití je uveden v kapitole Realizace,v části 5.2.10.
11
<http://code.google.com/intl/cs/apis/maps/documentation/javascript/tutorial.html>
12
<http://code.google.com/intl/cs/apis/maps/documentation/javascript/reference.html>
16 KAPITOLA 3.POUŽITÉ TECHNOLOGIE
Události K objektu inicializované mapy i k dalším objektům vytvořeným na mapě (např.
markers – ukazatele) lze přiřadit listenery – funkce,které se spustí v okamžiku vzniku nějaké
události.Je možno využít jak výchozí tzv.DOMudálosti javascriptu (click,mouseover,...),
tak další události,které produkuje mapa a některé její prvky při změně stavu.U objektu
mapy se jedná např.o události:
 drag – událost je opakovaně vyvolávána při posunu mapy o každý pixel;
 dragend – událost je vyvolána 1 po ukončení posouvání mapy uživatelem;
 zoom_changed – událost je vyvolána při změně přiblížení mapy;
 maptypeid_changed – událost je vyvolána při změně typu mapy.
Příklad přiřazení listeneru k mapě,reagujícímna událost dragend:listener funkce po spuštění
zjistí souřadnice nového středu map a údaje o souřadnicích zkopíruje do políček formuláře:
//přidat listener funkci k objektu"map":
google.maps.event.addListener(map,’dragend’,function() {
//načíst nový střed mapy:
var latlng = indexMap.getCenter();
//zkopírovat souřadnice do formuláře:
$(’#searchform input[name=lat]’).val(latlng.lat());
$(’#searchform input[name=long]’).val(latlng.lng());
});
Overlaye Jak bylo řečeno v úvodu kapitoly,na mapy lze přidávat také vlastní obsah.
Toto je možné prostřednictvím různých tzv.overlay objektů,které jsou přiřazeny k určeným
souřadnicím (takže se při posunu mapy rovněž přesunují).
Mapy nabízejí mimo jiné tyto overlaye:
 markers – ukazatel přiřazený jedněmkonkrétnímsouřadnicímna mapě,výchozí podoba
je „špendlík“,nicméně je možné využít i vlastní ikonu či využít rozšíření MarkerWith-
Label (viz kapitola 3.3);
 polylines,polygons – použitím více souřadnic je možno na mapě vytvořit linky či
mnohoúhelníkové objekty;
 info windows – umožňuje zobrazit další obsah (text,obrázky...) v malémpop-up okně
(„bublině“) v mapě;
 custom overlays – mapy dokonce umožňují vytvoření zcela vlastních typů overlay
objektů.
S jednotlivými overlayi lze různé manipulovat a také přiřazovat listenery navázané na
jejich události (viz předchozí kapitola).Častý způsob je např.po kliknutí (tj.události click)
na marker otevřít info window s dalšími informacemi o příslušném bodu.Tímto způsobem
funguje hlavní mapa aplikace GSAA – jednotlivé body jsou zobrazeny pomocí markers,po
kliknutí na daný marker se otevře info window s celým názvem bodu,adresou a odkazem na
zobrazení dalších informací – viz obrázek 3.3.
3.3.GOOGLE MAPS API 17
Obrázek 3.3:Marker a otevřené info window
MarkerWithLabel
Mimo nativních funkcí Google Maps JavaScript API existují i různé další doplňky,kterými
lze upravit či rozšířit funkcionalitu map.
MarkerWithLabel je součástí Google Maps Utility Library v3 [14] – projektu,shromažďu-
jícím různé nástroje pro Google Maps JavaScript API v3,který je zaštítěn přímo vývojáři
z Google.Jeho jednotlivé knihovny jsou k dispozici pod licencí Apache 2.0
13
.
Tato konkrétní knihovna umožňuje doplnit marker (ukazatel souřadnic) o popisek,jinak
se chová stejně jako běžný marker z Maps API.
MarkerWithLabel je v aplikaci použit při zobrazení check-inů přátel na mapě – viz
obrázek 3.4.Pomocí ikony popisku a jeho negativního pozicování pod profilový obrázek
(avatar) přítele je vytvořen efekt šipky směřující k souřadnicím místa check-inu na mapě.
Obrázek 3.4:Ukázka použití knihovny MarkerWithLabel
13
<http://www.apache.org/licenses/LICENSE-2.0>
18 KAPITOLA 3.POUŽITÉ TECHNOLOGIE
3.4 Google Geocoding API
Jako geocoding se označuje proces převedení adresy do zeměpisných souřadnic.Reverzní
geocoding je pak proces opačný – zjištění adresy na základě zeměpisných souřadnic.
Pro oba tyto účely poskytuje Google své Geocoding API [12].To je možné využívat buďto
samostatně (pomocí HTTP volání jako běžné webové API),nebo přímo v rámci Google Maps
API – zde je možno vytvořit instanci třídy geocoder a s její pomocí dynamicky překládat
přímo uživatelem zadaná data.
Díky integraci do Google Maps API tak lze snadno a bez potřeby obsluhy dalšího API
převést například adresu zadanou do formuláře na souřadnice a na ty přesunout střed mapy.
Právě takto v aplikaci funguje vyhledávací políčko – po zadání adresy (resp.se nemusí jednat
o adresu,Geocoding API dokáže najít souřadnice například i pro samostatné administrativní
celky jako města,státy,okresy,městské čtvrti aj.) je mapa přemístěna na toto místo a ne-
jbližší POI v okolí nového středy mapy jsou následně obnoveny.Vyhledávací políčko je navíc
doplněno o autocomplete funkcionalitu,takže automaticky dokončuje adresu již po zadání
prvních několika znaků – viz obrázek 3.5.
Obrázek 3.5:Automatické dokončování adresy
Reverzní geocoding je jako samostatné API používáno v serverové části aplikace – v zo-
brazení detailu POI pro určení přibližné adresy daného bodu,pokud není jeho adresa uvedena
v žádné LBS službě.Více viz kapitola 5.2.4.
3.5 OAuth
OAuth je otevřený
14
standard pro autorizaci.Protokol byl vytvořen za cílem umožnit sdílení
některých informací mezi různými službami,aniž by bylo nutné sdílet přístupové údaje uži-
vatele,k jehož datům se přistupuje.Jedná se tak o mechanismus pro bezpečnou autorizaci
přístupu k uživatelským datům u nějakého providera (poskytovatele) pro nějakého API con-
sumera (konzumenta)
15
.Příkladem může být načtení e-mailových kontaktů jinou službou:
uživatel e-mailové služby (providera) potvrdí externí aplikaci (consumerovi) přístup k těmto
datům,consumer je pak může načíst a dále s nimi pracovat.Konkrétně v aplikaci GSAAbude
prostřednictvím OAuth uživatel povolovat přístup k datům o svých přátelích z jednotlivých
LBS služeb.
14
Volně a veřejně dostupný
15
Pro konzistenci se specifikací OAuth je dále používáno anglické názvosloví.
3.5.OAUTH 19
Standard OAuth byl vytvořen poměrně nedávno (verze 1.0
16
roce 2006-7),přesto rychle
získal popularitu i mezi největšími poskytovateli různých webových služeb a webových API
(Facebook,Google,Twitter,Microsoft aj.).Důvodemrychlého rozšíření byla potřeba umožnit
vývojářům aplikací využívajících API bezpečný způsob autorizace přístupu k některým
datům uživatele v těchto službách.V současné době se pracuje na specifikaci OAuth verze
2.0,její draft
17
je však v natolik pokročilémstadiu,že je u většiny providerů implementována
právě v této verzi
18
.
3.5.1 OAuth vs.Open ID
OAuth bývá někdy mylně zaměňován s částečně podobnou technologií – Open ID.Jedná
se však nikoliv o konkurenční technologie,ale naopak o technologie doplňující se,kdy je
každá určená k řešení jiného problému.Zatímco – jak bylo popsáno výše – OAuth je určen
k autorizování
19
přístupu k datům z API jedné služby službě jiné,Open ID je určen k aut-
entizaci
20
uživatele jedním uživatelským účtem u různých služeb.Uživatel tak vlastní jeden
účet u poskytovatele identity,kterýmse může autentizovat u různých služeb.Službámvyuží-
vajícímOpen ID tak odpadá potřeba implementovat vlastní systémpro správu uživatelských
účtů,uživatelé si zase nemusí pamatovat hesla k uživatelským účtům na různých webových
stránkách,opakovaně vyplňovat při registraci do různých služeb stejné údaje (e-mail,adresa,
datum narození...) a podobně.Navíc se jedná o decentralizovaný autentizační systém – vše
nezávisí na jedné autentizační autoritě/firmě,ale uživatel si může vybrat z nabídky mnoha
Open ID providerů.Stejně tak je možné provozovat vlastního Open ID providera.
3.5.2 Proces autorizace pomocí OAuth
OAuth umožňuje provést autorizaci dvěma způsoby – server-side (metoda „Authorization
Code“) a client-side (metoda „Implicit Grant“).Client-side metoda je určená pouze pro au-
torizaci takových aplikací,kde k autorizovanému API providera přistupuje aplikace přímo
z klientské strany,například tedy čistě AJAX aplikace,které běží v prohlížeči uživatele a
neobsahují žádnou serverovou část.To však není případ mé aplikace,je tedy využíván server-
side způsob autorizace,oficiálně ve specifikaci nazvaný „Authorization Code“.
Při tomto autorizačním toku (angl.flow) zde figurují tři strany:
 Consumer,což je aplikace (běžící na serveru),která potřebuje získat přístup k datům
uživatele v API providera.V tomto případě se jedná o aplikaci GSAA.
 Uživatel,který chce aplikaci (consumerovi) udělit přístup k některým svým údajům
dostupným přes API providera.
 Provider,u kterého musí uživatel odsouhlasit poskytnutí přístupu pro consumera
a který po schválení poskytuje přes API consumerovi požadovaná data.V tomto pří-
padě se jedná o konkrétní LBS službu.
16
Specifikace OAuth 1.0 viz <http://tools.ietf.org/html/rfc5849>
17
Pracovní verze
18
Poslední verze draftu specifikace OAuth 2.0 je 22,viz <http://tools.ietf.org/html/
draft-ietf-oauth-v2-22>.
19
Autorizace – ověření přístupu
20
Autentizace – ověření identity uživatele
20 KAPITOLA 3.POUŽITÉ TECHNOLOGIE
Ještě než se aplikace může autorizovat u nějaké služby,musí v ní být nejprve zareg-
istrována jako tzv.OAuth consumer.Aplikace má pak přiděleny dvě hodnoty:identifikátor
aplikace (client_id) a tajný klíč aplikace (client_secret,de-facto heslo).Registraci ap-
likace u každého providera je nutno provést předem ze strany vývojáře.
Uživatel
Aplikace (consumer) OAuth provider
1. Žádost o autorizaci u providera
1. Žádost o autorizaci u providera
2. Přesměrování uživatele na autorizační URL
2. Přesměrování uživatele na autorizační URL
3. Autorizační stránka
3. Autorizační stránka
4. Autentizace uživatele, schválení přístupu pro consumera
4. Autentizace uživatele, schválení přístupu pro consumera
5. Přesměrování na redirect_uri
5. Přesměrování na redirect_uri
6. Žádost o token
6. Žádost o token
7. Access token
7. Access token
8. Zobrazení potvrzení autorizace
8. Zobrazení potvrzení autorizace
Obrázek 3.6:Sekvenční diagram OAuth autorizace
Sekvenční diagram na obrázku 3.6 popisuje,jak uživatel autorizuje aplikaci přístup k nějaké
službě (providerovi).Celý proces se skládá z těchto kroků:
1.Žádost o autorizaci u providera
Uživatel chce autorizovat danou aplikaci,zažádá tedy aplikaci o autorizační URL
providera (např.kliknutím na tlačítko).
2.Přesměrování uživatele na autorizační URL
Aplikace přesměruje uživatele na autorizační URL providera.Tento mezikrok není
nezbytně nutný,uživatel může v kroku 1 rovnou kliknout na odkaz vedoucí na au-
torizační URL.V obou případech je součástí autorizačního URL několik parametrů:
 client_id – ID aplikace,které je přidělené consumerovi u providera;
 response_type – musí mít hodnotu code;
 redirect_uri – adresa,na kterou má být uživatel přesměrován po úspěšné au-
torizaci (v kroku 5);
 scope (volitelné) – udává rozsah autorizace (tj.jaká data bude mít consumer
dostupná).
3.5.OAUTH 21
3.Autorizační stránka
Provider zobrazí uživateli autorizační stránku.Autorizační stránka providera zobrazí
uživateli rozsah dat,ke kterým má consumerovi umožnit přístup,název consumera
a možnost consumera autorizovat či autorizaci odmítnout.Některé služby v případě,
že uživatel již dříve povolil consumerovi přístup,provedou rovnou přesměrování na
redirect_uri (krok 5),tedy není nutné,aby uživatel přístup znovu povoloval
21
.
4.Autentizace uživatele,schválení přístupu pro consumera
Pokud není uživatel u providera již přihlášen,musí nejprve zadat přihlašovací jméno
a heslo a přihlásit se (autentizovat).Pokud je již přihlášen,uživatel consumerovi povolí
či odmítne přístup.
5.Přesměrování na redirect_uri
Provider přesměruje uživatele na stránku redirect_uri,jako parametr mu předá
buďto hodnotu code,nebo chybový kód.
6.Žádost o token
Na pozadí (tedy aniž by se uživateli zobrazovalo přesměrování apod.) provede con-
sumer HTTP request na speciální URL providera,určené k získání přístupového to-
kenu.Součástí tohoto požadavku je rovněž několik parametrů,mj.:
 client_id – ID aplikace;
 client_secret – tajný klíč aplikace;
 grant_type – musí mít hodnotu authorization_code;
 redirect_uri – musí mít pro kontrolu stejnou hodnotu jako v bodě 2;
 code – hodnota,kterou provider obdržel v bodě 5.
7.Access token
Consumer obdrží hodnotu access_token (autorizační token),se kterou může consumer
v budoucnu provádět již autorizované požadavky do API providera a přistupovat tak
k datům uživatele.
8.Zobrazení potvrzení autorizace
Consumer zobrazí uživateli výsledek autorizace – zda-li byla úspěšná či nikoliv (např.
pokud ji uživatel v kroku 4 odmítl).
V kapitole 5.2.6 je pak popsáno,jak přesně provádí OAuth autorizaci aplikace GSAA
a jak udržuje a ověřuje získané access_tokeny.
21
Tato funkcionalita není dosud popsána v OAuth 2.0 specifikaci,nicméně velcí OAuth provideři (Facebook,
Twitter,Foursquare...) ji tak obvykle implementují.
22 KAPITOLA 3.POUŽITÉ TECHNOLOGIE
Kapitola 4
Geolokační služby a jejich API
Dle zadání má aplikace GSAA agregovat čtyři geolokační služby – Foursquare,Gowalla,
Facebook a Google Places.Tato kapitola popisuje každou z těchto služeb nejprve obecně,
pak také z pohledu na její specifika,výhody a nevýhody.
Každá ze služeb poskytuje své webové API,které se v lecčems podobá,často se ale
i v zásadních věcech liší – více je popsáno v popisu jednotlivých služeb.Všechna API částečně
následují principy architektury REST
1
– pokud se načítají nějaká data,provádí se HTTP
požadavky metodou GET;pokud se vytváří nějaký záznam (vytvoření check-inu,posílání
komentáře aj.),použije se metoda HTTP POST.
Jednotlivé přístupové body v API se označují jako endpointy – jejich prostřednictvím se
přistupuje k nějakým konkrétním datům či se jimi provádí nějaká akce.Jedná se o URL,
někdy doplněné a další parametry.
4.1 Foursquare
Geolokační sociální služba Foursquare [6] byla spuštěna v roce 2009,jejími zakladateli jsou
Dennise Crowley a Naveen Selvadurai.Služba vychází z podobné služby Dodgeball,kterou
Dennis Crowley vytvořil v roce 2000 jako svou absolventskou práci na New York University.
Služba Dodgeball byla v roce 2005 koupena firmou Google a v roce 2009 nahrazena službou
Google Latitude;provoz původní samostatné služby Dodgeball byl Googlem ukončen.
Na rozdíl od služby Dodgeball,kde interakce s uživateli (check-iny,notifikace o blízkosti
přátel aj.) probíhala formou SMS,byl Foursquare od začátku vytvářen jako aplikace pro
mobilní telefony.Kromě mobilních aplikací služba poskytuje webové rozhraní,kde mohou
uživatele prohlížet check-iny své a svých přátel,přidávat komentáře,nahrávat fotografie,
hledat venue
2
,zobrazovat jejich detaily aj.Pro uživatele,kteří z nějakého důvodu nemohou
používat aplikace,je k dispozici také jednoduché webové rozhraní určené pro mobilní zařízení.
Foursquare má ke konci roku 2011 přes 15 milionů uživatelů po celém světě a roste
tempem asi milion nových uživatelů měsíčně [6].Jedná se tak o nejrozšířenější geolokační so-
ciální službu.Služba Foursquare získala i mnohá odborná ocenění,např.„nejlepší geolokační
služba“ [25,28].
1
Viz např.<http://en.wikipedia.org/wiki/Representational_state_transfer>.
2
Označení pro POI v názvosloví Foursquare
23
24 KAPITOLA 4.GEOLOKAČNÍ SLUŽBY A JEJICH API
Ze všech čtyř implementovaných LBS má Foursquare nejširší řadu gamifikačních a so-
ciálních prvků.Uživatel s nejvyšším počtem check-inů v jedné venue za poslední 2 měsíce
je zde „mayorem“ (starostou),za check-iny získávají uživatele body (jejich množství závisí
na různých dalších kritériích),odznáčky (např.za časté check-iny v nějakém druhu venues),
mohou sledovat žebříček bodů svých přátel i jejich získané odznáčky,komentovat check-iny
přátel aj.
Foursquare se však rozhodně nedá označit pouze za hru,neboť službu je možno využí-
vat i bez ohledů na její herní prvky.Kromě obsáhlé uživatelsky vytvořené a spravované
databáze míst (v aplikaci od Foursquare navázaných rovnou na mapu,což lze snadno využít
např.pro vyhledání a navigaci k dané venue) mohou uživatele sdílet u jednotlivých míst
tipy (doporučení) a označovat je jako „Done“ (tedy že je provedli,resp.s nimi souhlasí),
nahrávat fotografie,Foursquare také na základě vlastního algoritmu nabízí „doporučení“ ně-
jakým způsobem kvalitních venue (např.umí doporučit restaurace nějakého druhu v okolí,
kavárnu,hotel apod.).Obchodníkům zase nabízí různé nástroje („Foursquare for business“)
na nalákání zákazníků – tzv.„specials“:např.možnost nabídnou slevu za první či naopak
opakovaný check-in v obchodníkemspravované venue,nějaké výhody pro mayora a podobně.
Foursquare API
Podobně jako je obvyklé u moderních webových služeb,poskytuje i Foursquare své veřejné
API,a to navíc velmi rozsáhlé (lze skrze něj přistupovat ke všem datům,která používají
mobilní aplikace od Foursquare) a dobře dokumentované.Foursquare také poskytuje část
svého API jako tzv.„Venues Platform“.V rámci této části API nabízí přístup k databázi
venues pro širší využití ze strany vývojářů než jen pro funkce navázané na uživatele:typicky
jako externí databáze míst pro jiné aplikace či mash-up s jinou databází.Umožňuje tak
vyhledávat venue a související data v bezuživatelském režimu,tedy bez potřeby autentizace
konkrétního uživatele.
V aplikaci GSAA je k API přistupováno jak bezuživatelsky (hledání venues,načítání de-
tailu o venue),tak po autorizaci uživatele (načítání přátel,provádění check-inu).Autorizace
se,stejně jako u dalších služeb,provádí prostřednictvím protokolu OAuth 2.0.
Podoba požadavků
Základem URL adresy požadavků na Foursquare API je adresa
https://api.foursquare.com/v2,doplněná o konkrétní cestu k endpointu a další parame-
try.Například pro načtení check-inů přihlášeného uživatele má celé URL (bez parametrů –
viz odstavec níže) podobu:https://api.foursquare.com/v2/users/self/checkins.
Požadavky na Foursquare API mohou v URL obsahovat (mimo jiné) parametry:client_id,
client_secret,oauth_token a parametr v.První dva jsou přidělený identifikátor a heslo ap-
likace (viz kapitola 3.5.2).Vrámci parametru oauth_token je předána hodnota autorizačního
tokenu,která byla získána po dokončení OAuth autorizace v kroku 7.Ta slouží k rozpoznání
přihlášeného uživatele a bez ní nebudou endpointy vyžadující přihlášení dostupné.Pomocí
parametru v se předává datum (ve formátu RRRRMMDD),ke kterému je klient využívající API
aktuální,tj.datum,udávající jaká verze API byla v klientovi implementována.Tato hodnota
slouží v případě zpětně nekompatibilních změn v API na straně Foursquare – klientovi tak
4.1.FOURSQUARE 25
může být na základě tohoto parametru poskytováno starší (a vůči klientovi kompatibilní)
API;pokud k tomu dojde,je navíc v rámci meta části odpovědi (viz ukázka dále) obsažena
i poznámka o tom,že API je neaktuální.
Příklad URL požadavku doplněného o identifikátor a heslo aplikacce,autorizační token
a verzi použitého API:
https://api.foursquare.com/v2/users/self/checkins?client_id=QJ52TX16ALESORT3DMOW
1337&client_secret=XFCVWF3HNGW666ZJQC32ZM&v=20111125&oauth_token=T3R3M3S6E6L6B
Je možná také lokalizace odpovědi (pomocí Accept-Language HTTP hlavičky nebo po-
mocí parametru locale při požadavku).Protože ale mezi jazyky lokalizace není dostupná
čeština,nebude aplikace lokalizaci používat a využije výchozí angličtinu.
Podoba odpovědí
Odpovědi serveru jsou ve formátu JSON.Odpověď má obecně tuto podobu:
{
"meta":{
"code":200,
(...errorType,errorDetail,errorMessage...)
},
"notifications":{
(...notifications...)
},
"response":{
(...results...)
}
}
V části meta je vždy uvedena hodnota code,značící HTTP kód odpovědi (tento kód je
obsažen také v hlavičce odpovědi).Meta část může také obsahovat další informace:
 errorType,což je identifikátor chyby,pokud se vyskytla (deprecated – pokud je
použita zastaralá verze API,invalid_auth – pokud chybí nebo byl předán chybný
autorizační OAuth token atd.);
 errorDetail je celý popis chyby určený pro vývojáře;
 errorMessage je (lokalizovaná) zpráva,kterou je možno při výskytu chyby zobrazit
uživateli.
Část notifications je obsažena,pouze pokud se jedná o autorizovaný požadavek (tj.
s parametrem oauth_token) a obsahuje data pro notifikační lištu aplikací (která funguje
podobně jako např.upozornění na Facebooku) – upozornění na nově získané body,žádosti
o „přátelství“ a podobně.V aplikaci GSAA se z notifikací načítá zpráva pro uživatele,která
se zobrazí po provedení check-inu.
Poslední část response obsahuje samotná data.Přesná podoba JSON objektů,které
jsou v ní obsaženy,záleží na konkrétním použitém endpointu a je včetně všech obsažených
parametrů popsána v dokumentaci API [8].
26 KAPITOLA 4.GEOLOKAČNÍ SLUŽBY A JEJICH API
Endpointy a struktura API
Protože je Foursquare API relativně rozsáhlé,dá se jeho struktura rozdělit do tří částí.Jed-
nak zde existují různé kategorie „resources“ (zdrojů) – v diagramu 4.1 jsou zachyceny venue,
uživatelé a check-iny,existují ale i další,např.tipy,seznamy aj.Pro každou z těchto kategorií
jsou v API obecné endpointy,které zpravidla konkrétní resources buďto vyhledávají či jiným
způsobem načítají nebo je vytvářejí (v diagramu 4.1 zobrazeny jako metody tříd/venues,
/users a/checkins).Konkrétní resource (tj.jedna konkrétní venue,jeden checkin apod.),
který je v diagramu znázorněn jako třída asociovaná k resource třídě,pak má přes API přís-
tupných několik metod.Ty umožňují načtení dalších údajů o něm (například fotografie nebo
tipy u určené venue,seznam přátel uživatele aj.) – v diagramu jsou tyto metody zvýrazněny
tučně.Dále pro dotyčný resource existují na stejné úrovni i různé akce,v diagramu uvedeny
jako další metody třídy.
Obrázek 4.1:Model části Foursquare API endpointů
Diagram 4.1
3
ukazuje jen malou část API – tu,která je nejdůležitější pro mou aplikaci.
K endpointům uvedeným jako metody hlavního resource se přistupuje přímo pomocí URL,
které vznikne spojením názvu tohoto resource a dané metody,např.:
https://api.foursquare.com/v2/venues/search.
Metody uvedené v asociované třídě vyžadují v URL endpointu uvedení konkrétní resource,
např.:https://api.foursquare.com/v2/venues/4b6fff72f964a520c8022de3/tips.
3
Nejedná se však o plnohodnotný UML class diagram,jde spíše jen o vizualizaci struktury API.
4.1.FOURSQUARE 27
Lze přistupovat i přímo ke konkrétnímu resource:
https://api.foursquare.com/v2/venues/4b6fff72f964a520c8022de3.
Popis použitých endpointů
Tato část obsahuje přehled využívaných endpointů v rámci Foursquare API,včetně výčtu
parametrů při jejich volání a případných poznámek k nim.Kompletní dokumentaci každého
endpointu obsahuje dokumentace [8].
/venues
/search – vyhledá venues v okolí souřadnic definovaných parametremll ve okruhu
radius,limit udává počet vrácených výsledků (1-50),query může specifikovat
hledaný výraz;
/VENUE_ID
/– vrací kompletní venue objekt,jeho obsahem je však pouze několik posled-
ních fotografií a počet tipů,tyto je potřeba načíst samostatně;
/tips – načte tipy u venue,parametr limit udává jejich maximální počet (do
500),sort udává způsob řazení (dle nejnovějších/nejpopulárnejších/dle tipů
od přátel);
/photos – načte fotografie u venue,group udává jejich kategorii (fotografie
veřejné nebo přidané k check-inůmpřátel),limit udává max.počet fotografií
(do 500);
/users
/USER_ID (/self) – načte detaily zadaného uživatele,pokud je jako USER_ID
použito „self“,načte přihlášeného uživatele;
/checkins
/add – provede check-in v místě určeném parametrem venueId.Parametr shout
určuje zprávu,o kterou může být check-in doplněn.
/recent – vrátí seznam posledních check-inů přátel.
Ukázka práce s API
Pro příklad jak vypadá požadavek na API a jeho odpověď uvažujme,že chceme provést
hledání nejbližších venue v okolí souřadnic 50:076738 zeměpisné šířky a 14:41803 zeměpisné
délky (zhruba souřadnice Karlova náměstí v Praze).Provedeme tedy HTTP GET požadavek
na toto URL:
https://api.foursquare.com/v2/venues/search?ll=50.076738,14.41803&
v=20111125&client_id=(...)&client_secret=(...)
Úryvek vráceného JSON v odpovědi bude vypadat podobně:
28 KAPITOLA 4.GEOLOKAČNÍ SLUŽBY A JEJICH API
{
"meta":{"code":200 },
"notifications":[
{
"type":"notificationTray",
"item":{"unreadCount":0 }
}
],
"response":{
"venues":[
{
"name":"ČVUT FEL (KN)",
"id":"4b6fff72f964a520c8022de3",
(...)
},
(...)
]
}
}
V části response se nachází pole JSON objektů venues (v jedné odpovědi jich může
být až 50,jejich počet lze ovlivnit parametrem limit).To obsahuje zkrácené (kompaktní)
výpisy venue,ve kterých jsou obsaženy pouze základní informace (název,id,poloha,adresa,
základní statistiky venue...),další detaily jsou dostupné přímo při načtení detailu dané venue,
např.pro načtení plného detailu venue „ČVUT FEL (KN)“,která byla obsažena ve výsledku
výše uvedeného požadavku:
https://api.foursquare.com/v2/venues/4b6fff72f964a520c8022de3
Delší ukázka výpisu JSON při hledání venues v okolí zadaných souřadnic se nachází
v příloze,v kapitole D.1.1.
Pro vývojářské účely nabízí Foursquare vlastní webový API explorer
4
,kde je možné
jednoduše testovat jednotlivé endpointy a prohlížet odpovědi serveru.
Omezení,problémy a zhodnocení služby
Pravidla používání Foursquare API upravuje Foursquare API Platform Policy [7].Limit
požadavků na API je stanoven na 5000/hodina do databáze venue a 500/hodina pro poža-
davky vyžadující autentizovaného uživatele.U dat načtených z API musí být při jejich zo-
brazení uvedeno Foursquare jako jejich zdroj;při použití loga nebo ikonky Foursquare musí
být viditelně uvedeno,že Foursquare není se stránkou nijak spojen ani ji neautorizoval (toto
omezení se nachází v zápatí zobrazení detailu POI).Výrazným omezením však je,že není
povoleno kombinovat data z Foursquare API s jinými databázemi míst.To však neplatí v pří-
padě,když je Foursquare užíván jako primární zdroj dat (databáze míst),a k jednotlivým
místům nalezeným v této databázi by byly doplněny informace z dalších API.Toto omezení
by bylo třeba brát v potaz v případě veřejného nasazení služby (upravením způsobu vyh-
ledávání POI),nicméně pro potřeby práce jsou i tak výsledky vyhledávání v databázi míst
kombinovány s daty z API dalších LBS.
4
<https://developer.foursquare.com/docs/explore>
4.2.GOWALLA 29
V porovnání s API ostatních služeb určeným pro práci s POI je toto rozhodně nejob-
sáhlejší,s nejširšími možnostmi a dobrou dokumentací.Rovněž jeho rychlost je velice dobrá,
ačkoliv vzhledem k prudce rostoucímu počtu uživatelů jej čas od času postihnou krátkodobé
výpadky (v poslední době však již jen zřídkakdy).
I databáze míst je u Foursquare díky silné komunitě uživatelů (kteří nové venue vytvářejí
a systémem superusers
5
je také spravují) jedna z nejobsáhlejších a nejkvalitnějších.
4.2 Gowalla
Službu Gowalla [15] založili v roce 2009 Josh Williams a Scott Raymond.Služba byla
vytvořena hlavně jako geolokační hra (využívající princip augmented reality
6
).Uživatelé
(stejně jako ve Foursquare) prováděli check-in v určitých spotech
7
,avšak cílem nebyl „check-
in“ samotný ani sbírání bodů za něj – v rámci hry totiž mohli uživatelé v jednotlivých spotech
místě vyměňovat různé virtuální „předměty“,absolvovat návštěvy míst v rámci tripů (výletů;
jednalo se o seznamvíce spotů,který musel uživatel pro jeho splnění celý absolvovat) a dostá-
vat za tyto aktivity odznáčky.Tripy bylo také možno vytvářet a sdílet s dalšími uživateli.
Tuto herní funkcionalitu pak doplňovala možnost připojovat ve spotům komentáře (high-
lights) a nahrávat fotografie.
V září 2011 však autoři služby oznámili její radikální přepracování (tzv.Gowalla 4.0).
Celá funkcionalita s výměnou předmětů byla odstraněna,aplikace se přesměrovala mnohem
více na sdílení zážitků,což zahrnovalo i přejmenování check-inů na stories (příběhy).Místo
uživatelských výletů byly vytvořené social guides – průvodce pro veliká města,obsahující
seznam vybraných a doporučených spotů v dané oblasti.Tyto změny však nebyly uživateli
přijaty zcela pozitivně a po oznámení změn jich značná část přestala službu využívat.
Radikální obrat přišel 3.prosince 2011,tedy již v době vývoje aplikace GSAA a psaní
této bakalářské práce.Firma Facebook totiž oznámila,že „koupila“ Gowallu – nekoupila však
službu samotnou (ani její data),ale tým lidí,který za službou stál.Služba se tak nemá stát
součástí Facebooku,pouze tým,který ji vytvářel,bude začleněn do firmy Facebook a bude
pracovat také na jeho službách.Součástí oficiálního oznámení
8
zakladatele Gowally byla také
informace,že provoz služby Gowalla bude ukončen koncem ledna 2012.
Pro uživatele poskytuje Gowalla vlastní aplikace pro mobilní zařízení.Odlišností Gowally
byl svérázný designový styl,a to jak v aplikacích,tak na webových stránkách.Na těch
je rovněž možné procházet místa a check-iny přátel,komentovat a podobně.Služba dříve
nabízela i mobilní verzi svého webu,ta však již momentálně není dostupná.
Gowalla API
V okamžiku oznámení o plánovaném ukončení provozu služby již byla funkcionalita Gowalla
API do aplikace GSAAplně implementována.Do konce ledna 2012 by tak ještě mělo napojení
na službu Gowalla bez problémů fungovat.
5
Foursquare umožňuje zkušeným uživatelům stát se správcem a mít tak širší práva pro editace venues.
6
Rozšířená realita – přidání virtuálních prvků do zobrazení reality
7
Označení POI v názvosloví Gowally
8
<http://blog.gowalla.com/post/13782997303/gowalla-going-to-facebook>
30 KAPITOLA 4.GEOLOKAČNÍ SLUŽBY A JEJICH API
Ke Gowalla API bylo původně nutné přistupovat pouze na základě HTTP basic access
authentication
9
,což znamenalo zasílat spolu s požadavky jméno a heslo uživatele.Později
byla přidána i možnost přístupu pomocí OAuth 2.0,kterou využívá má aplikace.Mimo to
již není pro část požadavků nutná autorizace žádná a lze je tedy provádět v bezuživatelském
režimu (vyhledávání spots,načítání detailu spotu).
Podoba požadavků
Požadavky na Gowalla API směřují na adresu http://api.gowalla.com/,opět doplněnou
o adresu konkrétního endpointu.
Při požadavku je třeba předat prostřednictvím HTTP hlaviček dvě hodnoty:hlavička
X-Gowalla-API-Key obsahuje identifikátor aplikace a hlavička Accept obsahuje application/-
json,čímž je určený formát vrácených dat (JSON).
Autorizované požadavky jsou stejně jako u ostatních API doplněny o URL parametr
oauth_token.Příklad požadavku k načtení seznamu přátel uživatele:
HTTP hlavičky požadavku:
Accept:application/json
X-Gowalla-API-Key:fa574894bddc43aa96c556eb457b4009
URL požadavku:
http://api.gowalla.com/users/123456/friends?oauth_token=A1B2C34D56E78F9G
Podoba odpovědí
Odpovědi API jsou ve standardním JSON.Na rozdíl od ostatních služeb je ale jeho ob-
sah velice málo (až zmateně) strukturován.Například při načtení detailu spotu je naprostá
většina údajů v první úrovni JSON objektu daného spotu,přičemž pro větší přehlednost by
některé z nich mohly být utříděné více hierarchicky (např.hodnoty image_url,_image_url_20
a _image_url_50 by mohly být v jednom společném pod-objektu apod.).
Pro ukázku JSON odpovědi viz přílohu D.2.1.
Endpointy a struktura API
Struktura API Gowally není nikde kompletně popsána.V dokumentaci [17] je uvedeno
pouze několik základních endpointů (z toho navíc některé nefungují).Adresy hierarchicky
hlouběji zanořených endpointů jsou pak obsaženy ve vrácených hodnotách rodičovského end-
pointů.Například po načtení detailu spotu (/spots/SPOT_ID) obsahuje vrácený JSONobjekt
položky highlights_url,photos_url,activity_url a další.Na základě jejich hodnoty se
dá určit URL dalších endpointů.Dle dokumentace je to však záměr a při přístupu k API
by se měly URL určovat dynamicky dle těchto hodnoty,aby byla zajištěno fungování ap-
likací využívajících API i v případě změny adresy endpointů.Ironické však je,že některé
z těchto uvedených adres nefungují (např.je zde i hodnota items_url,ačkoliv funkcionalita
9
Metoda autentizace uživatele pomocí HTTP protokolu;uživatelské údaje jsou zasílány spolu v hlavičce
HTTP požadavku.
4.2.GOWALLA 31
spojená s „předměty“ byla odstraněna s příchodem Gowally 4.0).Celkově tak tento přístup
s dynamickými URL spíše celou práci s API komplikuje.
Nefunkčnost některých endpointů například znamenala,že nebylo jak načíst poslední
check-iny přátel.Nefungovala ani adresa endpointu,který měl poslední check-iny přátel
vracet uvedená v dokumentaci,ani adresa friends_activity_url,která byla při načtení
detailů přihlášeného uživatele obsažena ve vráceném objektu (a která se od předchozí lišila).
Přikročil jsemtedy k řešení,kdy je nejprve načten seznampřátel uživatele (který ale poslední
check-iny neobsahuje),a pak jsou iterativně samostatnými požadavky načítány detaily každého
uživatele,kde je poslední check-in uveden.Přirozeně se toto řešení ale negativně projevilo
na celkové době načítání posledních check-inů z Gowally.
Popis použitých endpointů
/spots
/– vyhledá spots v okolí souřadnic určených parametry lat a lng.Parametrem
radius je možno omezit okruh hledání v okolí souřadnic a parametr q určuje
vyhledávaný výraz;
/SPOT_ID
/– načte základní detail zadaného spotu;
/highlights – načte komentáře ke spotu;
/photos – načte fotografie uložené u spotu;
/users
/USER_ID (/me) – načte detaily uživatele,pokud je jako USER_ID uvedeno
„me“,načte detaily přihlášeného uživatele;
/categories
/– načte seznam všech kategorií,které mohou mít jednotlivé spots přiřazeny;
/CATEGORY_ID – načte detail kategorie;
/checkins – provede check-in ve spotu definovaném parametrem spot_id,může obsa-
hovat komentář k check-inu v parametru comment.
Ukázka práce s API
Pro příklad jak vypadá požadavek na API a jeho odpověď uvažujme,že chceme provést
hledání nejbližších spotů v okolí souřadnic 50:080821 zeměpisné šířky a 14:427375 zeměpisné
délky (zhruba souřadnice Václavského náměstí v Praze).Provedeme tedy HTTP GET poža-
davek na toto URL:
http://api.gowalla.com/spots?lat=50.080821&lng=14.427375&radius=500
Současně je třeba odeslat potřebné HTTP hlavičky,jak bylo uvedeno v kapitole 4.2.
Úryvek vráceného JSON v odpovědi bude vypadat podobně (delší ukázka je v příloze D.2.1):
32 KAPITOLA 4.GEOLOKAČNÍ SLUŽBY A JEJICH API
{
"groups":[],
"total_pages":1,
"spots":[
{
"name":"Lucerna",
"url":"/spots/103022",
"foursquare_id":null,
"checkins_url":"/checkins?spot_id=103022",
"highlights_url":"/spots/103022/highlights",
(...)
},
(...)
]
}
Objekt spots obsahuje pole objektů s jednotlivými spoty.Zde pak jsou např.hodnoty url
nebo highlights_url,které je možné použít pro načtení detailu spotu,např.takto pro
načtení spotu „Lucerna“:
http://api.gowalla.com/spots/103022
Obdobně pro načtení komentářů ke spotu je nutné vykonat požadavek na URL uvedené v
hodnotě highlights_url,např.takto:
http://api.gowalla.com/spots/103022/highlights
Omezení,problémy a zhodnocení služby
Pravidla pro použití Gowalla API jsou obsažena v krátkých Guidelines [16].Přístup k API
je omezen limitem 5 požadavků za sekundu.
NejvážnějšímproblémemAPI této služby je velice chabá dokumentace.Prakticky je pouze
dokumentováno,jak obecně provádět požadavky a jak provést OAuth autorizaci.Žádný
kompletní seznam endpointů a možných parametrů neexistuje,stejně tak není nikde popis
vrácených dat v JSON.Jako jediné poskytuje Gowalla svůj API explorer
10
se seznamem
ukázek jednotlivých endpointů.Tento seznamje však nekompletní,jak bylo uvedeno v popisu
API,některé endpointy jsou také nefunkční.Průzkum API tak probíhá pouze metodou
pokus-omyl.O existenci některých parametrů (například parametru q při vyhledávání spots,
pomocí kterého se určuje hledaný výraz) se dalo dozvědět pouze ze zmínek v mailing listu
služby
11
.
Vracené objekty API také často neobsahují ty hodnoty,které by bylo pro použití v mé
aplikaci třeba – například při načtení detailu spotu jsou sice vráceny URL adresy obrázků
kategorií,avšak jenomve velikostech 100100px a 200200px.Abych získal adresu malého,
30  30px,obrázku,který využívám při zobrazení detailu POI,je třeba udělat zvláštní
požadavek a načíst detail kategorie (který ale zase obsahuje jen adresu 200 200px a této
malé verze,URL prostřední 100px verze obrázku zde pro změnu chybí,ačkoliv v detailu
venue bylo obsaženo...).
10
<http://gowalla.com/api/explorer>
11
Viz <https://groups.google.com/forum/#!forum/gowalla-dev>.
4.3.FACEBOOK 33
Další nevýhodou je relativně pomalá odezva celého API.Ta je při načítání posledních
check-inů přátel ještě znásobená nutností načítat každého přítele zvlášť,obdobně při načítání
detailu spotu jsou zase nutné požadavky na detaily kategorií.OAuth autorizace zase vyžaduje
potvrzení přístupu i v případě,že jej již uživatel aplikaci dříve potvrdil (ostatní služby
v tomto případě provedou rovnou přesměrování,viz kroky 3 a 5 v části Proces autorizace
pomocí OAuth).
S API se nepracovalo vůbec dobře – kromě uvedených problémů s dokumentací a ne-
funkčností některých endpointů také v případě chyby nevrací často ani žádný specifičtější
chybový kód či zprávu,která by pomohla odhalit,kde je problém,některé položky obsahují
nestandardní obsah (např.formát data a času u check-inů neodpovídá žádnému běžnému
standardu),adresa spotů neobsahuje při přístupu přes API ulici,ale pouze „lokalitu“ a „re-
gion“ a podobně.
Ani databáze míst (spotů) Gowally není příliš obsáhlá,a protože místa přidávají pouze
uživatelé,souvisí to s relativně malýmrozšířenímtéto služby – celosvětově měla řádově méně
uživatelů než konkurenční Foursquare.I to pravděpodobně patří mezi příčiny ohlášeného
konce této služby.
Zatímco všechny ostatní služby umožňují prostřednictvím webu přístup uživateli k sez-
namu aplikací,kterým přes OAuth udělil oprávnění k přístupu ke svým datům,včetně
možnosti toto oprávnění odebrat,nikde na webu Gowally se tato možnost nenachází.A to
přesto,že i nápověda Gowally se na tuto možnost odkazuje.
4.3 Facebook
Facebook [2] je dnes největší sociální služba na světě;založená v roce 2004 Markem Zucker-
bergem a dnes s více jak 800 miliony uživatelů po celém světe.
Geolokační prvky však ve funkcionalitě Facebooku dlouho chyběly.Jako reakci na nástup
služeb Foursquare a Gowalla se Facebook rozhodl implementovat podobný geolokační sys-
tém a v srpnu 2010 ohlásil službu Facebook Places [3].Prostřednictvím mobilních aplikací
Facebooku mohli uživatelé provést check-in v určitém místě a sdílet jej se svými přáteli na
Facebooku.Na rozdíl od konkurenčních služeb neměly Facebook Places žádné gamifikační
prvky a po ohlášení se ani netěšily velikému uživatelskému zájmu – lidé,kteří měli o tuto
funkcionalitu zájem,zpravidla spíše používali Foursquare,ze kterého lze navíc check-in na
Facebook automaticky sdílet.O rok později (srpen 2011) se Facebook rozhodl samostatnou
službu Facebook Places zrušit a její funkcionalitu zahrnout pouze jako doplněk ke stáva-
jícímu „sdílení statusů“,fotografií aj.Uživatelé tak mohou připojit ke svému statusu infor-
maci o místě – tedy že se zde nacházejí,čímž zde prakticky provedou check-in.Navíc mohou
označit další přátele,kteří se zde s nimi nacházejí.U fotografií lze zase označovat že z tohoto
místa daná fotografie pochází a podobně.
Odlišností Facebooku od ostatních služeb je,že nemá oddělenou databázi míst určenou
pouze pro check-iny.Jednotlivé entity na Facebooku – nejčastěji „stránky“ (Pages) mohou
mít zadanou svojí poštovní adresu,od které je odvozena jejich poloha (typicky stránka
restaurace,firmy apod.).A právě tato místa mohou uživatele připojovat ke svým statusům
aj.a provádět v nich tak check-in.Kromě stránek ale mohou uživatelé přidávat i vlastní
místa,která mají podobu tzv.„komunitní stránky“,s určenou polohou.Stránky se zadanou
34 KAPITOLA 4.GEOLOKAČNÍ SLUŽBY A JEJICH API
polohou mají také další obsah (ať už uživateli tvořený,nebo vkládaný správcem stránky),z
pohledu mé aplikaci stojí za zmínku hlavně fotografie.
Facebook Graph API
Myšlenkou Facebooku,na kterou je navázané i jeho API,je tzv.social graph
12
,který reprezen-
tuje osoby a jejích spojení se vším,co je zajímá – dalšími osobami,zájmy,místy,fotografiemi,
událostmi a podobně.
Protože API Facebooku poskytuje přístup do tohoto social graph,je nazvané Facebook
Graph API.Každý objekt v Graph API má své unikátní ID,prostřednictvím kterého lze
přistupovat k jeho vlastnostem.Dále má každý objekt mnoho druhů spojení na další objekty
– tato spojení je třeba načítat zvlášť.
Část API je přístupná veřejně,i bez autorizace aplikace – jedná se o obsah,který je
sdílen veřejně i na Facebooku.Všechna další funkcionalita,včetně vyhledávání v Graph
API,je pak dostupná až po autorizaci aplikace – kromě běžné registrace aplikace jako OAuth
consumera musí tato pro uskutečňování dalších volání v API (např.vyhledávání míst) mít
vlastní autorizační OAuth token (tedy na rozdíl od ostatních služeb nestačí identifikátor
aplikace a její tajný klíč).Proces autorizace aplikace se v dokumentaci [5] Facebooku nazývá
„App Login“.
Pro volání vyžadující přihlášeného uživatele (načítání přátel,provedení check-inu aj.) pak
je nezbytné provést OAuth 2.0 autorizaci,specifikem Facebooku je využití parametru scope
při kroku 2 OAuth autorizace,pomocí kterého se určuje rozsah práv přidělených aplikaci
13
.
Tento způsob kontroly přístupu je nutný z důvodu,že geolokační funkcionalita je jen jednou
z mnoha částí Facebooku – uživatel tak povoluje pouze přístup k tomuto rozsahu dat:
 user_about_me – základní informace o uživateli,
 user_checkins – načítání check-inů uživatele,
 friends_checkins – načítání check-inů přátel,
 publish_checkins – provádění check-inů,
 offline_access – bez tohoto parametru by vypršel autorizační token po krátké době
a aplikace by tak o něj musela žádat znovu.
Podoba požadavků
ZáklademURL adresy API na kterou se provádí požadavky je https://graph.facebook.com/.
Ta je (vyjma hledání) doplněna o ID objektu v Graph API a případně i o typ dalších objektů,
se kterými má rodičovský objekt nějaký vztah.Příklad URL sloužícího k načtení přátel přih-
lášeného uživatele:
https://graph.facebook.com/me/friends.
12
Volně přeloženo jako „společenský graf“ či „společenská struktura“
13
Všechny možné hodnoty parametru scope jsou uvedeny zde:<https://developers.facebook.com/
docs/reference/api/permissions/>.
4.3.FACEBOOK 35
Vyjma požadavků na veřejně dostupné informace musí požadavky obsahovat parametr
access_token.Ten je třeba například i na vyhledávání míst v okolí,může se však jednat o au-
torizační tokem přidělený aplikaci;jinak je třeba platný access_token uživatele.Na rozdíl
od ostatních API však není třeba při provádění požadavků používat hodnoty client_id ani
client_secret – ty se používají pouze v rámci procesu OAuth autorizace.Při samotných
požadavcích se tedy autorizace provádí pouze parametrem access_token.
Endpointy a struktura API
Vzhledem k myšlence social graphu je struktura API Facebooku – i přes veliký objem dat,
která jsou přes něj přístupná – velice jednoduchá.
Načítání objektů Přístup k endpointům je prostřednictvím URL ve tvaru:
https://graph.facebook.com/ID/CONNECTION_TYPE.Základemje ID objektu.To může být
jeho číslo,u objektů se jmény (aliasy) je možno využít také toto – např.https://graph.-
facebook.com/cocacola i https://graph.facebook.com/40796308305 reprezentuje ten samý
objekt – stránky firmy Coca-Cola.Místo ID aktuálně přihlášeného uživatele je možno rovněž
využít speciální alias me.
Volitelná část CONNECTION_TYPE značí typ objektů,vůči kterým má objekt ID vztah
a které se mají načíst (např.hodnota photos pro načtení fotografií přiřazených k objektu,
friends pro načtení přátel,checkins pro načtení check-inů a podobně).
Vyhledávání objektů Odlišný způsob než přístup přes ID objektu se použije při vyh-
ledávání:https://graph.facebook.com/search?q=QUERY&type=OBJECT_TYPE.Parametr q
je hledaný výraz,type udává,v jakém druhu objektů se má vyhledávat (např.user pro
hledání uživatelů,pages pro hledání stránek,place pro hledání míst a checkin pro hledání
checkinů).V případě vyhledávání míst je ještě doplněn parametr center určující souřadnice,
okolo kterých se vyhledává,a distance značící okruh (radius) vyhledávání.
Vytváření objektů Objekty se vytváří pomocí HTTP POST požadavků na URL daného
typu objektu.Pro mou aplikaci nejpodstatnější je vytvoření checkinu,pro které se použije
adresa:https://graph.facebook.com/me/checkins/,doplněná o parametry place (ID ob-
jektu,kde se provádí check-in),message (zpráva k check-inu,použije se jako text statusu)
a coordinates (udávající současnou polohu uživatele).
Další parametry Požadavky do Graph API lze doplňovat i o různé další parametry –
parametrem fields lze vybrat,která pole má obsahovat vrácený JSON objekt,pomocí
parametru ids lze v rámci jednoho požadavku načítat více objektu,date_format umožňuje
změnit formát vracených dat a časů a podobně.
Ukázka práce s API
Pro ukázku uvažujme požadavek pro vyhledání míst v okolí Vítězného náměstí v Praze
(souřadnice 50.10059 a 14.395393).HTTP GET požadavek bude směřovat na tuto adresu:
36 KAPITOLA 4.GEOLOKAČNÍ SLUŽBY A JEJICH API
https://graph.facebook.com/search?type=place&center=50.10059,14.395393&
distance=500&access_token=(...)
Odpověď bude obsahovat podobná JSON data:
{
"data":[
{
"name":"Starbucks Dejvická",
"category":"Local business",
"location":{
"city":"Praha",
"country":"Czech Republic",
"latitude":50.099835681993,
"longitude":14.395145902707
},
"id":"201343903230884"
},
(...)
]
}
U objektu je zde mj.hodnota id,kterou je možné použít pro načtení detailu daného objektu.
V tomto případě by šlo o požadavek na URL:
https://graph.facebook.com/201343903230884
Delší ukázka výsledků vyhledávání se nachází v příloze D.3.1.V příloze D.3.2 je zase
ukázka načtení detailu jednoho objektu.
Pro testování Graph API poskytuje i Facebook vlastní API explorer
14
.
Omezení,problémy a zhodnocení služby
Pravidla použití Graph API jsou popsána ve Facebook PlatformPolicies [4].Limit požadavků
se nikde oficiálně neuvádí,měl by však být alespoň 600 požadavků za 600 sekund.Toto
omezení nijak neovlivňuje možnost načítat více objektů v rámci jednoho požadavku (pomocí
parametru ids,viz výše).
API Facebooku je na velmi vysoké úrovni.Má velice dobrou dokumentaci,je pro něj
dostupných mnoho vývojářských nástrojů,prostřednictvím API je jednoduchý přístup k ve-
likému množství údajů.Chytře je udělaná i správa oprávnění pro aplikaci i kontrola uživatele
nad udělenými oprávněními.Přes web může uživatel dokonce kontrolovat,kdy jaká z aplikací,
kterým udělil oprávnění,přistupovala k jakým datům.
Ohledně geolokační funkcionality je však vidět její neúplná „zralost“ i to,že se jedná
o doplněk k ostatní funkcionalitě.Vyhledávání není možné dle kategorií,navíc z kategorií
stránek je vidět,že jsou kategorizovány spíše k odlišení typu majitele stránek (firma,kapela,
celebrita...) než k vyhledávání míst (takže např.firmy takřka jakéhokoliv typu mají kategorii
„Local business“).Při načtení check-inů přátel se zase může stát,že zde nebudou pouze
přátelé – pokud (z pohledu přihlášeného uživatele) „cizí“ osoba provede veřejný check-in,
14
<https://developers.facebook.com/tools/explorer/>
4.4.GOOGLE PLACES 37
při kterém označí jako další přítomné osoby osobu,která již přítel přihlášeného uživatele je,
bude tento „cizí“ člověk uveden mezi check-iny přátel,a pouze jako doplňující hodnota (tag)
bude uvedena osoba,která je přítel (navíc bez odlišení že se jedná o přítele,což znemožňuje
jednoduché filtrování těchto check-inů).
Narazil jsemtaké na jeden technický problém– pokud byl při vyhledávání míst dle názvu
(použití parametru q) použit řetězec s diakritikou,nebyly vráceny žádné výsledky.Toto
tak muselo být řešeno na straně mé aplikace,kdy je před odesláním požadavku diakritika
z hledaného dotazu odstraněna.Výsledek pak již správně obsahuje i místa s diakritikou,vyh-
ledávání ji tedy evidentně nebere v potaz,pouze se nesmí ve vyhledávaném dotazu nacházet.
Databáze míst
15
Facebooku do značné míry těží z ohromné rozšířenosti celé služby –
kromě toho,že objekty s polohou vytvářejí vlastníci stránek,přidávají je také uživatele
jako tzv.„komunitní stránky“.Síť míst tak je již poměrně rozsáhlá,s postupující integrací