Mobilní aplikace Průvodce po MENDELU

Transkript

1 Mendelova univerzita v Brně Provozně ekonomická fakulta Mobilní aplikace Průvodce po MENDELU Bakalářská práce Vedoucí práce: Ing. Dita Dlabolová Ondřej Charvát Kurdějov 2015

2

3 Poděkování Tímto bych chtěl poděkovat svojí přítelkyni a rodině, za jejich neustálou podporu a důvěru ve mně. Dále bych chtěl rovněž poděkovat Ing. Ditě Dlabolové, za spolupráci, její ochotu a vstřícnost.

4 Čestné prohlášení Prohlašuji, že jsem práci Mobilní aplikace Průvodce po MENDELU vypracoval/a samostatně a veškeré použité prameny a informace uvádím v seznamu použité literatury. Souhlasím, aby moje práce byla zveřejněna v souladu s 47b zákona č. 111/1998 Sb., o vysokých školách ve znění pozdějších předpisů a v souladu s platnou Směrnicí o zveřejňování vysokoškolských závěrečných prací. Jsem si vědom/a, že se na moji práci vztahuje zákon č. 121/2000 Sb., autorský zákon, a že Mendelova univerzita v Brně má právo na uzavření licenční smlouvy a užití této práce jako školního díla podle 60 odst. 1 autorského zákona. Dále se zavazuji, že před sepsáním licenční smlouvy o využití díla jinou osobou (subjektem) si vyžádám písemné stanovisko univerzity, že předmětná licenční smlouva není v rozporu s oprávněnými zájmy univerzity, a zavazuji se uhradit případný příspěvek na úhradu nákladů spojených se vznikem díla, a to až do jejich skutečné výše. V Brně dne: podpis

5 Abstract CHARVÁT, Ondřej. Mobile app MENDELU Guide. Bachelor thesis. Brno: Mendel University, Bachelor thesis examines ways to simplify orientation within Mendelu Univesity grounds in Brno. For this purpose is designed and implemented mobile app for OS Android. The work also concisely describes the operating system and ways of development in it. Keywords Guide, MENDELU, Mendel university in Brno, mobile application, Android, geofence, Google Maps. Abstrakt CHARVÁT, Ondřej. Mobilní aplikace Průvodce po MENDELU. Bakalářská práce. Brno: Mendelova univerzita v Brně, Bakalářská práce zkoumá možnost usnadnění orientace v areálu Mendelovy univerzity. Za tímto účelem je navržena a implementována mobilní aplikace pro OS Android. V práci je rovněž stručně popsán samotný operační systém a způsob vývoje v něm. Klíčová slova Průvodce, MENDELU, Mendelova univerzita v Brně, mobilní aplikace, Android, geofence, Google Mapy.

6 6 Obsah Obsah 1 Úvod a cíl práce Úvod Cíl práce Usnadnění orientace v areálu školy Možnosti navigace Volba možnosti navigace Volba platformy Operační systém Android Historie OS Verze operačního systému Architektura OS Životní cykly Vývojové prostředí Eclipse Návrh aplikace Průzkum trhu Požadavky na aplikaci Uživatelské rozhraní Implementace aplikace Struktura aplikace Databáze SQLite Google Maps API v Server Indica a AsyncTask Implementace sledování geofencí Zobrazování notifikací Marketing a distribuce Marketing mobilní aplikace Zhodnocení aplikace... 48

7 Obsah Distribuce aplikace Diskuze Ekonomické zhodnocení aplikace Technické zhodnocení aplikace Využití aplikace na jiné univerzitě Zhodnocení vývoje Závěr 55 9 Literatura 56

8 8 Úvod a cíl práce 1 Úvod a cíl práce 1.1 Úvod Dnešní doma je uspěchaná. Každý něco hledá a ne vždy se mu to podaří najít tak rychle, jak potřebuje. Lidé nezůstávají stále na stejném místě, ale často navštěvují místa nová, na kterých nikdy nebyli, a tudíž to tam neznají. Někteří taková místa odhalují tzv. na vlastní pěst, jiní však nemají rádi nejistotu a proto raději vyhledají pomoc. Může jít o radu od člověka, který dané místo zná, o tabuli s mapou města, stojící na náměstí nebo to může klidně být mobilní aplikace, která ho daným místem provede a pomůže mu najít to, co hledal. Areál Mendelovy univerzity může pro někoho klidně být takovýmto neznámým místem. Člověk, který již několik let navštěvuje stejnou budovu, nebude zřejmě potřebovat poradit, kde v ní najde posluchárnu. Naopak se ale může dostat do situace, že je studovna v této budově uzavřena a tak musí najít studovnu jinou. Dále jsou tu ale samozřejmě lidé, kteří se chystají navštívit univerzitu poprvé nebo na ni chodí jen zřídka. Právě takovýto typ uživatele by mohl potřebovat poradit a mohl by aplikaci využít. Při rozhlédnutí v MHD nebo na náměstí, je téměř nemožné nevidět někoho, kdo právě využívá mobilní telefon. Mobilní telefon se již nejspíš stal naprosto nepostradatelným pomocníkem většiny obyvatel České republiky. Výzkumy Českého statistického úřadu říkají, že v roce 2013 mělo v ČR mobilní telefon více jak 96% obyvatel, starších 16 let. Jestliže vezmeme v úvahu pouze chytré mobilní telefony, není toto číslo zatím tak vysoké. Je však více než zřejmé, že díky neustále probíhající obměně mobilních zařízení, stále se snižujícím cenám a lákavým funkcím chytrých telefonů, dojde do několika let k převážení misky vah a chytré telefony budou u uživatelů dominovat. (Český statistický úřad, 2014) Chytrý mobilní telefon usnadňuje spoustě lidí jejich každodenní činnosti, připomene jim důležitou schůzku, kterou nechtějí zmeškat, dovede je na požadované místo v neznámém městě nebo jim jen zkrátí dlouhou chvíli při čekání na autobus. Spolu s vývojem nových technologií pro mobilní telefony tu byla i zřejmá snaha o jejich miniaturizaci. I přesto, že jde tento trend v posledních letech spíše opačným směrem, zůstávají mobilní telefony stále poměrně kompaktní a tudíž snadno přenositelné. Díky tomu, že jsou mobilní telefony přenositelné a jejich majitelé je tak mohou mít neustále u sebe, naskýtá se možnost jich využívat k celé řadě činností spjatých s určováním zeměpisné polohy. Jde například o prosté určení aktuální polohy zařízení (a zároveň tedy i uživatele), vytyčení nejkratší trasy k danému místu, neustálou kontrolu aktuální pozice a upozornění uživatele, kdykoliv se přiblíží k daným souřadnicím nebo nepřeberné množství dalších možností. I přes opravdu velké množství již vyvinutých aplikací má tato oblast stále veliký potenciál.

9 Úvod a cíl práce Cíl práce Hlavním cílem této práce je navrhnout nový způsob pro zlepšení orientace v areálu Mendelovy univerzity v Brně. Za tímto účelem vytvořím aplikaci pro chytré mobilní telefony využívající OS Android, která orientaci uživateli usnadní. Práce se bude skládat z části teoretické a části praktické. V části teoretické proberu způsoby, jakými je uživateli orientace usnadňována doposud a navrhnu způsob nový. Zmíním také několik informací o operačním systému Android, shrnu požadavky na aplikaci a provedu její první návrh. V části praktické provedu samotnou implementaci mobilní aplikace, pro operační systém Android. Tato aplikace využije globálního polohového systému k usnadnění orientace uživatele v areálu. Jako další věc implementuji jednoduchý organizér, ve kterém bude ke každé upomínce přiřazena geografická oblast (geofence), a tato upomínka bude spuštěna právě ve chvíli, kdy zařízení do dané oblasti vstoupí. Dále pak zhodnotím možnosti nasazení aplikace, způsoby její distribuce a marketingovou činnost s tím spjatou. Na závěr celou práci kriticky zhodnotím, nastíním možnou budoucnost této aplikace, její nedostatky i přednosti oproti podobným.

10 10 Usnadnění orientace v areálu školy 2 Usnadnění orientace v areálu školy Mendelova univerzita v Brně se svojí rozlohou zařadí na první místa jen stěží, avšak díky tomu, že se většina jejich budov nachází v jednom areálu, není tato plocha tak úplně zanedbatelná. Areál v Černých Polích má více jak 80 tisíc m 2, více jak 15 budov a nespočet učeben a jiných míst, která stojí za to hledat. 2.1 Možnosti navigace Možností, jak může člověk na neznámém místě nalézt to, co právě nalézt potřebuje, může být celá řada. Různá místa nabízejí různé způsoby, jak navigaci usnadnit. Některá místa nemají možnost žádnou, jiná jich mají více a člověk má možnost výběru. Ne vždy má však člověk takové štěstí, aby si mohl vybírat a proto se musí často spokojit s tím co má právě k dispozici. Jakmile uživatel zjistí, kde se hledané místo nachází, často potřebuje o tomto místě získat nějaké detailnější informace, jako je třeba otevírací doba. V této kapitole vám přiblížím některé způsoby pro usnadnění orientace a poskytování informací, které již v areálu Mendelovy univerzity fungují, a následně navrhnu nový způsob, kterým by bylo možné orientaci v areálu ještě více zjednodušit Tištěné navigační materiály Prvním způsobem jak usnadnit orientaci v areálu univerzity a dodat uživateli informace o hledaných místech, jsou tištěné navigační a informační materiály. Do této kategorie řadím například navigační a informační tabule, umístěné v areálu univerzity, tištěné prospekty o univerzitě, ale třeba i cedule s otevírací dobou umístěné u studijního oddělení. Společným rysem takovýchto materiálů je, že jakmile jsou jednou hotové (vytištěné nebo vyrobené jiným způsobem), nelze již většinou jejich obsah měnit. I přes tuto zřejmou nevýhodu je tento způsob stále velice často využíván a lze ho vidět po celé univerzitě. Navigační tabule s mapou je umístěna například u vstupu do areálu univerzity, mezi budovami A a Q. Informační letáky lze dostat téměř na každém rohu. Pokud mají zůstat tyto materiály aktuální, je třeba provádět při každé změně jejich aktualizaci, což u papírového prospektu obnáší vytištění jeho upravené verze. Proto se využití těchto materiálů hodí především v případech, kdy jsou poskytovány informace o věcech stálých a delší dobu neměnných. Pokud pominu stavbu nových budov v posledních letech, dalo by se říci, že je areál Mendelovy univerzity poměrně ustálený, a tudíž, že je pro něj využití navigace pomocí tištěných materiálů přijatelné. Pokud jde ovšem o poskytování informací, není jejich využití příliš vhodné. Informace, jako telefonní číslo na koleje nebo otevírací doba prodejny skript, se mohou měnit a v takové situaci jsou neaktualizované informace spíše matoucí. I přesto se tento způsob hojně

11 Usnadnění orientace v areálu školy 11 využívá, například ve formě vizitek nebo jako cedule s otevírací dobou kanceláře, umístěná vedle dveří Materiály využívající informačních technologií Hlavním nedostatkem prvního způsobu byla neměnnost zobrazovaných informací. Proto bylo téměř nemožné získat všechny potřebné informace na jednom místě (mapa areálu je na jednom místě, informace o objektu zase na jiném). Tento zásadní nedostatek je vyřešen díky informačním technologiím. Přestože je nadpis této kapitoly hodně obecný, řadím do této kategorie především statická zařízení, která nejsou určena pro práci v pohybu. Jde hlavně o stolní počítače s přístupem na Internet, které jsou umístěny například ve studovnách, dále potom informační stánky a informační obrazovky, které lze vidět například při vstupu do budovy Provozně ekonomické fakulty. Ať už jde o stolní počítač nebo informační stánek, jejichž ovládání je v rukou uživatele, nebo o informační obrazovky, jež zobrazují informace předem nastavené, umožňují tato zařízení zobrazované informace měnit a tím jich poskytnout mnohem více, než tomu bylo u tištěných materiálů. Již bylo několikrát napsáno, že tato zařízení mají oproti prvnímu přístupu velkou výhodu, tedy dynamický obsah. Je třeba však zmínit i jejich nevýhody a slabé stránky. Jelikož do této kategorie spadají hlavně statická zařízení (neumožňující jejich přenos nebo nevhodná pro práci v pohybu), je jejich hlavním nedostatkem právě nepřenositelnost a nemožnost s nimi pracovat v pohybu. Do této kategorie lze zařadit i laptopy, které i když jsou snadno přenositelné, nejsou konstruovány pro práci v pohybu. Jakmile uživatel počítač vypne nebo odejde od informačního stánku či obrazovky, je odkázán pouze na to, co si při interakci s takovýmto zařízením zapamatoval nebo zaznamenal. Pokud zjistí, že jsou tyto informace nedostačující, musí se k tomuto zařízení vrátit nebo se spoléhat na náhodu. Ani jedna z těchto možností nemusí však být časově přijatelná Aplikace pro mobilní telefony a tablety Rozumnou alternativou by tedy bylo něco, co uživateli poskytne mapové podklady, informace o objektu a zároveň to bude mobilní. Právě takováto kritéria může splňovat chytrý mobilní telefon nebo spíše aplikace pro chytrý mobilní telefon. Smartphony, tedy chytré telefony, jsou mobilní, snadno přenositelná zařízení, umožňující uživateli uchovávat velké množství dat, ke kterým má kdykoliv přístup. Výhodou je navíc to, že většina moderních zařízení má i GPS modul, který za vhodných podmínek umožní určit aktuální polohu uživatele. Vzácností již také není mobilní Internet, který dokáže takovouto aplikaci ještě více obohatit.

12 12 Usnadnění orientace v areálu školy 2.2 Volba možnosti navigace První dva způsoby popisují již využívané možnosti, jak usnadnit orientaci v areálu univerzity a dodat uživateli informace o místech, která hledá. Tento výčet přístupů nemusí být samozřejmě konečný a zajisté lze nalézt i další způsoby, které v této práci nejsou zmíněny. Třetí popsaný přístup pak nastínil zatím nepoužívaný, avšak slibně vypadající způsob, který má potenciál ještě více usnadnit orientaci v areálu univerzity. První přístup využívá například navigačních a informačních tabulí nebo tištěných letáků. Tyto navigační pomůcky mohou být tedy jak nepřenosné (informační tabule), tak přenosné (tištěný leták), výhodou může být obojí. Pokud je něco nepřenosné, je to stále na stejném místě a uživatel se může téměř s jistotou spolehnout, že to tam najde, kdykoliv potřebuje. Na druhou stranu, přenositelnost je zřejmě větším přínosem, avšak pouze v případě, kdy objektem může manipulovat pouze sám uživatel a má tedy nad jeho polohou přehled. Na hlavní nevýhodu tohoto přístupu, tedy neměnnost obsahu, se dá rovněž nahlížet ze dvou pohledů. Buďto jako na omezující faktor, který reguluje množství poskytovaných informací nebo jako na něco, co nám zaručí stálost, neměnnost a umožní nám informace archivovat, což může být v některých případech rovněž žádoucí. I přes hrozbu ztráty dat z elektronických zařízení je však na neměnnost informací nahlíženo spíše jako na omezující faktor. Druhý přístup se díky informačním technologiím zbavil hlavního nedostatku tištěných materiálů, tedy statického obsahu. Zařízení jako je například stolní počítač může uchovávat velké množství informací, které potom podle požadavků uživateli zobrazuje. Jakmile má počítač připojení k Internetu, stávají se jeho možnosti v poskytování informací téměř neomezené. Hlavním zástupcem této kategorie je stolní počítač, jež umožňuje uživateli zvolit, jaká data budou zobrazena. V předešlé kapitole bylo zdůrazněno, že do této kategorie jsou zařazena pouze nepřenosná zařízení nebo zařízení, která i přes svoji přenositelnost nejsou vhodná pro práci během pohybu. Takováto zařízení jsou tedy při práci upoutána na jedno místo, což je často velice omezující. První dva přístupy tedy zachycují způsoby, které lze pro usnadnění orientace v areálu univerzity využít již nyní. Oba tyto přístupy jsou zajímavé, avšak mají i své nedostatky. Proto přichází na řadu třetí zmiňovaný způsob, který zachovává většinu předností předchozích přístupů, ale zároveň minimalizuje jejich nedostatky. Ať už jde o chytré telefony nebo tablety, tato zařízení bývají poměrně dobře kapacitně vybavena a tudíž mohou uchovávat velké množství informací. Většina těchto zařízení má i možnost připojení k Internetu, čímž jejich potenciál ještě roste. Zároveň platí, že tato zařízení jsou mobilní a uživatel má tak k informacím přístup téměř kdykoliv a kdekoliv. S mobilitou těchto zařízení souvisí i jejich další výhoda. Většina moderních zařízení má vestavený GPS modul, pomocí kterého je možné téměř kdykoliv určit aktuální polohu těchto zařízení. Když to vezmeme s nadhledem, měli tuto možnost i předchozí dva přístupy. Na informační tabuli je většinou vyznačeno, kde se tabule nachází a rovněž pomocí počítače se dá přibližná poloha uživatele

13 Usnadnění orientace v areálu školy 13 zjistit. Oba tyto přístupy však ztroskotávají na tom, že je tato poloha statická a uživatel tak zjistí pouze svoji aktuální polohu, nikoliv jak se poloha s jeho pohybem mění. V tomto ohledu má chytrý mobilní telefon velkou výhodu. Chytré telefony a tablety nejsou ale samozřejmě bezchybné. Hlavní nevýhodou je bezesporu výdrž jejich baterie. Následující tabulka zobrazuje přehledně hlavní výhody a nevýhody jednotlivých přístupů. Tab. 1 Porovnaní přístupů pro zlepšení navigace v areálu školy Tištěné materiály Informační tech. Mobilní aplikace + velké množství + přenositelnost + velké množství + kreativita informací informací + možnost volby + lokace aktuální polohy + snadné vyhledávání + přiměřeně snadné vyhledávání - neměnnost informací - nepřenositelnost - omezená výdrž baterie První přístup, tedy využití tištěných materiálů, nemá příliš mnoho výhod. Tento způsob se však od těch dalších dvou liší. U tohoto přístupu je totiž možné naplno využít kreativitu a upoutat tak uživatele. Nemusí jít totiž pouze o vizualizaci obsahu, jako je tomu u ostatních přístupů (obrazovka zůstává stejná, mění se pouze to, co zobrazuje), ale taky o vzhled celého nositele informace, jeho umístění, atd. Nevýhodou tohoto přístupu je však neměnnost zobrazovaných informací, která činí tento přístup vhodným hlavně pro dlouhodobě neměnné informace. Zařízení z oblasti informačních technologií mohou oproti prvnímu přístupu uchovávat velké množství informací. Zatímco první přístup se stává při rostoucím množství informací nepřehledným (mnohostránkové katalogy), u druhého přístupu to znamená pouze zvýšení jeho potenciálu. Druhý přístup totiž často využívá přehledného třídění a snadného vyhledávání, pro které není velké množství dat problém. Uživatel má potom možnost volby, která data si přeje zobrazit. Ke snadnému vyhledávání přispívá rovněž jednoduché ovládání zařízení (klávesnice a myš, velká dotyková obrazovka informačního stánku, atd.). Velkou nevýhodou tohoto přístupu však stále zůstává nepřenositelnost těchto zařízení. Třetí přístup se jeví dle uvedené tabulky jako nejoptimálnější. Uchovává si výhody předchozích přístupů a k tomu přidává vlastní. Mobilní telefon může uchovávat velké množství informací, stejně jako počítač, ale na rozdíl od počítače je přenositelný. Díky poměrně malým dotykovým displejům nemají chytré telefony tak snadné ovládání jako je tomu u stolních počítačů. Vzhledem k ostatním výhodám je však tato daň přijatelná. Velkou výhodou tohoto přístupu, kterou předchozí dva postrádají, je určování aktuální polohy uživatele. Jejich nevýhodou je však omezená kapacita baterie.

14 14 Usnadnění orientace v areálu školy 2.3 Volba platformy Jak již bylo napsáno výše, první dva přístupy popisovali již využívané způsoby usnadnění navigace. Třetí způsob nastínil způsob nový, dosud nevyužívaný. Právě proto, že je tento způsob dosud nevyužívaný a taky proto, že má oproti prvním dvěma přístupům nepopíratelné výhody, pokusím se ho ve svojí práci využít. Za tímto účelem navrhnu a následně implementuji mobilní aplikaci, která bude využívat výhod popsaných v předešlé kapitole. Tato aplikace by poté měla dosahovat ještě lepších výsledků při usnadňování orientace v areálu univerzity, než tomu bylo u prvních dvou popsaných přístupů. Nabízí se však celá řada platforem, pro které lze tuto aplikaci vypracovat. Patří mezi ně např. Android, ios, Windows Phone, SymbianOS, BlackBerryOS a mnoho dalších. V současné době jsou nejrozšířenější právě první tři jmenované systémy, Android, ios a Windows Phone, přičemž první z nich má před zbytkem až propastný náskok v počtu uživatelů. V grafu jde vidět vývoj počtu uživatelů 3 nejpoužívanějších operačních systémů. 90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% 2013 prosinec 2014 březen 2014 červen 2014 září Android ios Windows Phone Obr. 1 Graf znázorňující výsledky průzkumu na stránkách StatCounter. Nastavený filtr zahrnuje data pouze z mobilních telefonů na území České republiky Tento graficky znázorněný průzkum pochází ze stránek StatCounter ( Na této stránce provádí výzkumy na základě sledování více jak 3 milionů webových stránek po celém světě. Sledují polohu připojeného zařízení, využívaný prohlížeč, operační systém, rozlišení obrazovky, jestli jde o mobilní telefon nebo počítač a spoustu dalších užitečných parametrů. Tento průzkum se nemusí zdát zcela objektivní, jelikož ne všichni uživatelé musí mít v telefonu přístup na Internet. Pro moji práci však poslouží tento průzkum velice dobře, jelikož bych se rád soustředil právě na uživatele, kteří přístup

15 Usnadnění orientace v areálu školy 15 k Internetu mají a mohou tak využívat větší škálu funkcí, než kdyby ho neměli. Koneckonců, chytrý telefon bez připojení k Internetu není tak úplně plnohodnotným chytrým telefonem. Jelikož jsou v průzkumu shromažďovány i geografické údaje, mohl jsem data omezit pouze na ČR. V grafu je vidět, že nejlépe je na tom platforma Android. Má skoro 80% všech uživatelů. Procento uživatelů samozřejmě nemusí být klíčovým faktorem pro výběr platformy. Bývá nepsaným pravidlem, že se aplikace vyvíjejí na všechny 3 tyto platformy. Pro účely mé práce bude ale stačit, když zvolím pouze jednu z nich a tou bude platforma Android. Rozhodl jsem se tak, protože je mi tento operační systém ze všech nejbližší a vývoj pro mě tedy bude o něco snadnější.

16 16 Operační systém Android 3 Operační systém Android Ještě předtím, než se vrhnu na vývoj samotné aplikace, zmíním zde několik faktů o operačním systému Android. 3.1 Historie OS Android je relativně mladým operačním systémem. Jeho vznik se datuje do roku 2003, kdy vznikla společnost Android, Inc. Tato společnost se původně soustředila na vývoj mobilních aplikací, avšak v roce 2005 se stala 100% dceřinou společností giganta Google. Tímto tahem získal Google zkušený tým, jenž dostal za úkol vytvořit novou platformu pro mobilní zařízení. Právě tímto krokem začal psát Google svoji úspěšnou historii na poli chytrých mobilních telefonů. (Ujbányai, 2012) Nový operační systém byl světu oficiálně představen 5. listopadu Tento den spatřilo světlo světa rovněž i nové uskupení firem, které mají co dočinění s mobilními technologiemi. Šlo o mobilní operátory, softwarové společnosti, společnosti vyrábějící polovodičové součástky nebo samotné výrobce mobilních telefonů. Toto sdružení, pojmenované Open Handset Alliance, si dalo za cíl, sdružit roztříštěný trh a vytvořit společné standardy pro mobilní zařízení. Tento den, bylo rovněž představeno první zařízení, založené na této platformě. Tímto začal stále přetrvávající souboj mezi Androidem a jeho konkurencí. (Ujbányai, 2012) 3.2 Verze operačního systému Od roku 2007 již uplynula řada let a operační systém Android ušel od té doby dlouhou cestu. Jak již bylo zmíněno dříve, Android zaujímá velkou část trhu. Takového úspěchu by nedosáhl, kdyby nedržel krok s potřebami jak uživatelů, tak vývojářů. Jenom díky neustálému zlepšování a inovacím se Android dostal tam, kde je nyní. Pro každou verzi je typické, že dostane za přívlastek nějakou sladkost. Tyto jména jsou vybírány podle abecedy. V době, kdy byla práce psána, měla poslední vydaná verze číslo 4.4 a přívlastek KitKat. Pro vývojáře je rovněž dobré pochopit systém úrovní API. API není to stejné co verze systému, i když to spolu úzce souvisí. Verze API jednoznačně identifikuje rámec revize API, jenž je poskytován pro danou verzi Android platformy. Každý rámec se skládá z různých komponent, patří mezi ně např. sada balíčků a tříd, sada elementů a atributů pro deklaraci v souboru AndroidManifest.xml a spousty dalších. Nová verze API sebou tedy přináší novu funkcionalitu, které dále rozšiřují možnosti tohoto operačního systému. Aktualizace rámce je vždy navržena tak, aby novější API byly kompatibilní se staršími verzemi, tzn. většina změn je aditivní a jen rozšiřuje stávající funkčnost. Verze API hraje klíčovou roli pro vývojáře aplikací. Vývoji aplikací předchází výběr verze API, na kterou bude

17 Operační systém Android 17 aplikace vyvíjena. Verzi API uchovává element <uses-sdk> v souboru Android- Manifest.xml, který má každá vyvíjená aplikace. (Ujbányai, 2012) 3.3 Architektura OS Funkcionalita operačního systému Android je rozdělena do pěti vrstev. I když má každá vrstva své vlastní úkoly a vystupuje víceméně samostatně, v praxi nakonec dochází k jejich spolupráci. Obr. 2 Schéma architektury operačního systému Android, zdroj: Android-App-Market, Linux Kernel Tato nejnižší vrstva architektury představuje jádro operačního systému. Její funkcí je vytvořit most mezi použitým hardwarem a softwarem. Při startu zařízení je jádro nataženo do operační paměti a je mu předáno řízení. To představuje neustálou kontrolu nad systémem a koordinaci činností všech běžících procesů (např. souběžný běh aplikací), podpora správy paměti, správy sítí, atd. (Android-App-Market.com, 2012) Knihovny (Libraries) Knihovny jsou další vrstvou architektury. Android nabízí vývojáři celou řadu rozhraní API. Kromě základních knihoven, sloužících např. pro práci s webovým

18 18 Operační systém Android obsahem nebo pro sledování telefonních hovorů či SMS zpráv, jsou tu ještě další knihovny, poskytované pomocí Android Application Framework. Patří mezi ně například OpenGL, jež slouží k podpoře 3D grafiky nebo SQLite, která obsahuje odlehčenou verzi relační databáze. (Android-App-Market.com, 2012) Android Runtime Tato vrstva obsahuje DVM (Dalvik Virtual Machine) a základní Java knihovny. Virtuální stroj Dalvik byl vyvíjen od roku 2005 speciálně pro Android společností Google. Důvodem pro vývoj DVM byl fakt, že i když knihovny jazyka Java mají volnou licenci, virtuální stroj (JVM) už volně šiřitelný není. Dalším důvodem bylo optimalizovat virtuální stroj pro potřeby mobilních zařízení, hlavní roli hrál tudíž výkon spolu s úsporou energie. (Android-App-Market.com, 2012) Application Framework Tato vrstva je pro vývojáře tou nejdůležitější. Díky otevřené platformě operačního systému Android se programátorům nabízí prostředí pro tvorbu bohatých a inovativních aplikací. Aplikační rámec umožňuje přistoupit k nejrůznějším službám, které mohou vývojáři využívat přímo ve svých aplikacích a ty jim následně dovolí např. přistoupit k prvkům graficko-uživatelského rozhraní, používat hardware zařízení, nastavovat alarmy, spouštět jiné aplikace na pozadí, atd. Některé důležité služby aplikačního rámce: View System, umožňuje použít pro tvorbu graficko-uživatelského rozhraní prvky jako textová pole, tlačítka, seznamy, přepínače, atd. Notification Manager, umožňuje zobrazení stavového řádku s vlastním upozorněním všem aplikacím. Content Providers, umožňuje přistoupit a pracovat s obsahem jiných aplikací, jako například Kontakty, Kalendář, aj. Activity Manager, ovládá životní cyklus aplikací, jejich start, průběh a ukončení. Resource Manager, poskytuje přístup k nekódovým zdrojům, jako jsou řetězce, grafika a další případné soubory. Package Manager, obsahuje informace o aplikacích nahraných do operačního systému. (Android-App-Market.com, 2012) 3.4 Životní cykly Životní cyklus Android aplikace se od většiny tradičních prostředí liší. Aplikace pro Android totiž nemá žádnou kontrolu nad svým životním cyklem. Proto je důležité, aby každá aplikace naslouchala změnám stavu a tyto změny následně řešila. Velký pozor je třeba si dávat na předčasné ukončení aplikace. Každá aplikace ve výchozím stavu běží ve vlastním procesu, který je spuštěn samostatnou

19 Operační systém Android 19 instancí virtuálního stoje Dalvik. Řízení procesů a přidělování paměti je řešeno výhradně za běhu aplikace. Jelikož je každá aplikace samostatný proces, souvisí její životní cyklus s životním cyklem procesu. Proces aplikace je řízen systémem v závislosti na aktuálním stavu systémové paměti. V případě nedostatku paměti je nucen OS Android některé méně důležité procesy ukončit. (Ujányai, 2012) 3.5 Vývojové prostředí Eclipse Jestliže se dnes kdokoliv podívá na stránky pro vývojáře (developer.android.com), najde tam jako preferované vývojové prostředí Android Studio. Tento razantní zlom proběhl ale teprve až ve druhé polovině roku Do té doby Android doporučoval pracovat ve vývojovém prostředí Eclipse do kterého byl nahrán plugin ADT (Android Developer Tools). Eclipse je integrované vývojářské prostředí (IDE), což je systém založený na rozšířitelných modulech. Prostředí je primárně určeno pro programování v jazyce Java, avšak pomocí těchto pluginů se dá rozšířit a následně je možné programovat např. v jazyce C++ nebo PHP. Jak už jsem psal výše, Android Studio je oficiálně doporučováno až od konce roku 2014 (předtím byla dostupná pouze beta verze) a tak jsem pro vývoj svojí aplikace využíval právě vývojové prostředí Eclipse. (The Java developer's guide to Eclipse, 2005)

20 20 Návrh aplikace 4 Návrh aplikace Při vývoji jakékoliv aplikace by měl být na prvním místě sběr požadavků, ze kterých je následně vytvořen návrh dané aplikace. Často se stává, že vývojáři zapomenout požadavky na aplikaci dostatečně přesně specifikovat, nebo tuto činnost odloží na později. Tento přístup je však naivní. Je velice důležité si uvědomit, že jakákoliv snaha o návrh aplikace, psaní kódu nebo testování je zbytečná, dokud nejsou dostatečně jasně stanoveny požadavky. (Phillips, 2004) Sběr požadavků může probíhat různými formami. Může jít například o dotazníkové šetření mezi potenciálními zákazníky a uživateli, interview se zadavatelem projektu nebo třeba pozorování prostředí budoucího nasazení a přizpůsobení aplikace jeho požadavkům. (Jonasson, 2013) Ve většině případů se požadavky odvíjejí od nějaké zavedené činnosti, jejíž vykonávání má být pomocí dané aplikace zjednodušeno. Najdou se samozřejmě i případy, kdy je jako první vyvíjena aplikace a na jejím základě potom podporované procesy vzniknou, takovýchto případů však není mnoho. Moje aplikace se dá zařadit jak do kategorie první, jelikož se snaží uživateli usnadnit orientaci v areálu, což je už činnost objevená, tak do kategorie druhé, jelikož ještě není žádná mobilní aplikace pro Android, která by uživateli orientaci v areálu zjednodušila, takže tuto činnost, tedy usnadnění orientace v areálu MENDELU pomocí Android aplikace, bude provádět uživatel poprvé, a tudíž ho moje aplikace podnítí k nové činnosti. Zařazení do jedné z těchto kategorií je silně ovlivněno subjektivním pohledem čtenáře. (Maciaszek, 2007) Před vývojem mojí aplikace by bylo tedy vhodné provést sběr požadavků, nejlépe od budoucích studentů Mendelovy univerzity v Brně, jelikož především na tyto uživatele je aplikace cílena. Realita byla však jiná. Kvůli nedostatku času jsem provedl sběr požadavků sám. Rozhodl jsem se najít aplikace s podobným zaměřením, provedl jsem jejich testování a zaznamenal si jejich přednosti i slabé stránky. 4.1 Průzkum trhu Jelikož mým cílem je tvorba mobilní aplikace, která má uživateli zjednodušovat orientaci v areálu Mendelovy univerzity, daly by se za konkurenci považovat pouze podobní průvodci pro MENDELU nebo jiné aplikace, které jakýmkoliv způsobem usnadňují orientaci v areálu. Provedl jsem nespočet hledání na oficiálním internetovém obchodě Google Play, sdružujícím hry a aplikace pro OS Android (v současné době už tento portál není pouze pro hry a aplikace, ale lze na něm nalézt rovněž hudbu, filmy, knihy a mnoho dalšího obsahu). Pro hledání jsem používal různá hesla jako průvodce, univerzita, guide, orientace, navigace a mnoho dalších. Zkoušel jsem různé kombinace hesel spolu se jmény konkrétních univerzit v Brně a následně i po celé ČR. Nenalezl jsem ale nic, co by se podobalo mnou zamýšlené aplikaci.

21 Návrh aplikace 21 Jakmile jsem nenalezl žádnou podobnou aplikaci na území ČR, rozšířil jsem své hledání i za hranice. Tam jsem byl už poněkud úspěšnější. Nalezl jsem hned několik podobných aplikací. Vybral jsem z nich ty nejzajímavější a jejich rozbor provedu na následujících řádcích MENDELU Q Ještě předtím, než jsem začal hledat aplikace v zahraničí, narazil jsem na jedno zajímavé dílo u nás. Nešlo tedy přesně o typ aplikace, kterou mám v úmyslu vyvíjet já, ale jelikož šlo o tuzemské dílo a mělo podobnou tématiku, zařadil jsem ho do této práce. Jde o aplikaci s názvem MENDELU Q od Marka Musila. Tato aplikace byla rovněž vyvíjena jako bakalářská práce na Mendelově univerzitě. Jde o interaktivní 3D průchod budovou Q. Autor píše, že aplikace může pomoci při orientaci v budově. Provedl jsem testování této aplikace a došel jsem k závěru, že tato aplikace není příliš vhodná, k usnadnění orientace v areálu školy. Za prvé se soustředí pouze na budovu Q a za druhé je orientovaná spíše na vizuální zážitek než na usnadnění orientace. Právě proto ji nebudu zahrnovat ani do hodnocených aplikací, zmínil jsem ji pouze proto, že mi přišla zajímavá a že se týkala naší univerzity. Tuto aplikaci naleznete na stránkách: LLN Campus LLN Campus je aplikace vyvíjená několika studenty Katolické univerzity v Lovani v Belgii. Aplikace je tedy již z roku 2013 a dle mého jsou některé věci již značně zastaralé a překonané. Nabídka aplikace se na mém zařízení zobrazuje špatně, chybí části textu a design celkově postrádá jiskru. Pokud jde o funkcionalitu, aplikace nabízí možnost vyhledat knihovny, posluchárny a místa pro volný čas, jako jsou místa s občerstvením a další. Dále poskytuje uživateli samozřejmě i mapu areálu, byť jde jen o zobrazení dokumentu ve formátu pdf. Aplikace nabízí ještě několik funkcí, jako je vyhledávání zaměstnanců školy či přihlašování do informačního systému. Obě tyto a ještě některé další funkce jsou však zprostředkovávány prostřednictvím internetového prohlížeče, kde vás aplikace jednoduše přesměruje na stránky školy. Rovněž pro navigaci k hledaným místům a k získání detailů o místě je využito internetového prohlížeče. Aplikace tedy obsahuje pouze několik stěžejních funkcí a většina funkcionality je vyřešena formou přesměrování na školní weby. Tuto aplikaci naleznete na stránkách: Monash University Jde o mobilní aplikaci vyvíjenou pro univerzitu Monash v Melbourne v Austrálii. Uživatelské prostředí této aplikace mi přišlo poměrně přívětivé, i když několik nedostatků by se našlo i zde. Aplikace má velice slušnou funkciona-

22 22 Návrh aplikace litu. Pro navigaci v aplikaci je použito kombinace Navigation Draweru a klasické úvodní obrazovky s tlačítky. Aplikace má velice pěkně zpracováno zobrazování mapy areálu. Uživatel si může zvolit z několika kampusů, které univerzita má. Jakmile si vybere kampus, zobrazí se mu mapa (využívá Google Maps API) a na ní jsou pomocí polygonů vykresleny budovy areálu. Je zde možnost, zvolit si jaká místa v areálu chceme zobrazovat nebo můžeme hledat pouze jedno konkrétní místo. Další zajímavé funkce jsou vyhledávání knih, zaměstnanců a oborů vyučovaných na univerzitě. Nejsem si jistý, jestli jsem tyto funkce testoval správně, ale jediná funkční byla ta, pro zobrazování informací o oborech vyučovaných na univerzitě. Aplikace nabízí rovněž novinky a události na univerzitě, přehled linek MHD a další zajímavé funkce. Aplikace na mě celkově zapůsobila velice dobře, nabízela zajímavé funkce, které na mě udělaly dojem. Nepochybuji o tom, že se tato aplikace těší u studentů univerzity velké oblibě. Tuto aplikaci naleznete na stránkách: university NC State On Campus Aplikace On Campus má uživateli usnadnit život v kampusu Statní univerzity v Severní Karolíně v USA. Tato aplikace byla vytvořena studenty této univerzity ve spolupráci se zaměstnanci Ústavu informatiky. Pro navigaci v této aplikaci je využito Navigation Draweru a hned na úvodní obrazovce po spuštění jsou zobrazeny novinky z univerzity. Tento přístup se mi líbí, jelikož ihned po spuštění aplikace jsou uživateli zobrazeny nějaké informace, místo strohého výběru, co dělat. V této aplikaci je velice pěkně zpracována nabídka míst s občerstvením. Aplikace dále využívá funkcí projektu TransLoc ( pro přehled o linkách MHD. I v této aplikaci je možnost podívat se na nabízené obory na univerzitě. Oproti předchozí aplikaci má tato zajímavou funkci ve formě předpovědi počasí. Některé funkce aplikace v ní nejsou přímo naimplementovány, ale využívají různých externích modulů. Jde například o zjišťování informací o MHD nebo předpověď počasí. Tyto moduly jsou však do aplikace začleněny takovým způsobem, že to uživatel ani nepozná. Celkově na mě aplikace působí rovněž velice dobrým dojmem, má zajímavé funkce a pěkně vypadá. Jediné co se mi nelíbilo, bylo zobrazování mapy. Mapa se vždy vycentruje na pozici, na které aktuálně jste a pokud je to jinde než v areálu univerzity, musíte areál najít ručně. Byť jde o vcelku malý detail, mapa je jednou ze stěžejních funkcí takovéto aplikace a tak mi to poměrně vadilo. Tuto aplikaci naleznete na stránkách:

23 Návrh aplikace Razorbacks Campus Guide Tato aplikace je vyvíjena pro University of Arkansas v USA. Hlavní navigace aplikace je prostřednictvím tzv. six-packu, neboli tlačítek, která při stisknutí spustí odpovídající část aplikace. Její první funkcí je hledání budov. Uživatel si zvolí libovolnou z nabízených budov a ta se mu po kliknutí zobrazí na mapě. Naprosto stejné je to i v případě, kdy chce hledat občerstvení, počítačové učebny nebo jiná místa v areálu univerzity. Zkrátka, jedinou funkcí této aplikace je, že uživatel vybere místo a ona mu ho zobrazí jeho pozici na mapě. V porovnání s předchozími aplikacemi je tato poněkud slabší, jak do vzhledu, tak do funkčnosti. Není samozřejmě úplně špatná a její funkce se mohou často hodit, pouze v porovnání s předchozími velice povedenými aplikacemi je poněkud nedostačující. Tuto aplikaci naleznete na stránkách: Porovnání aplikací V této kapitole ještě jednou přehledně shrnu přednosti a nedostatky jednotlivých testovaných aplikací. Tab. 2 Porovnání testovaných aplikací, známky jsou na škále od 1-nejhorší do 3-nejlepší Uživatelské Zobrazení Hledání Funkcionalita prostředí mapy míst LLN Campus Monash U On Campus Razorbacks Dá se říci, že zcela shodně na mě působila uživatelská rozhraní aplikací Monash University a NC State On Campus. U obou se mi jejich vzhled líbil na první pohled, působil jednotně a vše fungovalo, jak mělo. Další dvě aplikace mi připadali nedotažené a jejich design mě neohromil. Pokud jde o funkcionalitu, byl to rovněž velice vyrovnaný souboj mezi aplikacemi Monash University a On Campus. Nakonec má ale přeci jen o něco více funkcí aplikace On Campus. Nejhůře na tom byla aplikace Razorbacks Campus Guide, která uživateli umožňuje pouze zobrazit vybraná místa na mapě. Zobrazení mapy areálu mě uspokojilo pouze u aplikace Monash University. Její mapa využívá Google Maps API, kde jsou pomocí polygonů vykresleny jednotlivé budovy v areálu. Uživateli je rovněž umožněno vykreslit na mapě body, které ho mohou zajímat. Ostatní aplikace buďto vykreslování mapy neměli vůbec, nebo bylo naimplementováno takovým způsobem, který nebyl příliš uživatelsky přívětivý.

24 24 Návrh aplikace Hledání míst zájmu bylo na dobré úrovni ve všech testovaných aplikacích. Žádná aplikace mě však svým zpracováním této funkce příliš nenadchla a proto je hodnocení tak vyrovnané. 4.2 Požadavky na aplikaci Získávání požadavků bývá prvním krokem u vývoje téměř všech aplikací. Důvod je jasný, je potřeba si ujasnit hlavní funkcionalitu aplikace a očekávání, která od ní zadávající má. (Maciaszek, 2007) Jak již bylo řečeno, sběr požadavků na mobilní aplikaci, nebo na aplikaci obecně, může probíhat různými způsoby. Velice oblíbené jsou rozhovory se zákazníky. Tímto způsobem si lze detailně upřesnit, jaké požadavky na aplikaci uživatel má. Tato technika je však často používána v kombinaci s jinými technikami, jelikož uživatel nemusí umět dostatečně přesně vyjádřit, co je pro něj důležité. Další možností jak požadavky získat, je sledovat zákazníka při práci, čímž zjistíme jeho potřeby při vykonávané činnosti. Tento způsob je rovněž vhodné vykonávat v kombinaci s jinými technikami. Jestliže má aplikace sloužit spíše pro veřejnost, je vhodné provést dotazníkové šetření. Tímto způsobem lze získat požadavky od velkého množství potenciálních uživatelů. Mezi techniky pro zjišťování požadavků patří rovněž průzkum trhu. Tato technika se hodí především v počátečních fázích vývoje aplikace. Ukáže vývojáři, jaká je situace na trhu, co trh vyžaduje a co již bylo vyvinuto. Nevýhodou této techniky je možnost omezení kreativity při tvorbě požadavků. (Jonasson, 2013) Nejnáročnější, při přenášení nějakého nápadu do konkrétních požadavků a následně do výsledné aplikace, bývá komunikace mezi jednotlivými složkami tohoto procesu. Není vždy snadné správně zformulovat své myšlenkové pochody a přesné záměry, a tak je velice důležité, stanovit normy pro tuto komunikaci. Ať už jde o stanovení společného jazyka, mezi partnery z různých zemí nebo o výběr návrhového prostředí, pomocí kterého zadávající snadněji sdělí vývojáři svoje požadavky, jde o normy, které tento proces značně usnadní a zamezí se tak nedorozuměním. (Maciaszek, 2007) Já jsem se kvůli několika důvodům rozhodl stanovit požadavky na tuto aplikaci sám, a tudíž nebudu muset tyto problémy řešit. I když se budu co nejvíce snažit vyjít vstříc všem potencionálním uživatelům mojí aplikace, pravdou zůstává, že požadavky na aplikaci budou nejspíše zkreslené mým subjektivním názorem Poučení z průzkumu trhu Průzkum trhu jsem prováděl ze dvou důvodů. Prvním důvodem bylo nalézt potencionální konkurenci pro moji aplikaci. Druhým důvodem potom otestovat tyto konkurenty a jiné podobné aplikace a nalézt jejich slabé stránky a chyby, ze kterých bych se při vývoji vlastní aplikace poučil. Při testování aplikací jsem však narazil na spoustu zajímavých funkcí, kterými jsem se pro svůj vlastní vývoj inspiroval.

25 Návrh aplikace 25 Přestože jsem při průzkumu trhu nenarazil na žádné konkurenty, nalezl jsem několik zajímavých aplikací, které jsem otestoval. Hodnocení jednotlivých aplikací jsem prováděl již v předcházejících kapitolách, zde bych však chtěl ještě jednou shrnout věci, které se mi na nich líbili a naopak věci, na které si budu dávat při vývoji vlastní aplikace pozor a budu se jich snažit vyvarovat. Velice se mi líbilo zobrazování mapy areálu, v aplikaci Monash University. Na této mapě byly přehledně vykresleny budovy univerzity a navíc si uživatel mohl vybrat konkrétní typ míst, která chce na mapě zvýraznit (uživatel měl např. možnost zobrazit na mapě pouze autobusové zastávky). Naopak se mi nelíbilo, že aplikace LLN Campus měla téměř veškerou svoji funkcionalitu prováděnou pomocí internetového prohlížeče. Tomu bych se chtěl ve svojí aplikaci vyhnout a docílit tak funkcionality aplikace na dobré úrovni i bez připojení k Internetu. Na několika aplikacích se mi rovněž nelíbilo, že používaly vstupní obrazovku aplikace pouze pro navigaci a nezobrazovaly na ní žádná data Formulace požadavků Při získávání požadavků na vyvíjenou aplikaci jsem tedy nejprve vycházel z vlastních zkušeností s orientací v areálu. Přemýšlel jsem, co bych jako student prvního ročníku mohl potřebovat. Došel jsem k závěru, že aplikace by rozhodně měla mít mapu areálu, která uživateli pomůže se zorientovat a přehledně mu ukáže, kde se zrovna nachází. Další důležitou funkcí je samozřejmě hledání různých míst na univerzitě. Je totiž důležité, aby uživatel mohl aplikaci říci, co přesně chce v danou chvíli ukázat a ona mu to skutečně ukázala. Při objevování OS Android jsem se setkával s novými funkcemi a možnostmi tohoto systému, které by byly větším či menším přínosem pro vyvíjenou aplikaci. Mezi takovéto funkce patří například sledování geofencí. Geofence je virtuální oblast, reprezentující nějakou oblast reálného světa. Jejich sledování funguje tak, že si uživatel stanoví pomocí zeměpisných souřadnic a poloměru kruhovou oblast. Následně je pomocí povolených technologií pro určení zeměpisné polohy (GPS, mobilní sítě, ad.) kontrolováno, zdali zařízení do této oblasti vstoupilo. (Smith a Friesen, 2014) Právě sledování geofencí mi přišlo jako zajímavá funkce, rozhodl jsem se ji proto implementovat do svojí aplikace, a to ve formě upomínek, kde si uživatel k dané upomínce přiřadí lokaci, na kterou bude následně upozorněn Funkční a nefunkční požadavky Požadavky na aplikaci se dají rozdělit na funkční a nefunkční. Funkční požadavky jsou důležitější a reprezentují samotné procesy, a proto bývají často zachycovány ve formě use case diagramů. Funkční požadavky je důležité pozorně analyzovat, abychom se vyhnuli duplicitám a rozporům v zadání. Mezi funkční požadavky na moji aplikaci lze zařadit například schopnost zobrazit mapu areálu a určit aktuální polohu uživatele. Hledání konkrétního místa v areálu se dá do

26 26 Návrh aplikace funkčních požadavků zařadit rovněž, je to totiž něco, co musí aplikace umět. Do této kategorie rovněž patří i to, aby aplikace uměla sledovat geofence. (Maciaszek, 2007) Jak je vidět, všechny požadavky specifikované v předešlé kapitole byly funkčního charakteru. Bylo by rovněž dobré, stanovit si nějaké nefunkční požadavky. Nefunkční požadavky nedefinují už chování aplikace, spíše usměrňují její vývoj a implementaci. Dodržování těchto požadavků potom často určuje kvalitu výsledné aplikace. Mezi nefunkční požadavky patří například použitelnost, spolehlivost nebo výkonnost aplikace. Moje aplikace by měla být samozřejmě použitelná, měla by uživateli usnadnit orientaci v areálu univerzity. Samozřejmě bych chtěl, aby byla aplikace spolehlivá, výkonná a aby splňovala i další zde nezmíněné nefunkční požadavky, avšak to, jestli skutečně bude, ukáže až její ostrý provoz. (Maciaszek, 2007) Shrnutí požadavků Správné porozumění požadavkům zadavatele je velice důležitou části vývoje aplikace. Jakmile vývojář pochopí některou část zadání špatně, může dojít k omylům, které ho budou stát spoustu času. Při svém vývoji jsem měl tu výhodu, že k žádnému nedorozumění dojít nemohlo. I přesto jsem se snažil mít takové požadavky, aby aplikace uspokojovala co největší spektrum potenciálních uživatelů. Požadavky na svoji aplikaci shrnu pro jistotu ještě jednou zde. Hlavním požadavkem je vytvořit aplikaci pro chytré mobilní telefony, využívající OS Android, která usnadní uživateli orientaci v areálu Mendelovy univerzity v Brně. Aplikace bude obsahovat mapu areálu univerzity, na které zobrazí polohu uživatele a zajímavá místa v areálu. Aplikace pomůže uživateli najít jim hledaná místa, zobrazí mu o nich informace a ukáže mu jejich polohu na mapě. Aplikace umožní uživateli sledovat vybranou geografickou oblast, a jakmile se v ní ocitne, upozorní ho na to. Aplikace bude použitelná a uživatelsky přívětivá. 4.3 Uživatelské rozhraní Uživatelské rozhraní by mělo být samozřejmě jednoduché a uživatelsky přívětivé. Mělo by uživateli umožnit, dostat se co možná v nejkratším čase k informacím, které ho zajímají, a určitě by taky mělo odpovídat účelu, pro který je aplikace konstruována. Právě tím jsem se při návrhu uživatelského rozhraní řídil Vývojářské typy Vývojáři Googlu stanovili od verze Ice Cream Sandwich tři základní pilíře, na které se při vývoji aplikací soustředí. Názvy těchto tří pilířů jsou Upoutej mě,

27 Návrh aplikace 27 Usnadni mi život, Ohrom mě. První pilíř, Upoutej mě říká, že krása je víc než jen to, co vidíme na povrchu. Aplikace musí být dokonalé ve všech ohledech. Nestačí, když aplikace pouze dobře vypadá, musí i dobře fungovat, mít plynulé přechody, atd. (Android Developers, 2014) Druhý bod říká, Usnadni mi život. Aplikace by měly uživateli pomoci, usnadnit mu život. Zároveň by měly být snadno pochopitelné pro nového uživatele a měly by mu jednoduše zprostředkovat své základní funkce. Design by se neměl soustředit pouze na první dojem. Jednoduchým úkonům aplikace by nikdy neměly předcházet složité postupy a složité úkony by měly být přizpůsobeny i nezkušenému uživateli. Lidé všech kultur a věkových kategorií jsou rádi, když mají věci pod kontrolou a proto by aplikace neměla nabízet přebytek zbytečných možností. (Android Developers, 2014) Poslední pilíř se jmenuje Ohrom mě a říká, že aplikace má uživateli poskytnou to, co potřebuje, avšak k tomu ještě něco navíc. Android aplikace umožňují lidem zkoušet nové věci a nové postupy. Aplikace by měla působit dojmem, že v ní má uživatel soukromí a měla by se adaptovat konkrétním požadavkům. I přesto by měla uživateli poskytnout nějakou zajímavou technologii. (Android Developers, 2014) Barevné schéma aplikace Android aplikace používají mechanismus témat, která aplikují konzistentní styl na aktivitu (jednu obrazovku) nebo celou aplikaci. Uživatel může tímto způsobem upravovat jednotlivé elementy uživatelského prostředí a přizpůsobit ho tak požadavkům. Upravovat lze například barvu, velikost, odsazení či styl písma. Android poskytuje začínajícím vývojářům dvě základní témata, která je možno editovat a vytvářet z nich témata vlastní. (Android Developer, 2014)

28 28 Návrh aplikace Obr. 3 Ukázka použitého tématu v aplikaci Pro svoji aplikaci jsem zvolil téma Holy Light, které jsem postupně editoval, aby lépe vyhovovalo mým požadavkům. Jelikož barvou naší univerzity je světle zelená, ladil jsem do tohoto odstínu celou aplikaci. Tuto barvu najdete v prvku Action Bar (panel v horní části obrazovky), který je viditelný skrze celou aplikaci. Další využití této barvy bylo u Markerů, kterých se využívá pro vyznačení místa na mapě. Zelená je využita rovněž v Navigation Draweru, neboli bočním výsuvném menu Ikony aplikace Ikona obecně, je grafický prvek, jež zabírá pouze malou plochu displeje a pomáhá uživateli snadno a intuitivně rozeznat, jakou akci, stav nebo aplikaci daná ikona reprezentuje. (Android Developer, 2014) Při návrhu ikony aplikace je dobré myslet na to, že aplikace může být nainstalována na velkém množství odlišných zařízení, s odlišným rozlišením displeje. Při instalaci aplikace se zjistí informace o používaném zařízení a následně se použije sada obrázků s odpovídajícím rozlišením displeje. Z tohoto důvodu se vytváří ikona aplikace v několika rozlišeních. (Android Developer, 2014) Ikona pro spouštění aplikace je vlastně vizuální reprezentací dané aplikace na domovské obrazovce nebo na obrazovce všech aplikací. Je třeba se ujistit, že i když uživatel změní pozadí domovské obrazovky, bude ikona dostatečně kontrastní a půjde dobře vidět. (Android Developer, 2014)

29 Návrh aplikace 29 Obr. 4 Vzhled ikony aplikace Moje ikona převzala z loga Mendelovy univerzity čtyři zelené puntíky, neboli hrášky. Dále je v ní název aplikace a ukazatel směru, který má symbolizovat, že aplikace pomůže uživateli nalézt správný směr. V aplikaci je samozřejmě využito i jiných ikon. Obraz totiž dokáže předat informaci rychleji, než slova. Při použití správné ikony dojde uživateli mnohem rychleji, k čemu daná funkce slouží. Ikony jsou využívány v hlavním menu aplikace a taky u některých Action Buttons, což jsou tlačítka umístěná v Action Baru. Místo toho, abych všechny tyto ikony vytvářel, využil jsem portálu, který poskytuje grafický obsahu zdarma komukoliv, kdo o něj má zájem. Jde o server Všechny ikony jsem ladil do jednoho stylu. Jsou to jednoduché černě vykreslené symboly, které jsou ve zbývajících částech průhledné, takže jimi proniká barva pozadí. Tím nijak neruší konzistentnost prostředí a vypadají, jakoby byly pro tento účel stvořeny.

30 30 Implementace aplikace 5 Implementace aplikace V této kapitole jako první rozeberu strukturu navržené aplikace, a to jak pomocí scénářů, které popisují, jaké akce lze nad aplikací provádět, tak pomocí struktury jejich aktivit, které reprezentují zobrazované části mojí aplikace. Rozeberu způsoby navigace v aplikaci na nejvyšší úrovni a nejvhodnější způsob aplikuji do vlastní aplikace. Následně se zaměřím na zajímavé části aplikace a ukážu jejich implementaci ve svojí aplikaci. 5.1 Struktura aplikace Struktura obecně říká, jak je daná věc uspořádána, z jakých se skládá prvků, atd. Struktura může rovněž popisovat i vztahy mezi těmito prvky či jejich hierarchii. Jako užitečnou pomůcku při tvorbě struktury aplikace je dobré si stanovit primární scénář užití aplikace a následně se na něj zaměřit při vývoji. Od primárního scénáře se potom odvíjí scénáře vedlejší. (Android Developer, 2014) Scénáře užití aplikace Pro začátek si tedy vytvořím primární scénář užití, neboli popíšu, jak by mohl vypadat nejčastější případ využití mojí aplikace. V jedné z předchozích kapitol jsem shrnul požadavky na aplikaci a z nich budu nyní vycházet. 1. Uživatel otevře aplikaci. 2. Uživatel vybere z menu možnost Hledat místo. 3. Uživatel vybere konkrétní místo a stiskne tlačítko Hledat. 4. MendeluGuide zobrazí informace o místě Takto si představuji hlavní scénář užití aplikace. Nyní vytvořím diagram, který bude přehledně zobrazovat jak hlavní, tak i všechny vedlejší scénáře užití aplikace a tím nastíní její strukturu a funkcionalitu.

31 Implementace aplikace 31 Obr. 5 Grafická reprezentace možných případů užití aplikace Tento obrázek jsem vytvořil pomocí online editoru na stránkách Na obrázku je vidět jak primární scénář užití aplikace, tak všechny ostatní. První větev diagramu vypadá jednoduše, avšak opak je pravdou. Tato větev skrývá zobrazování mapy, jež je po implementační stránce poměrně náročné. Uživatel má možnost si vybrat, jaká místa chce na mapě zobrazit, což mu usnadní jejich hledání. Druhá větev, Hledat místo, slouží k zobrazení informací pouze o jednom vybraném místě. Uživatel si vybere z nabídky místo a po kliknutí na tlačítko je odkázán do aktivity s detailními informacemi o daném místě. Pro místa uvnitř budovy je zde možnost zobrazit plán budovy s umístěním hledaného místa. Pro všechna místa je pak poskytována možnost zobrazit hledané místo na mapě. Třetí větev se jeví v diagramu jako nejsložitější. Jde o větev obsluhující upomínky. Na úvod je zobrazen seznam všech uložených upomínek. V ActionBaru (horní liště aplikace) se nachází možnosti k přidání nové upomínky a vypnutí všech sledovaných upomínek. Při kliknutí na libovolnou upomínku dojde k otevření aktivity, která slouží pro její editaci. Při delším stisknutí upomínky potom dojde k otevření kontextového menu, jež umožní uživateli upomínku smazat, zobrazit k ní přidružené místo na mapě nebo zapnout její sledování. Čtvrtá větev slouží k editování rozvrhu. Jako první se uživateli zobrazí aktuální rozvrh. Při kliknutí na libovolný termín v rozvrhu dojde k otevření aktivity s jeho editací, při delším stisku dojde k vymazání termínu. Poslední větev je ze všech nejjednodušší a slouží pouze k zobrazování nápovědy aplikace.

32 32 Implementace aplikace Aktivity Jelikož jsou aplikace většinou složitější, je jejich struktura tvořena z několika volně vázaných komponent. K sestavení aplikace lze využít velké množství komponent, mezi něž patří například aktivity či služby. Aktivity tvoří základní prezentační strukturu aplikace. Každá aktivita potom reprezentuje jednu obrazovku aplikace a má přiřazenou nějakou činnost. Některé aktivity jen zobrazují data, jiné obsahují prvky pro výběr, možností je spousta. Tyto prvky musí být nějakým způsobem propojeny a musí mezi nimi být zajištěna navigace. (Ujbányai, 2012) Obr. 6 Struktura aktivit aplikace V první vrstvě (modré) jsou tzv. top level aktivity. Tyto aktivity tvoří základní rozhraní aplikace. Druhá vrstva (zelená) jsou aktivity tvořící tzv. detail level. Jde o aktivity reprezentující konec procedury, provádějící nějaký požadavek uživatele a slouží k zobrazení dat či vykonání nějaké jiné akce. Mezi těmito dvěma vrstvami bývá často ještě tzv. vrstva category, která tvoří mezistupeň mezi výše jmenovanými. Tato vrstva je typická pro aplikace, jako je fotoalbum, apod. Ve svojí aplikaci tuto vrstvu nevyužívám. V poslední (červené) vrstvě mám aktivitu Zobrazení na mapě, která je hodně vytížená a pro moji aplikaci je velice důležitá. Do této aktivity se vstupuje hned z několika míst a většinou slouží pro zobrazení na mapě nebo načtení dat z mapy Volba navigace na nejvyšší úrovni Velice důležitým elementem aplikace pro Android je způsob, jakým bude probíhat navigace mezi aktivitami na nejvyšší úrovni. V mojí aplikaci jde o 5 aktivit, jmenovitě Mapa areálu, Hledat místo, Upomínky, Rozvrh a Nápověda. Jako první uvedu možnosti, které OS Android nabízí.

33 Implementace aplikace 33 První možností je navigace typu Six-pack. Jde o 6 položek, nejčastěji reprezentovaných obrázky, tlačítky, popisky, apod., které jsou řazeny po dvojicích pod sebou. Tento systém navigace je přímočarý a jednoduchý, avšak není moc zajímavý na pohled. Na obrazovce nejsou žádná data a tak je potřeba vynaložit zvýšené úsilí, abychom se k nějakým datům dostali (kliknutí navíc). (Android Developer, 2014) Další typ se nazývá Fixed tabs. Oproti předchozímu typu jsou data ihned viditelná a navigace probíhá pomocí 3 tlačítek ležících ihned pod Action Barem. To jsou však výhody a zároveň i nevýhody. Omezením je, že je navigace určena pro pohyb maximálně mezi třemi aktivitami a taky to, že navigační panel nemizí, ale zůstává tam během celého běhu aplikace, čímž zabírá místo a zmenšuje použitelnou výšku okna. (Android Developer, 2014) Třetí možností je navigace Spinners, která eliminuje nevýhody předchozího přístupu. Jde o tzv. spinner neboli vysouvací nabídku. Za prvé, tato navigace je kompaktní, jelikož je umístěna přímo v Action Baru a nezabírá tak zbytečně moc místa. Za druhé, není omezena na nabídku pouze ze tří možností. Nevýhodou této navigace je však to, že není dostupná z nižších úrovní aplikace. (Android Developer, 2014) Čtvrtou a poslední možností, jak zabezpečit navigaci mezi aktivitami na nejvyšší úrovni aplikace je Navigation drawer. Jde o nejnovější způsob navigace a jeho využití má spoustu výhod. Může zobrazovat velké množství položek, v zavřeném stavu je velice kompaktní a navíc může být dostupný odkudkoliv, tedy i z nižších vrstev aplikace. Odkazy na aktivity na nižších úrovních mohou být umístěny i přímo v Navigation Draweru. Jeho nevýhodou je, že jakmile máte příliš položek, nemusí být vidět všechny naráz. (Android Developer, 2014)

34 34 Implementace aplikace Tab. 3 + přímočarý a jednoduchý + viditelné všechny toplevel aktivity Výhody a nevýhody jednotlivých způsobů navigace Six-pack Fixed tabs Spinners Nav Drawer + může zobrazit více položek + viditelné + při zavřeném stavu je všechny toplevel aktivity více položek +může zobrazit kompaktní + může odkazovat na + snadná + je kompaktní low-level aktivity navigace + je dostupná odkudkoliv - žádná data - zvýšené úsilí při navigaci - omezeno na 3 položky - zabírá místo na displeji - není přístupné z nižších úrovní - top-level aktivity nejsou viditelné naráz - není dostupný z nižších úrovní - při větším množství položek nemusí jít vidět všechny top-level aktivity Tabulka rekapituluje výhody a nevýhody jednotlivých způsobů navigace. Pro moji aplikaci jsem vybral Navigation Drawer. Implementace této navigace je sice náročnější, ale výsledná aplikace působí moderněji a uživatelsky přívětivěji. Navigation Drawer je tedy panel, který zobrazuje hlavní nabídku aplikace. Nabídka je většinu času schovaná v levé hraně displeje. Aktivována může být přetažením z levé hrany displeje směrem ke středu nebo kliknutím na ikonu v Action Baru. Implementace Navigation Draweru se skládá z několika kroků. Jako první je nutné vytvořit XML soubor s rozvržením. V mém případě vypadá následovně. <android.support.v4.widget.drawerlayout xmlns:android=" android:id="@+id/drawer_layout" android:layout_width="match_parent" android:layout_height="match_parent"> <FrameLayout android:id="@+id/frame_container" android:layout_width="match_parent" android:layout_height="match_parent" /> <ListView android:id="@+id/list_slidermenu" android:layout_width="240dp" android:layout_height="match_parent" android:layout_gravity="start" android:choicemode="singlechoice" android:divider="@color/list_divider" android:dividerheight="1dp"

35 Implementace aplikace 35 </android.support.v4.widget.drawerlayout> Kromě kořenového elementu DrawerLayout jsou v souboru 2 vnořené elementy. První z nich je FrameLayout. Tento prvek je dynamicky za běhu aplikace plněn různými fragmenty, a proto je důležité, aby měl definované id a vývojář se tak na něj mohl odkazovat. Fragmenty tvoří pouze určitou část dané aktivity, ve které jsou vloženy a je možné je za běhu aktivity měnit, čímž vzniká dynamičtější uživatelské rozhraní. Druhý prvek je ListView, který reprezentuje samotné boční menu. U tohoto prvku se určují atributy jako způsob výběru položek, pozadí vybrané položky a mnoho dalších. Aby byl Navigation Drawer naplněn hodnotami a aby byla při stisknutí jeho položek vykonána nějaká činnost, je také nutné dopsat implementační soubor. Ten můj vypadá přibližně protected void oncreate(bundle savedinstancestate) { super.oncreate(savedinstancestate); setcontentview(r.layout.activity_main); navmenutitles = getresources().getstringarray(r.array.nav_drawer_items); navmenuicons = getresources().obtaintypedarray(r.array.nav_drawer_icons); mdrawerlayout = (DrawerLayout) findviewbyid(r.id.drawer_layout); mdrawerlist = (ListView) findviewbyid(r.id.list_slidermenu); navdraweritems = new ArrayList<NavDrawerItem>(); navdraweritems.add(new NavDrawerItem(navMenuTitles[0], navmenuicons.getresourceid(0, -1))); navmenuicons.recycle(); mdrawerlist.setonitemclicklistener(new SlideMenuClickListener()); adapter = new NavDrawerListAdapter(getApplicationContext(), navdraweritems); mdrawerlist.setadapter(adapter); } if (savedinstancestate == null) { displayview(0); } Nyní tento kus kódu postupně rozeberu. Na prvních dvou řádcích se provádí inicializace aktivity a přiřazení souboru s rozvržením, který byl popsán výše. Následně jsou do proměnných navmenutitles a navmenuicons nahrány popisky a ikony jednotlivých položek v menu. Další dva řádky se starají o přiřazení ele-

36 36 Implementace aplikace mentů, nadefinovaných v XML souboru do proměnných definovaných v jazyce Java. Následně se vytvoří instance pole navdraweritems, který se skládá z navdraweritem (mnou definovaná třída, pro položku menu) a v dalším kroku se přidávají do navdraweritems položky. Zde v ukázce je pro ilustraci přidána pouze jedna položka. Jako parametry jsou vždy ikona a popisek, jež byly předtím nahrány. Následující krok, volání metody recycle() není nezbytné, nutné je pouze v případech, kdy chceme recyklovanou proměnnou znovu používat. Další řádek nastavuje pro Navigation Drawer posluchač, jež se bude starat o reakce na výběr z menu. Kód na dalším řádku se stará o přiřazení položek menu do adaptéru, který je na dalším řádku přiřazen do DrawerListu. Kromě zde popsaného, používám ve svém kódu ještě ActionBarDrawer- Toggle, jež se stará o změny vzhledu ActionBaru při změně stavu Navigation Draweru. Aby bylo možné na tyto změny reagovat, je samozřejmě nutné nastavit posluchač pro Navigation Drawer, pomocí metody setdrawerlistener(). Obr. 7 Vzhled použité navigace (Navigation Drawer) 5.2 Databáze SQLite SQLite je relativně malá knihovna, poskytující vývojáři relační databázový postavenou na jazyku SQL. Na rozdíl od většiny ostatních SQL databází, SQLite nepracuje na principu klient-server, což přináší její velice snadné nasazení

37 Implementace aplikace 37 v aplikacích. Jeho nespornou výhodou při nasazení na mobilní zařízení je i to, že je poměrně rychlý a zároveň velice šetrný k paměti zařízení. Vývojáři poskytují tuto databázi zdarma jak k osobnímu, tak ke komerčnímu využití. Při prvním využívání této knihovny, nejsou vývojáři nabídnuty žádné předdefinované databáze a tak je pouze na něm, jaké databáze a tabulky vytvoří. (SQLite, 2014) Během tvorby této práce jsem se teprve začínal učit vyvíjet aplikace pro OS Android, což bylo příčinou častých chyb v kódu aplikace. Jedna z nich byla například při tvorbě databáze. Ve svojí práci potřebuji ukládat 2 typy objektů. První jsou upomínky, které mají atributy jako název upomínky, tělo upomínky, zeměpisnou šířku a délku a další hodnoty. Druhým typem jsou místa, o kterých se může uživatel aplikace dozvědět nějaké informace a hledat je. S upomínkami je možné různé manipulovat, vytvářet nové, mazat je či editovat. Tato možnost u databáze míst není. Do databáze míst se data nahrají pouze jednou při prvním spuštění aplikace a od té doby z nich lze pouze číst. Chybou, kterou jsem zmiňoval výše je to, že jsem v aplikaci vytvořil 2 databáze, i když by postačilo vytvořit pouze jednu a v ní 2 tabulky. Na běh aplikace to nemá žádný razantní dopad, dojde však k nárůstu jejich kapacitních nároků. Jelikož jsem si tento svůj omyl uvědomil až příliš pozdě, rozhodl jsem se ho raději neřešit, než riskovat velkou ztrátu času. K vytvoření vlastní databáze bylo potřeba provést několik kroků. Jako první bylo potřeba vytvořit podtřídu třídy SQLiteOpenHelper, jež zajišťuje veškerou logiku pro vytvoření a aktualizaci databáze. Jakmile je třída vytvořena, je třeba vytvořit její konstruktor a přepsat několik základních metod. Konstruktor potomka musí být zřetězený s konstruktorem třídy SQLiteOpenHelper. Jeho základní funkcí je tvorba databáze. (SQLite, 2014) DatabaseHelper(Context context) { super(context, DATABASE_NAME, null, DATABASE_VERSION); } Druhou metodou je oncreate(), která slouží k vytvoření tabulek v databázi a zároveň může sloužit i pro naplnění tabulek daty. Jako parametr metody jsem použil konstantu DATABASE_CREATE, ve které je definován SQL kód pro vytvoření nové public void oncreate(sqlitedatabase db) { db.execsql(database_create); } Další metodou je onupgrade(). Ta se využívá při změně struktury tabulek, resp. celé databáze.

38 38 Implementace public void onupgrade(sqlitedatabase db, int oldversion, int newversion) { Log.w(TAG,"Upgrade databáze z verze " + oldversion + "na verzi " + newversion + ". Stará data byla odstraněna."); db.execsql("drop TABLE IF EXISTS notes"); oncreate(db); } Jakmile je vytvořená základní funkcionalita databáze, je třeba ji naplnit daty. Databáze může být naplněna již v metodě oncreate() nebo může její plnění probíhat až za běhu aplikace. Ve svojí práci jsem využil oba z těchto způsobů. Pro vkládání dat za běhu aplikace jsem si vytvořil metodu createnote(), která přebírá jako parametry informace o upomínce a vrací ID upomínky. ID se vrací na posledním řádku metody, kde dojde k zavolání metody insert() na instanci databáze (proměnná mdb). Tato metoda přebírá jako parametry jméno tabulky databáze (DATABASE_TABLE) a hodnoty uložené v předchozím kroku do proměnné typu ContentValues. public long createnote(string title, ){ ContentValues initialvalues = new ContentValues(); initialvalues.put(key_title, title); return mdb.insert(database_table, null, initialvalues); } Pro vracení hodnot jsem vytvořil hned několik metod. Některé vraceli pouze jednu položku podle id, jiné vraceli položky všechny. public Cursor fetchnote(long rowid) throws SQLException { Cursor mcursor = mdb.query(true, DATABASE_TABLE, new String[] {KEY_ROWID, KEY_TITLE, }, KEY_ROWID + "=" + rowid, null, null, null, null, null); if (mcursor!= null) { mcursor.movetofirst(); } return mcursor; } Záznamy databáze jsou vraceny v podobě Cursoru. Jde o seznam řádků, jež jsou výsledkem daného dotazu. Třída Cursor disponuje několika metodami, které umožňují manipulaci s vrácenými hodnotami. V následujícím kódu je vidět metoda, která naplní adaptér daty z databáze. Adaptér je následně použit v ListView, který zobrazuje uložené upomínky.

39 Implementace aplikace 39 private void filldata() { Cursor notescursor = mdbhelper.fetchallnotes(); getactivity().startmanagingcursor(notescursor); String[] from = new String[]{NotesDbAdapter.KEY_TITLE, Note sdbadapter.key_body,notesdbadapter.key_place, NotesDbAdap ter.key_validity}; int[] to = new int[]{r.id.nazev, R.id.text, R.id.misto, R.id.platnost}; SimpleCursorAdapter dataadapter = new SimpleCursorAdapter(getActivity(), R.layout.notes_row, notescursor, from, to, 0); } setlistadapter(dataadapter); Jako první se zavolá metoda fetchallnotes(), která vrátí všechny položky databáze a tyto záznamy jsou uloženy do proměnné typu Cursor. Následně se zavolá metoda startmanagingcursor, která umožní s těmito záznamy pracovat. V dalším kroku se do pole typu String uloží jména sloupců databáze (jde o ty data, která se v předchozím kroku uložila do proměnné notescursor, sloupce mají ale stejné názvy, jako v databázi), ze kterých se mají data načítat. Jako další se tentokrát do pole celočíselných hodnot uloží ID elementů (definované v XML souboru) uživatelského rozhraní, do kterých se mají hodnoty uložit (hodnoty v obou polích musejí být ve shodném pořadí). Následně už zbývá pouze vytvořit proměnnou typu SimpleCursorAdapter, které se v jejím konstruktoru předá aktuální kontext, návrh řádku adaptéru (soubor s návrhem typu XML) a 2 pole, jedno se zdrojovými indexy a druhé s indexy cílovými. Poté už zbývá pouze pomocí metody setlistadapter přiřadit výše navržený adapter do ListView. 5.3 Google Maps API v2 Google Maps API umožňuje přidávat do aplikace mapy, založené na Google Maps. Toto API obstarává přístup na servery Google Maps, stahuje potřebná data, zobrazuje mapy a reaguje na gesta nad nimi. Kromě toho umožňuje vývojáři přidávat na mapu ukazatele (markery), vykreslovat polygony či překrývat mapu vlastním obrázkem. Veškerou funkcionalitu lze nalézt na stránkách Před vytvořením Android aplikace, která bude využívat Google Maps Android API v2 je třeba provést několik kroků. 1. Jako první je samozřejmě nutné mít nainstalovaný Android SDK, jako je Eclipse nebo Android Studio. 2. Následně je nutné stáhnout a nastavit Google Play services SDK, jehož součástí je Google Maps Android API.

40 40 Implementace aplikace 3. Jako další je potřeba získat API key. Abyste ho získali, je nutné registrovat váš projekt v Google APIs Console ( 4. V dalším kroku je nutné provést požadované nastavení v Android Manifestu vaší aplikace, což zahrnuje např. přidání klíče vygenerovaného v předchozím kroku. 5. Nakonec už jen zbývá, přidat mapu do aplikace. Využití Google Maps API patří ke stěžejním bodům mojí aplikace. Toto API využívám ke spoustě úkonů, jako např. pro zobrazování mapy v úvodní aktivitě Mapa areálu. Tam je využito zobrazení mapových podkladů, na které je pomocí Ground Overlay přidána nakreslená mapa areálu školy. Dále je zde využito tzv. Markerů neboli ukazatelů na konkrétní místa na mapě. Další využití nalezlo toto API v aktivitě Zobrazení na mapě, do které se vstupuje hned ze tří různých míst. První možností jak vstoupit je z aktivity Detail budovy. V takovém případě se na mapě zobrazí Marker, vykreslí se čára (Polyline) od pozice zařízení k tomuto místu a pomocí Toast zprávy (zpráva ve formě malé, časově omezené bubliny, zobrazené ve spodní části displeje). Pokud do této aktivity uživatel vstoupí z aktivity Upravit upomínku za účelem určit nějakou vlastní polohu pro upomínku, není na mapě zobrazeno nic. Jakmile však na libovolné pozici provede dlouhý stisk, uloží se tato pozice a přiřadí se k upomínce. Poslední možnost jak vstoupit do této aktivity je přímo z aktivity Upomínky. Zde má uživatel možnost zobrazit na mapě místo, přiřazené k dané upomínce. Toto místo je na mapě vyznačeno pomocí barevného kruhu.

41 Implementace aplikace 41 Obr. 8 Využití Google Maps API v2 v aktivitě Mapa areálu 5.4 Server Indica a AsyncTask Server Indica je experimentální mapový server, o který se stará Ústav informatiky. Server slouží pro podporu výuky v předmětech Oddělení grafiky a GIT. (PEF-ÚI, 2009) Server Indica jsem použil ve svojí práci k zobrazování plánů podlaží v budově Q. Na stránce projektu (indica.mendelu.cz) se pomocí dodaných parametrů vygeneruje URL obrázku, na kterém je dle zadaných parametrů vyznačena místnost. U některých objektů nebylo možné využít pouze obrázek s vyznačenou místností (konkrétní body v místnosti) a tak bylo nutné tyto obrázky stáhnout a ručně do nich dokreslit konkrétní bod. Takovéto obrázky jsou pak uloženy přímo v aplikaci a je na ně odkazováno.

42 42 Implementace aplikace Obr. 9 Aktivita Detail místa, využívající serveru Indica V ostatních případech se však využití serveru Indica velice hodí. K načtení obrázků ze serveru Indica využívám třídy AsyncTask. Výhodou této třídy je, že zpracovává požadavek na pozadí a teprve když je dokončen, zobrazí jej. Aplikace si vždy jako první ověří, zdali je zařízení připojeno k Internetu. Jestliže tomu tak je, získá se z databáze URL pro daný objekt. Následně je zavolána instance třídy DownloadImageTask, která je potomkem třídy AsyncTask. Té se předá ImageView, ve kterém má být obrázek zobrazen a zavolá se metoda execute(), které se předá jako parametr URL získaná z databáze. V potomkovi třídy AsyncTask musí být vždy přepsána alespoň metoda doinbackground() a ve většině případů je implementována i metoda onpostexecute(). První z metod se používá pro provedení výpočtů na pozadí, které mohou trvat delší čas. Kromě těchto dvou metod je možné implementovat ještě metody onpreexecute() a onprogressupdate(). Ve většině případů si však vývojář vystačí pouze s prvními dvěma.

43 Implementace aplikace 43 protected Bitmap doinbackground(string... urls) { String urldisplay = urls[0]; Bitmap micon11 = null; try { InputStream in = new java.net.url(urldisplay).openstream(); micon11 = BitmapFactory.decodeStream(in); } catch (Exception e) { Log.e("Error", e.getmessage()); e.printstacktrace(); } return micon11; } Jakmile je výpočet na pozadí dokončen, je zavolána metoda onpostexecute(). Ta v moji aplikaci obstarává zobrazování staženého obrázku. protected void onpostexecute(bitmap result) { bmimage.setimagebitmap(result); } 5.5 Implementace sledování geofencí Sledování geofencí tvoří významnou část mojí aplikace. Na následujících řádcích se proto pokusím vysvětlit využití této funkce v mojí aplikaci a následně i část implementace této problematiky. Jednoduše řečeno, vezme se nějaká oblast (definovaná zeměpisnou šířkou, délkou a poloměrem), k té se přidá informace o tom, jestli chceme sledovat vstup nebo výstup z této oblasti a nakonec přidáme dobu trvanlivosti tohoto sledování. Všechny tyto informace se uloží do proměnné typu Geofence a ta se následně uloží do objektu LocationClient. Potom už probíhá sledování definované geofence. Jakmile zařízení do definované oblasti vstoupí nebo z ní vystoupí (záleží na nastavení), je přijat Intent (zpráva zaslaná LocationClientem) a uživateli se zobrazí notifikace. Celý tento proces je ve skutečnosti o dost složitější. Než tato funkce začne fungovat zcela správně, musí se provést spousta kroků. Ke sledování geofencí se využivá Location Services, jež jsou součástí Google Play Services, tudíž předtím, než začnu pracovat s Location Services, je třeba si ověřit, zdali je Google Play Services dostupné. Za tímto účelem je v aplikaci definována metoda, která vrací logický typ boolean. Na pozadí aktivity Nastavit sledování, ze které se sledování geofencí spouští, je prováděna řada operací. Při spuštění této aktivity jsou vytvořeny instance tříd GeofenceRequester a GeofenceRemover, které implementují přidávání a odebírání geofencí z Location Clienta. Dále potom třídy GeofenceSampleReceiver, potomka třídy BroadcastReceiver a taky třídy IntentFilter. Důležité je rovněž vytvořit si pole pro datový typ Geofence, kam postupně přidávám geofence, které chci sledovat.

44 44 Implementace aplikace Jakmile jsou vytvořeny instance těchto důležitých tříd, je třeba přidat akce a kategorie do IntentFilteru. mintentfilter.addaction(geofenceutils.action_geofence_error); mintentfilter.addcategory(geofenceutils.category_location_services); Ještě předtím, než pošleme geofence ke sledování, přidáme si je do proměnné typu List<>, uchovávající datové typy Geofence. K přidávání slouží metoda.add(). Jakmile máme v poli všechny geofence, zavoláme metodu.addgeofence, pro instanci třídy GeofenceRequester. mcurrentgeofences.add(muigeofence.togeofence()); mgeofencerequester.addgeofences(mcurrentgeofences); Po tomto kroku se na pozadí spustí série několika úkonů. Ve třídě GeofenceRequester se tedy zavolá metoda addgeofences(), která ověří, zdali se ve stejnou chvíli nepřidávají jiné geofence. Pokud ne, zavolá se metoda getlocationclient(), která vrátí objekt LocationClient. Tato třída obstarává hlavní funkcionalitu týkající se sledování geofencí. Jakmile máme instanci této třídy, zavolá se nad ní metoda connect(), která vytvoří PendingIntent a taky zavolá nad LocationClientem metodu addgeofences, jíž se dodá právě PendingIntent a pole s geofencemi. Tato metoda se postará o přidání geofencí do LocationClienta. Výše jsem napsal, že při otevření aktivity Nastavit sledování, se vytvoří instance třídy GeofenceSampleReceiver. Právě tato třída potom slouží ke sledování záměrů (Intentů) zaslaných z LocationClienta. Ten je zasílán v situaci, kdy uživatel vstoupí nebo odejde ze sledované oblasti. Implementace této třídy je v souboru ReceiveTransitionsIntentService.java. 5.6 Zobrazování notifikací Notifikace je zpráva, kterou je možné zobrazit mimo uživatelské rozhraní aplikace. Jako první je zobrazena pouze ikona notifikace, která se přidá do zásobníku v notifikační oblasti. Aby bylo možné se podívat na detaily notifikace, je třeba otevřít notification drawer (menu výsuvné z horní hrany displeje). Jakmile se tak stane, má většina notifikací možnost na mě kliknout, čímž se uživatel přenese nejčastěji do aplikace samotné. (Android Developer, 2014) private void sendnotification(string transitiontype,string ids){ Intent notificationintent = new Intent(getApplicationContext(), MainActivity.class); TaskStackBuilder stackbuilder = TaskStackBuilder.create(this); stackbuilder.addparentstack(mainactivity.class); stackbuilder.addnextintent(notificationintent);

45 Implementace aplikace 45 PendingIntent notificationpendingintent = stackbuilder.getpendingintent(0, PendingIntent.FLAG_UPDATE_CURRENT); NotificationCompat.Builder builder = new NotificationCompat.Builder(this); builder.setsmallicon(r.drawable.ic_launcher).setcontenttitle(transitiontype + titl).setcontenttext(getstring(r.string.geofence_transition_noti fication_text)).setcontentintent(notificationpendingintent).setsound(ringtonemanager.getdefaulturi(ringtonemanager.typ E_NOTIFICATION)).setVibrate(new long[] { 200, 500, 200, 500, 200, 200, 200, 200, 200, 200 }).setlights(color.blue, 3000, 10000); NotificationManager mnotificationmanager = (NotificationManager) getsystemservice(context.notification_service); } Integer ide = Integer.parseInt(ids); mnotificationmanager.notify(ide, builder.build()); Ve svojí aplikaci využívám notifikací v případě, že uživatel vstoupí nebo opustí sledovanou oblast. Jamile se tak stane, uživatel je upozorněn vyzváněním s vibrací, případně blikáním diody a hlavně přidáním notifikace do zásobníku. V Notification Draweru se zobrazí ikona aplikace a popis, jež je tvořen popisem vykonané činnosti (uživatel vstoupil do nebo uživatel opustil) a názvem uložené upomínky. Notifikace jsou nadefinovány tak, aby se notifikace stejné upomínky překrývaly, pokud ale půjde o jiné upomínky, budou se přidávat notifikace nové. V praxi to znamená, že pokud má uživatel jednu upomínku, do které první vstoupí a následně z ní odejde, bude mít v zásobníku pouze jednu notifikaci, která ho bude upozorňovat, že oblast opustil.

46 46 Implementace aplikace Obr. 10 Upozornění na vstup do sledované oblasti pomocí notifikace