ˇ ENI´ TECHNICKE´ V BRNEˇ VYSOKE´ UC BRNO UNIVERSITY OF TECHNOLOGY
ˇ NI´CH TECHNOLOGII´ FAKULTA INFORMAC ˇ ´ITAC ˇ OVE´ GRAFIKY A MULTIME´DII´ ´ STAV POC U FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF COMPUTER GRAPHICS AND MULTIMEDIA
´ ZKU.CZ NAPROCHA ´ VA´NI´ OKOLI´ MOBILNI´ SLUZˇBA PRO POZNA NAPROCHA´ZKU.CZ – MOBILE SERVICE FOR NEIGHBOUR WALKS
ˇ SKA´ PRA´CE ´R BAKALA BACHELOR’S THESIS
AUTOR PRA´CE
ˇ KAL ROSTISLAV DOC
AUTHOR
VEDOUCI´ PRA´CE SUPERVISOR
BRNO 2013
˝ Ing. IGOR SZOKE, Ph.D.
Abstrakt Tato bakalářská práce se zabývá vývojem mobilní služby – aplikace pro platformu Android. Součástí je návrh, implementace a testování aplikace pro poznávání okolí formou procházek. Práce také popisuje problematiku vývoje aplikací pro mobilní zařízení se systémem Android. Výsledná aplikace je naprogramovaná v jazyce Java s použitím vývojového kitu Android SDK a byla vytvořena ve vývojovém prostředí Eclipse s využitím pluginu ADT. Při tvorbě byl použit framework SherlockActionBar a mapové podklady GoogleMaps.
Abstract This bachelor’s thesis is mainly about development of new mobile application for Android system, which gives its users oportunity to get to know their suburb better through using it. Thesis includes design of application, its implementation and testing. This thesis also provides informations about developing applications for Android in general. Application is program in Java language and it uses development kit Android SDK, development environment Eclipse and plugin called ADT. In thesis was used framework SherlockActionBar and GoogleMaps.
Klíčová slova Android, Google, mobilní aplikace, GPS, mapa, procházka, ActionBarSherlock, SQLite
Keywords Android, Google, mobile application, GPS, map, walk, ActionBarSherlock, SQLite
Citace Rostislav Dočkal: Naprocházku.cz – mobilní služba pro poznávání okolí, bakalářská práce, Brno, FIT VUT v Brně, 2013
Naprocházku.cz – mobilní služba pro poznávání okolí Prohlášení Prohlašuji, že jsem tuto bakalářskou práci vypracoval samostatně pod vedením Ing. Igora Sz˝okeho, Ph.D. Uvedl jsem všechny literární prameny a publikace, ze kterých jsem čerpal. ....................... Rostislav Dočkal 15. května 2013
Poděkování Rád bych poděkoval vedoucímu mé bakalářské práce Ing. Igorovi Sz˝oke, Ph.D. za odborné vedení, rady a jeho pomoc, kterou mi při tvorbě práce poskytl.
c Rostislav Dočkal, 2013.
Tato práce vznikla jako školní dílo na Vysokém učení technickém v Brně, Fakultě informačních technologií. Práce je chráněna autorským zákonem a její užití bez udělení oprávnění autorem je nezákonné, s výjimkou zákonem definovaných případů.
Obsah 1 Úvod
3
2 Platforma Android 2.1 Výběr mobilní platformy . . . . . 2.2 Seznámení se systémem Android 2.3 Architektura operačního systému 2.4 Vývoj aplikací pro OS Android . 2.5 Základní komponenty aplikace . .
. . . . .
4 4 4 5 7 8
. . . . . . . . . . . .
12 12 12 13 14 14 14 14 15 15 16 16 16
. . . . . . . .
17 17 17 18 19 20 21 21 22
5 Testování a publikace 5.1 Testování aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Zveřejnění služby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Budoucnost projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 23 24 25
3 Návrh aplikace 3.1 Konkurenční projekty . . . . . . 3.1.1 SmartMaps Navigator . . 3.1.2 Turistická navigace Beta . 3.1.3 Zhodnocení konkurence . 3.2 Typy uživatelů . . . . . . . . . . 3.3 Použité technologie . . . . . . . . 3.3.1 GPS . . . . . . . . . . . . 3.3.2 GoogleMaps . . . . . . . . 3.3.3 Uložení perzistentních dat 3.3.4 SQLite databáze . . . . . 3.3.5 ActionBarSherlock . . . . 3.4 Komunikace se serverem . . . . . 4 Implementace 4.1 Uživatelské rozhraní . . . . . . 4.2 Komunikace s webovou službou 4.3 Databáze . . . . . . . . . . . . 4.4 Zobrazení mapových podkladů 4.5 Vytvoření vlastní procházky . . 4.6 Práce s vlákny . . . . . . . . . 4.7 Vyhledávání procházek . . . . . 4.8 Google Analytics . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
1
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
. . . . .
. . . . . . . . . . . .
. . . . . . . .
6 Závěr
26
A Obsah CD
28
B Definice metod aplikačního rozhraní
29
2
Kapitola 1
Úvod Mobilní telefon dnes používá téměř každý. Někteří jen z důvodu nutnosti být k dispozici ” kdykoli a kdekoli“, jiní si bez něj naopak nedokáží svůj život vůbec představit a s trochou nadsázky se dá říct, že telefon je jejich nejlepším přítelem a každodenním společníkem. S příchodem chytrých telefonů se tento trend ještě více rozšířil, a to především u mladší generace. Výkonnost mobilních zařízení se velmi rychle zvyšuje. Hardwarové konfigurace, které byly nadstandardem ještě před pár lety u stolních PC či notebooků, se dnes téměř běžně objevují v telefonech nebo tabletech (procesory s více jádry, operační paměť v jednotkách GB apod.). Tyto parametry dovolují, spolu s možností využití například bezdrátového připojení k internetu, GPS modulu nebo kamery, vytvářet aplikace, se kterými se u osobních počítačů nesetkáme. Právě tento aspekt vedl k výběru bakalářské práce zaměřené na tvorbu mobilní služby. Pro její vývoj byla zvolena open-source1 platforma Android, která je vyvíjena společností Google Inc. Více informací ohledně samotné platformy a vývoje aplikací pro ni určených je uvedeno v kapitole 2. Mobilní aplikace naprocházku.cz, která je předmětem této bakalářské práce, slouží k vyhledávání, ukládání a sdílení krátkých procházek v přírodě i urbanistickém prostředí. Vyhledání jednotlivých procházek je prováděno na základě různých kritérií, které si může uživatel zvolit. Jedním z hlavních cílů služby je vyplnění mezery na trhu mobilních aplikací. Toto jsou základní požadavky, které byly vytyčeny při návrhu služby, a na jejichž základě poté byla celá aplikace vytvořena. Této části návrhu je věnována kapitola 3. V ČR existuje několik konkurenčních aplikací, které jsou ale zaměřeny spíše na delší výlety a turistiku, než na procházky. Více o nich v kapitole 3.1. Hlavní motivací byla možnost seznámení se s tvorbou aplikací na relativně nové a stále se vyvíjející platformě Android a vytvoření mobilní služby, kterou by mohli využívat jednak mí známí a kamarádi, ale i široká skupina majitelů mobilních zařízení s tímto operačním systémem. Problematika týkající se implementační části je uvedena v kaptiole 4. Další velmi zajímavou výzvou pro mne bylo propojení mobilní aplikace s webovou částí služby naprocházku.cz, jenž je popsána v 4.2. Autorem této webové služby, která vznikala rovněž jako bakalářská práce, je Jiří E. Špaček. Jelikož je nutné při návrhu jakéhokoli softwaru jeho kvalitní otestování, nebyla opomenuta ani tato stránka. Díky tomu vznikly podklady pro část 5. Poslední kapitola 5.2, týkající se publikování, zveřejnění projektu na GooglePlay, je doplněna o možné směry dalšího vývoje a budoucnosti této aplikace. 1
software s otevřeným zdrojovým kódem
3
Kapitola 2
Platforma Android V zadání této diplomové práce nebyla přímo specifikována mobilní platforma, pro kterou má být výsledná služba určena. V úvahu proto přicházely tři nejrozšířenější operační systémy mobilních zařízení dneška: Windows Phone, iOS a Android.
2.1
Výběr mobilní platformy
První operační systém, který přicházel v úvahu, byl vyvinutý společností Microsoft. Jedná se o Windows Phone, který je nástupcem Windows Mobile. Jako cílový systém pro aplikaci naprocházku.cz však nebyl vybrán díky jeho poměrně malému zastoupení na trhu mobilních zařízení v ČR, viz obr.2.1. Operační systém společnosti Apple Inc s názvem iOS byl původně určen pro mobilní telefony iPhone. Později se rozšířil i do tabletů iPad, či multimediálních přehrávačů iPod. Jedná se o odlehčenou verzi MAC OS X pro mobilní zařízení. Důležitou vlastností je fakt, že tento operační systém je určen pouze pro zařízení od firmy Apple. Není se s ním možné setkat na žádném jiném mobilním přístroji. Vzhledem k pořizovací ceně zařízení společnosti Apple, ve srovnání s konkurenčními přístroji, která je výrazně vyšší, bylo rozhodnuto pro poslední z trojice platforem. Třetí možností byl systém Android. Jelikož má být aplikace naprocházku.cz určena primárně pro český trh, důležitý aspekt pro výběr zde sehrálo rozšíření právě této platformy, která aktuálně pokrývá více než 63% trhu, jak je vidět z grafu 2.1, který zobrazuje období posledních dvou let výzkumu1 . Stále rostoucí tendence předpovídá, že ani v následujícím období tomu nebude jinak. OS Android, který je tvořen pod záštitou společnosti Google Inc, a je určen pro široké spektrum mobilních zařízení. V současnosti se sním ale můžeme setkat také u chytrých domácích spotřebičů, jako jsou chladničky, pečící trouby, či pračky a sušičky 2 .
2.2
Seznámení se systémem Android
Android je rozsáhlý a dobře známý produkt tvořen pod záštitou společnosti Google Inc. Jedná se o operační systém šířený pod licencí open-source. Zjednodušeně řečeno smí uživatel při splnění určitých podmínek systém používat bez omezení zdarma. Díky této licenční 1
http://gs.statcounter.com/#mobile os-CZ-monthly-201105-201304 http://www.androidmarket.cz/ruzne/invaze-chytrych-domacichspotrebicu-na-ces-2013 2
4
Obrázek 2.1: Zastoupení mobilních platforem v ČR politice mají všichni uživatelé přístup ke zdrojovým kódům, které poté mohou užívat a případně upravovat podle svých vlastních potřeb. Základem operačního systému je linuxové jádro verze 2.6, které zabezpečuje správu paměti, správu procesů, stará se o přístup k sítím a ovladačům vestavěných senzorů a komponent. K funkcím jádra nemohou aplikace přistupovat přímo, ale pouze skrze Android API. Součástí platformy je také virtuální stroj, který optimalizuje paměť a hardwarové prostředky v mobilním prostředí. Android je progresivním operačním systémem, který je primárně vyvíjen jako platforma pro PDA, chytré telefony a tablety. Jeho základy byly postaveny tak, aby umožnily vývojářům vytvářet aplikace od jednoduchých až po velmi rozsáhlé, přičemž mohou plně využívat všech vlastností, jenž jsou poskytovány zařízeními, na nichž je OS Android spuštěn. Tato platforma má do budoucna stále se rozvíjející tendence. Již dnes je možné se setkat s tzv. inteligentními domácími spotřebiči (chladničky, pečící trouby, pračky či sušičky), které obsahují právě tento operační systém, na němž běží aplikace obstarávající veškerou funkčnost. I přesto, že je Android jedním z nejmladších operačních systémů, má slibné vyhlídky do budoucna[7]. Pro vytvoření aplikace je stěžejní znalost jednotlivých komponent systému a jejich funkcí v něm.
2.3
Architektura operačního systému
Struktura OS Android se skládá z pěti vrstev, přičemž každá z nich má na starosti jinou operaci a vystupuje téměř jako samostatný celek. Linux kernel Linuxové jádro je nejnižší vrstvou architektury. Její základní funkcí je implementace abstrakce mezi hardware a software ve vyšších vrstvách, dále řízení celého systému – obsahuje kontrolu nad systémem, koordinaci činnosti všech spuštěných procesů, podporu správy paměti, také správu sítí atd.
5
Obrázek 2.2: Architektura systému Andorid [2] Libraries Poskytuje velké množství rozhraní API pro vývoj aplikací, např. android.app, android.database, android.content, android.provider, android.location apod. Právě těchto posledně zmíněných knihoven bylo využito při tvorbě aplikace naprocházku.cz. Dále jsou vývojářům k dispozici knihovny vytvořené v jazyce C/C++, které využívají různé komponenty systému. Jako příklad je možné uvést knihovnu SQLite, viz 3.3.4. Android Runtime Obsahem této vrstvy jsou základní Java knihovny a virtuální stroj – DALVIK Virtual Machine, jenž využívají základních vlastností jádra, např. koordinaci procesů, správu paměti a práci s vlákny. Právě jeho optimalizace mají vliv na výkon a úsporu energie. Každá spuštěná aplikace na zařízení je potom proces s instancí právě tohoto virtuálního stroje. Application Framework Nejdůležitější vrstvou operačního systému je pro vývojáře bezesporu Application Framework, neboli aplikační rámec. Poskytuje totiž aplikacím přístup ke službám, které zpřístupňují prvky graficko-uživatelského rozhraní (View System), ovládání životního cyklu aplikace (Activity Manager), možnost spouštění jiných aplikací (Content Provider), či přístup k hardwaru zařízení). Spojení právě této skutečnosti s otevřenou vývojovou platformou systému Android je důvodem vzniku a inovací velkého množství aplikací. Applications Nejvyšší část struktury označuje samotné aplikace, které jsou buď předinstalovány, nebo si je může uživatel dodatečně stáhnout a doinstalovat sám prostřednictvím GooglePlay.
6
2.4
Vývoj aplikací pro OS Android
Tvorba aplikací pro mobilní zařízení (telefony, tablety) se poněkud liší od vývoje programů určených pro operační systémy osobních počítačů a notebooků. Mobilní aplikace jsou vytvářeny ve vývojovém prostředí na počítači, kdežto finální testování a výsledné nasazení probíhá na mobilních zařízeních [7]. Za účelem zúžení této propasti mezi počítačem a výsledným zařízením je pro platformy použit Android emulátor. Více informací o něm je uvedeno v části 2.4. Java Development Kit (JDK) Protože se aplikace, respektive drtivá většina z nich, pro Android programují v jazyce Java, je nutností nainstalovat Java Development Kit. Ten obsahuje základní nástroje a knihovny pro tvorbu aplikací na platformě Java. Software Development Kit (SDK) Nástroje, které poskytuje Software Development Kit, jsou nezbytné pro vývoj, testování a odladění aplikací pro Android[1]. Součástí tohoto balíčku jsou knihovny API, dokumentace, ukázky použití včetně zdrojových kódů atd. Dále je zde obsažen SDK Manager, díky kterému je možné stažení a použití vybraných verzí OS Android. Na to navazuje AVD – Virtuální mobilní zařízení, které dovoluje emulovat přístroje s různými verzemi OS Android, respektive jen s těmi, které byly staženy SDK Managerem. U všech těchto zařízení je možno nastavit požadovanou hardwarovou konfiguraci, např. velikost a rozlišení displeje, velikost paměti RAM, případně paměťové karty, přítomnost GPS modulu a mnoho dalších. Poskytuje rovněž možnost simulace odchozích a příchozích hovorů, či sms [7], což se velmi dobře hodí pro simulování běhu aplikací v situacích z reálného života. Eclipse – vývojové prostředí Eclipse je open-source vývojová platforma, která je určena primárně pro programovací jazyk Java. Díky pluginům je ale možné rozšířit seznam podporovaných jazyků o mnoho dalších, např. PHP nebo C++. S jistotou se dá říci, že po spojení s Android SDK se jedná o nejkomfortnější způsob jak tvořit Android aplikace. Získáme totiž nejen funkční kompilátor zdrojového kódu, ale zároveň velmi účinný debugger a emulátor, o kterém byla řeč výše. Android Development Tool (ADT) Posledním prvkem vývojového prostředí je Android Development Tool, který se dá označit za určité propojení mezi prostředím Eclipse a Android SDK. Konkrétně jsou díky ADT programátorům k dispozici editory vizuálních částí aplikace, XML editory a další ladící panely.
7
2.5
Základní komponenty aplikace
V každé aplikaci určené pro zařízení s Androidem se můžeme setkat s několika základními stavebními prvky [7]. Activity Dá se říci, že každá aktivita je vizuální reprezentací právě jedné obrazovky aplikace. Celá aplikace se poté sestává z několika těchto aktivit, přičemž jedna je zvolena jako hlavní – je zobrazena při spuštění aplikace a z ní jsou poté otvírány další aktivity. Po zobrazení nové obrazovky (aktivity), je ta předchozí pozastavena a uložena do LIFO zásobníku. Jedná se tedy o frontu, kdy po stisknutí tlačítka zpět se právě aktivní (zobrazená) aktivita ukončí a uživatel se dostane k aktivitě, která byla spuštěna před ní. Tímto způsobem může právě samotný uživatel ovlivnit do jisté míry životní běh jednotlivých aktivit. Pokud se však objeví situace, kdy nastane nedostatek paměti, je starostí systému se o vyřešení postarat. Řešením je ukončení některých méně důležitých aktivit. Z toho vyplývá, že aplikace právě běžící může být zastavena a ukončena předčasně. Níže na obr. 2.3 je uvedeno schéma tohoto procesu3 . Životní cyklus aktivity se podle [7] a [2] dělí na tři základní etapy: • Úplný životní cyklus Každá aktivita začíná jejím vytvořením, jenž je provedeno metodou onCreate(). Jejím protipólem je metoda onDestroy(), která je volána pro zrušení aktivity. To je prováděno systémem implicitně, případně explicitně metodou finish(). Těsně před svým ukončením každá aktivita uvolní veškeré prostředky, které během své existence zabrala. • Viditelný životní cyklus Mezi voláním metod onStart() a onStop() se aktivita stává viditelnou pro uživatele. Pokud je spuštěna nová aktivita, díky níž se dostala původní do pozadí, zavolá se právě metoda onStop(), která zastaví původní aktivitu. • Životní cyklus v popředí Po zavolání metody onResume() se příslušná aktivita dostane do popředí před všechny ostatní a uživatel s ní může interagovat. V případě volání metody onPause() je, jak již název napovídá, aktivita pozastavena a komunikace s uživatelem poté není možná až do dalšího zavolání metody onResume(). Jak je vidět, tento cyklus se může pro danou aktivitu opakovat i několikrát za sebou. Pro úplnost popisu metod životního cyklu aktivit v systému Android chybí už jen zmínit metodu onRestart(). Ta se uplatní v případě, kdy je aktivita zastavena a je zapotřebí její obnovení.
3
http://developer.android.com/guide/components/activities.html
8
Obrázek 2.3: Životní cyklus aktivity Services Služby jsou velmi podobné aktivitám. Zásadní rozdíl mezi nimi je ten, že služby neposkytují grafické uživatelské rozhraní a mohou provádět dlouhodobé operace na pozadí. Content Providers Tato komponenta dovoluje aplikacím zprostředkovaně přistupovat k datům, načítat je, či ukládat. Jako příklad je možné uvést obrázky, audio, video apod. Za zmínku určitě stojí, že programátor může vytvořením vlastního poskytovatele obsahu zveřejnit a dát k dispozici vlastní data jiným aplikacím pomocí třídy ContentProvider. Za určitých podmínek je také možné využít k tomuto účelu již existujícího poskytovatele obsahu.
9
Intents Intenty, neboli záměry se dají přirovnat ke zprávám, kterými mezi sebou komunikují jednotlivé aktivity. Jako příklad je možné uvézt zobrazení webové stránky, odeslání SMS zprávy atd. Základní rozdělení těchto záměrů je na implicitní a explicitní, přičemž u implicitních není přímo určena aplikace, která má akci provést. Tu si může zvolit uživatel. Typickým příkladem může být volba webového prohlížeče, pokud jich je v zařízení nainstalováno víc, či výběr prohlížeče souborů *.pdf. Broadcast Receivers Jedná se o prvek, který podobně jako služba nemá grafické uživatelské rozhraní. Broadcast receiver naslouchá určitému typu oznámení, na které reaguje spuštěním určité komponenty, nebo avizuje tuto skutečnost do stavového řádku. Jako příklad je možné uvést reakci na přijetí SMS zprávy, či ztrátu signálu sítě Wi-Fi. Notifications Oznámení se využívá především v situacích, kdy se provedla, provádí, nebo bude provádět v aplikaci určitá, svým způsobem důležitá činnost, o které by měl uživatel vědět. Další možností, při níž bývá oznámení velmi často využíváno, je informovat v případě, kdy určitá akce trvá delší dobu a uživatel by si mohl myslet, že aplikace zamrzla. Typickým příkladem takovéto činnosti je stahování dat z internetu, případně načítání velkého souboru apod. V sytému Android se setkáváme s třemi základními možnostmi, jakými může programátor uživateli oznámit určitou skutečnost: • Toast oznámení Tento typ avizace se objeví na displeji jen na určitou dobu a samovolně, bez zásahu uživatele, opět zmizí. Jeho nespornou výhodou je možnost použití u služeb, či aplikací běžících na pozadí, které mají možnost Toastů využívat. • Oznámení v dialogovém okně Dialogové okno je do jisté míry opakem předchozího typu oznámení, vyžaduje totiž uživatelovu interakci. Pokud je aplikace v popředí, často je potřeba aby uživatel sám rozhodl o pokračování chodu této aplikace. K tomuto účelu se hodí velmi dobře právě dialogové okno. Nejčastějším příkladem je potvrzovací dialog, kdy má uživatel na výběr buďto souhlasit (tlačítko Ano/OK), nebo odmítnout (tlačítko Ne/Storno). • Oznámení ve stavovém řádku Posledním možným typem avizace je přidání ikony do stavového řádku. Potom může aplikace na pozadí bez problému vykonávat svoji činnost, po jejímž ukončení je uživatel o této záležitosti informován v seznamu oznámení. Ve spojení s tímto typem oznámení se často využívá signalizace světelná (LED dioda), zvuková, nebo za pomoci vibrací mobilního zařízení.
10
Android Manifest Android Manifest4 není nic jiného než XML soubor, který je nutný pro správné fungování výsledné aplikace na daném zařízení. Jsou v něm totiž uvedeny všechny důležité informace o aplikaci, které musí operační systém Android, na němž je aplikace spuštěna, znát před jejím spuštěním. Mezi tyto prvky patří: • Jméno balíčku aplikace (unikátní identifikátor dané aplikace) • Deklarace minimální vyžadované verze Android API • Deklarace komponent, které jsou v aplikaci použity (všechny aktivity, služby atd.) • Seznam potřebných knihoven • Deklarace oprávnění pro přístup k chráněným částem API funkcí (použití SD karty, připojení k internetu, či přístup k poloze zařízení – GPS modul, apod.)
4
http://developer.android.com/guide/topics/manifest/manifest-intro.html
11
Kapitola 3
Návrh aplikace Aplikace naprocházku.cz by měla být především uživatelsky přívětivá a jednoduše ovladatelná. Být součástí uživatelova mobilního zařízení, kterou bude moci využívat každý den, bez ohledu na místo, kde se právě nachází. Primární určení je pro obyvatele ČR, bez rozdílu věku, či pohlaví. Grafické zpracování musí působit pozitivně - volba barev a vzorů spojených s procházkami, přírodou, apod. Tak jako samotné procházky vyvolávají v lidech pozitivní pocity a nálady, měla by i mobilní služba naprocházku.cz na uživatele působit v podobném duchu a otevřít určitým způsobem cestu k novým zážitkům při objevování dosud nenavštívených míst. Tyto základní požadavky byly vytyčeny před začátkem implementační práce. Další důležitým předpokladem a zároveň i motivací pro mě byla skutečnost, že se na našem trhu s mobilními aplikacemi podobná služba, týkající se procházek a krátkých výletů, prozatím vůbec neobjevuje. Je zde tedy velké množství potenciálních budoucích uživatelů.
3.1
Konkurenční projekty
Po vytvoření základní představy, uvedené v předchozí části, následoval další krok. Konkrétně tedy prozkoumání existujících řešení - zkoušení a testování konkurenčních aplikací, které byly zveřejněny na GooglePlay. Prvním důležitým zjištěním bylo, že na našem trhu opravdu neexistuje stejně zaměřená aplikace. Tímto se projekt naprocházku.cz stává ještě zajímavějším. Ke stažení jsou sice aplikace určené pro turistiku, delší výlety, či cykloturistiku. Avšak záležitosti krátkých procházek se nevěnuje ani jedna z nich. Přesto ale bylo velmi přínosné jejich vyzkoušení, otestování, zjištění předností a nedostatků, které jsou využity dále při tvorbě aplikace.
3.1.1
SmartMaps Navigator
Jedná se o aplikaci společnosti Mapy.cz, s.r.o., specializující se na mapové podklady ČR a SR. Vzhledem k jejich zaměření jsou mapy opravdu kvalitně a detailně zpracované. Podporuje plánování výletů po cyklistických i turistických trasách, nabízí možnost hlasové navigace, či podporu geocatchingu. Dále obsahuje více než 95tis. bodů zájmu, mezi kterými nalezneme polohy nejrůznějších typů položek- např. čerpací stanice, bankomaty, turistické suvenýry nebo ubytování. Možná však právě i díky tomu je celkově aplikace pro průměrného uživatele poměrně nepřehledná a složitá na ovládání. Trvá tedy delší dobu, než ji člověk přijde na chuť. Dalším záporem je bezpochyby nízké rozlišení mapy v neplacené verzi, které může rovněž řadu uživatelů odlákat.
12
(a)
(b)
(c)
Obrázek 3.1: Snímky obrazovky aplikace SmartMaps Navigator Co se týká hodnocení na GooglePlay, dosahuje aplikace 4,1b, přičemž maximum je 5. Počtem stažení se řadí do sekce 100tis. – 500tis., což je počet poměrně vysoký.
3.1.2
Turistická navigace Beta
Oproti předchozí aplikaci je Turistická navigace Beta dílem jednoho vývojáře. Dá se říci, že je úplným opakem té předešlé. Jedná se o poměrně jednoduchou službu, která využívá mapové podklady GoogleMaps. Veškerá data jsou získávána ze serveru turistika.cz. Jedna z jejích klíčových vlastností není funkční – jedná se o možnost zaznamenání trasy.
(a)
(b)
(c)
Obrázek 3.2: Snímky obrazovky aplikace Turistická navigace Beta Bohužel v současné době je již více než půl roku bez aktualizace a vypadá to, že už se žádné další nedočkáme. Je to docela škoda, protože počet instalací se pohybuje mezi 10tis. – 50tis. s průměrným hodnocením 3,6b.
13
3.1.3
Zhodnocení konkurence
Obě uvedené aplikace plní svůj účel a jsou poměrně dobře zpracovány. Samozřejmě je mezi nimi vidět velký rozdíl, který je dán především množstvím investovaného času do návrhu a implementace u obou aplikací. Není možné srovnávat práci několikačlenného týmu v případě SmartMaps Navigatoru a práci jednotlivce u Turistické navigace. Pro směr dalšího návrhu a práci na aplikaci bylo toto prozkoumání již vytvořených aplikací stěžejní. Díky zkoušení a testování jejich funkcí, byla vytvořena představa o tom, jakým směrem se bude aplikace naprocházku.cz ubírat. Hlavním nedostatkem je především absence podpory uživatelských účtů. Ve SmartMaps Navigatoru sice účty existují, ale jsou zde v první řadě kvůli aktualizacím placené verze mapových podkladů, které jsou k dispozici. U druhé testované aplikace se sice objevuje možnost přihlášení k výše zmíněnému serveru turistika.cz, avšak tato část aplikace je nefunkční. Určitě by ale neměla být registrace povinná pro všechny uživatele, z mých dosavadních zkušeností nutnost zaregistrování nové uživatele spíše odradí. Pokud je jim ale nabídnut kvalitní produkt, který se jim zalíbí, dřív nebo později sami registraci provedou. Velmi důležitá je rovněž jednoduchost ovládání, ne však na úkor omezení funkčnosti. Kvalitní navržení grafického uživatelského rozhraní je pro úspěch výsledné služby jedním z rozhodujících faktorů. Jako příklad je možné uvést, dle mě ne zrovna vhodně vytvořeného grafického uživatelského rozhraní (GUI) v SmartMaps Navigator viz obrázek 3.1b, kde je vidět, že mapa je zobrazena pouze na necelé polovině obrazovky. Na displeji s menší uhlopříčkou a rozlišením by byla situace pravděpodobně ještě horší.
3.2
Typy uživatelů
Základní rozdělení by mělo být totožné jako u drtivé většiny služeb/aplikací. Bude zde tedy figurovat uživatel přihlášený do služby naprocházku.cz a anonymní. Aby se mohl nový uživatel v aplikaci přihlásit ke svému účtu, musí jej nejprve vytvořit – zaregistrovat se. Díky skutečnosti, že vytvářet, ukládat a sdílet procházky bude moci pouze přihlášený uživatel je zabráněno anarchii, která by mohla nastat, pokud by tuto možnost měl kterýkoli návštěvník. Takto lze vyfiltrovat uživatele, kteří by nevytvářeli vhodné procházky, odstranit je, případně i samotný uživatelský účet apod.
3.3
Použité technologie
Následující kapitola přináší základní informace o technologiích, které byly zvoleny a následně použity při tvorbě služby.
3.3.1
GPS
Zkratka GPS označuje počáteční písmena spojení Global Positioning Systems. Původně byla tato navigační technologie určena výhradně pro armádu. Pro veřejnost však byl signál tohoto systému, respektive zjištění polohy záměrně znepřesněno, takže jej nebylo možné prakticky využívat. Změna nastala v roce 2000, kdy byla tato funkce vypnuta. Jak je uvedeno v [8], došlo tím k obrovskému zlepšení přesnosti určení polohy z původních desítek až stovek metru na jednotky metrů, což bezpochyby přispělo k celosvětovému rozšíření GPS. V současné době jsou provozovateli dvou fungujících globálních systémů stále armády. Konkrétně se jedná o armády Spojených států amerických a Ruska. 14
Při použití GPS je velmi důležitá dostupnost signálu družic. Jeho kvalita a přesnost určení polohy záleží na prostředí, ve kterém se nachází přijímač. Signál je přijímán pouze z těch družic, které jsou pro zařízení viditelné. To značí, že například v městech s vysokými budovami, v hustých lesích, či ve velmi kopcovité krajině, bude získání signálů složitější, než v přírodě . Pokud není počet viditelných družic dostatečný, stává se signál méně přesný, případně polohu není možné určit vůbec.
3.3.2
GoogleMaps
Mapy GoogleMaps jistě není třeba představovat. I když je jejich využití umožněno pro webové aplikace, zařízení s operačním systém iOS, v této práci je pozornost zaměřena na jejich použití pro platformu Android. Právě díky Google Maps Android API je možné přidat do aplikace mapy, které jsou založeny na mapových podkladech Google Maps od společnosti Google Inc. Ty jsou pro nekomerční použití k dispozici zdarma a neomezeně. Pokud se jedná o komerční užití, to je zpoplatněno až nad určitou hranici počtu zobrazených map u uživatelů. Jedná se tedy o komplexní balík, který poskytuje již zmíněné mapové podklady, možnost do mapy přidávat libovolné značky (markery), nebo vykreslovat geometrické útvary (od jednoduchých čar až po složité mnohoúhelníky). V neposlední řadě také dovolují tvůrci aplikace dát uživateli možnost přibližování/oddalování, naklánění, či otáčení mapy. Aktuálně je vývojářům k dispozici API v2, kterou byla 3.prosince 2012 nahrazena předchozí verze Google Maps Android API v1 [3].
3.3.3
Uložení perzistentních dat
Při volbě umístění dat, u kterých je nutné, aby zůstali k dispozici i po ukončení aplikace, bylo na výběr několik možností1 . • Sdílené preference Ukládání soukromých dat ve tvaru klíč-hodnota, kdy hodnota je primitivního datového typu. • Interní úložiště Slouží k uložení dat v paměti přístroje, která je v zásadě přístupná pouze dané aplikaci. Toto nastavení lze však změnit a dovolit tak uživateli přístup k těmto datům. • Externí úložiště Ukládání veřejně přístupných dat na sdíleném externím úložišti. K těmto datům má uživatel přístup pomocí jakéhokoli souborového manažeru, což je pro uložení důležitých dat nevhodné vzhledem k tomu, že může libovolně data přidávat, upravovat či mazat. • Databáze Používá se pro ukládání strukturovaných dat v privátní databázi. Je zejména vhodné pro uložení dat s opakující se strukturou – např. větší množství procházek se stejnými typy atributů. 1
http://developer.android.com/guide/topics/data/data-storage.html
15
• Připojení k síti Ukládání dat na vlastní webový server, respektive databázi připojenou k webovému rozhraní. K tomuto účelu je však nutností dostupné připojení k internetu. Z výše uvedených možností byly zvoleny dva typy uložení perzistentních dat, které jsou později využity v implementaci. Jedná se o uložení dat do lokální databáze v přístroji, které slouží pro uchování informací o jednotlivých procházkách, jejich souřadnicích či bodech zájmu bez nutnosti je při každém spuštění stahovat z webové databáze. K té se bude přistupovat také v případě, kdy uživatel vytvoří novou procházku a chce ji sdílet s ostatními zájemci. V tomto případě je nutné ji odeslat a a uložit rovněž na webový server.
3.3.4
SQLite databáze
Kvůli omezené velikosti paměti mobilních zařízení (především v minulosti), byla pro Android zvolena databáze SQLite. Jedná se o poměrně malou knihovnu, která je napsána v jazyce C a obsahuje celý relační databázový systém. Rozdílem oproti většině databází typu klient-server je přímé připojení této knihovny k aplikaci. Každá vytvořená databáze poté tvoří pouze jediný soubor, který je platformě nezávislý. Celý databázový systém je distribuován pod licencí public domain a v praxi se s SQLite můžeme setkat v projektech jako jsou prohlížeče Chrome, Safari, či komunikátor Skype. Rovněž jej využívají mobilní zařízení firmy Apple (iPod, iPhone) [9].
3.3.5
ActionBarSherlock
ActionBarSherlock, zkráceně jen ABS, je rozšířením support library, která poskytuje podporu pro jednodušší správu Action Baru2 napříč různými verzemi OS Android. Knihovna automaticky využívá nativní Action Bar, pouze jej v případě potřeby nahrazuje svou vlastní implementací. Výsledkem tak je stejně se chovající a vypadající komponenta Action Bar na všech verzích od 2.x výše. Pro účely tvorby aplikace naprocházku.cz je využita jak základní verze 4.2.0, tak i její plugin pro Google Maps opět ve verzi 4.2.0, který rozšiřuje standardní typ aktivit – MapActivity. Veškeré informace ohledně zapojení ABS do aplikace byly čerpány z [6].
3.4
Komunikace se serverem
Vytvořená architektura klient-server by měla sloužit pro spojení a výměnu dat mezi mobilní a webovou částí služby naprocházku.cz. Aplikace (klient) posílá dotazy na server, který zpět vrací příslušné odpovědi. K této činnosti by měla být využita dotazovací metoda POST3 , s využitím datového formátu JSON.
2
horní část okna aktivity, která se využívá pro navigaci v rámci aplikace, k zobrazení možností nastavení apod. 3 metoda internetového protokol určeného pro výměnu hypertextových dokumentů ve formátu HTML
16
Kapitola 4
Implementace Tato kapitola obsahuje informace o implementační části práce. Jedná se tedy o tu část, kdy jsou známy všechny nastudované informace a je potřeba je převézt do podoby aplikace. Je nutno zmínit, že všechny následující části prošly několika stádii vývoje. Nejedná se tedy o první řešení, které bylo nasnadě.
4.1
Uživatelské rozhraní
V první části vývoje nebyla brána grafická stránka aplikace jako rozhodující a spíše bylo myšleno na funkcionalitu. Jako příklad je možné uvést základní menu, jenž se sestávalo z několika klasických tlačítek. Tedy bílá plocha a pár šedých obdélníčků. Tento styl vzhledu byl původně u všech komponent (aktivit), jejichž funkčnost byla rozhodující pro běh celé aplikace (úvodní menu, vytvoření vlastní procházky, detail procházky apod.). Finální grafická verze aplikace je výsledkem konzultací jak s lidmi, kteří se pohybují v oblasti IT – povětšinou studenty, tak i lidí nezainteresovaných, kteří s IT nemají téměř nic společného. Tento postup byl zvolen především kvůli skutečnosti, že aplikaci by měli používat i uživatelé chytrých mobilních telefonů či tabletů, kteří jinak technice nijak zvlášť neholdují. Jak již bylo zmíněno dříve, celý grafický koncept by měl v uživateli vyvolávat pozitivní pocit a dobrou náladu. Jednotný návrh grafické části aplikace byl sice znám, dalším úkolem bylo jeho zobrazení na různých verzích OS Android. Ty se totiž v určitých ohledech liší, některé funkce na starších zařízeních nejsou k dispozici, jiné pro změnu byly označeny za zastaralé, a tudíž se v novějších verzích již nevyužívají. Pro práci s komponentou Action Bar byl zvolen výše popsaný ActionBarSherlock viz. 3.3.5, který se stará právě o sjednocení vzhledu této části na různých verzích OS. Při tvorbě byla dodržena konvence známá z mnoha webových či mobilních aplikací – umístění funkce pro přihlášení vpravo nahoře. Snímky výsledné aplikace jsou uvedeny na obrázcích 4.1 a 4.2.
4.2
Komunikace s webovou službou
Služba naprocházku.cz se skládá z mobilní aplikace a webové (serverové) části. Z tohoto důvodu bylo tedy nutné propojit obě části tak, aby existovala pouze jediná databáze, která obsahuje informace o jednotlivých uživatelích, procházkách, jejich bodech zájmu apod. Samozřejmostí je umístění této databáze na server webové služby. Mobilní aplikace poté přistupuje k potřebným údajům uvedeným v této databázi a zpracovává je. Za tímto účelem bylo
17
(a) Úvodní obrazovka
(b) Detail cházky
pro-
(c) Zobrazení procházky na mapě
Obrázek 4.1: Snímky obrazovky finální verze aplikace ve spolupráci s Jiřím E. Špačkem vytvořeno API rozhraní, pomocí kterého spolu aplikace a server komunikují, viz. příloha B. Celá komunikace probíhá v datovém formátu JSON, kdy aplikace vytvoří požadavek, který je odeslán na server, ten jej zpracuje a odpověď, opět ve formátu JSON, zašle zpět. V aplikaci je za tímto účelem vytvořen balík cz.naprochazku.json, který obsahuje dvě třídy – HttpPost.java a JSONParser.java. První z nich má na starost vytváření dotazů pro POST metodu protokolu HTTP, přičemž využívá vždy dvojici klíč, hodnota. Pro názornost je možné uvést tvar JSON požadavku pro získání souřadnic všech bodů procházky s ID = 5: {"api":"naprochazku", "method":"coordinatesForWalk","id":5} Třída JSONParser.java má poté na starost odeslání dotazu a následně přijetí a zpracování odpovědi. Pokud dotazovaný cíl neexistuje, např. procházka s ID = 5 byla z databáze odstraněna, je z webového API odesláno upozornění na chybu, která je poté v jednotlivých částech aplikace zpracována, a pokud je to vhodné, je o této skutečnosti seznámen i uživatel.
4.3
Databáze
Pro práci s SQLite databází slouží třídy obsažené v balíku cz.naprochazku.database. Základním stavebním kamenem je třída MySQLiteHelper.java, která obstarává vytváření databázových tabulek, verzování celé databáze apod. Jednotlivé tabulky poté obsluhují další třídy, které jsou nazvány podle svého účelu s koncovkou DataSource – např. WalksDataSource, PoisDataSource atd. Každá z nich obsahuje metody pro získání všech záznamů v příslušné tabulce, včetně všech atributů. Pro vkládání nových prvků či pro procházení tabulek je využito proměnné datového typu Cursor, která odkazuje vždy jeden řádek záznamu. Nutno zmínit, že určité části databáze je nutné znovuvytvářet častěji než jiné. Jedná se o tabulky, které obsahují data uživatelem uložených procházek. Ty je nutné po jejich odeslání na server z paměti telefonu i databáze, odstranit. V opačném případě by byly při každém odeslání znovu zaslány k vytvoření v databázi serveru dříve vytvořené procházky.
18
4.4
Zobrazení mapových podkladů
Pro zobrazení procházek byly zvoleny mapy společnosti Google Inc viz 3.3.2. Aktuálně je k dispozici Google Maps Android API v2 viz. [3]. Právě díky přechodu na novou verzi rozhraní API došlo ke komplikacím. 3.prosince 2012 byl první typ označen za zastaralý a za přibližně tři a půl měsíce, přesně 18.března, bylo ukončeno vydávání API klíčů pro tuto verzi. S touto skutečností při vývoji nebylo počítáno. Jelikož byla aplikace v této době stále vyvíjena a testována, byl pro zobrazení map využit tzv. debugovací klíč“, který však ” nelze použít při zveřejnění aplikace – zobrazení mapy funguje pouze při instalaci aplikace do zařízení pomocí ADB [4]. Z tohoto důvodu musely být třídy, které se staraly o zobrazování mapy, vykreslování značek atd., upraveny pro Google Maps Android API v2, což ve výsledku znamenalo nejen jistou časovou ztrátu při reimplementaci, ale také nutnost uskutečnit znovu testování týkající se správného zobrazení mapy s procházkami. O tuto činnost se v aplikaci starají dvě třídy z balíku cz.naprochazku.maps. V obou případech se jedná o aktivity (2.5), přičemž první z nich – ShowMapActivity.java slouží k zobrazení základní mapy, na které jsou ikonou kráčející postavy označeny jednotlivé procházky viz. obrázek 4.2 níže.
Obrázek 4.2: Snímek obrazovky – ShowMapAcitivty.java Druhá třída se nazývá ShowWalkMapActivity.java, její snímek je vidět na obrázku 4.1c. Zobrazení této aktivity je možné dvěma způsoby. První možností je z aktivity ShowMapActivity, po kliknutí na některou z ikon procházek a následným zvolením vhodné volby z kontextového menu – Zobrazit na mapě“. Další možností je pomocí aktivity WalkDe” tailActivity, ve které se nachází přímo tlačítko Zobrazit na mapě“. V obou případech ” je vytvořen nový záměr (viz 2.5), který původní aktivitu pozastaví a spustí novou, tedy kýženou ShowWalkMapActivity. Z pohledu implementaci i celkové vzhledu je tato aktivita zajímavější. Obsahuje totiž zobrazení několika typů ikon, podle svého významu – lavička, parkoviště, občerstvení aj. K detailu procházky však nepatří pouze určení těchto míst, tzv. bodů zájmu, ale především zobrazení trasy, kterou daná procházka vede. Toto je řešeno pomocí metody addPolyline(), kterou nabízí instance třídy GoogleMap. Bezpochyby nová verze Google Maps Android API poskytuje vývojářům mnohem přátelštější a jednodušší přístup k řešení požadovaných operací s mapou. Značky doplňované do mapy, tzv. markers, jsou v nové verzi přidávány metodou addMaker přímo do mapy, kdežto v minulé verzi bylo nutné vytvářet vrstvy (overlays) pro jednotlivé typy značek a až poté jednu po druhé tyto vrstvy přidávat k mapovému podkladu. Ještě zřetelnějším rozdílem je 19
vykreslení trasy. Kvůli jejímu zobrazení bylo dříve nutno u některé z vrstev přetížit metodu draw(). To ale znamenalo při jakékoli změně zobrazení mapy – přiblížení/oddálení, posunutí atd., vždy vše zahodit a celý proces vykreslení trasy opakovat znovu a znovu. V nové verzi se tato činnost provede při spuštění aktivity jen jednou, poté je již, dalo by se říci, součástí mapy, takže celková práce uživatele s mapou je rychlejší a efektivnější. Důležitým prvkem, který se bezprostředně dotýká problematiky zobrazení mapy je implementace LocationListener u. Přesněji jeho metody onLocationChanged(). Ta v sobě ukrývá definici činnosti, jenž se má provést, pokud nastane změna polohy zařízení. Ta je hlídána u GPS modulu, případně u datového připojení, které rovněž poskytuje informace o přibližné poloze přístroje. V případě zobrazení mapy se po změně pouze upraví poloha ikony oznamující uživateli právě aktuální polohu. V případě ukládání vlastní procházky je zde činností více viz. následující podkapitola.
4.5
Vytvoření vlastní procházky
Ze zadání práce vyplývá, že jednou z nejdůležitějších částí aplikace má být aktivita věnující se vytváření nové procházky. K její činnosti je nutné mít v zařízení zapnutý GPS modul, který poskytuje informaci o poloze uživatele. Ukládání souřadnic začíná po stisknutí tlačítka Začít ukládat trasu“. Od této chvíle již výše zmiňovaný LocationListener, který je ” implementován ve třídě OwnWalkListener.java umístěné v balíku cz.naprochazku.ownwalk. V průběhu nahrávání procházky jsou ukládány pouze pozice, které splňují následující vlastnosti: • přesnosti zaměření polohy menší než 501 • vzdálenost od předchozího bodu minimálně 50 metrů • doba od zaznamenání předchozího minimálně 10 sekund Původní myšlenka byla dát uživateli možnost tyto parametry nastavovat dle svého uvážení, například pomocí komponenty SeekBar. Avšak po vyzkoušení aplikace Turistická navigace Beta 3.1.2, kde je toto nastavení svěřeno uživateli a po délce testování upravování tohoto nastavení tak, aby odpovídalo požadavkům nahrávání procházek, bylo rozhodnuto o určení těchto proměnných napevno. Předejde se tak situacím, když uživatel díky nesprávně zvoleným parametrům procházku sice vytvořil, ale souřadnice by kvůli nepřesnostem nemusely odpovídat opravdové trase. Více o problematice testování viz. 5. V průběhu vytváření procházky je umožněno průběžné přidávání bodů zájmu, kde stačí vybrat typ a případně doplnit popisek k danému bodu. Po stisknutí tlačítka jsou bodu přiřazeny poslední známé souřadnice polohy zařízení. V případě, kdy se uživatel rozhodne pro ukončení nahrávání procházky, má k dispozici tři možnosti postupu vztahující se k právě vytvořené procházce: • Odeslat ihned V tomto případě, pokud je k dispozici datové připojení, je kompletní procházka přetransformována do formátu JSON a odeslána do webové databáze. Pro tento případ je využito vícevláknového zpracování viz. 4.6. Pokud vše na serveru proběhne v pořádku, je procházka ihned k dispozici všem uživatelům služby naprocházku.cz. Pokud však datové připojení k dispozici není, nebo prostě jen není aktivováno, automaticky se 1
http://developer.android.com/reference/android/location/Location.html#getAccuracy()
20
celá procházka uloží do lokální databáze. Pro tuto činnost je využit stejný postup jako v případě, kdy uživatel rovnou zvolí možnost uvedenou níže. • Uložit, odeslat později Tato možnost v sobě skrývá přístup k lokální SQLite databázi (3.3.4). Všechny získané údaje – trasa procházky, její popis, body zájmu atd., musí být uloženy pro pozdější odeslání do databáze umístěné na webu. Využity jsou zde tedy metody tříd balíku cz.naprochazku.ownwalk – OwnWalksDataSource.java, OwnCoordDataSource.java a OwnPoisDataSource.java. Každá z nich se stará o konkrétní část dat vztahujících se k procházkám. Předem nelze odhadnout, kdy se uživatel dostane k internetovému připojení a odešle vytvořenou procházku, proto je v implementaci myšleno na možnost uložit i několik takto vytvořených procházek. Poté jsou data ze všech tří tabulek databáze – procházka, souřadnice trasy a body zájmu opatřeny identifikátory, které určují jejich provázanost na určitou procházku. • Neukládat Po stisknutí tlačítka Neuhládat“ je uživatel upozorněn, zda-li chce procházku sku” tečně nenávratně odstranit. Po potvrzení svého rozhodnutí je daná procházka se všemi svými atributy odstraněna z paměti a aplikace je připravena k nahrávání nové procházky.
4.6
Práce s vlákny
Veškerá činnost, která na zařízeních s operačním systém Android běží v hlavním vláknu a trvá nepřetržitě déle než 5 sekund, vede k pozastavení aplikace a zobrazení dialogu, díky kterému je možné aktivitu nechat dále běžet, či ukončit. Je to především z toho důvodu, že pokud je hlavní vlákno zaneprázdněno, nemůže přístroj reagovat na uživatelské akce (stisk tlačítka, kliknutí na displej aj.). Aby tato situace v aplikaci naprocházku.cz nenastávala, muselo být využito vícevláknové zpracování určitých částí kódu. Typickým příkladem je komunikace s webovou částí služby. Není možné dopředu určit čas potřebný k přijetí odpovědi, či dobu následného zpracování (např. uložení získaných dat do databáze). Za tímto účelem byly tyto činnosti umístěny do tříd, které extendují třídu AsyncTask2 . V aplikaci se objevují dvě – DownloadWalks.java v balíku cz.naprochazku.main, která má za úkol stažení všech existujících procházek z webové databáze a její uložení do lokální databáze v konkrétním zařízení. Druhou je třída pro odeslání uživatelem vytvořené procházky do webové databáze. Ta se nachází v balíku cz.naprochazku.ownwalk a nese název AsyncSendOwnWalk.java. Při činnosti těchto tříd je uživateli zobrazen ProgressDialog, který upozorňuje na právě probíhající činnost.
4.7
Vyhledávání procházek
Jedním z požadavků, který byl uveden v zadání, byla možnost vyhledávání mezi procházkami. Tak jako v celé práci, bylo i zde myšleno nejen na uživatele, kteří budou mít k dispozici datové připojení, ale i na uživatele, jejichž zařízení bude offline“. ” Pro první z případů, tedy u zařízení, která budou moci přistupovat k internetu, jsou uživateli nabídnuty tři možnosti vyhledávání: 2
http://developer.android.com/reference/android/Asynctask.html
21
• Vyhledávání podle atributů • Vyhledávání podle kraje • Fulltextové vyhledávání V případě, kdy připojení není k dispozici, má uživatel možnost vyhledávání pouze podle kraje, ve kterém se procházka nachází. Všechny třídy, které mají nějakým způsobem na starost právě vyhledávání jsou sdruženy v balíku cz.naprochazku.search a pojmenovány podle svého účelu, vždy s koncovkou SearchActivity“. ”
4.8
Google Analytics
Pro zaznamenávání činnosti jednotlivých uživatelů při práci s aplikací a získávání statistik z těchto údajů byla zvolena možnost využití služby Google Analytics určené pro mobilní zařízení s operačním systémem Android [5]. Díky využití nové verze, která je prozatím k dispozici pouze v testovací beta verzi, byla implementace služby poměrně jednoduchá a přímočará. Základem je třída obsahující metody pro práci s třídou EasyTracker – TrackActivity.java, jež je umístěna v balíku cz.naprochazku.track. V každé z aktivit je umístěn kód, který při každém spuštění aktivity uloží právě do EasyTracker u záznam o této události. Veškeré informace jsou v případě dostupného datového připojení odesílány každé 3 minuty ke zpracování na server. Jinak jsou uloženy a k jejich odeslání dojde až po navázání připojení. Více o získaných datech je uvedeno v následující kapitole 5.2.
22
Kapitola 5
Testování a publikace Pro jakýkoli úspěšný projekt, aplikaci, či program, je velmi důležitá jeho správná implementace, která splňuje požadavky, jenž byly stanoveny na začátku práce. Toho je možno dosáhnout pouze podrobným a kvalitním vyzkoušením funkcionality.
5.1
Testování aplikace
V případě vývoje aplikace má programátor na výběr dvě možnosti. Jednou je využití emulátoru, o kterém byla řeč v kapitole věnované platformě Android, konkrétně v 2.4. Druhá zahrnuje testování na reálných zařízeních – mobilních telefonech, či tabletech. Každá z nich má určité výhody, ale i nevýhody. • Emulátor + Možnost volby parametrů zařízení (velikost a rozlišení displeje, velikost paměti apod.) + Simulování situací jako přijetí SMS, či oznámení příchozího hovoru + Možnost sledování ladících informace (vývojový nástroj Eclipse) – Rychlost odezvy emulátoru • Reálné zařízení + Možnost testování v terénu, reálných podmínkách + Rychlost odezvy zařízení – Doba generování souboru *.apk (podepisování, uložení z PC do zařízení) – Nemožnost sledování ladících informací Při testování vznikající aplikace bylo využíváno jak emulátoru, tak testování na skutečných zařízeních. V počátcích byl využíván převážně emulátor, především kvůli možnosti téměř libovolného nastavení parametrů virtuálního přístroje. Toho bylo využíváno z důvodu optimalizace vzhledu uživatelského rozhraní. Později, především při testování vytváření vlastních procházek a jejich správného ukládání, přišly na řadu skutečné přístroje. Celkově jich bylo vystřídáno osm – mobilní telefony LG Optimus One P500, Samsung Galaxy Nexus, LG Optimus 2X P990, HTC Desire S, tablety Google Nexus 7, GoClever T76GPS, Fuzhou Rockchip a GoClever Tab A104.2. Díky tomuto širokému spektru byly otestovány různé verze OS Android, od 2.3.3 až po nejnovější 4.2.2, různé hardwarové konfigurace 23
a velikosti/rozlišení displejů. Při ověřování správné funkčnosti určitých částí implementace, které se starají o zpracování informací z GPS modulu, bylo několikrát, především z důvodu úspory času, přistoupeno k testování v terénu s mobilním zařízením připojením k notebooku. Jen tak totiž bylo možné kontrolovat ladící informace. Součástí testování bylo také stanovení klíčových parametrů pro vytváření procházky, jenž byly uvedeny v kapitole 4.5. Metodou pokus omyl bylo dosaženo nejlepších možných výsledků – testování správného nastavení těchto parametrů bylo zkoušeno na desítkách vytvořených procházek, které byly poté analyzovány. Cílem bylo dosáhnout kompromisu mezi počtem ukládaných souřadnic trasy, vzhledem k její délce, a přesností výsledné trasy, vzhledem k mapovým podkladům. V potaz zde byla brána také přesnost určení polohy zařízení pomocí technologie GPS, která se běžně pohybuje v rozmezí 5 – 15 metrů.
5.2
Zveřejnění služby
Jedním z bodu zadání byla také publikace vytvořené aplikace. K tomuto účelu byl vytvořen vývojářský účet na Google Play, pod nímž bylo možné aplikaci zveřejnit a rozšířit jej mezi reálné uživatele. V začátcích to byli především studenti IT oborů, kteří se stali prvními uživateli mobilní služby naprocházku.cz. Ta se ale zanedlouho rozšířila i mezi širokou veřejnost – kategorie dle počtu stažení 100 – 500 viz. 5.1. Podle statistik z Google Analytics si aplikaci do svého mobilního telefonu, či tabletu během prvního týdne od zveřejnění nainstalovala více než stovka uživatelů. Dle grafu z obrázku 5.2 trvala průměrná návštěva, tedy zobrazení aplikace, 2:25 sekund a za tuto dobu bylo uživateli průměrně zobrazeno 6,91 obrazovek (aktivit). Dalším zajímavým údajem je bezesporu hodnota 52,5%, která označuje procento uživatelů, jenž si aplikaci v mobilním zařízení pouštěli opakovaně. Zpětnou vazbou bylo zjištěno, že hlavním důvodem, proč někteří uživatelé navštívili a vyzkoušeli aplikaci pouze jednou, bylo především nedostatečné množství již existujících procházek v databázi služby. Ohlasy ze sociálních sítí byly ve většině případů kladné. Objevilo se pouze jediné upozornění na chybu při zobrazování mapy, která byla vzápětí opravena. Z komentářů a připomínek byl vytvořen seznam možných vylepšení a rozšíření aplikace, který je nastíněn v následující kapitole 5.2. Získávání zpětné vazby však nefungovalo pouze po zveřejnění, ale dá se říci již od počátku návrhu aplikace. Grafika jednotlivých aktivit, potažmo celé aplikace, požadavky na základní funkčnost, to všechno byly záležitosti, jenž vedly k diskuzi s testery, budoucími uživateli. Vzhledem k cílové skupině, která je velmi široká – nezáleží na pohlaví ani věku, konzultace návrhu probíhaly s lidmi ve věku od 17 až do 68 let. U reálných uživatelů informace o věku není k dispozici, avšak vzhledem k zařízením, která podporují OS Android se lze domnívat, že aplikaci využívá převážně mladší generace. Jako nejpřínosnější informace od uživatelů, kteří byli jako testeři při vývoji Obrázek 5.1: Údaje aplikace, může být označeno upozornění na potřebu uložení vytvořené z GooglePlay procházky v případě, kdy není k dispozici datové připojení.
24
Obrázek 5.2: Graf průměrné doby návštevy a počtu obrazovek na návštěvu
5.3
Budoucnost projektu
Možností, kam dále rozvíjet funkcionalitu aplikace je celá řada, ať už se jedná o zlepšení stávajících částí, či přidání částí úplně nových. Jelikož je aplikace úzce provázána s webovou částí služby, bude nutno, tak jako doposud, všechny důležité kroky dalšího vývoje obou částí společně prodiskutovat a určit, jakým způsobem dále pokračovat, a kterým směrem rozvoje této služby se ubírat. Jako příklad možných rozšíření vytvořené aplikace je možné uvést: • Stažení a uložení pouze procházek, které si uživatel sám zvolí • Vytvoření procházky přímo v mapě (určení trasy, přidání bodů zájmu), bez nutnosti využití GPS modulu • Propojení se sociálními sítěmi – možnost sdílet a doporučovat procházky
25
Kapitola 6
Závěr Cílem práce bylo vytvoření mobilní služby pro poznávání okolí ve formě krátkých procházek, jenž je určena pro širokou veřejnost. Po nastudování frameworku pro vývoj aplikací na platformě Android, vytvoření série návrhů vzhledu a funkčnosti, byla vytvořena služba, která uživateli umožňuje vyhledávat procházky v již existující databázi. Dále pak vytvářet vlastní nové procházky, které jsou posléze sdíleny s ostatními uživateli. Jak je výše uvedeno, aplikace byla implementována pro aktuálně nejrozšířenější operační systém mobilních zařízení v ČR, tedy OS Android. Během vývoje docházelo k průběžnému testování v emulátoru virtuálních zařízení a současně na několika reálných přístrojích. Důležitým faktorem podporujícím tuto tvorbu byla zpětná vazba od prvních uživatelů – testerů, která dodávala cenné podněty a informace, jenž pomáhaly určovat směr vývoje aplikace. V tomto ohledu probíhala také spolupráce s Jiřím E. Špačkem, který je autorem webové části projektu naprocházku.cz. Vývoj aplikace nebude ukončen odevzdáním práce, či jejím obhájením, ale v budoucnu bude služba dále rozvíjena. Možností jak ji vylepšit je nespočet, ať už se jedná o implementaci nových funkcí, či úpravu a zdokonalení již existujících. Pro příklad mohu uvést propojení se sociálními sítěmi, či možnost vytváření procházek jejich naklikáním“ přímo ” v mapě. Hlavní roli v tomto ohledu však budou hrát samotní uživatelé a jejich názory a požadavky. Publikací v distribuční službě GooglePlay se aplikace stala dostupná pro všechny uživatele s mobilním telefonem, či tabletem s operačním systémem Android ve verzi 2.3 a vyšší. V současnosti se nachází dle počtu stažení v sekci 100 – 500, což je poměrně dobrý výsledek, dosažený během prvních deseti dnů od jejího zveřejnění, a také s přihlédnutím k faktu, že aplikace má sloužit především obyvatelům ČR. Díky této diplomové práci se mi podařilo proniknout do světa vývoje mobilních aplikací, získal jsem velké množství nových praktických zkušeností, se kterými jsem se během studia nesetkal. Prošel jsem všemi fázemi tvorby mobilní aplikace (analýza zadání, návrh funkčnosti, návrh grafického uživatelského rozhraní, implementace, testování a publikace), tedy od teoretického výzkumu až ke konkrétním výsledkům.
26
Literatura [1] Google: Android SDK [online]. http://developer.android.com/sdk/index.html, 2013 [cit. 2013-05-04]. [2] Google: Android Architecture [online]. http://developer.android.com/about/versions/index.html, 2013 [cit. 2013-05-05]. [3] Google: Google Maps Android API v2 [online]. http://developers.google.com/maps/documentation/android, 2013 [cit. 2013-05-05]. [4] Google: Android Debug Bridge [online]. http://developer.android.com/tools/help/adb.html, 2013 [cit. 2013-05-09]. [5] Google: Google Analytics SDK for Android v2 (Beta) - Overview [online]. http://developer.android.com/analytics/devguides/collection/android/v2, 2013 [cit. 2013-05-10]. [6] Jake Wharton: ActionBarSherlock [online]. http://www.actionbarsherlock.com/index.html, 2012 [cit. 2013-05-06]. [7] Miroslav Ujbányai: Programujeme pro Android. Grada, 2012, iSBN 978-80-247-3995-3. [8] Radek Hojgr and Jan Stankovič: GPS: Praktická uživatelská příručka. Computer Press, 2007, iSBN 978-80-251-1734-7. [9] SQLite: SQLite Documentation [online]. http://www.sqlite.org/docs.html, 2013 [cit. 2013-05-05].
27
Příloha A
Obsah CD • thesis/latex – adresář zdrojových souborů písemné práce ve formátu jazyka LATEX • thesis/naprochazku.pdf – písemná zpráva ve formátu pdf • thesis/naprochazku.avi – prezentační video • src/app – adresář zdrojových souborů implementované aplikace • src/apk/naprochazku.apk – instalační balíček aplikace • src/manual.txt – manuál instalace • src/screen shots – snímky obrazovky aplikace
28
Příloha B
Definice metod aplikačního rozhraní Všechny metody začínají http://www.naprochazku.cz/api?api=naprochazku Některé metody, respektive jejich odpovědi již prošli úpravou, proto je u nich uveden parametr v=2. Odpověď je ve formátu JSON a vždy ve tvaru { status:"succes", // může nabývat hodnot success nebo fault při chybě result:"data" // v případě úspěchu obsahuje výsledek, který je dále pro každou metodu rozepsán; při chybě je zde chybová hlášení } Souřadnice jsou v odpovědi vždy ve tvaru coordinate {walk_id, id, latitude, longitude, previous_coordinate_id, attribute_id } Zájmový bod je v odpovědi vždy ve tvaru pointOfInterest {walk_id, latitude, longitude, type, title, note, w_attribute_id } Jednotlivé metody a jejich odpovědi: Seznam všech procházek dotaz: &v=2&method=allWalks odpověď: {[user_name, country {short, original}, walk_id, short_name, name, about, image_url], ...} Hledání v procházkách dotaz: &method=findWalks&value=tags_or_key_words odpověď: stejný jako v případě seznamu procházek, každá procházka má navíc položku rank, která určuje relevanci shody
29
Načtení detailu procházky dotaz: &v=2&method=walkDetail&short_name=libovolna-prochazka odpověď: {user_name, country {short, original}, walk_id, short_name, name, about, image_url, tags[{ name, relevance, group_id, gourp_name}, ...], coordinates {seznam souřadnic, viz. výše coordinate}, pointsOfInterest {seznam zájmových bodů, viz výše POI}} Vytvoření nové procházky dotaz: &method=createWalk&input={walk_name, user_id, country, walk_about, coords[{latitude, longitude},...], tags[{name},...]} odpověď: {walk_id, short_name} Přihlášení uživatele dotaz: &method=login&login=...&password=... odpověď: {identity{id, username, email, country{short, original, latitude, longitude}, about, latitude, longitude, roles[...]}} Pro následující označuje api key unikátní klíč vždy pro danou spolupracující aplikaci. Seznam všech uživatelských jmen dotaz: &method=getAllUsername&k=api_key} odpověď: {[ username, ...]} Vytvoření nového uživatele dotaz: &method=createUser&k=api_key&input={username, name, password, email, country} odpověď: {user_id} Seznam všech dostupných tagů dotaz: &method=getAllTags odpověď: {[{id, name, relevance, uses, group_id, group_name\}, ...]} Seznam tagů pro zadanou procházku dotaz: &method=getTagsForWalk&walkId=walk_id odpověď: stejný formát jako předchozí Uložení poslední známé pozice uživatele dotaz: &method=saveLastPositionOfUser&latitude=...& longitude=...&user_id=...} // parametr user id je nepovinný odpověď: success message
30
