}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Notifikaˇcní aplikace využívající GPS na platformˇe Google Android ˇ B AKALÁ RSKÁ PRÁCE
Jaromír Benda
Brno, jaro 2013
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Jaromír Benda
Vedoucí práce: RNDr. Martin Jakubiˇcka ii
Podˇekování Dˇekuji vedoucímu mé bakaláˇrské práce RNDr. Martinu Jakubiˇckovi za pˇripomínky a ochotu pˇri vedení práce, sleˇcnˇe Kateˇrinˇe Gbelcové za korekturu práce a svým blízkým za jejich podporu.
iii
Shrnutí Tato bakaláˇrská práce se zabývá pˇriblížením vývoje mobilních aplikací pro platformu Android, geolokaˇcních technologií a implementace vlastní aplikace LocNote. V rámci práce došlo ke srovnání a hodnocení vybraného reprezentativního vzorku soudobých existujících rˇ ešení s následným návrhem aplikace pro upozornˇení uživatele na základˇe geografické polohy. Hlavním cílem práce byla právˇe implementace programu s testováním, nasazením na Google Play Store a pˇredstavením výsledku. ˚
iv
Klíˇcová slova Android, LocNote, mobilní aplikace, GPS, geolokace, chytrý telefon, notifikace, Google, Facebook, SMS, geografická poloha
v
Obsah 1 2
3
4
5
6
7
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . OS Android . . . . . . . . . . . . . . . . . . . . . 2.1 Historie . . . . . . . . . . . . . . . . . . . . . 2.2 Architektura . . . . . . . . . . . . . . . . . . 2.3 Aplikaˇcní komponenty . . . . . . . . . . . . 2.4 Verze Androidu . . . . . . . . . . . . . . . . 2.5 Vývoj aplikací . . . . . . . . . . . . . . . . . Zjištˇení geografické polohy zaˇrízení . . . . . . . 3.1 Globální polohový systém . . . . . . . . . . 3.2 Bezdrátové sítˇe . . . . . . . . . . . . . . . . 3.3 Globální systém pro mobilní komunikaci . Analýza . . . . . . . . . . . . . . . . . . . . . . . 4.1 Analýza dosavadních rˇ ešení . . . . . . . . . 4.2 Popis aplikace . . . . . . . . . . . . . . . . . Návrh . . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Uživatelské rozhraní . . . . . . . . . . . . . 5.1.1 Layout . . . . . . . . . . . . . . . . . 5.2 Vnitˇrní struktura . . . . . . . . . . . . . . . 5.2.1 Diagram tˇríd . . . . . . . . . . . . . Implementace . . . . . . . . . . . . . . . . . . . . 6.1 Vypracování aplikace . . . . . . . . . . . . . 6.1.1 Perzistence dat . . . . . . . . . . . . 6.1.2 Prezentace dat . . . . . . . . . . . . . 6.1.3 Geolokace a upozornˇení na událost 6.1.4 Lokalizace a logování . . . . . . . . 6.2 Využití externích knihoven . . . . . . . . . 6.2.1 ActionBar Sherlock . . . . . . . . . . 6.2.2 Facebook SDK . . . . . . . . . . . . . 6.2.3 Google Maps . . . . . . . . . . . . . 6.2.4 Google Analytics . . . . . . . . . . . 6.3 Distribuce aplikace . . . . . . . . . . . . . . 6.3.1 Nasazení na GooglePlay . . . . . . . 6.3.2 Statistiky . . . . . . . . . . . . . . . . 6.3.3 Zpˇetná vazba a testování . . . . . . Závˇer . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 3 4 4 6 10 11 13 13 14 14 16 16 19 21 22 23 25 25 28 28 28 30 34 36 37 37 38 40 42 43 43 45 46 47 vi
Literatura . . . . . . . . . . . . . . . Pˇríloha . . . . . . . . . . . . . . . . A Elektronická pˇríloha v IS . B Ukázka Layout . . . . . . C Ukázka DbHelper . . . . . D Ukázka DbManager . . . . E Ukázka Fragment . . . . . F Ukázka Facebook SDK . . G Ukázka Google Maps . . . H Ukázka Google Analytics
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
48 50 50 50 50 50 50 50 50 50
vii
1 Úvod Moderní doba klade stále vˇetší duraz ˚ na zpracování informací. Každý se musí s tˇemito informacemi nejen seznamovat, ale umˇet je i správnˇe používat. Je velmi duležité ˚ nauˇcit se filtrovat, tedy dokázat rozlišit, které zprávy jsou pro jednotlivce duležité, ˚ které povinné a které jsou nepodstatné. I pˇresto muže ˚ nastat situace, kdy nˇekdo zapomene splnit svou povinnost. Z tohoto duvodu ˚ vzniká plno pomucek ˚ pro podporu pamˇeti a uchování duležitých ˚ informací, napˇr. poznámkových bloku, ˚ pˇripomínkovaˇcu˚ a úkolníku˚ inspirujících se klasickým diáˇrem se schopností stát se souˇcástí našeho bˇežného života. Stále cˇ astˇeji se také v reálném životˇe setkáváme s chytrými mobilními pˇrístroji, které mají široké množství funkcí, jakými jsou internetové pˇripojení, globální polohový systémem (GPS) nebo fotoaparát. Mezi tato zaˇrízení rˇ adíme chytré telefony, osobní digitální pomocníky (PDA) cˇ i fenomén poslední doby, tablety. Vyˇcnívají nad ostatními zaˇrízeními díky své nízké váze, relativnˇe vysokému výkonu a pˇredevším nainstalovanému operaˇcnímu systému. Jednou z dalších kladných vlastností tˇechto pˇrístroju˚ je jejich snadná pˇrenositelnost. Mít možnost všechnu funkcionalitu použít kdykoliv a kdekoliv je fascinující. Právem zajistila vysokou popularitu tˇemto zaˇrízením a dala podklad k vytvoˇrení notifikaˇcní aplikace, potažmo této práce, jakožto spojení rozsáhlé funkcionality chytrého telefonu s dalším pevným prvkem našeho života. Mobilní telefony v kombinaci s poskytnutím služby lokalizace fyzických umístˇení, tzv. location-based services1 , umožnují ˇ inovátorský pˇrístup a tvoˇrení vyspˇelých aplikací. Tímto názvem se oznaˇcují technologie jako již zmínˇená GPS, dále vyhledání polohy využitím bezdrátových sítí nebo triangulace telefonních stožáru. ˚ S touto metodou jako první pˇrišla spoleˇcnost Google. Analýza zmínˇených technologií je taktéž souˇcástí této práce. 1.
Více na en.wikipedia.org/wiki/Location-based_service
1
1. Ú VOD Cílem této práce je základní seznámení s tvorbou aplikace pro Android, analýza možností a dostupných rˇ ešení, návrh a implementace notifikaˇcní aplikace založené na GPS lokaci. Program má za úkol pˇripomenout duležité ˚ události vytvoˇrené uživatelem s možností sdílení se svými bližními. Notifikace jsou vyvolány dosažením unikátní zemˇepisné polohy v jakýkoli cˇ as a jako upozornˇení slouží jednoduchý notifikaˇcní status na displeji doprovázený zvukovým, vibraˇcním a pˇrípadnˇe svˇetelným signálem, dle aktuálního nastavení zaˇrízení. Nejprve jsme nastudovali elementární stavbu programu pro operaˇcní systém Android. Po studii nˇekolika již vytvoˇrených aplikací jsme vytvoˇrili odpovídající srovnání a hodnocení. Posuzovali jsme tˇri základní aspekty: vzhled prostˇredí, uživatelskou pˇrívˇetivost a možnosti, které jsou nabízeny uživatelum. ˚ Následný koncept nejen zohlednuje ˇ výsledky analýzy, ale zahrnuje i vlastní nápady a poznatky. Aplikace je zamˇerˇ ena zejména na chytré telefony a pˇredpokládá pˇrítomnost internetového pˇripojení a GPS modulu.
2
2 OS Android Operaˇcní systém Android je nejoblíbenˇejší softwarová platforma [Tabulka 2.1] založená na linuxovém jádru pro mobilní zaˇrízení od spoleˇcnosti Google. Toto jádro umožnuje ˇ systému Android unikátní hardwarovou pˇrenositelnost, která je vnímána jako velký benefit. Android je prezentován a vyvíjen jako open-source projekt pod licencí Apache 2.0 a GPLv21 a jako takový je zcela zdarma. Uživatelé mohou libovolnˇe mˇenit ruzné ˚ aspekty svého oblíbeného operaˇcního systému, vývojáˇri nejsou jakýmkoliv zpusobem ˚ omezováni a mohou vytváˇret vlastní nadstavby uživatelského rozhraní, využívat všechny funkce zaˇrízení, které jsou dostupné.
Platforma Android iOS BlackBerry Windows Mobile Ostatní
Distribuce v mil. ks 159.8 47.8 7.4 6.0 6.8
Podíl na trhu v % 70.1 21.0 3.2 2.6 3.1
Tabulka 2.1: Rozšíˇrení OS dle platformy, zdroj dat: Mobilmania.cz, stáˇrí dat: prosinec 2012
Avšak tato volnost se zaˇcala projevovat negativním dusledkem. ˚ Pˇrítomností fragmentace zaˇcínalo docházet k degradaci platformy, snižování uživatelské zkušenosti, která pˇredstavovala potenciální riziko snížení uživatelu˚ používajících platformu Android. Spoleˇcnost Google na tento poˇcínající trend zareagovala a vydala sadu doporuˇcení, Android Guidelines2 , za úˇcelem zamezení hrozícího úpadku softwaru. Touto sadou doporuˇcení se taktéž rˇ ídíme pˇri implementaci aplikace. 1. 2.
Více na en.wikipedia.org/wiki/Apache_License Více na developer.android.com/guide/practices/ui_guidelines/index.html
3
2. OS A NDROID Kromˇe oblasti našeho zájmu, platformy Google Android, který jsme si vybrali pˇredevším, protože se jedná o moderní operaˇcní systém s otevˇreným zdrojovým kódem a s faktem aktuální zvýšené poptávky mobilních aplikací, což cˇ iní vývoj velmi zajímavým, existuje na trhu mnoho dalších platforem. Mezi nejvˇetší konkurenty patˇrí iOS od firmy Apple a Windows Mobile od firmy Microsoft. Jejich hlavní nevýhodou jsou rozsáhlé restrikce a tvrdé licenˇcní podmínky vuˇ ˚ ci vývojáˇri.
2.1
Historie
Puvodní ˚ spoleˇcnost Android Inc. zabývající se tvorbou mobilních aplikací byla založena jako podnikatelský zámˇer Andy Rubinem a jeho kamarády ve Spojených státech amerických v rˇ íjnu 2003. Projekt nebyl známý a brzy se dostal do finanˇcních problému, ˚ tyto problémy, které byly vyˇrešeny fúzí s gigantem – spoleˇcností Google v srpnu roku 2005, která firmu Android Inc. odkoupila a udˇelala z ní svoji dceˇrinou spoleˇcnost [7]. Softwarová platforma Android, puvodnˇ ˚ e vyvíjená firmou Android Inc., byla dále vyvíjena pod spoleˇcností Google. Ta 5. listopadu 2007 založila sdružení Open Handset Alliance (OHA), které oficiálnˇe pˇredstavilo nový open-source software Android. OHA je sdružení mobilních operátoru, ˚ výrobcu˚ mobilních zaˇrízení, spoleˇcností vyvíjející aplikace, výrobcu˚ cˇ ipu˚ a obchodních spoleˇcností. Aktuálnˇe sdružení cˇ ítá 84 spoleˇcností [8]. První komerˇcní telefon s operaˇcním systémem Android byl uveden v rˇ íjnu 2008 v USA [9].
2.2
Architektura
Architektura softwarové platformy Android je založena na pˇeti vrstvách, každá vrstva má definovaný úˇcel, ale nemá jasnˇe vymezené hranice [Obrázek 2.1]. Nejnižší vrstvou je již zminované ˇ linuxové jádro. Slouží jako spojovník mezi hardwarem a zbytkem operaˇcního systému, pˇrináší nám 4
2. OS A NDROID
Obrázek 2.1: Struktura systému Android, zdroj: Androidland.pl pˇrenositelnost. Jádro rˇ ídí veškeré základní systémové služby a je odpovˇedné za zabezpeˇcení, multitasking, správu pamˇeti, sítˇe, procesu˚ i ovladaˇcu˚ [10]. Další souˇcástí architektury jsou C/C++ knihovny používané ruz˚ nými komponentami systému, tyto funkce jsou dále poskytovány vývojáˇri skrze aplikaˇcní rámec [10]. Stˇežejní komponentou je virtuální stroj speciálnˇe vytvoˇrený firmou Google pro platformu Android, Dalvik Virtual Machine (dále DVM cˇ i Dalvik). Dalvik byl vytvoˇren pro optimalizaci v oblasti práce s pamˇetí, práce s vlákny a úspory baterie vzhledem k výkonu. Dalvik vychází z Java Virtual Machine (JVM) používaném v programovacím jazyce Java. Proces kompilace je v prostˇredí Android taktéž obdobný. Proveden stejným kompilátorem zdrojového kódu (Java kompilátor) na volnˇe pˇrenositelný Java byte kód (pˇrípona „.class“), který je následnˇe zpracován DVM (konkrétnˇe Dex kompilátorem) na 5
2. OS A NDROID Dalvik byte kód (pˇrípona „.dex“) a zabalen do formy distribuˇcního spustitelného programu (pˇrípona „.apk“) [10].
Aplikaˇcní rámec je pro vývojáˇre nejduležitˇ ˚ ejší vrstva. On totiž poskytuje a zpˇrístupnuje ˇ bohaté množství služeb a funkcí v plném rozsahu. Využití získané funkcionality je zcela na vývojáˇri, napˇr. pˇrístupu k datum ˚ o umístˇení, ovládání prvku˚ uživatelského rozhraní nebo administrování nastavení samotného telefonu [10].
Nejvyšší, aplikaˇcní vrstva je tvoˇrena základními aplikacemi, a zárovenˇ spravována uživateli operaˇcního systému Google Android. Aplikace rozdˇelujeme do dvou kategorií. První kategorie, nativní aplikace, jsou pˇredinstalované programy pro bˇežnou práci se systémem, jako je kalendáˇr, kontakty, mapy a jiné. Druhá kategorie, komerˇcní aplikace, jsou programy tˇretích stran, jako je naše aplikace, které jsou dodateˇcné nainstalovány uživatelem [10].
2.3
Aplikaˇcní komponenty
Aplikace vyvíjena pro Android obsahuje nˇekolik základních stavebních prvku, ˚ které si nyní pˇredstavíme.
Activity (aktivita) vˇetšinou reprezentuje jednu zobrazovanou jednotku na displeji. Pˇredstavuje grafické uživatelské rozhraní pro interakci s uživatelem. Aplikace je obvykle složena z více aktivit, mezi kterými je uživatel pˇresouván, a pˇritom si aktivity mohou pˇredávat informace. Zahájení aktivity obnáší vytvoˇrení nového procesu, alokování pamˇeti pro objekty uživatelských rozhraní a zobrazení pˇripravené obrazovky. Tato událost muže ˚ být výpoˇcetnˇe nároˇcná, tudíž aby nedocházelo ke zbyteˇcnému plýtvání, nalezneme zde Manažera aktivit, který zodpovídá za celkovou správu životního cyklu aktivit [Obrázek 2.2]. Manažer aktivit pracuje se zásobníkem, ve kterém se shromažd’ují data o spuštˇených aktivitách a na vrcholu tohoto zásobníku je aktuálnˇe zobrazovaná vizuální komponenta. 6
2. OS A NDROID
Obrázek 2.2: Životní cyklus aktivity, zdroj: developer.android.com
7
2. OS A NDROID Životní cyklus se skládá ze tˇrí stavu, ˚ do kterých se aktivita muže ˚ dostat. Pokud aktivita pusobí ˚ v popˇredí, pˇrijímá uživatelské vstupy, nachází se ve stavu running/resumed (bˇežící). V pˇrípadˇe pˇrekrytí jinou aktivitou, tzn. cˇ ásteˇcném pˇrekrytí a nepˇrijímání uživatelského vstupu oznaˇcujeme stavem paused (pˇrestávka). Posledním stavem, ve kterém aktivita již není viditelná, ale objekt v pamˇeti nebyl doposud zniˇcen je stavem stopped (zastavena) [11]. Životní cyklus a pˇrechod mezi stavy je doprovázen tzv. callback metodami pro rˇ ízení chodu aktivity. Pˇrekrytím tˇechto metod dosáhneme požadovaného chování. Pˇri spuštˇení aktivity dojde v systému k inicializaci popsané výše a vytvoˇrení objektu aktivity v pamˇeti. První volanou metodou je onCreate, v níž podle zásad nastavuje content view, pˇripojení uživatelského rozhraní. V následné onStart metodˇe by se mˇely provést všechny úkony, které jsou potˇreba, aby se aktivita mohla zobrazit. Napˇríklad spuštˇení vlákna, které pravidelnˇe stahuje data z internetu a v aktivitˇe je zobrazujeme. Po zavolání onStart má aktivita pˇrestávku. V naprosté vˇetšinˇe pˇrípadu˚ bude následovat volání onResume, ale ojedinˇele muže ˚ pokraˇcovat pomocí onStop. Konec pˇrestávky je provázen metodou onResume a následným pˇreklopením do stavu bˇežící, po jejím provedení je aktivita viditelná a pˇrijímá vstup. Metoda onResume muže ˚ být volána celkem cˇ asto, proto by se v ní nemˇely provádˇet žádné nároˇcné operace. Každá metoda životního cyklu, s výjimkou onRestart, má svuj ˚ protikladný ekvivalent. Po onResume pˇrichází vždy onPause. Ta opˇet pˇrivede aktivitu do stavu pˇrestávka. V situaci, ve které zaˇrízení disponuje kriticky nízkou úrovní pamˇeti, vˇetšinou dojde k rychlému zabití nekritických procesu. ˚ onPause je jedinou garantovanou volanou metodou pˇri zniˇcení objektu aktivity, proto je vhodný a doporuˇcený kandidát na uložení uživatelem provedených akcí na datech, která se netýkají jen jedné konkrétní instance aktivity. onStop je opakem metody onStart. Aktivita pˇrechází z pˇrestávky na stav zastavená a mˇeli bychom v ní zrušit všechno, co jsme v onStart vytvorˇ ili. Po onStop mužeme ˚ dojít k resetování aktivity (onRestart, která hned zavolá onStart), anebo standardnˇe zniˇcena pomocí onDestroy. Metoda onDestroy je protikladem onCreate a mˇeli bychom uklidit 8
2. OS A NDROID to, co jsme vytvoˇrili v onCreate. Service (služba) na rozdíl od aktivity neposkytuje uživatelské rozhraní, ale pˇredstavuje proces bˇežící na pozadí. Komponenta nachází uplatnˇení u dlouho trvajících požadavku˚ nebo u pˇrístupu k vzdáleným zdrojum, ˚ u kterých není známá doba odezvy. Služba muže ˚ být spuštˇena dvˇema zpusoby. ˚ Pomocí metody startService, u níž ukoncˇ ení muže ˚ být iniciováno svévolnˇe nebo jinou komponentou. Pomocí metody bindService, kterou volá jiná komponenta cˇ i skupina komponent, tzv. klient/klienti, v tomto pˇrípadˇe službu muže ˚ ukonˇcit pouze klient, který ji spustil. V pˇrípadˇe navázání více komponent je služba ukonˇcena po odpojení všech klientu˚ [2]. Content provider (poskytovatel obsahu) je jednoduché rozhraní poskytující pˇrístup k informacím. Jedná se o zpusob ˚ sdílení dat a to nejen mezi aplikacemi, ale i mezi jednotlivými aktivitami [1]. Aplikace muže ˚ uchovávat data ruznými ˚ zpusoby ˚ – v souborech, SQLite databázi nebo na internetu, a pˇresto mohou mít k tˇemto datum ˚ pˇrístup jiné aplikace. Práce s poskytovatelem obsahu je intuitivní, nad úložištˇem, podobnˇe jako u relaˇcní databáze, jsou provádˇeny dotazy a pˇríkazy. Broadcast reciever (zámˇer) má za úkol reagovat na ruznorodé ˚ události v systému. Naslouchá cˇ innosti systému a pˇri odposlechu „správné“ akce provede požadovanou reakci. Aplikace mohou využívat broadcast (relace) systémové nebo vytváˇret své vlastní. Relace lze i vysílat. Podobnˇe jako služba a poskytovatel obsahu ani broadcast receiver nemá uživatelské rozhraní. Všechny tyto souˇcásti musí být definovány v klíˇcovém souboru AndroidManifest.xml3 , uloženém v koˇrenovém adresáˇri projektu. Každá Android aplikace musí tento soubor obsahovat. Identifikuje pˇrístupové body, komponenty, rozsah kompatibilních verzí. Požadavky aplikace na konfiguraci zaˇrízení, hardwarové a softwarové vlastnosti, oprávnˇení a také unikátní jméno balíˇcku. 3.
Více na developer.android.com/guide/topics/manifest/manifest-intro.html
9
2. OS A NDROID Další prostˇredkem v prostˇredí Android je intent4 neboli asynchronní zpráva pro propojení komponent vyjma content provideru. ˚ Slouží ke startu aktivit, služeb a vysílání relací. Také umožnuje ˇ nést dodateˇcnou informaci. Každá aplikace využívá uživatelského rozhraní definovaného v tzv. layoutu, obrázky, animace, lokalizaˇcní rˇ etˇezce. Souhrnnˇe tyto zdroje nazýváme resource (prostˇredky). Prostˇredky by mˇely být optimalizovány pro ruzné ˚ typy zaˇrízení, napˇríklad podle velikosti displeje. Každý prostˇredek má svuj ˚ identifikátor, skrz který je zpˇrístupnˇen. Tyto identifikátory jsou následnˇe automaticky udržovány v souboru R.java.
2.4
Verze Androidu
Nové verze Androidu jsou vydávány za úˇcelem opravy chyb nalezených v pˇredchozích verzích. Snahou udržení tížené kompatibility se stále vyvíjejícími a zlepšujícími technologiemi a platformou ˇ Android. Císlování verzí se odvíjí od velikosti zmˇen, v pˇrípadˇe menších úprav a oprav je verze inkrementována o desetinu. V pˇrípadˇe zavedení novinek a významných oprav je verze inkrementována o jedniˇcku. Každá verze je také pojmenována dezertem a to v abecedním uspoˇrádání a její vydání je doprovázeno vydáním aktualizace vývojáˇrského API [Tabulka 2.2]. Historicky si nejlépe vede verze 2.3 – Gingerbread. Gingerbread se brzy stal uživatelsky velice oblíbený a zajistil nejvˇetší úspˇechy operaˇcního systému Android. Opravuje nedostatky pˇredchozích dvojkových verzí, nehospodárnou správu prostˇredku, ˚ špatnou klávesnici a nedokonalé Google Maps [12]. I dnes [Obrázek 2.3] verze Gingerbread dosahuje témˇerˇ poloviˇcního podílu v rámci komunity Android. Nejvˇetším nedostatkem zustává ˚ vzhled. Dalším úspˇešným zástupcem je verze 4.0 – Ice Cream Sandwich s témˇerˇ tˇretinovým podílem v distribuci Android. V polovinˇe tohoto roku oˇcekáváme pˇríchod verze 5.0 s pojmenováním Key Lime Pie. 4.
Více na developer.android.com/reference/android/content/Intent.html
10
2. OS A NDROID Verze 1.5 1.6 2.0/2.1 2.2 2.3/2.4 3.1/3.2 4.0/4.0.4 4.1/4.2 5.0
Název Cupcake Donat Eclair Froyo Gingerbread Honeycamb Ice Cream Sandwich Jelly Bean Key Lime Pie
API 3 4 6/7 8 9/10 12/13 14/15 16/17 18
Datum vydání 30. dubna 2009 15. záˇrí 2009 26. rˇ íjna 2009 20. kvˇetna 2010 6. prosince 2010 22. února 2011 23. rˇ íjna 2011 9. cˇ ervence 2012 kvˇeten 2013
Tabulka 2.2: Pˇrehled verzí OS Google Android, zdroj dat: developer.android.com Spoleˇcnost Google vede politiku zpˇetné kompatibility, proto aplikaci vyvíjenou pro Android Froyo spustíme v jakékoliv další verzi. To je duležité ˚ pro vývojáˇre, kteˇrí musí posoudit, jaké technologie chtˇejí použít vuˇ ˚ ci potenciální uživatelské dostupnosti a komerˇcním cílum. ˚
2.5
Vývoj aplikací
Jak již bylo zmínˇeno, Android pro uživatele a vývojáˇre je zdarma. Oficiální doporuˇcované vývojové prostˇredí je program Eclipse od spoleˇcnosti Eclipse Foundation Inc. Pro toto prostˇredí existuje nadstavba v podobˇe Android Development Tools (ADT)5 ulehˇcující vytvárˇ ení Android aplikací. Na tomto základu vznikla i naše aplikace. Samotné nástroje pro vývoj aplikací se nalézají v podobˇe Software Development Kit (SDK)6 . Dalším pomocníkem pˇri vývoji je Android Virtual Device (AVD)7 . AVD dokáže emulovat bezpoˇcet zaˇrízení na 5. 6. 7.
Více na developer.android.com/tools/help/adt.html Více na developer.android.com/sdk/index.html Více na developer.android.com/tools/help/emulator.html
11
2. OS A NDROID
Froyo 8,1%, Gingerbread 45,6%, Ice Cream Sandwich 29,0%, Jelly Beans 13,6%, Ostatní 3,7% Obrázek 2.3: Distribuce OS Android podle jednotlivých verzí trhu s ruznorodým ˚ hardwarem a nastavením systému. Slouží pˇredevším pro testování a ovˇerˇ ení chování aplikace na diametrálnˇe rozdílných zaˇrízeních.
12
3 Zjištˇení geografické polohy zaˇrízení Možnosti v oblasti geolokace jsou rozmanité, zásadním omezením jsou hardwarová vybavení mobilních zaˇrízení. V podstatˇe mužeme ˚ využít tˇri druhy vyhledání souˇcasné polohy uživatele. Technologie mají odlišný princip, pˇresnost, vliv na výdrž baterie a cenu za jejich využívání. Zpˇrístupnˇením informací o poloze mobilního zaˇrízení se budeme zabývat pˇredevším v cˇ ásti Implementace. Nyní se podíváme na teorii skrytou v pozadí používání tˇechto moderních zpusob ˚ u˚ zjišt’ovaní polohy.
3.1
Globální polohový systém
Zjišt’ovaní polohy pomocí globálního družicového polohového systému (GPS) je dnes preferovaná a oblíbená metoda. Je zajištˇena soustavou 24 satelitu˚ ve výšce pˇrekraˇcující 20 tisíc kilometru˚ nad zemským povrchem [13]. Technologie je pˇresná, ale energeticky nároˇcná. Pro každého jednoduše dostupná prostˇrednictvím GPS modulu, vˇetšinou integrovaného v mobilním zaˇrízení. Družice provozují pouze jednosmˇerný vysílací kanál, tj. satelity vysílají a zaˇrízení s GPS modulem tento signál vyhledávají, pˇripojují se k nˇemu a pˇrijímají data. Rozšíˇrením klasické technologie GPS je Assisted GPS (A-GPS). Tato technologie se snaží pˇreklenout jednu z nejvˇetších slabin bˇežné GPS, dlouhé cˇ ekání na pˇripojení k satelitu, které muže ˚ trvat i 20 minut. S intenzivní integrací GPS pˇrijímaˇcu˚ a uživatelským požadavkem na rychlost vzniklo rˇ ešení v podobˇe souˇcinnosti s dalšími dvˇema technologiemi, mobilními sítˇemi a bezdrátovými sítˇemi. Integrace tˇechto služeb do mobilu˚ je taktéž vysoká, a proto využití pˇrináší pozitivní rˇ ešení tohoto problému. Hlavním pˇrínosem A-GPS je urychlení prvotního zjištˇení pozice uživatele, tzv. fix, do doby, než je navázáno normální GPS spojení. Doplnující ˇ metody zjišt’ují pozici rychleji, avšak jsou ménˇe pˇresné. V pˇrípadˇe využití internetu lze podporˇ it zrychlení samotného pˇripojení k GPS stažením potˇrebných informaˇcních komponent, zárovenˇ dochází ke snížení energetické nároˇcnosti vyhledáním polohy uživatele pomocí GPS modulu. 13
ˇ ˇ 3. Z JIŠT ENÍ GEOGRAFICKÉ POLOHY ZA RÍZENÍ
3.2
Bezdrátové sítˇe
Ve mˇestech s hustou výstavbou a vysokými budovami, pˇrípadnˇe uvnitˇr budov, efektivnost GPS rapidnˇe klesá. Naopak zde nalezneme kompaktní pokrytí bezdrátovými sítˇemi tzv. Wireless network (Wi-Fi) a mobilními datovými sítˇemi. Wi-Fi poziˇcní systém (WPS) využívá informací pˇrístupových bodu˚ a jejich jedineˇcnou MAC adresu. Mobilní telefon je pˇripojen vždy pouze k jednomu pˇrístupovému bodu, který zná svou polohu a ke kterému umíme dopoˇcítat vzdálenost od ostatních smˇerovaˇcu. ˚ Veškeré sítˇe v okolí zaˇrízení s Wi-Fi modulem jsou dotazovány na jejich polohu, vzdálenost od zaˇrízení a MAC adresu. Následnˇe dle zjištˇených dat je urˇcena pˇribližná poloha zaˇrízení [14]. Na stejném principu, ale ve vˇetším mˇerˇ ítku, i mimo mˇesto, funguje zjištˇení polohy pomocí datové sítˇe, ovšem její využívání je spojeno s vyššími finanˇcními náklady. Nejstarší datovou mobilní sítí je GPRS, která funguje oddˇelenˇe od hlasové sítˇe (GSM; bud’ volat, nebo stahovat) a není schopna garantovat kvalitu služby. Nástupcem GPRS se stala technologie EDGE, která díky mnoha vylepšením zaˇcala garantovat služby typy geolokace. V souˇcasnosti máme mobilní telefony oznaˇcovány jako tˇretí generace (3G) a stejnojmennou datovou sítí, které již mužeme ˚ volat a stahovat data najednou [15]. Avšak datový pˇrístup prostˇrednictvím pomalejší mobilní sítˇe EDGE prodlužuje výdrž baterie.
3.3
Globální systém pro mobilní komunikaci
Globální systém pro mobilní komunikaci (GSM, mobilní sít’) je celosvˇetovˇe rozšíˇrený standard pro komunikaci mezi mobilními telefony pˇrenášející hlas [15]. Je tvoˇren stožáry, které mají okruh pusobnosti ˚ v rˇ ádu desítek kilometru. ˚ Mechanizmus triangulace stožáru˚ k nalezení polohy uživatele je podobný mechanizmu u bezdrátových sítí, nicménˇe ménˇe pˇresný a je potˇreba vlastnit zaˇrízení se speciálním cˇ ipem nebo SIM kartu umožnující ˇ tuto pokroˇcilou funkcionalitu. Triangulaˇcní systém urˇcování polohy mobilních stanic se oznaˇcuje zkratkou E-OTD (Enhanced-Observed Time Difference)1 . 1.
Více na en.wikipedia.org/wiki/E-OTD
14
ˇ ˇ 3. Z JIŠT ENÍ GEOGRAFICKÉ POLOHY ZA RÍZENÍ
Operátoˇri pˇrirozenˇe znají pˇresnou geografickou polohu vysílající základny. V triangulaci se jedná o zamˇerˇ ení mobilního zaˇrízení pomocí více okolních stožáru, ˚ pokud možno s využitím údaju˚ o zpoždˇení signálu. Na základˇe tˇechto informací se snažíme nalézt pruseˇ ˚ cík oblouku˚ kružnic, které urˇcují místo, kam svým signálem zasahují tˇri nejsilnˇejší základny v okolí hledaného telefonu. Tato technika muže ˚ být provádˇena z iniciativy operátora pro zamˇerˇ ení lokace uživatele, vˇetšinou je to využíváno v pˇrípadˇe odcizení mobilního zaˇrízení.
Technologie GPS Bezdrátové sítˇ e GSM
Poplatek za technologii / kvalita služby NE/Vysoká* ANO**/Uspokojící ANO**/Problematická
Pˇresnost Jednotky metru˚ Desítky metru˚ Stovky metru˚
* Po prvotním pˇripojení je služba kvalitní a trvající ** Uživatel vˇetšinou musí platit poplatky zprostˇredkovateli sítˇe za její využívaní Tabulka 3.1: Pˇrehled vlastností technologií použitých k lokalizaci mobilního zaˇrízení
15
4 Analýza Aplikace založená na geolokaˇcních technologiích za úˇcelem pˇripomínání duležitých ˚ událostí není novinkou na trhu. Ovšem trh není zcela zaplnˇen a žádná z dosud vytvoˇrených aplikací nedosáhla takového rozšíˇrení, aby novˇe pˇricházející aplikace s podobným zamˇerˇ ením nebyla konkurenceschopná. Cílem analýzy je pruzkum ˚ dosavadních rˇ ešení na trhu, nalezení nedostatku˚ a získání základní pˇredstavy k vytvoˇrení návrhu vlastní aplikace a následné implementace.
4.1
Analýza dosavadních rˇešení
Vybrané aplikace byly staženy z oficiálního úložištˇe Android aplikací, GooglePlay, nainstalovány a zkoušeny na mobilním telefonu Huawei Ideos X5. Podmínky pro výbˇer aplikací byly jednoduché, programy jsou zdarma, urˇceny minimálnˇe pro Android 2.2 a mají stejný úkol: notifikovat uživatele na základˇe geografické polohy. Mezi aspekty našeho zájmu patˇrily pˇredevším vzhled prostˇredí, uživatelská pˇrívˇetivost pˇri tvorbˇe, editace a smazání pˇripomínky. Neménˇe duležitý ˚ byl zpusob ˚ upomenutí, chování a funkce poskytované aplikací. GeoNote GeoNote1 [Obrázek 4.1a] je jedna z prvních aplikací na toto téma vytvoˇrená pro platformu Android. Také díky tomu je pomˇernˇe známá. Avšak již prostý fakt stáˇrí poslední aktualizace (15.12.2010) znaˇcí, že aplikace není udržovaná a nereflektuje novinky a trendy posledních let. Aplikace se snaží pusobit ˚ inovátorským dojmem. Design je navrhnut na míru, ale podle dnešních mˇerˇ ítek je nekonvenˇcní a nedostaˇcující. Zajímavostí je možnost celkové deaktivace aplikace a výbˇer zpusobu ˚ lokalizace zaˇrízení. Pˇred vytvoˇrením notifikaˇcní události je nutné vytvoˇrení lokace, ke které tyto události budeme asociovat. Lokace jsou zobrazeny na 1.
K dispozici na play.google.com/store/apps/details?id=com.jambo.geonote
16
4. A NALÝZA hlavní stránce, po jejich otevˇrení mužeme ˚ upravovat samotnou lokaci, vytváˇret události, anebo je také upravovat. Dalším zajímavým prvkem pˇri vytváˇrení a editaci události je výbˇer, kdy notifikovat uživatele, jestli pˇri navštívení lokace, jejím opouštˇení s eventuálním omezením na urˇcitý cˇ asový horizont. Nejvˇetší nedostatkem této aplikace je existence programátorských chyb a s tím spojené pády aplikace. Obˇcas aplikace neupozorní na událost, kterou mˇela. Location Reminder Alarm Location Reminder Alarm2 [Obrázek 4.1b] pˇripomíná spíše webovou aplikaci. Uživatel je pˇred puštˇením do tˇela aplikace nucen k registraci, a to, i když nechce využívat funkce s registrací spojené (logování lokací a prohlížení historie na webu), což je u mobilních aplikací krajnˇe nevhodné. Opuštˇení aplikace je vynucováno tlaˇcítkem „Exit“ a i poté jsme o pˇrítomnosti aplikace informováni nesmazatelným notifikaˇcním statusem. Design je tvoˇren zastaralými standardními prvky uživatelského rozhraní, které neoslní. Hlavní strana je tvoˇrena seznamem již vytvoˇrených pˇripomínek. Tvorba nových notifikaˇcních událostí je jednoduchá, ovšem zase vynucována poˇradím kroku. ˚ Zajímavostí je možnost výmˇeny pohledu na mapu. Nejvˇetším nedostatkem této aplikace, mimo vzhled a agresivitu, s kterou se vnucuje, je neintuitivní správa událostí. Program pˇredstavuje ukázku špatnˇe instruované aplikace. Location Reminder Location Reminder3 [Obrázek 4.1c] je jednoduchá aplikace urˇcená pro nenároˇcné uživatele. Nalezneme zde svébytný, pˇrímoˇcarý, nepˇríjemný a nepovedený design. Hlavní aktivitu tvoˇrí mapa, která 2. K dispozici na play.google.com/store/apps/details?id=com.cg.android.proximityalarm 3. K dispozici na play.google.com/store/apps/details?id=rcs.LocationReminder
17
4. A NALÝZA umožnuje ˇ nalezení požadované geografické polohy a následné vytvoˇrení upomínky, u které lze nastavit cˇ asování. Mimo vytváˇrení událostí, aplikace poskytuje pouze možnost editace a smazání. GPS Location Alarm Další z rˇ ady nepovedených aplikací je GPS Location Alarm4 [Obrázek 4.1d], která navíc postrádá logiku. Hlavní strana je též tvorˇ ena mapou a jakékoliv kliknutí je bráno jako povel k vytvoˇrení události bez potvrzovacího dialogu. K události lze pˇripojit vlastní ikonu a zvuk, avšak po vytvoˇrení se na mapˇe nezobrazí a to ani defaultní. Aplikace se jeví totálnˇe nepoužitelnou a pˇripomíná spíše špatný vtip, než funkˇcnˇe užiteˇcného pomocníka. Hodnocení Analýza ruznorodých ˚ aplikací na trhu ukázala nedostateˇcnˇe kladený duraz ˚ na vzhled uživatelského rozhraní a pˇrinesla celkové zklamání z úrovnˇe nˇekterých exempláˇru. ˚ Design má v dnešní dobˇe rozhodující význam pˇri volbˇe a používání aplikace zákazníkem. Další zklamání pˇrineslo vynechání integrace technologií a funkcí poskytovaných chytrými mobilními telefony. Tyto funkce by aplikace zatraktivnily a porušily panující monotónnost. Otestování aplikací pˇrineslo mnohá ponauˇcení, která se následnˇe projevila v návrhu a implementaci. Název aplikace GeoNote Location Rem. Alarm Location Reminder GPS Location Alarm
Design 5/10 4/10 3/10 5/10
Uži. pˇrívˇetivost 7/10 3/10 6/10 2/10
Ostatní* 6/10 3/10 5/10 2/10
*Nadstandardní možnosti pro uživatele, chování aplikace a zpusob ˚ reakce pˇri dosažení polohy. Tabulka 4.1: Pˇrehled výsledku˚ z pruzkumu ˚ trhu 4.
K dispozici na play.google.com/store/apps/details?id=com.agila.wakeme
18
4. A NALÝZA
(a) Geonote
(c) Location Reminder
(b) Location Reminder Alarm
(d) Gps Location Alarm
Obrázek 4.1: Snímky testovaných aplikací, zdroj: GooglePlay.com
4.2
Popis aplikace
Primárním cílem této bakaláˇrské práce je vytvoˇrení celkovˇe funkˇcní aplikace s intuitivní manipulací pro uživatele. Rozšíˇrení všední aplikace o možnosti zapojení vyspˇelé funkcionality dnešních chytrých telefonu˚ s moderními komunikaˇcními nástroji jako sdílení prostˇrednictvím populární sociální sítˇe Facebook. Prohlídka požadovaného místa skrze webovou službu Google Street View nebo zobrazení navigace k tomuto místu v této oblasti unikátní. Takové zatraktivnˇení a ulehˇcení administrace denních povinností s líbivým a moderním 19
4. A NALÝZA uživatelským rozhraním by mˇelo pˇredˇcit již existující rˇ ešení. K dosažení cíle je využito široké spektrum nástroju. ˚ Od aplikace Balsamiq Mockup pro navržení nativního uživatelského rozhraní po Visual Paradigm pro navržení vnitˇrní struktury programu. Neménˇe duležitým ˚ prvkem jsou externí knihovny pro implementaci rozšírˇ ené funkcionality.
20
5 Návrh Vˇetšina funkcí poskytovaných naší aplikací již byla vyložena, formální a úplný pˇrehled je popsán v pˇriloženém diagramu pˇrípadu˚ užití [Obrázek 5.1]. Pro ulehˇcení práce jsou uživateli poskytnuty aktivity pro hledání konkrétní geografické lokace na mapˇe a seznam telefonních kontaktu˚ pro výbˇer osob, které by si uživatel pˇrál kontaktovat prostˇrednictvím SMS.
Obrázek 5.1: Pˇrípady užití podporované naší aplikací, vytvoˇreno pomocí: Visual Paradigm
Název a ikona Název by mˇel vystihovat a korespondovat podstatu aplikace, a zároven, ˇ z marketingových duvod ˚ u, ˚ být lehce zapamatovatelný a libozvuˇcný. Oblast zájmu naší aplikace je geografická poloha, pro kterou si lidé asociují poznámky a vytváˇrí události. V anglickém jazyce nalezneme ekvivalent ke slovum ˚ poloha (location) a poznámka (note). Spojením tˇechto slov vznikl originální název naší aplikace LocationNote, zkrácenˇe a pak dokonce oficiálnˇe LocNote. 21
5. N ÁVRH Pro vytvoˇrení ikony [Obrázek 5.2] aplikace bylo použito webového generátoru1 . Webový generátor produkuje grafiku zcela zdarma, je omezen na styl CS5 a Web 2.0, což je zcela dostaˇcující, jelikož tvorba grafiky není ústˇredním tématem této práce. Jako hlavní barevný motiv aplikace je zvolen kontrast mezi cˇ ernou, bílou a cˇ ervenou.
Obrázek 5.2: Ikona LocNote aplikace, vytvoˇreno pomocí: icon-generator.net
5.1
Uživatelské rozhraní
Uživatelské rozhraní je založeno na jednoduchosti a pˇrímoˇcarosti. Návrh uživatelského rozhraní byl vytvoˇren programem Balsamiq Mockup. Výhoda tohoto prostˇredí pro tvorbu vzhledu aplikace tkví ve snaze o nezaujatý pohled. Vizuální podoba skici jasnˇe deklaruje snahu o pˇredkládání myšlenek. Nepopiratelným faktem a nepsaným pravidlem je vylouˇcení vývojáˇre od návrhu vzhledu aplikace. Bohužel charakter bakaláˇrské práce vyžaduje samostatnost a tím muselo být pravidlo porušeno, avšak v rámci konzultace s vedoucím práce byl design dukladnˇ ˚ e rˇ ešen. Hlavní aktivita je tvoˇrena dvˇema fragmenty. Uživatel se muže ˚ mezi záložkami pohybovat stisknutím požadované záložky nebo prstem (tzv. gestem swipe). První záložka [Obrázek 5.3a], která je zárovenˇ výchozí, pˇredkládá pˇrehled již vytvoˇrených událostí. Položka v tomto seznamu nese identifikaˇcní data a stav události. Kliknutím na položku se otevˇrou základní informace, pˇri dlouhém stisknutí (tzv. Long-press) se objeví kontextové menu s dalšími možnostmi, co s událostí provést [Obrázek 5.3b]. 1.
K dispozici na icon-generator.net
22
5. N ÁVRH
(a) Hlavní obrazovka aplikace
(b) Kontextové menu události
Obrázek 5.3: Skici návrhu uživatelského prostˇredí, vytvoˇreno pomocí: Balsamiq Mockup Další záložka [Obrázek 5.4a, 5.4b] je urˇcena pro vytváˇrení nových událostí. Fragment pˇredstavuje formuláˇr, jednotlivé cˇ ásti jsou vizuálnˇe oddˇeleny tlaˇcítky. Každé tlaˇcítko má svou urˇcitou funkci vystihující popisek. Duležitým ˚ prvkem je tlaˇcítko „Sdílet skrze“, kde uživatel definuje, jakým zpusobem ˚ chce informovat blízké o své aktivitˇe. Pokud není oznaˇcena volba sdílení pomocí SMS, jsou prvky „Telefonní cˇ ísla“ a „Telefonní seznam“ skryty, pˇri neoznaˇcení volby publikování na sociální síti Facebook, taktéž není zobrazeno tlaˇcítko k pˇrihlášení. Dokud uživatel není pˇrihlášen, není možné vytvoˇrit událost. Další podmínkou pro vytvoˇrení události je správné vyplnˇení všech políˇcek kromˇe „Text události“ a „Telefonní cˇ ísla“. Pro možnost publikování v rámci systému Facebook pˇri dosažení unikátní geografické polohy je uživatel dotazován až pˇri jejím dosažení. Zbytek aplikace je doprovázen stejným motivem a myšlenkou [Obrázek 5.5a, 5.5b]. 5.1.1 Layout Layout [Obrázek 7.1] je XML definice uživatelského rozhraní na platformˇe Android. Jmenný prostor je definován uvnitˇr prvního koˇrenového elementu, kterým bývá RelativeLayout cˇ i LinearLayout. Tyto 23
5. N ÁVRH
(a) Formuláˇr pro vytvoˇrení nové události 1.ˇcást
(b) Formuláˇr pro vytvoˇrení nové události 2.ˇcást
Obrázek 5.4: Skici návrhu uživatelského prostˇredí, vytvoˇreno pomocí: Balsamiq Mockup elementy vˇetšinou v tˇele nesou další tagy a muže ˚ docházet k zanoˇrování. LinearLayout organizuje své potomky jednoduše do horizontálních rˇ ádku˚ nebo vertikálních sloupcu. ˚ RelativeLayout umožnuje ˇ zadání relativní polohy potomka vzhledem k ostatním elementum. ˚ Postavení vuˇ ˚ ci ostatním elementum, ˚ chování a vzhled tagu˚ v XML dokumentu definují zpravidla jejich atributy. Atributy layout_width a layout_height jsou povinné u všech elementu˚ [3]. Další typem tagu˚ jsou ListView a GridView, sloužící jako kontejner pro adaptéry. Tyto elementy výraznˇe zjednodušují práci s reprezentací kolekce dat. Kromˇe nich nalezneme plno elementu˚ pˇredstavujících komponenty uživatelského rozhraní – tlaˇcítka, pole, popisky a nadpisy. Za zmínku také stojí prvek ScrollView, který umožnuje ˇ srolování v pˇrípadˇe, jestliže layout pˇresahuje velikost obrazovky. Tuto základní vlastnost totiž mají pouze zmínˇené kontejnery. Každý layout stojí samostatnˇe ve složce res/layout/ od zdrojových kódu˚ aplikace. Ke spojení dochází v aktivitˇe, typicky v metodˇe onCreate, pˇríkazem setContentView(R.layout.nazev). Programátorská manipulace s prvkem uživatelského rozhraní je podmínˇena existencí 24
5. N ÁVRH
(a) Editace události
(b) Obrazovka pˇri dosažení lokace
Obrázek 5.5: Skici návrhu uživatelského prostˇredí, vytvoˇreno pomocí: Balsamiq Mockup atributu id s unikátním názvem u tohoto XML tagu. Ukázku mužeme ˚ vidˇet zde [Obrázek 7.1], veškeré identifikátory jsou následnˇe generovány a automaticky udržovány ve tˇrídˇe R.java, v adresáˇri gen/, kterou se doporuˇcuje neupravovat [3].
5.2
Vnitˇrní struktura
Vnitˇrní rozvržení systému je podle dobrých zásad z programování Java rozvrženo do balíˇcku. ˚ Každý balíˇcek pˇredstavuje logickou cˇ ást aplikace a shromažd’uje významovˇe podobné tˇrídy. Konvencí pro jméno balíˇcku je obrácená webová adresa, v našem pˇrípadˇe je základním balíˇckem aplikace cz.muni.fi.benda.bachelor. Název balíˇcku v prostˇredí Android navíc slouží jako jednoznaˇcný identifikátor aplikace tj. aplikace, kterou chceme poskytovat v oficiálním obchodˇe, muže ˚ mít stejné oznaˇcení, stejné tˇrídy apod., ale pojmenování balíˇcku musí být odlišné. 5.2.1 Diagram tˇríd Diagram tˇríd pˇrehlednˇe reprezentuje stavbu aplikace [Obrázek 5.6]. Vstupním bodem, který je definován i v manifestu, je tˇrída 25
5. N ÁVRH MainActivity v koˇrenovém balíˇcku. Aktivity jsou duležitou ˚ složkou každé aplikace, slouží jako funkˇcní jednotka, pˇrípadnˇe zastˇrešují fragmenty. V situaci, ve které aktivita poskytuje zázemí pro fragmenty, využívá stránkové adaptéry z balíˇcku „Utils“ a samotné fragmenty z balíˇcku „Fragments“. Balíˇcek „Utils“ dále obsahuje tˇrídu CommonsUtil s pomocnými validátory a syntaktickými analyzátory (slangovˇe parsery). V balíˇcku „Database“ nalezneme tˇrídy pro práci s databází. Komunikaˇcním prvkem a elementární jednotkou v našem systému je tˇrída Event v balíˇcku „Entity“. Event entita je ukládána, tedy rozložena do databáze, pˇrípadnˇe z ní vytahována a složena pro další práci s ní, proto atributy tohoto prvku odpovídají tabulce v databázi. Naše aplikace pro úˇcely registrování požadavku na pˇrijímání geografické polohy a pˇrípadnou reakci na ni využívá vlastní Broadcast Receiver – ProximityIntentReceiver. Pro potˇreby zapnutí služby monitorující stav GPS modulu po startu telefonu existuje další AutostartReceiver taktéž v balíˇcku „Receiver“. Zminovaná ˇ služba GpsService se nachází v balíˇcku „Service“, jediný její úkol je ovˇerˇ ování dostupnosti modulu, pˇrípadné upozornˇení uživatele na nedostupnost modulu a žádost o jeho zapnutí.
26
5. N ÁVRH
Obrázek 5.6: Diagram tˇríd zobrazující vnitˇrní strukturu aplikace, vytvoˇreno pomocí: Visual Paradigm 27
6 Implementace Finální cˇ ástí této práce je samotná implementace zdrojových kódu˚ programu a distribuce aplikace na GooglePlay. Psaní probíhalo v prostˇredí Eclipse Juno s vylepšením Android Development Tools na základech provedené analýzy a návrhu. Toto poskytuje dostaˇcující a pˇríjemné prostˇredí pro tvorbu Android aplikací. Souˇcástí aplikace je taktéž integrace mnohých externích knihoven pro vytvoˇrení uživatelsky pˇrívˇetivého a pˇrirozeného prostˇredí vzhledem k uživatelským zkušenostem.
6.1
Vypracování aplikace
Implementace je provedena v jazyce Java. Nejedná se o klasickou Javu, uplatnuje ˇ se zde pˇredevším Android API, který obsahuje vˇetšinu potˇrebných metod pro práci v prostˇredí Android. Dále využíváme návrhu uživatelského rozhraní založeného na znaˇckovacím jazyku XML. Standardnˇe má Android projekt XML soubor layout, ve kterém každý element pˇredstavuje konkrétní komponentu uživatelského rozhraní (viz sekce Layout). Snadno si jej mužeme ˚ pˇredstavit jako tˇelo a Java implementaci jako orgány pˇrijímající rozkazy a rˇ ídící tˇelo. 6.1.1 Perzistence dat Každé Android zaˇrízení disponuje interním SQLite databázovým systémem, do kterého je možno vytváˇret a následnˇe využívat své vlastní databáze a tabulky. SQLite je, podobnˇe jako operaˇcní systém Android, projektem open-source, který ovšem nezaostává za komerˇcními rˇ ešeními a podporuje standardy relaˇcnˇe entitních databází dnešní doby. Mimo tyto standardy jako klasickou SQL syntaxi, podporu transakcí nebo tzv. prepared statement tedy pˇredpˇripravených pˇríkazu˚ má ohromnou výhodu v nízké spotˇrebˇe pamˇeti, která má u mobilních zaˇrízení rozhodující význam [4]. SQLite databáze podporuje pouze tˇri datové typy. Analogii k rˇ etˇezcum ˚ a znakum ˚ dosáhneme v podobˇe typu TEXT, k celým cˇ íslum ˚ 28
6. I MPLEMENTACE jakými jsou v Javˇe Integer nebo Long typ INTEGER a desetinná cˇ ísla typu Float a Double ve formˇe typu REAL. Konverze datových typu˚ je provádˇena automaticky, ale validace s vloženými daty zde chybí, proto musí vývojáˇr dbát zvýšené obezˇretnosti, aby v dalších fázích vývoje nedocházelo k chybám zpusobených ˚ poˇcáteˇcní nedbalostí. Pro zjednodušení vytváˇrení a otevírání databáze existuje tˇrída SQLiteOpenHelper [Obrázek 7.2]. Vlastního potomka této tˇrídy podle nepsané normy pojmenováváme DbHelper cˇ i DatabaseHelper a implementujeme tˇri jednoduché metody. Konstruktor, který volá svého rodiˇce a pˇredává mu kontext, verzi databáze a jméno databáze. Metoda onCreate, která pomocí SQL dotazu vytvoˇrí tabulku s požadovanými sloupci požadovaného typu. Jedním z nich je atribut _id, který se v prostˇredí Android používá jako primární klíˇc a jeho pojmenování je další nepsanou konvencí. V naší aplikaci se hodnota sloupce _id bude nastavovat automaticky a vytvoˇrí tak syntetický primární klíˇc pro jednoznaˇcné urˇcení totožnosti události. Celkovˇe pro potˇreby aplikace je dostaˇcující jediná tabulka obsahující veškeré informace o události, geografické poloze a stavu. Tˇretí v poˇradí je metoda onUpgrade pro snadnˇejší zavádˇení nových verzí tabulek. Ve skuteˇcnosti k nahrazení stávajících tabulek dochází smazáním (pˇríkazem DROP) a zavoláním metody onCreate [4]. Dále v naší vnitˇrní struktuˇre nalezneme tˇrídu DbManager [Obrázek 7.3], která vytváˇrí logickou vrstvu mezi databází a aplikací, a zárovenˇ sdružuje metody pro pˇrístup k databázi. Pˇri dotazování do databáze není na Androidu zvykem tvoˇrit celý SQL rˇ etˇezec, ale dotaz je realizován voláním specializovaných metod a dosazením žádoucích parametru. ˚ Tímto pˇrípadem je napˇríklad vícenásobnˇe pˇretížená metoda SQLiteDatabase.query, metoda SQLiteDatabase.insert pro vkládání rˇ ádku cˇ i SQLiteDatabase.delete pro smazání záznamu. V naší implementaci, ovšem nalezneme i druhý, ménˇe preferovaný zpusob, ˚ a to vytváˇrením SQL rˇ etˇezcu˚ a voláním metody SQLiteDatabase.rawQuery(String sql, String sqlArgs). Duvody ˚ jsou ryze studijní, za úˇcelem vyzkoušet si dostupné prostˇredky. Mezi hlavní metody tˇrídy DbManager patˇrí createDb pro zpˇrístupnˇení, pˇrípadnˇe vytvoˇrení databáze a closeDb pro uzavˇrení pˇripojení, které 29
6. I MPLEMENTACE je relativnˇe drahé. Metoda getLocNote vrací celou tabulku pro potˇreby zobrazení událostí na hlavní stranˇe. Bez otevˇrení pˇripojení není možné vykonávat pˇríkazy nad databází a je vyhozena systémem adekvátní výjimka. Výsledkem dotazu˚ do databáze bývá entita nazývaná Cursor1 , která je v našem programu zpracována dle úˇcelu metody. Kromˇe individuální databáze v naší aplikaci získáváme informace skrze content provider, konkrétnˇe pro pˇrístup k telefonním kontaktum ˚ uživatele. Poskytovatel obsahu již zde byl zminován, ˇ funguje jako fasáda nad daty, která z ruznorodých ˚ datových úložišt’ zpˇrístupnuje. ˇ Benefit v podobˇe unifikovaného pohledu právˇe na tato úložištˇe výraznˇe ulehˇcuje vývoj. V drtivé vˇetšinˇe se jedná o interní SQLite databáze, ale mužeme ˚ se setkat se soubory apod. Výsledky jsou nám pˇredkládány ve formˇe Cursoru, obdobnˇe jako u databází. Abychom mohli tato data prostˇrednictvím content provideru získat, musíme mít pˇríslušná oprávnˇení k datovým úložištím, definovaná v AndroidManifest.xml. Mimo oprávnˇení musíme znát adresu, tzv. content URI, úložištˇe. Content URI je unikátní a skládá se ze tˇrí cˇ ástí: scheme (schéma), vždy povinnˇe „content://“, authority (autorita), cˇ ást, která ukazuje na úložištˇe, a path (cesta), která identifikuje jednotlivé tabulky popˇrípadˇe záznamy [5]. Aplikace umožnuje uživateli výbˇer zobrazených kontaktu˚ rozlišit dle úložištˇe: SIM karta nebo pamˇet’ telefonu. Akce je podmínˇena oprávnˇením android.permission.READ_CONTACTS uvedeném v manifestu. Aktivita ContactActivity získává metodou Context.getContentResolver entitu ContentResolver, která má stejné rozhraní jako ContentProvider. Na získaném ContentResolveru provedeme SQL dotaz pro získání kontaktu˚ uživatele. Napˇríklad pro získání kontaktu˚ ze SIM karty je využito content URI:„content://icc/adn“. 6.1.2 Prezentace dat Neménˇe duležitou ˚ souˇcástí mobilních aplikací, ihned po zajištˇení perzistence dat, je manipulace s daty a jejich reprezentace. Mani1.
Více na developer.android.com/reference/android/database/Cursor.html
30
6. I MPLEMENTACE pulace cˇ ásteˇcnˇe probíhá ve zminované ˇ tˇrídˇe DbManager, kde metody zpracovávají Cursor získaný z dotazu do databáze a vracejí vhodný výsledek. Není vhodné takovou manipulaci provádˇet až na místˇe potˇreby, kde by docházelo k znepˇrehlednˇení a duplikaci kódu. Další cˇ ásteˇcné zpracování, které nepotˇrebuje pˇrístup do databáze, je provádˇeno v pomocné tˇrídˇe CommonsUtil. CommonsUtil kromˇe validátoru˚ a parseru, ˚ obsahuje metody jako sendSMS pro odeslání SMS zprávy uživateli, v souˇcinnosti s opravnˇením android.permission.SEND_SMS, setupProximityAlert pro zaregistrování broadcast receiveru, isNetworkConnection pro zjištˇení stavu pˇripojení k internetu, startService pro zapnutí služby a mnohé další. V ContactActivity je k vidˇení klasická reprezentace kolekce dat. Získaný Cursor pˇredáváme CursorAdapteru a ten následnˇe nastavíme layoutu pomocí metody ListView.setListAdapter. Abychom mohli takto jednoduše zobrazit nalezené kontakty, je nutné mít v layoutu této aktivity element ListView a aktivitu implementující rozhraní ListActivity. Navíc rˇ ádky seznamu dynamicky mˇení ikonku podle stavu (zaškrtnutí), toho je dosaženo pˇrekrytím metody getView v CursorAdapteru. Tato schopnost zmˇeny souvisí s dosazením vlastního rˇ ádku seznamu a pˇridˇelováním ikonky podle pˇrítomnosti telefonního cˇ ísla v množinˇe vybraných kontaktu. ˚ Aktivita ContactActivity je pouze pomocnou aktivitou, protože nepˇredpokládáme, že by si uživatel pamatoval veškerá telefonní cˇ ísla z hlavy. Klasický pˇrístup je zde dostaˇcující, ale aplikace reflektuje trendy a nové pˇrístupy pˇri tvorbˇe moderních mobilních aplikací, a proto využívá fragmenty. Celkovˇe fragmenty oznaˇcují nový pˇrístup k tvorbˇe uživatelského rozhraní, kdy mezi aktivitu a view (pohled) vstupuje ještˇe jedna vrstva, a to fragment [Obrázek 7.4]. V klasickém pˇrístupu je základním prvkem uživatelského rozhraní aktivita. Každá aktivita má nastavený pohled. Takovýto pˇrístup lze pˇrirovnat k MVC architektuˇre, kde aktivita se stará o funkcionalitu, naslouchá událostem, reaguje na nˇe a plní cˇ i mˇení pohled daty. Layout pouze definuje, jak bude výsledné uživatelské rozhraní 31
6. I MPLEMENTACE vypadat. Fragment má za úkol obalit funkˇcní celek, tedy napˇríklad formuláˇr pˇridávající novou událost. Klasický pˇrístup je jednoduchý a pˇrímoˇcarý, ale neflexibilní a omezující. Fragment s obalenou funkcionalitou se muže ˚ stát souˇcástí jiné aktivity nebo fragmentu na rozdíl od aktivity. Díky tomu mužeme ˚ vytváˇret flexibilní a znovupoužitelné jednotky uživatelského rozhraní. V novém revoluˇcním pˇrístupu každá aktivita muže ˚ zastˇrešovat libovolné množství fragmentu, ˚ které se chovají jako view, ale životní cyklus mají spíše pˇripodobnˇen aktivitˇe. Pˇridání se dá deklarovat v XML layoutu nebo v kódu. Aktivita muže ˚ volat metody, upravovat nastavení fragmentu, ˚ fragmenty naopak pomocí metody Fragment.getActivity mohou volat svého zastˇrešujícího pˇredka. Zavedení tˇechto komponent pˇrišlo od Androidu 3.0, tedy API 11 a masovým rozšíˇrením tabletu. ˚ Prvotním cílem je schopnost pˇrizpusobit ˚ rozhraní jak fyzicky velkým, tak malým displejum ˚ bez duplikace kódu. Ovšem nikdo by fragmenty nepoužíval, kdyby nebyly podporovány v nižších verzích, proto spoleˇcnost Google vydala tzv. Support Library v4. Ta pˇrináší podporu této komponenty od API 4, tedy Android Donut a nastavila kurz, jakým se vývoj Android aplikací uchýlil. V naší aplikaci fragmenty využívají tˇrídy EditActivity a MainActivity, jejich implementace je opravdu prostá. Layout je tvorˇ en elementem View.ViewPager, kterému v aktivitˇe nastavíme adapter a posluchaˇc (listener) pro možnosti reakce pˇresunu mezi fragmenty. Adapter již nastavuje fragmenty, které jsou zobrazeny. MainActivity dynamicky rozhoduje na základˇe pˇrítomnosti asynchronní zprávy intent o tom, který adapter použije, duvodem ˚ jsou problémy ohlednˇe Facebook SDK (viz sekce Facebook SDK). Fragment OverviewFragment tvoˇrí základní pˇrehled již vytvoˇrených událostí a je jako první zobrazován pˇri vstupu do aplikace. Konkrétnˇe se jedná o ListFragment, tedy ekvivalent ListActivity. K naplnˇení ListView dochází v callback metodˇe onCreateView a k nastavení layoutu ovšem dochází trochu odlišným zpusobem ˚ než u aktivit. Cursor je dodán metodou 32
6. I MPLEMENTACE DbManager.getLocNote. Pro seznam událostí ve fragmentu je, taktéž pomocí registerForContextMenu, registrováno kontextové menu, které uživateli poskytuje funkcionalitu vytvoˇrených událostí. Kontextové menu se zobrazí pˇri tzv. dlouhém stisku, pˇri krátkém je uživateli skrze dialogové okno zobrazeno rychlé shrnutí události. Fragment EventFragment de facto slouží jako formuláˇr pro vytvárˇ ení událostí. Jeho chování odpovídá specifikaci z návrhu. Pˇred uložením do databáze jsou hodnoty položek provˇerˇ ovány, telefonní cˇ ísla jsou verifikována regulárním výrazem, aby do databáze byly uloženy pouze: cˇ ísla, znak „+“ a oddˇelovaˇc cˇ árka. Pˇri odesílání SMS jsou pak cˇ ísla pomocí oddˇelovaˇce rozparována a pouze na telefonní cˇ íslo splnující ˇ svˇetový standard MSISDN2 je odeslána textová zpráva. Po úspˇešném uložení do databáze je zavolán CommonsUtil.setupProximityAlert a pˇrípadnˇe publikace na sociální sít’ Facebook. Z tohoto fragmentu muže ˚ dojít k volání zminované ˇ ContactActivity a MyMapActivity pro zvýšení uživatelské pˇrívˇetivosti. Vrácené hodnoty jsou následnˇe zobrazeny v odpovídajících polích. Pokud je dostupná poslední známá poloha zaˇrízení, je automaticky dosazena. Fragment ThanksFragment se zobrazuje v pˇrípadˇe dosažení geografické polohy události po stisku notifikaˇcní zprávy. Obsahuje informace pro uživatele, podˇekování za využívání naší aplikace a možnosti ke sdílení s pˇráteli na Facebooku a ohodnocení naší aplikace na GooglePlay. Je zastˇrešován MainActivity a bud’ dojde k jeho zobrazení, nebo jsou použity pˇredešlé dva fragmenty. Fragmenty BasicFragment a LocationFragment zastˇrešuje aktivita EditActivity. Jsou definované v MyPagerAdapter2 a jejich zobrazení je podmínˇeno akcí „Editovat událost“ v kontextovém menu události. BasicFragment pˇredstavuje popis události, LocationFragment popis geografických informací o poloze. Jakákoli úprava podléhá stejným požadavkum ˚ jako u EventFragment. Možnosti nalezení kontaktu˚ v telefonním seznamu a polohy pomocí mapy jsou taktéž podporovány. 2.
Více na en.wikipedia.org/wiki/MSISDN
33
6. I MPLEMENTACE 6.1.3 Geolokace a upozornˇení na událost Souˇcástí Android specifikace jsou služby pro zjištˇení geografické polohy zaˇrízení, již zminované ˇ location-based services. Tyto služby jsou poskytnuty prostˇrednictvím Android Location API v balíˇcku android.location3 . Toto API zprostˇredkovává aplikaci informace o fyzické poloze zaˇrízení, s kterou muže ˚ dále operovat. Využití této služby je doprovázeno oprávnˇeními v manifestu.xml: ACCESS_FINE_LOCATION, ACCESS_MOCK_LOCATION a ACCESS_COARSE_LOCATION. ACCESS_COARSE_LOCATION oprávnˇením získáme pˇrístup k pˇribližné poloze, která využívá energeticky ménˇe nároˇcných, ale také ménˇe pˇresných technologií, napˇr. mobilní sít’ (GSM) a bezdrátové datové sítˇe. Avšak naše aplikace, dle zadání, využívá pˇresnˇejší GPS, a proto toto oprávnˇení je nedostateˇcné, tedy používáme ACCESS_FINE_LOCATION. Mimo pˇrístupu k pˇribližné poloze, získáváme povolení k použití dat z GPS modulu a pˇresnou polohu zaˇrízení. ACCESS_MOCK_LOCATION slouží pouze k testovacím úˇcelum ˚ pro získání fiktivního lokaˇcního providera. Nejduležitˇ ˚ ejšími prvky Location API jsou tˇrídy LocationManager, LocationProvider, LocationListener a Criteria. Tˇrída Criteria zaobaluje požadavky pro výbˇer vhodného poskytovatele pˇrístupu ke geografickým datum. ˚ Na základˇe nastavených vlastností je vybrán nejvhodnˇejší poskytovatel geolokaˇcních dat (LocationProvider). LocationProvider je abstraktní supertˇrída pro lokalizaˇcní poskytovatele obsahu. Provideˇri provádí a poskytují periodické zjišt’ování aktuální polohy. Dle kritérií a oprávnˇení nebo pˇrímým pˇríkazem LocationManager.getProvider(LocationManager.NAZEV_PROVIDER) je možné získat GPS providera pro pˇresnou polohu nebo Network providera pro pˇribližnou polohu. LocationListener obsahuje callback metody, které jsou volány pˇri zmˇenˇe geografické polohy zaˇrízení. LocationManager zastˇrešuje pˇrístup k celé geolokaˇcní službˇe a umožnuje ˇ získávání lokalizaˇcních provideru, ˚ poslední známé polohy nebo také registraci LocationListeneru [6]. 3. Více na developer.android.com/reference/android/location/package-summary.html
34
6. I MPLEMENTACE Existují dva pˇrístupy k lokalizaˇcním službám a použití Location API na platformˇe Android, aktivní a pasivní. Aktivní spoˇcívá v periodickém vynucovaném dotazování na polohu do doby, než je dosažena. Za tímto úˇcelem je vytvoˇren vlastní LocationListener s pˇrekrytými callback metodami a pomocí LocationManager.requestLocationUpdates registrován požadavek. Druhým, více sofistikovanˇejším, zpusobem ˚ je užití broadcast receiveru. Tento zpusob ˚ nalezneme i v naší aplikaci.
LocationManageru je zaregistrován požadavek, aby informoval systém, vyvolal informaˇcní vlnu pˇri dosažení urˇcité polohy LocationManager.addProximityAlert. Zárovenˇ na tento broadcast registrujeme vlastní broadcast receiver Context.registerReceiver(new ProximityIntentReceiver(), filter). Tímto zpusobem ˚ nenutíme ke kontrole aktuální polohy, ale vyˇckáváme, až bude dosažena. Broadcast recevier slouží jako odpovˇed’ systému na vyvolanou událost. Pˇri odpovˇedi vytváˇríme notifikaˇcní zprávu doprovázenou zvukovými a svˇetelnými signály, dle souˇcasného nastavení mobilu. Následuje odstranˇení požadavku LocationManager.removeProximityAlert, deaktivace události, pˇrípadné odeslání SMS. Pˇri stisknutí notifikaˇcního statusu je otevˇrena LocNote aplikace s informacemi o události plánované na této poloze, podˇekování za vˇernost, eventuálnˇe možnost sdílení na sociální síti Facebook.
Souˇcástí aplikace je taktéž již zmínˇená vlastní služba, MyGpsService, pro kontrolu a pˇrípadné upozornˇení na neaktivní modul GPS. Služba je zavedena z duvodu ˚ komplexnosti našeho zámˇeru upozornˇení uživatele. V pˇrípadˇe, v kterém má vytvoˇrené události, ale nemá zapnutý modul pro pˇrijímání signálu ze satelitu, ˚ dojde k neupozornˇení i pˇres navštívení požadované lokace. Násilné a svévolné povolení této funkce by znamenalo kritické narušení dobrých programátorských zvyku˚ a uživatelských preferencí. Naše aplikace proto v cˇ asových intervalech pˇeti minut žádá o manuální zapnutí modulu GPS nenásilnou formou oznámení na displeji. Toto oznámení není produkováno, pokud není aktivní žádná událost nebo je zapnuta požadovaná funkce. 35
6. I MPLEMENTACE Jestliže služba dosud nebˇeží, je zapnuta v dobˇe vytvoˇrení cˇ i reaktivace neaktivní události. Její ukonˇcení je spojeno se smazáním nebo deaktivací poslední aktivní události. Služba je ovšem vypnuta i pˇri vypnutí mobilního zaˇrízení, ale zpˇetná aktivace není zaˇrízením podporována, proto v implementaci nalezneme další broadcast receiver, AutostartReceiver, který díky oprávnˇení android.permission.RECEIVE_BOOT_COMPLETED reaguje na zapnutí telefonu a pˇri zjištˇení aktivních událostí v databázi provede opˇetovné nastartování služby. 6.1.4 Lokalizace a logování Naše aplikace muže ˚ potenciálnˇe bˇežet v mnoha regionech po celém svˇetˇe. Každý region má jiná specifika, tzv. národní prostˇredí: formát data a cˇ asu, mˇena, samozˇrejmˇe jazyk a jiné. Pˇrizpusobení ˚ aplikace tˇemto národním prostˇredí se oznaˇcuje lokalizace. Každá aplikace má výchozí sadu prostˇredku, ˚ lokalizace se provádí pˇridáním alternativních zdroju˚ a následným pˇrekrytím a modifikací zdrojových souboru. ˚ Konkrétnˇe pˇridáním složky do adresáˇre res/. Formát vypadá následovnˇe: res/zdroj-kód, kde zdroj oznaˇcuje, které prostˇredky budou lokalizovány a kód oblast, zaˇrízení nebo verzi Androidu, pro kterou lokalizujeme. K lokalizaci dochází pˇri spuštˇení aplikace podle hodnoty locale, vždy má pˇrednost nejkonkrétnˇejší zdroj, pˇriˇcemž muže ˚ docházet k doplnˇením z jiného prostˇredku, pokud soubor v aktuálním chybí. Výchozím prostˇredkem je nejrozšíˇrenˇejší komunikaˇcní jazyk, angliˇctina, ale aplikace obsahuje i lokalizaci pro cˇ eštinu. Logování je dobrým programátorským návykem, dobˇre logovaný program poskytne komplexní informace, kde a jakým zpusobem ˚ došlo k chybˇe, pˇrípadnˇe jak je aplikace používána. Logovat bychom mˇeli vstupy, výstupy metod a duležité ˚ akce, které mohou nastat. V prostˇredí Android k logování slouží tˇrída Log s metodami Log.x(tag, zpráva). X je jméno metody a zárovenˇ oznaˇcuje úrovenˇ logu, Log.v neboli verbose je úrovní nejnižší a slouží pˇredevším pro testovací úˇcely. Naopak metoda Log.e znaˇcí vážnou chybu v systému. Parametr tag 36
6. I MPLEMENTACE
Úˇcel prostˇredku Grafika a ikony XML definice UI Texty a styly Multimedia a animace
Základní cesta res/drawable/ res/layout/ res/values/ res/raw/
Pˇríklad res/drawable-cs/ res/layout-720dp/ res/values-cs/ res/raw-small/
Tabulka 6.1: Základní pˇrehled zdroju, ˚ jejich umístˇení a lokalizace je název tˇrídy, ve které se nacházíme, konvencí je tento tag deklarovat jako konstantu. Zpráva je nosiˇc informace o akci, která právˇe probˇehla.
6.2
Využití externích knihoven
Zavedení externích prostˇredku˚ v prostˇredí Eclipse Juno do Android projektu lze provést více zpusoby. ˚ Klasické knihovny musí být v projektu ve složce libs/, následnými kroky: Project -> Properities -> Java Build Path -> Add External JAR dosáhneme pˇridáním požadované knihovny. Do projektu lze pˇridat i jiné projekty a to tˇemito kroky: Project -> Properities -> Android -> Add Project. Náš projekt defaultnˇe používá Support Library v4, abychom dosáhli podpory fragmentu. ˚ Duležité ˚ je, abychom v pˇridaných projektech, které taktéž používají tuto knihovnu, ovˇerˇ ili, pˇrípadnˇe dosadili stejnou verzi. V pˇrípadˇe, že tak neuˇciníme, nedojde ke kompilaci a budeme duraznˇ ˚ e upozornˇeni na odstranˇení tohoto problému. 6.2.1 ActionBar Sherlock Sherlock4 je dosazen jako další projekt. Jeho nasazení je dusledkem ˚ snahy o vylepšení vzhledu a manipulace s aplikací. Pˇrínos projektu je v poskytnutí prvku uživatelského prostˇredí Action bar, umožnˇení gesta swipe k pˇresunu mezi fragmenty a celkovému vzhledu moderních aplikací i pˇresto, že naše aplikace je vytvoˇrena pro verze zaˇcínající Androidem 2.2. 4.
Stránka projektu actionbarsherlock.com
37
6. I MPLEMENTACE Pˇrítomnost tohoto prostˇredku indikuje nahrazení dˇediˇcnosti aktivity z FragmentActivity na SherlockFragmentActivity pˇrípadnˇe fragmentu z Fragment na SherlockFragment. Implementace tˇríd je témˇerˇ nemˇenná, instanci Action baru získáme namísto volání Activity.getActionBar metodou SherlockActivity.getSupportActionBar a další práce je standardní. Pˇresun mezi taby, za pomoci táhnutí prstem, je bˇežným prvkem od API 11, který nám pˇrináší tato knihovna. Vzhled je unifikován do podoby stávajících aplikací. Styl byl ještˇe vylepšen webovými generátory5 pro dodržení barevného schématu aplikace urˇceného v návrhu. Problémem pˇri zavedení vygenerovaného schématu byla podmínka pˇri použití knihovny Sherlock ˇ ActionBar a to použití schématu Theme.Sherlock. Rešení pˇredstavuje nahrazení koˇrenových rozšíˇrení, vygenerovaný styl rozšiˇruje místo klasického Theme.Holo téma Theme.Sherlock. 6.2.2 Facebook SDK Facebook SDK6 [Obrázek 7.5] je též pˇriloženo jako další projekt. Pˇrináší nejvýznamnˇejší rozdíl a konkurenˇcní výhodu v oblasti notifikaˇcních aplikací na základˇe geografické polohy. V dnešní dobˇe se stala komunikace skrze sociální sítˇe velice oblíbenou a uživatelé tyto funkce vyhledávají, bohužel spoleˇcnost Facebook, i pˇres velké snahy, komplikuje vývojáˇrum ˚ integraci této služby do aplikací. Puvodní ˚ verze naší aplikace pracovala s Facebook SDK 2.0, ovšem spoleˇcnost Facebook i kvuli ˚ nástupu jiné filosofie tvorby mobilních aplikací na platformˇe Android v nové verzi, Facebook SDK 3.0, výraznˇe zmˇenila zavedené postupy. S touto zmˇenou došlo k diskreditaci pˇredešlé verze, znepˇrístupnˇení pˇrihlášení a to donutilo vývojáˇre k pˇrechodu na tu nejvyšší, kterou si popíšeme. Po stažení Facebook SDK je nutné aplikaci, která jej bude využívat zaregistrovat. Obojí provedete na stránce uvedené v poznámce pod cˇ arou. Pˇri registraci kromˇe základních údaju˚ narazíte na požadavek o urˇcení jedné komponenty, která bude urˇcena ke komunikaci 5. Konkrétnˇe jgilfelt.github.com/android-actionbarstylegenerator a android-holo-colors.com 6. Stránka projektu developers.facebook.com
38
6. I MPLEMENTACE se sociální sítí a zde muže ˚ nastat problém. Pokud vaše aplikace, jako v našem pˇrípadˇe, komunikuje na více místech, vytvoˇrení události (EventFragment) a dosažení lokace (ThanksFragment), jste pˇrirozenˇe ˇ limitováni. Rešení v naší aplikaci pˇrichází v zaregistrování komunikace na MainActivity, která zastˇrešuje a dynamicky rozhoduje o zobrazených fragmentech, ale oba díky tomu mohou komunikovat se sociální sítí. Další položkou je vyplnˇení Key Hash. Jedná se o hash (otisk) certifikátu tzv. keystore7 , kterým jsou podepisovány aplikace. Vytvoˇrení tohoto otisku se provádí ulitou keytool.exe, která slouží k zajištˇení modularity, autenticity a autentizace. Pˇri komunikaci aplikace se serverem je aplikace vyzvána k verifikaci. Tímto otiskem se ovˇerˇ uje, že je tou, za kterou se vydává. I zde je menší problém. Aplikace jsou pˇri vývoji podepisovány vývojovým debug klíˇcem, ovšem pˇri distribuci je nutné aplikaci podepsat soukromým keystorem vývojáˇre, který má jiný hash, a proto aplikaci pak není umožnˇeno pˇrihlášení k serveru. Toto byl i náš pˇrípad. Jedná se o drobnost, která ovšem není nepodstatná a spoleˇcností Facebook opomíjena. Po vyplnˇení potˇrebných údaju˚ získáme klíˇc pro druhou cˇ ást autentizace naší aplikace tzv. Application ID. Ten je následnˇe použit v manifestu.xml pro zaregistrování aplikace k tomu, že je pˇripravena používat Facebook SDK, umožnit uživateli pˇrihlášení k sociální síti, potažmo vložit pˇríspˇevek na uživateluv ˚ profil. Mimo pˇrihlášení je vyžádáno oprávnˇení android.permission.INTERNET pro pˇrístup na internet. Díky pˇredešlým krokum ˚ jsme si pˇripravili prostˇredí pro použití externí knihovny. Klíˇcovým objektem tohoto API je tˇrída Session. Tato tˇrída umožnuje ˇ autorizaci uživatelu˚ a rˇ ídící prubˇ ˚ eh spojení aplikace se serverem v prubˇ ˚ ehu cˇ asu. Jejím úkolem je reagovat na ruzné ˚ scénáˇre, které mohou nastat. Není v tom však sama, nové Facebook API pˇrináší tˇrídu UiLifecycleHelper, která už podle názvu pomáhá a pˇrebírá rˇ ízení životního cyklu v aktivitˇe nebo fragmentu, ve kterém je použita. K získání této tˇrídy je zapotˇrebí kontextu a entity 7.
Více na developer.android.com/tools/publishing/app-signing.html
39
6. I MPLEMENTACE Session.StatusCallback. StatusCallback je další podstatnou souˇcástí, jelikož reaguje na zmˇeny spojení a vyvolává reakce uživatelského rozhraní. Aby uživatel mohl vubec ˚ pomýšlet na publikaci své události na sociální sítí, je nutné jeho pˇrihlášení. K tomuto kroku je poskytnut element uživatelského rozhraní LoginButton. V podstatˇe jde o rozšíˇrení a modifikaci standardního tlaˇcítka (elementu Button) spoleˇcností Facebook. Ve spojení s instancí UiLifecycleHelper umožnuje ˇ rychlou autentizaci uživatele. Autentizace uživatelem je dvojitá, prvnˇe dojde k pˇrihlášení uživatele a po druhé k potvrzení a získání potˇrebných oprávnˇení pro naši aplikaci. Podle dobrých návyku˚ aplikace vyžaduje jen potˇrebná minimální oprávnˇení, kterým je požadavek na publikaci publish_actions. K publikování dochází po úspˇešném uložení do databáze zavoláním metody publishStory. Metoda ovˇerˇ í, zdali jsme drželi oprávnˇení, pˇripraví potˇrebné materiály k publikování a v novém vláknˇe dojde k odeslání pˇríspˇevku. Po ukonˇcení akce je uživatel informován o jejím výsledku. Ve fragmentu taktéž nalezneme metodu updateUI pro zajištˇení chování požadovaném v návrhu. 6.2.3 Google Maps Google Maps API8 [Obrázek 7.6] je též zaveden jako knihovní projekt. První verze naší aplikace využívala mapy Google Maps Android API v1, které s námi byly pomˇernˇe dlouho, a vývojáˇri si vytvoˇrili zavedené postupy. Avšak s pˇríchodem nového zpusobu ˚ práce a nového elementu fragment, firma Google, po vzoru spoleˇcnosti Facebook, zareagovala vydáním nové verze a starou zapovˇedˇela. Ne zcela, aplikace vytvoˇrené, které s puvodní ˚ verzí fungují, budou fungovat i dnes, ovšem nové již nevytvoˇríte, konkrétnˇe od 18. 3. 2013. Nová verze, Google Maps Android API v2, pˇrináší spoustu zmˇen doprovázených výraznˇe odlišnou integrací a manipulací v mnoha smˇerech. Nutno podotknout, že tyto zmˇeny byly vˇetšinou pozitivního charakteru. Mapy pˇrináší lepší vzhled, více interakce, jsou rychlejší a mají více vestavˇené funkcionality. 8.
Stránka projektu developers.google.com/maps
40
6. I MPLEMENTACE Mapy verze dva jsou novˇe distribuovány jako souˇcást Google Play services SDK, které si stáhneme pomocí SDK manažeru ve vývojovém prostˇredí Eclipse a následnˇe zavedeme jako knihovní projekt. Po zavedení pˇrichází podobná pˇrípravná fáze jako u Facebook SDK, pro umožnˇení pˇrístupu k serverum ˚ spoleˇcnosti Google. První etapou pˇrípravné fáze je registrování projektu a získání potˇrebného klíˇce k autorizaci aplikace. Obojí se provádí na stránce code.google.com/apis/console, po vybrání požadovaného API, Google Maps Android API v2, jsme vyzváni k vložení identifikaˇcních údaju˚ aplikace. V tomto pˇrípadˇe SHA-1 hash otisk privátního klíˇce (fingerprint) našeho keystore certifikátu a jména balíˇcku. Tento otisk taktéž získáme ulitkou keytool.exe a zase slouží k první fázi verifikace naší aplikace. Na rozdíl od pˇredešlé externí knihovny zde jsme ihned upozornˇeni na potˇrebu odlišení fingerprintu keystore certifikátu pro vývoj a distribuci.
Vygenerovaný klíˇc použijeme v druhé etapˇe první fáze k zaregistrování aplikace v manifestu.xml. Registrace je ovšem doprovázena širší modifikací AndroidManifestu.xml. Kromˇe vložení klíˇce, který Maps API posílá serveru pˇri pokusu o spojení, v pˇrípadˇe potvrzení získáváme pˇrístup k Google Maps datum, ˚ musíme vložit následující oprávnˇení. Nejprve si vytvoˇríme vlastní oprávnˇení s názvem MAPS_RECEIVE, které podminuje ˇ využití map autorizaˇcním podepsáním aplikace. Dále ACCESS_NETWORK_STATE pro získání informací o sítovém spojení, které napˇríklad využije API ke stažení informací o poˇcasí v konkrétní lokalitˇe. Speciální com.google.android.providers.permission.READ_GSERVICES, aby API mohlo využít potˇrebných webových služeb. WRITE_EXTERNAL_STORAGE, jelikož nové mapy provádˇejí pˇredbˇežné naˇcítání do pamˇeti a tato data se doˇcasnˇe ukládají do mobilního zaˇrízení. Nesmí chybˇet oprávnˇení k pˇrístupu na internet a je též doporuˇceno pˇripsat oprávnˇení k získání pˇribližné a pˇresné polohy (viz výše). Jelikož nové Google Maps Android API vyžaduje funkci OpenGL ES v2, musíme pˇridat element <uses-feature> jako potomka koˇrenového elementu <manifest>. 41
6. I MPLEMENTACE Celé nové mapy jsou postaveny na tˇrídˇe com.google.android.gms.maps.MapFragment, pˇrípadnˇe SupportMapFragment pro starší verze. Pˇri zavolání klíˇcové metody MapFragment.getMap získáme instanci com.google.android.gms.maps.GoogleMap, s kterou dále pracujeme. Layout je tvoˇren jediným elementem, fragment, odpovídajícím zminovanému ˇ (Support)MapFragment. V mapˇe provádíme pˇridání bodu˚ zájmu, ˚ tzv. markers, jednoduchým voláním GooleMap.addMarker. V našem pˇrípadˇe body zájmu tvoˇrí již vytvoˇrené události, pˇri stisknutí kterékoli z nich získáte informace o plánované aktivitˇe. Mapa slouží pˇredevším k nalezení urˇcitého místa, protože nepˇredpokládáme uživatelskou znalost geografických souˇradnic. Toto místo lze nalézt pomocí implementovaného vyhledávání. Pro lepší orientaci mapa poskytuje tlaˇcítko pro pˇrechod na aktuální pozici v pˇrípadˇe, že tato pozice je známá. Uživatelé také mohou pˇrepínat mezi ruznými ˚ pohledy na mapu, po nalezení požadovaného místa je uživatel vyzván k jejímu potvrzení a následnˇe jsou informace o poloze tohoto místa použity. 6.2.4 Google Analytics Celým oficiálním názvem Google Analytics SDK for 9 Android v2 [Obrázek 7.7] je pˇriložen v podobˇe klasické knihovny do složky /libs. Slouží k online získávání informací o používání aplikace. Vývojáˇri je poskytnuta podrobná a pˇrehledná kolekce dat pro získání reálné pˇredstavy o stavu aplikace na trhu. Pˇrínosnost knihovny je vysoká a integrace v podstatˇe jednoduchá. Pro získání aktivaˇcního klíˇce je zapotˇrebí vlastnit uživatelský úˇcet u spoleˇcnosti Google a registrovat aplikaci na stránce uvedené v poznámce pod cˇ arou. V aplikaci je nutné v manifetu.xml pˇridat oprávnˇení pro pˇrístup na internet a získat informace o stavu sítˇe, ovšem ty jsou vyžadovány již jinými prostˇredky. Pro konfiguraci a rˇ ízení Google 9.
Stránka projektu google.com/analytics
42
6. I MPLEMENTACE Analytics SDK je nezbytné vytvoˇrit ve složce res/values XML dokument analitycs.xml, kde pod názvem ga_trackingId pˇripojíme klíˇc získaný dˇríve. K zasílání informací slouží duležitá ˚ entita EasyTracker, kterou povinnˇe aktivujeme v callback metodˇe onStart pˇríkazem EasyTracker.getInstance.activityStart a deaktivujeme v metodˇe onStop, EasyTracker.getInstance.activityStop, v každé tˇrídˇe ve které jej chceme použít. Po samotném získání entity metodou EasyTracker.getTracker mužeme ˚ dle libosti používat knihovnu k získávání dat o uplatnˇení aplikace. V našem pˇrípadˇe nejˇcastˇeji využíváme metodu EasyTracker.sendEvent a to na veškeré duležité ˚ úkony uživatele.
6.3
Distribuce aplikace
První oficiální aplikace s názvem LocNote byla nasazena 16.3.201310 na nejvˇetší obchod s aplikacemi pro platformu Android, Google Play Store. Google Play Store, dˇríve Android Market, je obchod s digitálním zbožím. Lze skrze nˇej nakupovat písniˇcky, filmy nebo knihy, avšak toto u nás a na Slovensku zatím není podporováno. Mimo Play Store nalezneme plno menších alternativních obchodu, ˚ ovšem tento nabízí rˇ adu výhod. Vˇetšina zaˇrízení jej má nastavený jako výchozí zdroj aplikací a to formou integrace klientské aplikace. Poskytnutí, získání aplikace je jednoduché a i následná aktualizace, pˇrechod na novou verzi není složitý. 6.3.1 Nasazení na GooglePlay Google Play sám o sobˇe zahrnuje okolo jedné miliardy aplikací. Na ruzných ˚ zaˇrízeních po celém svˇetˇe je nainstalováno 25 mld. aplikací a zhruba tˇri cˇ tvrtiny z nich jsou zdarma. Pro zaˇcátek je potˇreba mít založený vývojáˇrský úˇcet, stránka play.google.com/apps/publish. Poté, aby každý nešíˇril cokoliv, zavedla spoleˇcnost Google jednorázový registraˇcní poplatek 25USD, po kterém je vývojáˇri umožnˇena distribuce. Pˇred samotným zveˇrejnˇením je nutné aplikaci zabalit a podepsat a poté nahrát na GooglePlay. 10. K dispozici play.google.com/store/apps/details?id=cz.muni.fi.benda.bachelor
43
6. I MPLEMENTACE Platforma Android vyžaduje, aby všechny instalované aplikace byly digitálnˇe podepsány pomocí certifikátu, jehož soukromý klíˇc je v držení vývojáˇre aplikace. Toto je kontrolováno pˇri nahrávání aplikace na GooglePlay, pokud je aplikace nepodepsána nebo podepsaná nástrojem SDK (zpravidla certifikát debug.keystore) nedojde k nahrání aplikace. Certifikát slouží jako prostˇredek identifikace autora aplikace ke vztahu duvˇ ˚ eryhodnosti aplikace, proto se doporuˇcuje podepisovat všechny své aplikace stejným certifikátem. Standardními nástroji pro generování certifikátu˚ a podepisování jsou ulity keytool.exe a jarsigner.exe, avšak vývojové prostˇredí Eclipse nám pˇrináší rozhraní pro tyto potˇreby.
Postup je následující: pravým tlaˇcítkem klikneme na projekt v seznamu projektu, ˚ který chceme zabalit a podepsat, vybereme Android Tools -> Export Signed Application Package. Pokud nevlastníme dosud vytvoˇrený certifikát, zvolíme Create new keystore. Po vložení názvu a hesla o nejménˇe šesti znacích pokraˇcujeme tlaˇcítkem Next. Zde musíme vytvoˇrit tzv. Alias, taktéž vložením názvu, minimálnˇe šestimístného hesla, požadované platnosti (validity; min. 25 let) a osobních informací. Tímto jsme vytvoˇrili vlastní distribuˇcní certifikát, kterým podepíšeme aplikaci. Je duležité ˚ certifikát neztratit a pamatovat si všechna hesla, v pˇrípadˇe aktualizace aplikace je nutné podepsat stejným klíˇcem. Pokud aplikace je podepsána jiným klíˇcem, pˇrípadnˇe se zmˇenil název balíˇcku, bude GooglePlay aplikaci považovat za odlišnou a nepˇrijme ji.
Podepsanou aplikaci mužeme ˚ zveˇrejnit na Google Play. Pˇri pˇridání musíme zadat jméno aplikace, výchozí jazyk a vybrat si, jestli chceme nejdˇríve nahrát soubor .apk, anebo vyplnit informace o aplikaci. Po nahrání a vyplnˇení povinných informací, napˇr. popisu aplikace, nahrání dvou screenshotu. ˚ Nezbytnˇe musíme urˇcit pro jakou kategorii a pro jaký trh je aplikace urˇcena. Po odsouhlasení licenˇcních podmínek je naše aplikace koneˇcnˇe vystavena svˇetu. 44
6. I MPLEMENTACE 6.3.2 Statistiky Po nasazení aplikace je pˇrirozeným požadavkem vˇedˇet, jak je aplikace používána pro pˇrípadnou optimalizaci funkcionality v další aktualizaci. Ruznorodé ˚ statistiky o používání máme ze tˇrí zdroju. ˚ Spoleˇcnost Facebook umožnuje ˇ vývojáˇri sledovat, kolik uživatelu˚ použilo aplikaci ke sdílení události na svém profilu. Na Google Play Store má vývojáˇr pˇrehled o poˇctu stáhnutí, poˇctu aktivních zaˇrízení apod. a nakonec Google Analytics [Obrázek 6.1] pˇrináší plnohodnotné informace o celkovém využívání aplikace. Naše aplikace byla, dle oficiálních dat z GooglePlay, za uplynulých 40 dní od nasazení 30 krát stažena a má 21 aktivních uživatelu˚ (ti, kteˇrí jí mají nainstaloˇ vanou v telefonu). Kromˇe Ceské republiky byla aplikace stažena na Slovensku a USA. Nejvíce využívanou funkcí je nalezení geografické polohy na mapˇe. Více jak 80% uživatelu˚ otevˇrelo aplikaci více než jednou. Prumˇ ˚ erný poˇcet zobrazených obrazovek za jednu návštˇevu je sedm, prumˇ ˚ erný cˇ as strávený pˇri jedné návštˇevˇe jsou témˇerˇ tˇri minuty.
Poznámka autora: Aktivní uživatelé jsou ti, kteˇrí aplikaci alesponˇ jednou otevˇreli. Je zde zapoˇcítáno i testování aplikace tzn. pˇred nasazení na GooglePlay Obrázek 6.1: Statistika používání z Google Analytics, stáˇrí dat: 20.4.2013
45
6. I MPLEMENTACE 6.3.3 Zpˇetná vazba a testování Pˇred publikací bylo nutné vyzkoušet chování aplikace. Testu se nezávisle na sobˇe zúˇcastnilo 6 dobrovolníku˚ z rˇ ad pˇrátel na ruznorodých ˚ zaˇrízeních. Kromˇe toho bylo využito emulátoru pro vyzkoušení aplikace na všech podporovaných verzích. Cílem bylo ovˇerˇ ení chování aplikace, reakce na neobvyklé situace a kontrola použitelnosti. Úkolem uživatelu˚ bylo projít a proklikat aplikaci, dˇelat vˇeci obvyklým i neobvyklým zpusobem. ˚ Výsledky hodnocení a postˇrehy získané zpˇetnou vazbou byly zahrnuty do finální verze. Testovací osoby si vytvoˇrily bˇehem testu˚ k aplikaci pozitivní vztah, pˇripomínek nebylo mnoho a hodnocení bylo pˇrevážnˇe kladné.
46
7 Závˇer V rámci bakaláˇrské práce byla navrhnuta a implementována mobilní aplikace pro platformu Google Android. Pˇri vypracování bylo nutné osvojení znalostí v rámci programování pro mobilní zaˇrízení, práce s externími knihovnami a programu˚ pro vytvoˇrení podkladu˚ k analýze a návrhu. Práce uskuteˇcnuje ˇ pˇredstavu, a zárovenˇ splnuje ˇ požadavky ze zadání. Bˇehem vývoje byly pˇrekonány veškeré problémy. Aplikace byla podrobena funkˇcnímu a zátˇežovému testování. Výsledkem práce je flexibilní aplikace použitelná v bˇežném životˇe, pˇripomínající svým uživatelum ˚ denní povinnosti na základˇe geografické polohy. Implementace je vedena moderním zpusobem, ˚ zdrojový kód je zárovenˇ snadno cˇ itelný, dokumentovaný a tudíž lehce rozšiˇritelný o další metody. Jako další rozšíˇrení lze navrhnout napˇríklad implementaci o další sociální sítˇe, odesílání upozornˇení pˇres e-mail nebo zavedení a propojení s klasickým cˇ asovým upozornˇením. První verze aplikace vznikla v dobˇe pˇred velkými zmˇenami na platformˇe Android, proto byla po této zmˇenˇe implementovávána znovu, aby podporovala nové technologie a zárovenˇ bylo dodrženo zadání bakaláˇrské práce.
47
Literatura [1] MURPHY, Mark L. Android 2: pruvodce ˚ programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 23. ISBN 978-80-251-3194-7. [2] MURPHY, Mark L. Android 2: pruvodce ˚ programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 288-290. ISBN 978-80-251-3194-7. [3] MURPHY, Mark L. Android 2: pruvodce ˚ programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 41-45. ISBN 978-80-251-3194-7. [4] MURPHY, Mark L. Android 2: pruvodce ˚ programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 230-239. ISBN 978-80-251-3194-7. [5] MURPHY, Mark L. Android 2: pruvodce ˚ programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 262-266. ISBN 978-80-251-3194-7. [6] MURPHY, Mark L. Android 2: pruvodce ˚ programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, s. 298-301. ISBN 978-80-251-3194-7. [7] ELGIN, Ben. Google Buys Android for Its Mobile Arsenal. In: Business week [online]. European ed. [New York, etc.: Bloomberg L.P., etc.], 2005-08-16 [cit. 2013-03-04]. Dostupné z: http://www.businessweek.com/stories/2005-08-16/googlebuys-android-for-its-mobile-arsenal [8] Alliance FAQ. In: Open Handset Alliance [online]. Listopad 2007 [cit. 2013-03-04]. Dostupné z: http://www.openhandsetalliance.com/oha_faq.html [9] Industry Leaders Announce Open Platform for Mobile Devices. In: Open Handset Alliance [online]. 2007-11-05 [cit. 2013-03-04]. Dostupné z: http://www.openhandsetalliance.com/press_110507.html 48
[10] Architecture Overview. In: YouTube [online]. 2007-11-12 [cit. 2013-03-05]. Dostupné z: http://www.youtube.com/watch?v=QBGfUs9mQYY [11] Managing the Activity Lifecycle. Android Developer [online]. [2012] [cit. 2013-03-05]. Dostupné z: http://developer.android.com/training/basics/activitylifecycle/index.html [12] Gingerbread. In: Android Developer [online]. [2012] [cit. 2013-03-05]. Dostupné z: http://developer.android.com/about/versions/android2.3-highlights.html [13] GPS Space Segment. GPS.gov [online]. 2013-02-12 [cit. 2013-0310]. Dostupné z: http://www.gps.gov/systems/gps/space/ [14] GUPTA, Ajay. Google’s Approach of a “_NOMAP” Wi-Fi ZONE. In: Infosecurity magazine [online]. 2011-11-20 [cit. 2013-03-10]. Dostupné z: http://www.infosecuritymagazine.com/blog/2011/11/20/googles-approach-of-anomap-wifi-zone/460.aspx [15] Mobile Technology. GSMA [online]. 2013 [cit. 2013-03-11]. Dostupné z: http://www.gsma.com/aboutus/gsm-technology
49
Pˇríloha A
Elektronická pˇríloha v IS
Souˇcástí této bakaláˇrské práce je taktéž zdrojový kód aplikace. Tento zdrojový kód je dostupný v Informaˇcním systému MU, kam byl vložen pˇri odevzdání této práce.
B
Ukázka Layout
C
Ukázka DbHelper
D
Ukázka DbManager
E
Ukázka Fragment
F
Ukázka Facebook SDK
G
Ukázka Google Maps
H
Ukázka Google Analytics
50
1
3
5
7
9
11
13
15
17
<ScrollView xmlns:android= "http://schemas.android.com/apk/res/android" xmlns:facebook= "http://schemas.android.com/apk/res-auto" android:layout_width="fill_parent" android:layout_height="fill_parent">
<Button android:id="@+id/btn" android:layout_width="fill_parent" android:layout_height="wrap_content" android:text="Tlacitko" /> Obrázek 7.1: Ukázka XML definice uživatelského rozhraní na platformˇe Android
51
2
4
6
8
10
12
14
16
18
20
22
24
public class DbHelper extends SQLiteOpenHelper{ private static final String DATABASE_NAME="db"; public static final String TABLE_NAME="table"; public static final String TEXT="text"; //Basic constructor public DbHelper(Context context) { super(context, DATABASE_NAME, null, 1); } @Override public void onCreate(SQLiteDatabase db) { String str="CREATE TABLE IF NOT EXISTS " +TABLE_NAME +" (_id INTEGER PRIMARY KEY AUTOINCREMENT," +TEXT+" TEXT)"; db.execSQL(str); } @Override public void onUpgrade(SQLiteDatabase db, int oldVersion, int newVersion) { String str="DROP TABLE IF EXISTS "+TABLE_NAME; db.execSQL(str); onCreate(db); } } Obrázek 7.2: Ukázka tˇrídy DbHelper
52
1
3
5
//Pouziti rawQuery public Cursor getLocNote() { String str = "SELECT * FROM " + DbHelper.TABLE_NAME; return (database.rawQuery(str, null)); }
7
9
11
13
15
17
19
21
23
25
27
//Pouziti specializovane insertOrThrow public boolean insertEvent(Event event) { //validation ContentValues cv = new ContentValues(); cv.put(DbHelper.LATITUDE, event.getLatitude()); cv.put(DbHelper.LONGITUDE, event.getLongitude()); cv.put(DbHelper.RADIUS, event.getRadius()); cv.put(DbHelper.NUMBERS, event.getNumbers()); cv.put(DbHelper.STATUS, EventStatus.ACTIVE.name()); cv.put(DbHelper.TITLE, event.getTitle()); cv.put(DbHelper.TEXT, event.getText()); try { database .insertOrThrow(DbHelper.TABLE_NAME, null, cv); return true; } catch (SQLException e) { return false; } } Obrázek 7.3: Pˇríklady dotazu˚ do databáze
53
2
4
6
8
10
12
14
16
18
20
22
24
26
28
30
public class Fragment extends SherlockFragment { private static final String TAG = "Fragment"; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { Log.i(TAG, "onCreateView"); if (container == null) { return null; } View v~= inflater .inflate(R.layout.frag_view, container, false); TextView ttl = (TextView) v.findViewById(R.id.title); ttl.setText("title"); TextView txt = (TextView) v.findViewById(R.id.text); txt.setText("text"); Button rate = (Button) v.findViewById(R.id.btn); rate .setOnClickListener(new View.OnClickListener(){ @Override public void onClick(View v) { Log.i(TAG, "click rate"); doSomething; } }); return v; } } Obrázek 7.4: Ukázka implementace Fragmentu
54
1
3
//Asociace tlacitka pro prihlaseni s~fragmentem LoginButton authButton = (LoginButton) view.findViewById(R.id.fb_login); authButton.setFragment(this);
5
7
9
11
13
15
17
19
//Overovani opravneni pred publikaci Session session = Session.getActiveSession(); if (session != null) { List<String> permissions = session.getPermissions(); if (!isSubsetOf(PERMISSIONS, permissions)) { pendingPublishReauthorization = true; Session.NewPermissionsRequest perm = new Session .NewPermissionsRequest(this, PERMISSIONS); session .requestNewPublishPermissions (newPermissionsRequest); } } Obrázek 7.5: Ukázka práce s Facebook SDK
55
2
4
6
8
10
12
//Ziskani instance GoogleMap googleMap = ((SupportMapFragment) (getSupportFragmentManager() .findFragmentById(R.id.map))).getMap(); //Pridani bodu zajmu LatLng point = new LatLng(45.8587,15.3658); googleMap.addMarker(new MarkerOptions() .position(point).title("TADY") .snippet("Nejlepsi pizza v~Brne")); //Zmena zobrazeni mapy googleMap.setMapType(GoogleMap.MAP_TYPE_TERRAIN); Obrázek 7.6: Ukázka práce s novými Google Maps
56
1
3
5
//Aktivace a~deaktivace pro vybranou aktivitu @Override public void onStart() { super.onStart(); EasyTracker.getInstance().activityStart(this); }
7
9
11
@Override public void onStop() { super.onStop(); EasyTracker.getInstance().activityStop(this); }
13
15
17
//Instanciace objektu EasyTracker //v callback metode onCreate EasyTracker.getInstance() .setContext(getApplicationContext()); EasyTracker tracker = EasyTracker.getTracker();
19
21
//Poslani informace o~udalosti, //konkretne kliknuti na tlacitko tracker.sendEvent("Btn_category", "mapa", "", 0l); Obrázek 7.7: Ukázka práce s Google Analytics
57
