Mobilní aplikace Průvodce po MENDELU

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

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.

Č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: 5. 1. 2015

……………………………………. podpis

Abstract CHARVÁT, Ondřej. Mobile app “MENDELU Guide”. Bachelor thesis. Brno: Mendel University, 2015. 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ě, 2015. 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

Obsah

Obsah 1

2

3

4

5

6

Úvod a cíl práce

8

1.1

Úvod .......................................................................................................... 8

1.2

Cíl práce .....................................................................................................9

Usnadnění orientace v areálu školy

10

2.1

Možnosti navigace ................................................................................... 10

2.2

Volba možnosti navigace ......................................................................... 12

2.3

Volba platformy ....................................................................................... 14

Operační systém Android

16

3.1

Historie OS .............................................................................................. 16

3.2

Verze operačního systému ....................................................................... 16

3.3

Architektura OS ....................................................................................... 17

3.4

Životní cykly............................................................................................. 18

3.5

Vývojové prostředí Eclipse ...................................................................... 19

Návrh aplikace

20

4.1

Průzkum trhu.......................................................................................... 20

4.2

Požadavky na aplikaci .............................................................................24

4.3

Uživatelské rozhraní ................................................................................26

Implementace aplikace

30

5.1

Struktura aplikace .................................................................................. 30

5.2

Databáze SQLite ......................................................................................36

5.3

Google Maps API v2 ................................................................................39

5.4

Server Indica a AsyncTask ...................................................................... 41

5.5

Implementace sledování geofencí ...........................................................43

5.6

Zobrazování notifikací ............................................................................ 44

Marketing a distribuce

47

6.1

Marketing mobilní aplikace .................................................................... 47

6.2

Zhodnocení aplikace ............................................................................... 48

Obsah

7

6.3

Distribuce aplikace ................................................................................. 49

7

Diskuze

52

7.1

Ekonomické zhodnocení aplikace .......................................................... 52

7.2

Technické zhodnocení aplikace .............................................................. 53

7.3

Využití aplikace na jiné univerzitě .......................................................... 54

7.4

Zhodnocení vývoje .................................................................................. 54

8

Závěr

55

9

Literatura

56

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.

Úvod a cíl práce

9

1.2 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


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 m2, 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. 2.1.1

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

využívá, například ve formě vizitek nebo jako cedule s otevírací dobou kanceláře, umístěná vedle dveří. 2.1.2

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á. 2.1.3

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


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

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.

+ kreativita

+ velké množství informací + možnost volby + snadné vyhledávání

- neměnnost informací

- nepřenositelnost

Mobilní aplikace + přenositelnost + velké množství informací + lokace aktuální polohy + přiměřeně snadné vyhledávání - 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


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%

Android

50,00%

iOS

40,00%

Windows Phone

30,00% 20,00% 10,00% 0,00% 2013 prosinec

2014 březen

2014 červen

2014 září

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 (http://gs.statcounter.com/). 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

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


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 2007. 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

aplikace vyvíjena. Verzi API uchovává element <uses-sdk> v souboru AndroidManifest.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, 2012

3.3.1

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) 3.3.2

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


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) 3.3.3

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) 3.3.4

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

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 2014. 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

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.

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. 4.1.1

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: https://play.google.com/store/apps/details?id=com.MarekMusil.MendeluQ 4.1.2

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: https://play.google.com/store/apps/details?id=be.ac.ucl.lfsab1509.llncampus 4.1.3

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

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: https://play.google.com/store/apps/details?id=com.monashuniversity.monash university 4.1.4

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 (http://transloc.com/), 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: https://play.google.com/store/apps/details?id=edu.ncsu.oncampus

Návrh aplikace

4.1.5

23

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: https://play.google.com/store/apps/details?id=com.jaguart.campusmaps 4.1.6

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ší

LLN Campus Monash U On Campus Razorbacks

Uživatelské Funkcionalita prostředí 1 2 3 3 3 3 2 1

Zobrazení mapy 1 3 1 1

Hledání míst 2 2 2 2

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

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. 4.2.1

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.

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. 4.2.2

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. 4.2.3

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

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) 4.2.4

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. 4.3.1

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ě“,

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) 4.3.2

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

Obr. 3

Návrh aplikace

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. 4.3.3

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)

Návrh aplikace

Obr. 4

29

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 http://www.freepik.com/. 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


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) 5.1.1

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. 2. 3.

Uživatel otevře aplikaci. Uživatel vybere z menu možnost Hledat místo. 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.


Obr. 5

31

Grafická reprezentace možných případů užití aplikace

Tento obrázek jsem vytvořil pomocí online editoru na stránkách https://www.draw.io/. 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

5.1.2


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. 5.1.3

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

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


Tab. 3

Výhody a nevýhody jednotlivých způsobů navigace

Six-pack

Fixed tabs

Spinners

+ přímočarý a jednoduchý + viditelné všechny toplevel aktivity

+ viditelné všechny toplevel aktivity + snadná navigace

+může zobrazit více položek + je kompaktní

- žá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í

Nav Drawer + může zobrazit více položek + při zavřeném stavu je kompaktní + může odkazovat na low-level aktivity + je dostupná odkudkoliv - 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ě.

35

android:listSelector="@drawable/list_selector" android:background="@color/list_background"/>

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ě následovně. @Override 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(); 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


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ě ActionBarDrawerToggle, 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

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é tabulky. @Override 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


@Override 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

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 https://developers.google.com/maps/documentation/android/. 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. 2.

Jako první je samozřejmě nutné mít nainstalovaný Android SDK, jako je Eclipse nebo Android Studio. Následně je nutné stáhnout a nastavit Google Play services SDK, jehož součástí je Google Maps Android API.

40

3.


Jako další je potřeba získat API key. Abyste ho získali, je nutné registrovat váš projekt v Google APIs Console (https://code.google.com/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.


Obr. 8

41

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

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

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


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

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

Obr. 10


Upozornění na vstup do sledované oblasti pomocí notifikace


47

6 Marketing a distribuce Jakmile skončí vývoj aplikace, je na čase se začít zabývat tím, co s ní bude nyní. Některé aplikace mohou být samozřejmě tvořeny pouze pro osobní účely, většina z nich je však tvořena s nadějí, že budou mít uživatelů co nejvíce.

6.1 Marketing mobilní aplikace Předtím, než začne samotná marketingová činnost, je důležité si odpovědět na několik otázek. Správně odpovědět na tyto otázky je stejně důležité jako mít jasně definované požadavky na aplikaci. Pokud tomu tak není, může dojít ke špatnému cílení marketingových aktivit a počet uživatelů aplikace pak neporoste takovým tempem, jakým by mohl. Je důležité si ujasnit, jaký problém vlastně aplikace řeší. Moje aplikace slouží především k usnadnění orientace v areálu Mendelovy univerzity v Brně, uživatelům chytrých telefonů s OS Android. Tím je částečně stanovena i cílová skupina mojí aplikace, je však potřeba ji zacílit konkrétněji. Mělo by jít tedy především o budoucí studenty a studentky Mendelovy univerzity, ve věku 17-20 let, vlastnící a využívající chytrých mobilních telefonů s operačním systémem Android. Je rovněž důležité vědět, jestli někdo vytvářel podobnou aplikaci již přede mnou. V případě, že tomu tak je a naše aplikace není navíc nijak inovativní, může být tvorba nové aplikace zcela zbytečná. Průzkum trhu jsem prováděl již před samotným vývojem aplikace a došel jsem k závěru, že na trhu není žádný přímý konkurent mojí aplikace, tudíž má tato aplikace potenciál, najít si velké množství uživatelů. Velice důležité je rovněž vědět, pro jaká zařízení je aplikace vyvíjena. Aplikace je určena pro chytré mobilní telefony s operačním systémem Android ve verzi minimálně 4.0, pojmenované Ice Cream Sandwich. Telefony musejí rovněž podporovat OpenGL alespoň verze 2.0. (Rollins, 2011) Jakmile jsou tyto otázky zodpovězeny, už vím, co vlastně propaguji a komu to propaguji. Zbývá ještě vymyslet, jakým způsobem to budu propagovat. 6.1.1

Používané způsoby propagace mobilní aplikace

Jelikož není aplikace určena pro širokou veřejnost, není třeba se soustředit na co největší pokrytí marketingových prostředků. Místo toho bude stačit, zaměřit se pouze na již popsanou skupinu lidí, tedy budoucí studenty Mendelovy univerzity v Brně. Velice často využívanou technikou k prvotní propagaci aplikace je PR, neboli vztahy s veřejností. Jde především o to, získat kladné ohlasy na propagovanou aplikaci, nejlépe ze strany odborníků. Za tímto účelem se oslovují různá odborná tištěná periodika nebo internetové portály zabývající se touto tématikou. Jejich výstupy (recenze a jiné články) mohou potom působit na potenciální uživatele propagované aplikace, kteří si ji mohou na základě kladných ohlasů stáhnout a začít využívat. Zde samozřejmě platí, že čím více, tím lépe. (Rollins, 2011)

48


Jako další velice účinný kanál pro rozšíření povědomí o aplikaci mohou posloužit sociální sítě. Nestačí samozřejmě pouze založit profil a očekávat, že se uživatelé dostaví sami. Je třeba o stránky pečovat a neustále vymýšlet zajímavý obsah. Jako dobrá virální reklama může posloužit také možnost sdílet různé stavy aplikace (úspěchy) pomocí těchto sociálních sítí. (Rollins, 2011) Dalším často užívaným marketingovým nástrojem je placená reklama. Tomuto způsobu propagace se však pokusím ve svojí práci vyhnout a budu se snažit využít spíše nízkonákladových prostředků. Mezi další způsoby, jak dostat více informací mezi potenciální uživatele je například tvorba produktového webu, natočení propagačního videa nebo organizování soutěží. 6.1.2

Propagace mobilní aplikace Mendelu GUIDE

Jak již bylo opakovaně zmiňováno, tato aplikace bude sloužit pro usnadnění orientace v areálu Mendelovy univerzity. Jelikož nepředpokládám, že by uživatel začal na této škole studovat pouze kvůli mojí aplikaci, budu se při marketingové kampani soustředit hlavně na uživatele, kteří tento areál navštěvují nebo se ho navštívit chystají. V předchozí kapitole byly jako první zmiňovány oborné články a recenze. Tento způsob propagace se jistě hodí, pokud je aplikace cílena na širší spektrum uživatelů. V mém případě by však šlo využít například studentských novin. V takovémto periodiku by samozřejmě nešlo o odborný článek, ale spíše o představení aplikace čtenářům. Propagace na sociálních sítích je velice lákavá. Lidé tam o sobě poskytují spoustu osobních údajů a tak je zde možné velice dobře zacílit na správnou skupinu. Po domluvě se správci by bylo výhodné využít existujících facebookových skupin (skupina školy, skupiny jednotlivých fakult, atd.), které již sleduje velký počet uživatelů. Každý rok rovněž vznikají nové skupiny, které zakládají budoucí studenti prvních ročníků. Právě na takovéto skupiny by bylo vhodné se zaměřit. Každý rok jsou studentskou unii organizovány akce nazvané Prvákoviny, které mají za cíl seznámit budoucí studenty s chodem univerzity. Právě na takovýchto akcích by bylo vhodné aplikaci propagovat. Propagace by mohla probíhat buď formou mluveného slova od organizátorů akce, nebo letáky s odkazem na stažení aplikace. Letáky s informacemi o aplikaci by mohli být rovněž, po domluvě se studijním oddělením, poskytovány budoucím studentům univerzity během zápisu ke studiu. Propagace aplikace by rovněž mohla probíhat celoplošně po univerzitě, pomocí letáků nebo spotů na obrazovkách, umístěných po celé univerzitě.

6.2 Zhodnocení aplikace Jelikož je do vývoje mobilní aplikace vloženo velké úsilí, očekává od ní vývojář ve většině případů nějakou kompenzaci.


6.2.1

49

Jednorázová platba

První způsob je stanovit cenu na nákup aplikace. Jestliže chce uživatel aplikaci využívat, musí za ni zaplatit. Nevýhodou tohoto přístupu může být, že uživatel nemá šanci si produkt vyzkoušet, takže vlastně neví, jestli mu vyhovuje a jestli mu stojí za to do něj investovat. 6.2.2

Přístup k bonusovým funkcím

Moderním trendem je uvolnit uživatelům odlehčenou verzi aplikace, aby si ji mohl vyzkoušet, zjistit, jestli mu vyhovuje uživatelské prostředí, atd. Následně je uživateli předložena možnost získat ještě další bonusové funkce, které funkcionalitu aplikace dále zlepší. Za tyto funkce navíc si však uživatel musí již připlatit. Výhodou však je, že uživatel již zná prostředí aplikace a ví, jestli mu vyhovuje a stojí za to do ní investovat. 6.2.3

Prezentace reklamních sdělení

Dalším způsobem je prezentovat v aplikaci cizí reklamu. Tento způsob je zcela určitě nejméně oblíbený, minimálně mezi uživateli a i proto ho většinou nenajdete mezi těmi nejoblíbenějšími aplikacemi a hrami. Tento způsob spočívá v tom, že uživateli neustále vyskakují reklamní sdělení a plní mu okno aplikace. Takovéto reklamy dokážou být velice nepříjemné a jsou uživateli neoblíbené. Mohou však velice dobře pokrývat náklady vynaložené na vývoj aplikace. 6.2.4

Volně dostupné aplikace

Některé aplikace jsou uživatelům poskytovány v jejich plné verzi a bez jakýchkoliv poplatků. Ve většině případů jde o aplikace podporované nějakými firmami, apod., které hradí náklady na vývoj a údržbu aplikace. Tito sponzoři mají z těchto aplikací většinou nějaký užitek, který si běžný uživatel často ani neuvědomí.

6.3 Distribuce aplikace Už jsem nastínil, jakým způsobem je možné aplikaci zhodnotit a jakým způsobem bude vedena marketingová kampaň, zbývá však ještě určit způsob, jak budeme aplikace distribuovat mezi uživatele. Google podporuje několik způsobů distribuce aplikací. 6.3.1

Google Play

Google Play je hlavní distribuční kanál aplikací, her a jiného obsahu pro zařízení používající OS Android. Vývojáři sem své aplikace nahrají s nadějí, že si je uživatelé stáhnou a bude je využívat. K nahrávání aplikací na Google Play je potřeba běžný Google účet, který lze využít např. jako mailovou schránku, pro přihlášení na YouTube, atd.

50


Dále je potřeba si vytvořit účet pro vývojáře. K tomu je nutné souhlasit s licenční smlouvou, kterou lze nalézt na adrese https://play.google.com/intl/ALL_cz/about/developer-distributionagreement.html a zaplatit registrační poplatek ve výší 25$. Jakmile je vývojářský účet vytvořen, je možné začít nahrávat aplikace. Do vývojářské konzole je potřeba nahrát APK soubor aplikace a dodat několik důležitých informací o aplikaci, jako je její název, popis, atd. K informacím v textové podobě je rovněž možné přidat i screenshoty aplikace. Zbývá ještě nastavit cenu aplikace, tedy kolik musí uživatel zaplatit, aby si mohl aplikaci stáhnout. Poté již nic nebrání nahrání aplikace na Google Play (Google Play, 2014) 6.3.2

Alternativní způsoby distribuce

Kromě tohoto oficiálního kanálu je distribuce možná i jinými cestami. Může jít například o jiné obchody, umožňující aplikace sdílet. Důvodů k volbě alternativního obchodu s aplikacemi může být mnoho. Uživatel může chtít například využít výhodné cenové nabídky, lepšího filtrování aplikací podle různých kategorií nebo chce využít obchod, který se specializuje pouze na jeho zemi. S alternativními obchody mohou být však spojené i jisté problémy. Jakmile vývojář souhlasí s podmínkami používání obchodu, může být jeho aplikace použita třeba k nedobrovolné reklamě, atd. Mezi alternativní obchody s Android aplikacemi patří například http://slideme.org/ nebo https://f-droid.org/. Při hledání alternativních Android obchodů jsem narazil na zajímavý projekt s názvem Aptoide. Tento projekt vznikl rovněž jako obyčejný Android obchod, avšak později se z něj stalo něco víc. Vývojář si může na internetových stránkách (http://www.aptoide.com/) vytvořit svůj vlastní Android obchod, který může spravovat a přidávat na něj své aplikace. Dalším způsobem distribuce jsou například vývojářské weby, kde vývojáři poskytují své aplikace ostatním vývojářům, čímž získávají odbornou zpětnou vazbu, kterou by od běžných zákazníků nezískali. Další alternativou pro šíření aplikací je distribuce pomocí mailu. Jde o rychlou a jednoduchou cestou, jak dostat aplikaci k uživatelům. Je třeba jen připravit aplikaci na vydání, připojit soubor k mailu a poslat ho uživateli. Jakmile uživatel otevře email na nějakém zařízení využívající OS Android, systém rozpozná APK soubor a nabídne uživateli možnost aplikaci nainstalovat. Distribuovat přes email je vhodné pouze v případech, kdy chcete aplikaci rozšířit pouze mezi několik prověřených uživatelů. Aplikaci je totiž pomocí přeposlání emailu možné nekontrolovatelně distribuovat mezi další uživatele, což nemusí být vždy žádoucí. Jestliže chcete mít vaši aplikaci veřejně přístupnou, ale nechcete ji nahrávat do žádného obchodu, jako je Google Play, můžete ji poskytnout ke stažení na vašich vlastních webových stránkách. K tomu je potřeba připravit aplikaci na vydání, jako každým jiným způsobem. Následně je třeba nahrát APK soubor připravený k vydání a poskytnout uživatelům jeho adresu. Potom už jen stačí, když si uživatel soubor stáhne a zařízení mu samo nabídne instalaci aplikace.


51

Právě tímto způsobem bych chtěl svoji aplikaci distribuovat. Jde o velice jednoduchou cestu, jak dostat aplikaci k uživatelům. V předešlé kapitole jsem zmiňoval použité marketingové prostředky a právě pomoci nich, by bylo možné tento způsob distribuce využít. Nemuselo by jít přímo o URL adresu ke stažení. Pro tento účel jsou použitelné QR kódy, které nahrazují opisování dlouhých adres. Tyto kódy lze snadno vygenerovat např. na stránkách http://www.qrgenerator.cz/.

52

Diskuze

7 Diskuze 7.1

Ekonomické zhodnocení aplikace

V mém případě byly náklady na vývoj aplikace nulové, pokud bych však měl ocenit svůj čas, strávený sběrem informací, vývojem, testováním a dalšími činnostmi, souvisejícími s vývojem aplikace, byla by tato částka jistě vysoká. Velká časová náročnost vývoje byla zapříčiněna především mojí počáteční nezkušeností s vývojem aplikaci pro OS Android. Provedl jsem průzkum trhu, abych zjistil, kolik by aplikace stála, kdyby byla vyvíjena profesionálním vývojářským studiem. Většina studií na svých stránkách tyto informace neuvádí, jelikož cena je do velké míry závislá na velikosti projektu, využitých technologiích, atd. Na stránkách firmy Pixelmate (http://www.pixelmate.cz/) jsem však našel, že cena individuálního projektu se může pohybovat od 20 tis. Kč. Následně jsem nalezl ceník ještě na stránkách firmy CERNET (http://www.cernet.cz/). Tato firma měla na svých stránkách oceněny některé části vývoje aplikace. Jejich cena za návrh struktury aplikace byla od 59 tis. Kč. Jak už jsem psal, v mém případě byly náklady na vývoj aplikace nulové. Pokud bych ji však měl nabízet např. naší škole, s největší pravděpodobností bych finanční vyrovnání vyžadoval. Po průzkumu trhu jsem zjistil, že cena vývoje vlastní aplikace u profesionálního studia, se může pohybovat v řádech desítek, ale i stovek tisíc Kč. U některých složitých 3D her může být tato částka až milióny korun. Vzhledem ke složitosti mojí aplikace by byla její cena zhruba někde kolem sta tisíc Kč. Já bych svoji aplikaci univerzitě nabídl za částku 10 tis. Kč. Tím bych univerzitě ušetřil velkou část nákladů oproti profesionálním studiím. Moje nízká cena je opodstatněná především mojí nezkušeností (implementace kódu není jistě optimální) a taky tím, že jsem aplikaci vyvíjel pro svoji BP. V kapitole 6.1.2 Propagace mobilní aplikace MENDELU Guide jsem popsal způsob, jakým bych chtěl svoji aplikaci propagovat a distribuovat. Snažil jsem se využít pokud možno neplacené prostředky, ale ne vždy se to podařilo. Aplikace má zajímavou funkcionalitu a mohla by být ceněným pomocníkem při orientaci v areálu. Proto předpokládám, že by ji mohla některá periodika (např. studentské noviny) propagovat sama a napsala by o ní článek. Rovněž pro informování uživatelů pomocí sociálních sítí není potřeba nic platit, avšak pokud by měla aplikace vlastní stránku na facebooku nebo kdekoliv jinde, bylo by nejspíš potřeba najmout někoho, kdo by se o takovéto stránky staral. Pro další způsob, tedy propagování aplikace na univerzitních akcích pro budoucí studenty, by bylo s největší pravděpodobností potřeba vytisknout letáčky s informacemi o aplikaci a o tom jak ji stáhnout. Tento způsob by tedy vyžadoval určité finanční prostředky. Na stránkách firmy InetPrint (http://www.inetprint.cz/) jsem zjistil, že cena na vytištění 500 barevných jednostránkových letáků ve formátu A5 vychází zhruba na 2800 Kč (cena se samo-

Diskuze

53

zřejmě odvíjí od kvality papíru, barevnosti tisku a dalších atributů). Při objednání 3000 kusů by cena stoupla pouze na 3300 Kč, což je při růstu množství o 500% pouze 18% nárůst ceny. Bylo by rozhodně výhodné objednat větší množství letáků a následně požádat studijní oddělení, aby je rozdávali studentům při zápisu do prvních ročníků.

7.2 Technické zhodnocení aplikace Pokud bych měl na svojí aplikaci hodnotit stejné aspekty, jako na testovaných aplikacích v kapitole 4.1, dopadlo by hodnocení takto. Uživatelské prostředí aplikace jsem navrhnul tak, aby bylo uživatelsky přívětivé a intuitivní. Jako hlavní navigaci aplikace jsem využil Navigation Drawer, který kombinuje kompaktnost (když není využívaný, je skrytý) a zároveň umožňuje zobrazovat mapu hned na úvodní obrazovce. Celkově na mě prostředí působí dobrým dojmem, avšak některé prvky by bylo možné ještě upravit a tím podpořit jednotný vzhled aplikace. Vzhled uživatelského prostředí je zhruba na stejné úrovní jako u aplikací Monash University (dále jen MU) a On Campus. Funkcionalita mojí aplikace není v porovnání s některými testovanými aplikacemi na takové úrovni. Tím chci říct, že uživateli neposkytuje takové množství funkcí, jako je tomu například u aplikace On Campus. Ta poskytovala uživateli funkce jako předpověď počasí, sledování pohybu MHD, atd. Moje aplikace se soustředí pouze na základní funkce usnadňující orientaci v areálu školy. Zobrazení mapy mi vyhovovalo pouze u aplikace MU a právě touto mapou jsem se inspiroval. Stejně jako aplikace MU využívám pro zobrazení mapy Google Maps API. Oproti MU jsem využil pro vykreslení areálu university Ground Overlay, neboli překrytí dodávané mapy vlastní vrstvou (mapou). Stejně jako aplikace MU, poskytuje i moje aplikace možnost zobrazit na mapě vybraná místa. Hledání míst mi nepřišlo zajímavé ani v jedné z testovaných aplikací a proto jsem se ho ve svojí aplikací pokoušel nějak ozvláštnit. Vyhledávání probíhá zprvu podobně jako u ostatních aplikací, uživatel si vybere místo a aplikace mu o něm dodá informace. Uživatel má následně možnost, zobrazit vybrané místo na mapě. Co však žádná z aplikací nepodporovala, je zobrazení konkrétního umístění místa v budově. K tomu využívám ve svojí aplikaci serveru Indica, který shromažďuje plány jednotlivých pater budovy Q a umožňuje na nich zvýraznit jednotlivé místnosti. Některé funkce mojí aplikace jsou použitelné i bez připojení k Internetu, k použití jiných je však připojení potřeba. Jelikož jsou v aplikaci zobrazovány mapové podklady pouze pomocí Google Maps API, je pro jejich správné zobrazení důležité, alespoň při prvním použití aplikace připojení k Internetu mít. Pokud tomu tak není, nenačte se mapa do zařízení a není tak možné používat mapové podklady v aktivitách Mapu areálu a Hledání místa. Ostatní funkce aplikace, jako Upomínky nebo Rozvrh je možné využívat i bez připojení k Internetu. Aplikace používá ke spoustě svých funkcí určování aktuální polohy zařízení a

54

Diskuze

proto je podmínkou, pro spuštění aplikace, mít určování aktuální polohy zařízení zapnuté.

7.3 Využití aplikace na jiné univerzitě Pří průzkumu trhu jsem nenalezl v tuzemsku žádnou podobnou aplikaci a tak se nabízí otázka, jak náročné by bylo vytvořit podobnou aplikaci pro jinou univerzitu. Jelikož jsem se během vývoje svojí aplikace spoustu věcí naučil, odpadá čas strávený při učení nových věcí týkajících se implementace aplikace. Rozhodně by však bylo potřeba provést průzkum nového prostředí a dotázat se potenciálních uživatelů na jejich konkrétní požadavky. Dále by bylo potřeba provést sběr nových dat, která jsou samozřejmě odlišná. Jakmile by byl dokončen sběr požadavků, který je třeba vykonat před vývojem každé aplikace, bylo by třeba už pouze přepsat data v databázi, daty nově získanými, znovu naimplementovat části kódu, soustředěné na MENDELU (přesunutí mapy na areál MENDELU, atd.) a samozřejmě by nebylo možné využít serveru Indica. Část s upomínkami je naimplementována obecně a proto by stačilo při převádění akorát změnit předdefinovaná místa, která se dají k upomínce přiřadit. Pokud pominu tyto fakty, neměl by být převod mojí aplikace na jinou univerzitu obzvlášť náročný a její vývoj by se měl oproti mojí aplikaci o dost zkrátit.

7.4 Zhodnocení vývoje Vývoj aplikace pro OS Android byl velice zajímavý, a jakmile jsem se dostal přes svoji počáteční neznalost, tak i plynulý a vcelku rychlý. K implementaci aplikace jsem používal vývojové prostředí Eclipse, které bylo uživatelsky velice přívětivé, výborně v něm fungovala nápověda, zvýrazňování syntaxe a můj vývoj mi usnadnilo. Na oficiálních stránkách Android Developers je opravdu obrovské množství informací a konkrétních postupů, které mi ve vývoji velice pomohly. Kromě toho, díky velké oblíbenosti Androidu, lze na Internetu nalézt skutečně mnoho dalších informací, rad, kusů kódu a postupů, které při vývoji zajisté přijdou vhod.

Závěr

55

8 Závěr Cílem mojí práce bylo vytvořit nový způsob usnadnění navigace v areálu Mendelovy univerzity v Brně. Už na začátku jsem měl jasno, že půjde o aplikaci pro chytré mobilní telefony s operačním systémem Android. K tomu, abych tohoto cíle mohl dosáhnout, bylo zapotřebí provést spoustu věcí. Začal jsem tím, že jsem provedl průzkum trhu a ujasnil si požadavky na aplikaci. Potom následovalo studování základů vývoje v jazyce Android. Jakmile jsem znal základy, začal jsem aplikaci vyvíjet. Potřeboval jsem vymyslet strukturu aplikace, která bude funkční a přitom jednoduchá, abych uživatele nezahltil přebytečnými informacemi. Tato struktura se během vývoje nepatrně měnila, bylo však důležité, mít na čem začít stavět. Moje studium samozřejmě pokračovalo dál a to v průběhu celého vývoje. Musím ale říct, že jazyk je opravdu zajímavý a určitě v něm budu pokračovat i dále. V praktické části jsem tedy provedl návrh struktury aplikace, vybral jsem vhodný způsob navigace pro aktivity na nejvyšší vrstvě a následovala samotná implementace aplikace. Během psaní aplikace jsem se několikrát dostal do slepé uličky, ale vždy jsem si dokázal poradit a aplikace je nakonec hotová a funkční. Největší problémy jsem měl zřejmě s implementací sledování geofencí, což je po svém dokončení opravdu zajímavá funkce. Do teoretické části se dá jistě zařadit i návrh ikony aplikace. Ta je vcelku jednoduchá, obsahuje symboliku školy spolu s ukazatelem směru, což myslím jasně vyjadřuje účel aplikace. V teoretické části jsem si rozebral jednotlivé možnosti, jak navigaci v areálu univerzity usnadnit, dále jsem zmínil informace o samotném OS Android a provedl jsem průzkum trhu. Při průzkumu trhu jsem testoval podobné aplikace, které rovněž slouží pro usnadnění navigace na univerzitách, od kterých jsem se následně inspiroval pro svojí práci. Jakmile byl průzkum dokončen, sepsal jsem požadavky na vlastní aplikaci a zahájil vývoj. Jakmile byla aplikace hotová, začal jsem ji jako první testovat sám. K prvnímu testování jsem využil zařízení Samsung Galaxy S5 a taky několik rozmanitých virtuálních zařízení. Na všech byla funkčnost dobrá a nenarazil jsem na žádné problémy. Po první fázi testování jsem poskytl tuto aplikaci svým známým a lidem ve svém okolí. Během této fáze mi bylo reportováno několik drobností, které bylo potřeba opravit a tak se i stalo.

56

Literatura

9 Literatura Android-App-Market.com [online]. 2012 [cit. 2014-12-07]. Dostupné z: http://www.android-app-market.com/ MURPHY, MARK L. Android 2: průvodce programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, 375 s. ISBN 978-80-251-3194-7. BURTON, MICHAEL A DONN FELKER. Android application development for dummies. 2nd edition. xviii, 386 pages. ISBN 978-1-118-38710-8. SMITH, DAVE A JEFF FRIESEN. Android Recipes: A Problem-Solution Approach. New York, 2014. Android Developers [online]. 2014 http://developer.android.com/

[cit.

2014-12-07].

Dostupné

z:

Český statistický úřad [online]. 2014 [cit. 2014-12-29]. Dostupné z: http://www.czso.cz/ JONASSON, HANS. Determining project requirements: mastering the BABOK and the CBAP exam. 2nd ed. Boca Raton: CRC Press/Taylor, c2013, xvii, 385 p. ISBN 978-143-9896-518. Mendelova univerzita v Brně [online]. 2014 [cit. 2014-12-30]. Dostupné z: http://mendelu.cz/ UJBÁNYAI, M. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012, 187 s. Průvodce (Grada). ISBN 978-80-247-3995-3. MACIASZEK, LESZEK. Requirements analysis and system design. 3rd ed. Harlow: Addison-Wesley, 2007, xxxvii, 612 s. ISBN 978-0-321-44036-5. SQLite [online]. 2014 [cit. 2014-12-20]. Dostupné z: http://www.sqlite.org/ Stat Counter: Global Stats [online]. 2014 [cit. 2014-12-22]. Dostupné z: http://gs.statcounter.com/

Literatura

57

ROLLINS, MARK. The business of Android apps development: making and marketing apps that succeed. New York: Disctributed to the book trade worldwide by Springer Science Business Media, 2011, xvi, 228 p. ISBN 14302-3942-5. The Java developer's guide to Eclipse. 2nd ed. Boston: Addison-Wesley, c2005, xlvi, 1083 s. ISBN 03-213-0502-7. PHILLIPS, DWAYNE. The software project manager's handbook: principles that work at work. 2nd ed. Los Alamitos, CA: IEEE Computer Society, c2004, xiv, 485 p. ISBN 04-716-7420-6. Ústav informatiky: Mapový server Indica [online]. 2009 [cit. 2014-12-23]. Dostupné z: http://ui.pefka.mendelu.cz/

58

Literatura

Přílohy

Přiložené CD

A Přiložené CD Přiložené CD obsahuje:  Instalační soubor aplikace  Zdrojové kódy aplikace  XML soubory uživatelského rozhraní aplikace

59

Mobilní aplikace Průvodce po MENDELU

Recommend Documents