Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Bakalářská práce
Informační systém pro evidenci potápěčských ponorů pro OS Android Jakub Majdl
Vedoucí práce: Ing. Michal Šoch, Ph.D.
15. května 2013
Poděkování Děkuji vedoucímu práce Ing. Michalu Šochovi, Ph.D. a rodině za podporu a pomoc při testování.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Praze dne 15. května 2013
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Jakub Majdl. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Majdl, Jakub. Informační systém pro evidenci potápěčských ponorů pro OS Android. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.
Abstract The goal of this work is to analyze, design and implement an application for mobile devices running Android, which will be used as a diving logbook. It is an alternative to the classical paper logbook with additional features, which are for example based on integration with the Google Maps API and Dropbox API. Keywords diving logbook, Android, Google Maps API, Dropbox API
Abstrakt Cílem práce je analyzovat, navrhnout a realizovat aplikaci na mobilní zařízení s OS Android, která bude sloužit jako potápěčský deník. Jedná se o alternativu ke klasickému papírovému deníku, která má další funkce, které vycházejí například z integrace s Google Maps API a Dropbox API. Klíčová slova potápěčský deník, potápěčský logbook, Android, Google Maps API, Dropbox API ix
Obsah Úvod
1
1 Rešerše existujících řešení 1.1 Diver’s Log . . . . . . . 1.2 Diving LogBook . . . . . 1.3 Dive Log . . . . . . . . . 1.4 Easy Diver . . . . . . . .
. . . .
3 3 6 6 8
. . . . . . .
11 11 13 16 20 24 24 25
. . . .
27 27 31 33 33
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
2 Analýza a návrh 2.1 Analýza požadavků . . . . . . . . . . . . . 2.2 Případy užití . . . . . . . . . . . . . . . . 2.3 Prototyp . . . . . . . . . . . . . . . . . . . 2.4 Operační systém Android . . . . . . . . . 2.5 Webové úložiště Dropbox . . . . . . . . . . 2.6 Mapové podklady Google Maps . . . . . . 2.7 Použité vývojové prostředí a další nástroje 3 Realizace 3.1 Základní součásti aplikace 3.2 Popis tříd . . . . . . . . . 3.3 Ukládání dat . . . . . . . 3.4 Požadavky aplikace . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
. . . .
. . . . . . .
. . . .
4 Testování 35 4.1 Uživatelské testování . . . . . . . . . . . . . . . . . . . . . . 35 4.2 Chyby a možnosti řešení . . . . . . . . . . . . . . . . . . . . 36 xi
5 Další vývoj
39
Závěr
41
Literatura
43
A Seznam použitých zkratek
47
B Snímky aplikace
49
C Diagramy případů užití
51
D Obsah přiloženého CD
55
xii
Seznam obrázků 1.1 1.2 1.3 1.4 1.5
Papírový potápěčský deník Aplikace Diver’s Log . . . Aplikace Diving LogBook Aplikace Dive Log . . . . Aplikace Easy Diver . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
4 5 7 8 9
2.1 2.2 2.3 2.4 2.5 2.6
Případy užití - celkový pohled . . . . . . . . . . Prototyp - úvodní obrazovka . . . . . . . . . . . Prototyp - obrazovky výpisů . . . . . . . . . . . Prototyp - obrazovky přidání a úpravy záznamů Prototyp - obrazovky detailu záznamu . . . . . OS Android - podíl verzí . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
14 17 18 19 20 22
3.1 3.2 3.3
Aktivity - diagram zásobníku . . . . . . . . . . . . . . . . . . . Aktivity - životní cyklus . . . . . . . . . . . . . . . . . . . . . . Databáze - schéma . . . . . . . . . . . . . . . . . . . . . . . . .
28 29 34
B.1 Snímky aplikace - úvodní obrazovka a výpis ponorů . . . . . . . B.2 Snímky aplikace - úprava ponoru a mapa . . . . . . . . . . . . . B.3 Snímky aplikace - úvodní obrazovka na tabletu . . . . . . . . .
49 50 50
C.1 Případy užití - správa ponorů . . . . . . . . . . . . . . . . . . . C.2 Případy užití - správa lokalit . . . . . . . . . . . . . . . . . . . . C.3 Případy užití - správa výstroje . . . . . . . . . . . . . . . . . . .
52 53 54
xiii
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Úvod Cílem této bakalářské práce je analyzovat, navrhnout a realizovat aplikaci na mobilní zařízení s OS Android, která bude fungovat jako potápěčský deník. Potápěčský deník slouží pro potápěče jako nástroj pro evidenci detailů o svých ponorech. Potápěč by si měl vždy po uskutečněných ponorech zapsat některé důležité informace o nich. Potápěčský deník tedy vypovídá zejména o zkušenostech daného potápěče, což může být využito například při dalším zvyšování jeho kvalifikace. Přestože je v dnešní době trend přesouvat všechny věci do elektronické podoby, stále ještě velké množství potápěčů využívá klasickou papírovou podobu deníku, kterou lze lehce ztratit nebo zničit. Jelikož ale v dnešní době nadále velmi roste obliba mobilních zařízení, ať už chytrých telefonů nebo tabletů, a díky některým nesporným výhodám elektronické podoby deníku je velmi pravděpodobné, že velká část z těchto potápěčů přejde například právě na deník v podobě aplikace na mobilní zařízení. Naprostá většina z těchto mobilních zařízení využívá buď platformu Android od společnosti Google, nebo platformu iOS od společnosti Apple. Přestože jsou to obě velmi rychle rostoucí platformy, Android má stále velký náskok před iOS co se týče počtu uživatelů, zejména díky mnohem lepší dostupnosti pro běžné lidi. Android nalezneme jak v obyčejných levných telefonech, tak v dražších výkonných zařízeních. Proto jsem se rozhodl právě pro ni, jako cílovou platformu aplikace. Díky tomu se může aplikace dostat k co nejvíce lidem. Vzhledem k tomu, že žádná potápěčská směrnice nestanovuje závaznou formu a obsah deníku, máme velkou svobodu při tvorbě nového deníku. Takže kromě základních údajů o ponoru, jako je místo, datum, délka, maximální hloubka apod., můžeme evidovat i souřadnice místa ponoru, získané například pomocí GPS, a následně je využít k zobrazení v integrované mapě. 1
Úvod Také můžeme evidovat použitou potápěčskou výstroj a její detaily. V samotných záznamech je možné velmi lehce vyhledávat podle různých kritérií, nebo si uživatel může zobrazit své statistiky. Kromě samotného zapisování ponorů je také důležité zálohování, kde uživatel má možnost udělat zálohu jednoduše na paměťovou kartu nebo může využít propojení s webovým úložištěm Dropbox.
2
Kapitola
Rešerše existujících řešení Jak jsem již v úvodu nastínil, potápěčské deníky můžeme v dnešní době rozdělit do dvou základních skupin - klasické papírové a elektronické. Papírový deník je většinou blok s předtištěnou šablonou, kam můžeme vepsat základní údaje o ponoru, viz obrázek 1.1. Už z tohoto popisu můžeme jasně vidět základní nevýhody oproti elektronické podobě deníku - omezená kapacita a možnost případného poškození nebo ztráty a z toho plynoucí ztráta veškerých zapsaných dat, čemuž můžeme u elektronické varianty předejít pomocí pravidelného zálohování. Elektronickou podobu můžeme dále rozdělit například na webové aplikace, aplikace na osobní počítače nebo aplikace na mobilní zařízení, na které se v rešerši zaměřím. Pro rešerši jsem vybral čtyři z nejoblíbenějších potápěčských deníků na OS Android umístěných v Google Play, tedy standardní distribuční službě na této platformě. Výsledek rašerše bude využit při návrhu aplikace.
1.1
Diver’s Log
Diver’s Log2 je velice jednoduchá aplikace, která pokrývá pouze základní funkčnost deníku - vkládání, úpravu a mazání záznamů. Narozdíl od jiných deníků obsahuje navíc možnost evidovat u záznamu ponoru použitou potápěčskou výstroj. Bohužel lze ale vybrat pouze výstroj z předpřipraveného seznamu, který nemusí být pro každého dostačující, jak i naznačují komentáře u aplikace na Google Play. Mezi velké nedostatky aplikace patří nemožnost vytváření zálohy dat a následného obnovení. 2
https://play.google.com/store/apps/details?id=com.archerzz.diveLog
3
1
1. Rešerše existujících řešení
Obrázek 1.1: Ukázka stránky papírového potápěčského deníku1 .
4
1.1. Diver’s Log
Obrázek 1.2: Aplikace Diver’s Log
1.1.1
Výhody
• Jednoduchost a přehlednost.
1.1.2
Nevýhody
• Chybí možnost vytvářet zálohu dat. • Přestože se jedná o poměrně jednoduchou aplikaci a v nabídce Google Play se nachází několik let, obsahuje řadu chyb.
1
http://www.snorchl.cz/knihy-logbook/denik-potapece-logbookdetail.html
5
1. Rešerše existujících řešení
1.2
Diving LogBook
Diving LogBook3 nabízí kromě klasických funkcí potápěčského deníku také integraci s mapami, možnost zálohování na paměťovou kartu a zobrazení statistik ponorů. Je zde také umožněna evidence potápěčských lokalit, lokalitu si ale nelze samostatně zobrazit na mapě. Další nedostatek u integrace s mapami je, že se na mapě zobrazují pouze značky, nevíme však, který ponor odpovídá které značce. Aplikace je také propojena s webovou stránkou www.divinglogbook.it, kde můžou potápěči sdílet své ponory.
1.2.1
Výhody
• Jednoduché a přehledné grafické rozhraní. • Integrace map. • Možnost sdílet ponory přes webovou stránku.
1.2.2
Nevýhody
• Reklamní bannery a vnucování úvodní stránky s Donate tlačítkem. • Nemožnost evidovat u ponoru použitou potápěčskou výstroj. • Každý zápis ponoru musí obsahovat souřadnice, jinak se zobrazí na mapě na nesmyslných souřadnicích.
1.3
Dive Log
Dive Log4 se od ostatních odlišuje zejména možností zápisu osobních dat o potápěči včetně evidence certifikací a členství v potápěčských klubech. Jedná se však o placenou aplikaci, zdarma je pouze zkušební verze, která je omezena na 5 zapsaných ponorů. Aplikace také nabízí integraci s mapami, zálohování a možnost exportu do souboru CSV. 3
https://play.google.com/store/apps/details?id= it.studionovesei.divinglogbook 4 https://play.google.com/store/apps/details?id=com.shuffledbits.divelog
6
1.3. Dive Log
Obrázek 1.3: Aplikace Diving LogBook
1.3.1
Výhody
• Možnost uložení osobních informací. • Integrace map. • Pěkné grafické rozhraní.
1.3.2
Nevýhody
• Zdarma pouze zkušební verze na 5 ponorů. • Ne velmi intuitivní grafické rozhraní. • Chybí možnost evidovat potápěčské lokality, u každého ponoru musíme všechny údaje o lokalitě vyplňovat znovu.
7
1. Rešerše existujících řešení
Obrázek 1.4: Aplikace Dive Log
1.4
Easy Diver
Easy Diver5 kromě základní funkčnosti nabízí také integraci s mapami, zálohování, statistiky ale i základní potápěčskou kalkulačku. Tato aplikace je sice zadarmo, vynahrazuje si to ale reklamními bannery po celé aplikaci. Využití integrované mapy je ale velmi omezené, protože si na ní můžeme zobrazit vždy pouze jeden zvolený ponor, není tak třeba možné vyhledávat ponory podle mapy.
1.4.1
Výhody
• Základní potápěčská kalkulačka. • Integrace map. 5
8
https://play.google.com/store/apps/details?id=org.android.easydiver
1.4. Easy Diver
Obrázek 1.5: Aplikace Easy Diver
1.4.2
Nevýhody
• Reklamní bannery v aplikaci. • Omezené využití integrace s mapou. • Není možné nastavit souřadnice pomocí GPS.
9
Kapitola
Analýza a návrh 2.1
Analýza požadavků
Analýza funkčních požadavků slouží k vymezení hranic systému, jaké všechny funkce má systém mít. Požadavky zachycují také omezení, které jsou na systém kladeny. Požadavky se dají rozdělit do dvou základních skupin funkční a nefunkční požadavky. Funkční požadavky právě definují veškerou funkčnost aplikace, nefunkční specifikují omezení kladená na samotnou aplikaci nebo na proces vývoje, například tedy na jaké platformě má aplikace fungovat. Nejdříve byl proveden sběr požadavků, které vyplývají ze zadání práce. Tyto požadavky byly následně doplněny o další získané při řešerši podobných aplikací a ze zkušenosí jejich uživatelů.
2.1.1
Funkční požadavky
• Evidence ponorů s následujícími údaji: datum, čas, lokalita, teplota vzduchu a vody, viditelnost ve vodě, typ vody - sladká nebo slaná, doba ponoru, maximální hloubka, buddy - člověk, se kterým byl ponor proveden, dodatečná váha, objem láhve, použitá dýchací směs, koncentrace O2 - pokud je jako dýchací směs vybrán Nitrox, počáteční a koncový tlak v láhvi, použitá potápěčská výstroj a poznámka. • U evidovaných ponorů jsou údaje datum, čas a lokalita povinné. • Lokalita se u záznamu ponoru vyplňuje pomocí výběru ze seznamu uložených lokalit, případně je možno rovnou vytvořit novou lokalitu. 11
2
2. Analýza a návrh • Evidence potápěčských lokalit s následujícími údaji: název lokality, země ve které se lokalita nachází, zeměpisné souřadnice (šířka a délka) a popis. • U evidovaných lokalit je povinný pouze název lokality, který musí být v rámci názvu ostatních lokalit unikátní. • Vkládání zeměpisných souřadnic u záznamu lokality je možné vepsáním souřadnic do polí, kliknutím na místo na mapě, pomocí modulu GPS, pokud ho mobilní zařízení obsahuje, nebo pomocí informací získaných z internetu nebo mobilní sítě. • Potápěčská výstroj se k záznamu ponoru připojuje pomocí výběru ze seznamu již uložené výstroje, kdy je možné označit více záznamů najednou, nebo je možné vytvořit nový záznam výstroje. • Evidence potápěčské výstroje, která kromě názvu, který je povinný a musí být unikátní, obsahuje jen případný popis. • Ve výpisech všech uložených ponorů, lokalit nebo výstroje je možné vyhledávat. U výpisu ponorů je možné vyhledávat podle datumu nebo názvu a země lokality ponoru, u výpisu lokalit podle názvu a země lokality a u výpisu výstroje podle jejího názvu. • Výpis uložených ponorů nebo lokalit, případně vyfiltrovaný pomocí vyhledávání, stejně tak jako jeden konkrétní ponor nebo lokalitu je možné zobrazit jako značku(y) na mapě. Ale pouze pokud jsou vyplněny souřadnice. • Na značky na mapě je možné kliknout a zobrazit tak stručné informace o dané lokalitě, při dalším kliknutí se zobrazí plnohodnotný detail lokality. • Aplikace umožňuje vypočítat a zobrazit základní statistiky o uložených ponorech: počet ponorů, v kolika různých lokalitách, celková doba ponorů, průměrná a maximální doba ponoru, průměrná a maximální hloubka a nejpoužívanější dýchací směs. • V aplikaci je možné nastavit jednotky u jednotlivých údajů. Nastavení jednotek bude ovlivňovat pouze nově vkládané ponory. Jednotky je možné nastavit jednotlivě nebo je nastavit všechny najednou výběrem mezi metrickými a imperiálními, vyjimkou je nastavení objemu, to je na tomto nezávislé. 12
2.2. Případy užití • Veškerá data uložená v aplikaci je možné zálohovat. Buď je možné zálohu provést na paměťovou kartu v zařízení nebo využít služeb webového úložiště a soubor se zálohou nahrát tam. • Po prvním propojení s účtem na webovém uložišti si aplikace uloží údaje o propojení a uživatel se již nemusí znovu přihlašovat.
2.1.2
Nefunkční požadavky
• Aplikace je funkční na OS Android verze 2.2 a vyšší. • Přehledné a intuitivní GUI. • Podpora všech velikostí obrazovek - od malých chytrých telefonů po velké tablety. • Podpora více jazykových verzí a jednoduché přidání dalších překladů. Aplikace je z počátku v češtině a angličtině, angličtina je výchozí. • Aplikace respektuje regionální nastavení zařízení - například při zobrazení datumu.
2.2
Případy užití
Případy užití se využívají k popisu funkčnosti systému z pohledu uživatelů. Případy užití byly vytvořeny na základě analýzy požadavků tak, aby pokryly všechny pažadavky. Systém obsahuje jedinou uživatelskou roli, nazvanou uživatel. Z případů užití byl sestaven UML diagram, který je všechny zachycuje i s jejich vzájemnými vazbami. Digram byl pro přehlednost rozdělen na více částí: celkový pohled - obrázek 2.1, detailní pohledy na správu ponorů, lokalit a výstroje jsou v příloze - C.1, C.2, C.3. Níže jsou slovně popsány nejdůležitější z nich.
2.2.1
Přidání ponoru
Uživateli se zobrazí fomulář, kde vyplní údaje o uskutečněném ponoru a stiskne tlačítko uložit ponor. Aby byl ponor úspěšně uložen, musí být minimálně vyplněná povinná pole - datum, čas a lokalita. Jelikož jsou pole datum a čas předvyplněná aktuálními hodnotami, stačí vyplnit lokalitu. Lokalita se vyplní pomocí vybrání lokality v dialogovém okně, případně vytvořením nového záznamu lokality. Kromě povinných polí může uživatel 13
2. Analýza a návrh
Obrázek 2.1: Diagram případů užití - celkový pohled
14
2.2. Případy užití libovolně vyplnit ostatní údaje a připojit použitou potápěčskou výstroj, kterou vybírá pomocí dialogového okna, případně může vytvořit nový záznam výstroje. Zároveň má uživatel možnost ihned z formuláře přejít k úpravě připojené lokality nebo potápěčské výstroje.
2.2.2
Úprava uloženého ponoru
Umožňuje uživateli upravit údaje u již dříve vloženého ponoru. Uživateli se zobrazí stejný formulář se stejnými možnostmi jako při přidávání ponoru, ale s vyplněnými hodnotami z uloženého ponoru. Po dokončení úprav uživatel stiskne tlačítko uložit ponor, nebo stiskne tlačítko zpět, pokud změny nechce uložit.
2.2.3
Vytvoření zálohy
Uživatel touto funkcí může vytvořit soubor obsahující zálohu veškerých dat uložených v systému, kromě aktuálního nastavení jednotek - nastavení jednotek v uložených ponorech záloha obsahuje. Uživatel si může vybrat, kam se vytvořený soubor umístí, zda na paměťovou kartu zařízení nebo se nahraje do webového úložiště Dropbox. Pro možnost nahrání souboru na Dropbox je nejdříve nutné mít aplikaci propojenou s účtem na serveru Dropbox. O konkrétním umístění souboru se zálohou na paměťové kartě či Dropboxu je uživatel informován při jejím vytváření.
2.2.4
Obnovení zálohy
Tato funkce slouží k obnovení dat ze souboru vytvořeného při zálohování. Uživatel má stejně jako při zálohování na výběr, zda obnovit data ze souboru uloženého na paměťové kartě či z webového úložiště. Při obnovení je soubor se zálohou očekáván na stejném místě jako byl vytvořen při záloze. Před samotným obnovením zálohy je provedena validace souboru se zálohou. Pokud soubor neobsahuje validní zálohu dat, obnovení je přerušeno a uložená data zůstanou nedotčena. Pokud je soubor se zálohou validní, data z něj nahradí data uložená v aplikaci.
2.2.5
Nastavení jednotek
Uživatel si může nastavit jednotky, které se zobrazují u jednotlivých údajů u ponoru. Změna tohoto nastavení ovlivňuje pouze nově vytvářené záznamy, již uložených záznamů se tato změna nedotkne. Uživatel má dvě možnosti, 15
2. Analýza a návrh jak může jednotky nastavit - může obecně nastavit metrické případně imperiální jednotky, nebo si jednotlivé jednotky nastaví sám.
2.3
Prototyp
Na základě analýzy požadavků a následně případů užití byl vytvořen následující prototyp uživatelského rozhraní. Jedná se pouze o návrh uživatelského rozhraní sloužícího k jeho otestování, proto je bez obrázků a barev - důležité je rozmístění prvků. Tento prototyp nám umožní otestovat uživatelské rozhraní a nalézt případné nedostatky před započetím samotné implementace. Pro vytvoření prototypu byl využit program Pencil[5], který umožňuje prototyp vyexportovat jako webovou stránku. V té můžeme využít další důležité vlastnosti prototypu - interaktivity. Prvkům na jednotlivých obrazovkách prototypu lze přiřadit odkaz na jinou obrazovku protypu. Díky tomu lze u prototypu docílit chování velmi podobné chování výsledné aplikace. Ačkoliv se u výsledné verze aplikace počítá s více verzemi uživatelského rozhraní v závislosti na verzi OS Android, jejich rozdíl však nebude natolik velký, aby mělo smysl vytvářet více prototypů. Tento prototyp zachycuje rozhraní pro verze OS Android do verze 3.0, kdy se pro zobrazení menu využívá hardwarové tlačítko menu.
2.3.1
Úvodní obrazovka
Úvodní obrazovka se uživateli zobrazí po spuštění aplikace. Obsahuje logo aplikace s jejím názvem, výpis několika posledních ponorů a tlačítka na nejpoužívanější funkce. Tato obrazovka slouží jako rozcestí mezi jednotlivými částmi aplikace. V menu této obrazovky se nachází odkazy na výpisy ponorů, lokalit a výstroje, na zobrazení statistik, na obrazovku s možností zálohování a nastavení aplikace a na obrazovku s informacemi o aplikaci. Odkazy na nejvyužívanější funkce aplikace - vložení nového ponoru a výpis uložených ponorů, jsou umístěny také přímo na obrazovce tak, aby byly jednoduše a rychle přístupné. Výpis několika posledních ponorů na obrazovce vybírá z databáze uložených ponorů nejnovější ponory podle data uskutečnění, ne podle data vložení do systému. Počet ponorů, které se zobrazí, je vypočten v závislosti na velikosti obrazovky zařízení. Ponor je ve výpisu reprezentován základními údaji o něm - datum a čas ponoru plus název a země lokality, kde byl ponor proveden. 16
2.3. Prototyp
Obrázek 2.2: Úvodní obrazovka
2.3.2
Výpisy ponorů, lokalit a výstroje
V aplikaci se nachází tři obrazovky pro výpis záznamů z databáze - výpis ponorů, lokalit a výstroje. Všechny tyto výpisy umožňují filtrování záznamů podle různých kritérií pro jednodušší vyhledávání při větším objemu vložených dat. Ve výpisu ponorů je možné filtrovat záznamy podle názvu či země lokality, nebo dle data ponoru. Při filtrování podle data ponoru není nutné zadávat celé datum, stačí zadat například jen rok, měsíc nebo den, případně jakoukoliv jejich kombinaci. Ve výpisu lokalit a výstroje je možné filtrovat záznamy podle jejich názvu, případně podle země u lokality. Ve výpisech ponorů a lokalit je navíc ještě možnost zobrazit celý, případně vyfiltrovaný, seznam na mapě.
2.3.3
Přidání a úprava záznamů
Tyto obrazovky obsahují formuláře pro vytvoření nových či úpravu již uložených záznamů - ponorů, lokalit nebo výstroje. Formuláře obsahují pole pro vyplnění jednotlivých údajů, případně tlačítka, kterými se dají zjednodušeně vyplnit, a ve spodní části obsahují tlačítko pro uložení. Formulář pro záznam ponoru obsahuje pole datum a čas spojená s tlačítky, která otevřou speciální dialogová okna pro jednoduché nastavení 17
2. Analýza a návrh
Obrázek 2.3: Obrazovky výpisů
těchto polí. Dále pole lokalita je vyplňováno pomocí tlačítka, které otevře dialogové okno se seznamem všech uložených lokalit, ze kterých si uživatel může vybrat, případně se v dialogu nachází tlačítko na vytvoření nového záznamu lokality, která je poté automaticky připojena k ponoru. Obdobně funguje připojování výstroje k záznamu ponoru, v dialogovém okně se seznamem veškeré výstroje má uživatel možnost vybrat více položek najednou a následně potvrdit, stejně tak se v dialogu nachází tlačítko na vytvoření nového záznamu výstroje. Pokud chce uživatel již připojenou výstroj odebrat, klikne na malé tlačítko vedle názvu výstroje ve formuláři ponoru. Formulář pro záznam lokality obdobně obsahuje dvě tlačítka, přičemž obě souvisí s poli pro zeměpisné souřadnice lokality. První z nich slouží k nastavení souřadnic podle informací získaných z modulu GPS, případně podle informací ze sítě - mobilní nebo Wi-Fi. Další tlačítko slouží k nastavení souřadnic pomocí mapy. Po stisknutí tlačítka se uživateli zobrazí mapa, na níž uživatel umístí značku, souřadnice této značky se následně přenesou do polí ve formuláři.
2.3.4
Detail záznamu
Tyto obrazovky slouží k zobrazení všech údajů uložených u jednotlivých záznamů - ponorů, lokalit nebo výstroje. U detailů lokality a výstroje nalezneme pole s počtem ponorů, se kterými jsou spojené. Po kliknutí na 18
2.3. Prototyp
Obrázek 2.4: Obrazovky přidání a úpravy záznamů
toto pole se zobrazí dialogové okno s podrobným výpisem těchto ponorů. V menu se nachází tlačítka s možností přejít na formulář pro úpravu těchto záznamů, také se zde nachází tlačítko pro odstranění tohoto záznamu z databáze, u ponoru a lokality se zde také nachází možnost zobrazit daný záznam na mapě.
2.3.5
Nastavení
Na této obrazovce má uživatel možnost vytvořit zálohu dat v aplikaci buď na paměťovou kartu v zařízení nebo na webové úložiště Dropbox a také z již dříve vytvořené zálohy data obnovit. Kromě zálohování má zde uživatel možnost nastavit jednotky, které se zobrazují u jednotlivých údajů o ponoru. Uživatel může nastavit jednotky obecně - zvolit metrické případně imperiální, nebo si může všechny jednotlivé jednotky nastavit zvlášť. 19
2. Analýza a návrh
Obrázek 2.5: Obrazovky detailu záznamu
2.4
Operační systém Android
Android je rychle se rozvíjející open source platforma určená zejména pro mobilní zařízení s dotykovými obrazovkami (chytré telefony a v poslední době také tablety). Momentálně se jedná o nejrozšířenější mobilní platformu na světě s více než 38% podílem na trhu a nadále roste[27]. Platforma se skládá z jádra, postaveného na Linuxovém jádru, s middleware, knihovnami a API napsanými v jazyce C a z aplikací napsaných v jazyce Java, které běží na aplikačním frameworku, který obsahuje knihovny jazyka Java[22].
2.4.1
Historie
Android byl původně vyvíjen společností Android Inc. od října 2003, kdy byla společnost založena. Původním záměrem společnosti bylo vyvinout pokročilý operační systém pro digitální kamery, záhy si ale uvědomili nedostatečnou velikost tohoto trhu a přesměrovali se na vývoj operačního systému pro chytré telefony, jako konkurenci pro Symbian a Windows Mobile. V srpnu 2005 byla tato společnost jako nepříliš známá odkoupena společností Google Inc. a stala se její dceřinou společností. Po odkoupení se týmu Googlu pod vedením Andyho Rubina, jednoho ze zakladatelů původní společnosti Adnroid Inc., podařilo vyvinout platformu postavenou na Linuxo20
2.4. Operační systém Android vém jádře[22]. Google začal jednat s výrobci mobilních telefonů a s telekomunikačními operátory o poskytnutí této platformy. 5. listopadu 2007 bylo vytvořeno uskupení Open Handset Alliance (OHA) skládající se z 34 významných společností - výrobců mobilních telefonů, telekomunikačních operátorů a technologických firem, jejichž cílem bylo vytvořit otevřený standard pro mobilní zařízení. Od té doby OHA neustále roste, dnes se již skládá z 84 společností. Ve stejný den, jako bylo uskupení OHA založeno, byl ohlášen Android jako jejich první produkt. O pár dní později byla vydána první beta verze Android SDK[25]. První komerční telefon s OS Android byl na trh uveden 22. listopadu 2008 s názvem HTC Dream. Od té doby Android neuvěřitelně rychle roste, z mobilních telefonů se rozšířil na tablety, netbooky a další zařízení. V dnešní době se nachází na více než 200 mobilních telefonech, 30 tabletech a řadě dalších zažízení, celkově na více než 280 různých zařízení od více než 40 výrobců[24].
2.4.2
Výhody OS Android
Jako cílovou platformu pro tuto práci byl zvolen právě OS Android. Zde jsou vypsány některé nejdůležitější výhody, které má OS Android oproti konkurenci, jako například iOS či Windows Phone. • Rozšířenost - je asi největší výhodou této platformy. Jedná se momentálně o nejrozšířenější platformu na trhu s více než 38% podílem na trhu a nadále jeho podíl roste. Vděčí za to zejména své dostupnosti OS Android nalezneme na velmi levných a zároveň i na velmi drahých a výkonných mobilních telefonech. Naopak například Windows Phone má pouze 1% podíl na trhu a i jeho růst je mnohem pomalejší než v případě OS Android a iOS. • Přenositelnost - přestože je OS Android vyčítána jeho velká roztříštěnost[20], tak díky dobré zpětné i dopředné kompatibilitě a dodržením určitých zásad při vývoji, je možné jednu aplikaci bez nutnosti zásadních úprav přenášet mezi zařízeními s různými verzemi OS Android, s jinak velkými obrazovkami i s úplně jinou hardwarovou konfigurací. • Open source - Android je zcela otevřená platforma, od Linuxového jádra, přes veškeré knihovny, aplikační framework až po základní aplikace. Tímto se Android od ostatních velmi odlišuje. I veškeré vývojářské nástroje jsou otevřené a multiplatformní, narozdíl od iOS, kde 21
2. Analýza a návrh
Obrázek 2.6: Podíl jednotlivých verzí OS Android
jsou oficiální vývojářské nástroje dostupné pouze na platformu Mac OS X také od společnosti Apple.
2.4.3
Verze OS Android
Android je velice rychle se rozvíjející platformou, což je vidět na počtu již vydaných verzí. Od září 2008 vyšlo již 10 hlavních verzí a řada menších obsahujících hlavně opravy chyb a drobná vylepšení. Aktuální verze je 4.2.2, tedy hlavní verze 4.2 s názvem Jelly Bean. Podíl jednotlivých verzí je vidět na obrázku 2.6. Hlavní verze jsou od dubna 2009 pojmenovávány abecedně podle anglických jmen zákusků: Cupcake, Donut, Éclair, Froyo, Gingerbread, Honeycomb, Ice Cream Sandwich, Jelly Bean a další chystaná verze 5.0 Key Lime Pie[18]. Jednotlivé nové verze přináší vždy množství různých nových funkcí a úpravy stávajících. Největší změna však nastala s příchodem verze 3.0 Honeycomb, která byla určena pouze pro tablety. Díky tomu byla vytvořena druhá vývojová větev, vývoj verze 2.3 Gingerbread na mobilní telefony pokračoval nezávisle dál. Obě vývojové větve byly opět spojeny s příchodem verze 4.0 Ice Cream Sandwich. Honeycomb přinesl řadu velkých změn, které byly následně přeneseny i na mobilní telefony. Asi největší změnou je přidání systémové lišty, která obsahuje tlačítka, která dříve musel mít mobilní telefon jako hardwarová. Dále bylo nahrazeno klasické menu, které se zobrazovalo po stisknutí hardwarového tlačítka menu, Action Barem, který tyto akce obsahuje, dříve nebylo jasné, zda obrazovka menu obsahuje či nikoliv. 22
2.4. Operační systém Android Další velkou novinkou zejména pro vývojáře bylo uvedení fragmentů, které přidávají GUI více flexibility, aplikace jednodušeji přizpůsobí svůj obsah velikosti obrazovky[23]. Většina těchto novinek se dá přenést i do starších verzí pomocí Android Compatibility Library (ACL), případně pomocí dalších neoficiálních knihoven. Přesto při optimalizaci GUI na více verzí je často nutné vytvářet soubory s definicí GUI pro každou verzi zvlášť a jsou nutné i určité úpravy kódu. Proto pro určité zjednodušení a větší přehlednost budou výstupem této práce dvě verze aplikace, jedna pokrývající OS Android od verze 2.2, která je minimální požadovanou kvůli využití mapových podkladů Google Maps API V2, po verzi 3.0 a druhá verze bude pokrývat zbylé verze od verze 3.0 včetně dál.
2.4.4
Vývoj aplikací
Pro vývoj aplikací na OS Android Google uvolnil oficiální vývojářské nástroje Android SDK[17]. Součástí SDK je Android Developer Tools[15] (ADT) plugin pro multiplatformní vývojové prostředí Eclipse[4], které je momentálně jediné oficiálně podporované. Tento plugin rozšíří Eclipse o nástroje obsažené v SDK, z nichž nejdůležitější jsou: • Android Emulator - emulátor zařízení s OS Android, sloužící k otestování vyvíjené aplikace. • AVD Manager - slouží ke správě Android Virtual Devices (AVD), které jsou využívány emulátorem. • ADB - Android Debug Bridge - nástroj, který umožňuje komunikaci s virtuálním nebo skutečným zařízením. • DDMS - Dalvik Debug Monitor Server - nástroj, který dává vývojářům úplný přístup k připojenému zařízení. Vývojář tak získá například přístup k informacím o vláknech, haldě a logu v zařízení, také má možnost vytvářet falešné SMS zprávy, příchozí hovory či podsunout zařízení falešnou polohu[14]. Kromě samotných nástrojů je součástí SDK také samotná platforma Android se všemi potřebnými knihovnami, které jsou využívány při samotném vývoji aplikace. Při stažení SDK je součástí aktuální verze platformy, ale pomocí nástroje Android SDK Manager lze stáhnout i starší, případně novější, verze platformy, stejně tak jako aktualizace samotných nástrojů v SDK, nebo další nástroje, které nejsou běžnou součástí SDK. 23
2. Analýza a návrh Samotné aplikace jsou následně psány v programovacím jazyce Java v kombinaci s jazykem XML, kterým se vytváří grafické rozhraní. Některé části aplikace mohou být také napsány v nativních jazycích jako C nebo C++ s využitím Native Development Kit (NDK). To může být užitečné pro použití již existujících knihoven napsaných v těchto jazycích, ale naprostá většina aplikací tuto možnost nevyužívá[16].
2.5
Webové úložiště Dropbox
Jedním z požadavků na aplikaci je možnost zálohování dat do webového úložiště. Velké množství lidí v dnešní době využívá více než jedno zařízení a právě webová úložiště usnadňují synchronizaci a sdílení souborů mezi nimi. Díky tomu jejich obliba neustále roste. V dnešní době existuje celá řada těchto uložišť, mezi nejvýznamnější z nich určitě patří Dropbox a Google Drive. Obě tato řešení jsou si velmi podobná - nabízejí podobné funkce. Obě tato řešení je také možné integrovat do aplikací třetích stran. Při důkladném porovnání těchto úložišť vychází řešení Google Drive o trochu lépe, zejména díky lepší ceně, která je mnohem nižší než u Dropboxu a také díky větší online funkcionalitě - například možnost vytvářet a upravovat textové a tabulkové dokumenty online. Přesto má však Google Drive mnohem méně uživatelů - konkrétně Dropbox má přes 100 milionů uživatelů a Google Drive přibližně 10 milionů uživatelů[2]. Z důvodu tohoto velkého rozdílu v počtu uživatelů bylo rozhodnuto pro Dropbox jako webové úložiště pro tuto práci.
2.6
Mapové podklady Google Maps
Pro mapové podklady bylo vybráno Google Maps API V2, které je součástí Google Play services, které se nacházejí v naprosté většině zařízení s OS Android. Google Play services však nepodporují starší verze OS Android než verze 2.2, tyto nepodporované verze ale tvoří pouze 1,8% podílu všech Android zařízení, viz obrázek 2.6. Navíc je Google Maps API V2 velice snadno integrovatelné do aplikace a obsahuje podrobnou dokumentaci veškerých funkcí[19]. 24
2.7. Použité vývojové prostředí a další nástroje
2.7
Použité vývojové prostředí a další nástroje
Pro vývoj bylo využito vývojové prostředí Eclipse[4] rozšířené o ADT plugin[15], který rozšířil jeho funkčnost o nástroje dodávané v Android SDK[17]. Při implementaci bylo kromě samotného Android SDK využito také Dropbox SDK[3] a Google Play services SDK[19]. Další nástroje, které byly při tvorbě této práce využity, jsou Enterprise Architect[26] na tvorbu diagramů, program Pencil[5] na tvorbu prototypu uživatelského rozhraní a programy Notepad++[21] a Latex[1] pro samotné napsání a vysázení této práce.
25
Kapitola
Realizace 3.1
Základní součásti aplikace
Výsledná aplikace, podobně jako většina aplikací na OS Android, se skládá z několika základních součástí. Jednotlivé součásti jsou zde podrobně popsány.
3.1.1
Android Manifest
AndroidManifest.xml je soubor, který musí obsahovat každá aplikace pro OS Android ve svém kořenovém adresáři. Tento XML soubor obsahuje veškeré informace o dané aplikaci, které potřebuje systém znát před samotným spuštěním kódu aplikace. Soubor popisuje jak požadavky, tak funkcionalitu samotné aplikace[7]. Nejdůležitější informace obsažené v manifestu: • Jméno Java balíčku aplikace - toto jméno zároveň slouží jako unikátní identifikátor aplikace, nemělo by se tedy stát, že by více aplikací mělo stejný název balíčku. Proto existuje konvence jak balíčky pojmenovávat - jméno balíčku je obrácené jméno domény organizace (autora) doplněné o název aplikace, tedy - [země].[autor].[jméno aplikace]. • Požadavky na verzi Android API - je zde definovaná cílová, minimální a maximální verze API, pro které je aplikace určena, to zabraňuje možnosti instalovat aplikaci na nepodporovanou verzi OS Android. • Knihovny vyžadované pro běh aplikace. 27
3
3. Realizace
Obrázek 3.1: Diagram zásobníku aktivit
• Permissions - oprávnění, která aplikace vyžaduje. Jedná se o oprávnění k přístupu do chráněných částí API, například přístup k internetu, možnost zapisovat na paměťovou kartu nebo zjištění polohy zařízení pomocí GPS. Uživatel je před instalací aplikace s těmito požadavkami seznámen, může je přijmout a aplikace je následně nainstalována, nebo odmítnout a přerušit instalaci. Jedná se o způsob ochrany uživatelů před podvodnými aplikacemi. • Komponenty, ze kterých se aplikace skládá - aplikace na OS Android může obahovat komponenty: Actvity, Service, Broadcast Reciever a Content Provider. V této práci jsou využity pouze Activities (dále česky aktivity). Všechny aktivity využívané v aplikaci zde musí být napsané, jinak je aplikace ukončena chybou. Záznam o aktivitě v Android Manifestu obsahuje název třídy, která aktivitu implementuje a může obsahovat další informace, například jakým způsobem se má aktivita spouštět, nebo které Intenty (zprávy) umí zpracovat. Je zde také definována hlavní aktivita - ta, která se spustí při spuštění aplikace.
3.1.2
Activities
Aktivita je základní a nejvíce využívanou komponentou, která se využívá k zobrazení určité obrazovky aplikace a následné interakci s uživatelem. Aplikace se tedy běžně skládá z více aktivit, které jsou vzájemně propojené, z nichž je jedna definovaná jako hlavní a spustí se po spuštění aplikace. Každá aktivita může spustit další aktivitu pro zobrazení další obrazovky. Když je spuštěna nová aktivita, předchozí je pozastavena, ale je zachována v tzv. back stacku, tedy zásobníku, kde se jednotlivé aktivity ukládají, viz obrázek 3.1. Každá nová aktivita se běžně vkládá na vrchol zásobníku, 28
3.1. Základní součásti aplikace
Obrázek 3.2: Životní cyklus aktivit
ačkoliv toto chování se dá ovlivnit nastavením aktivity v manifestu. Pokud uživatel dokončí práci na aktuální obrazovce (aktivitě) a stiskne tlačítko zpět, daná aktivita je vyjmuta ze zásobníku a zničena. Ze zásobníku se poté obnoví aktivita, která se nachází na jeho vrcholu[13]. V rámci běhu aplikace prochází aktivity svým životním cyklem, viz obrázek 3.2. Při změnách stavu aktivity, jako je například vytvoření nebo pozastavení, jsou v aktivitě volány příslušné metody, které umožní aktivitě reagovat na dané změny stavu, například při pozastavení aktivity uzavřít internetové připojení a naopak při obnovení aktivity ze zásobníku internetové připojení opět otevřít[6]. 29
3. Realizace
3.1.3
Layout soubory
Jedná se o soubory umístěné ve složce /res/layout v kořenovém adresáři. Jsou to XML soubory, které obsahují definici vizuální struktury GUI. Každá obrazovka je reprezentována jedním takovýmto souborem. Struktura GUI v těchto souborech definuje umístění a vzájemné vnoření jednotlivých elementů GUI. Elementy GUI jsou třídy dědící z tříd ViewGroup nebo View. V knihovnách existuje celá řada těchto tříd, například třída definující tlačítko nebo textové pole, programátor si však může vytvořit zcela vlastní. ViewGruop jednotlivé elementy v sobě sdružují a ovlivňují jejich rozmístění. Elementy mají v těchto XML souborech řadu parametrů, kterými se dají upravit, například umístění v rámci ViewGroup, barva, text apod., a docílit tak požadovaného vzhledu. Tyto soubory jsou následně využívány aktivitami pro zobrazování jednotlivých obrazovek. Běžně má každá obrazovka aplikace vlastní aktivitu s vlastním layout souborem[8].
3.1.4
Menu
Menu jsou definovány také pomocí XML souborů, které jsou umístěny v /res/menu. XML soubory definují jednotlivé položky menu, jejich název, identifikátor a případně ikonu, která se při použití menu jako Options Menu zobrazí. Takto definované menu jsou následně přiřazeny jako Options Menu k aktivitám (Options Menu se u starších verzí Android zobrazuje po stisknutí hardwarového tlačítka menu, případně u novějších verzí se položky menu nacházejí na Action Baru) nebo jako Context Menu k jednotlivým elementům GUI (Context Menu se zobrazuje po dlouhém stisknutí některého elementu)[10].
3.1.5
Values
V XML souborech umístěných v této složce (/res/values) jsou umístěny definice různých hodnot. Na jednotlivé hodnoty v těchto souborech je možné odkazovat z celé aplikace, což nám usnadňuje udržet jednotnost celé aplikace - při provádění změn těchto hodnot je stačí změnit pouze na jednom místě. Proto se využívají například k definicím barev, velikostí apod. Nejčastěji se zde však ukládají textové řetězce obsažené v aplikaci. Tím, že tyto texty nejsou umístěny přímo v kódu aplikace, je velmi usnadněná jejich případná lokalizace do jiných jazyků. Složka values se navíc může vyskytovat v aplikaci vícekrát s různými parametry, parametrem může být například kód státu. Takže například při překladu této aplikace do češtiny byla vytvořena složka values-cs, která obsahovala soubor s textovými řetězci pře30
3.2. Popis tříd loženými do češtiny. Systém automaticky vybere podle nastavení zařízení nejvhodnější soubory.
3.2
Popis tříd
Samotný kód aplikace se skládá z řady tříd. Většina těchto tříd implementuje jednotlivé obrazovky pomocí aktivit. Další třídy slouží například pro správu databáze v aplikaci, nebo se starají o zálohování dat v aplikaci, případně rozšiřují některé standardní třídy z knihovny.
3.2.1
Třídy aktivit
Tyto třídy implementují aktivity, které se starají o zobrazení obrazovky uživateli a jeho následnou interakci s ní. Většina z těchto tříd rozšiřuje základní třídu Activity, ale některé rozšiřují příbuzné třídy, jako PreferenceActivity, která je uzpůsobená funkčností pro zobrazení obrazovky s nastavením aplikace, nebo ListActivity, která se využívá v obrazovkách, kde je hlavní částí výpis dat z databáze ve formě seznamu, tato třída usnadňuje práci s ListView, který se musí v layoutu aktivity nacházet. Jednotlivé aktivity v aplikaci: • AboutActivity - obsahuje informace o aplikaci, autor, verze apod. • EquipmentInsertUpdateActivity - formulář na vkládání nebo úpravu výstroje • EquipmentShowAllActivity - seznam veškeré uložené výstroje • EquipmentShowDetailActivity - detail uložené výstroje • HomeActivity - úvodní stránka aplikace • LoactionInsertUpdateActivity - formulář na vkládání nebo úpravu lokality • LocationShowAllActivity - seznam všech uložených lokalit • LocationShowDetailActivity - detail uložené lokality • LogInsertUpdateActivity - formulář na vkládání nebo úpravu ponoru • LogShowAllActivity - seznam všech uložených ponorů • LogShowDetailActivity - detail uloženého ponoru 31
3. Realizace • MapLocationPickActivity - slouží pro nastavení souřadnic u lokality pomocí mapy • MapShowActivity - zobrazuje mapu s vyznačenými lokalitami • SettingsActivity - obsahuje možnosti na zálohování a obnovení dat a také možnost nastavit jednotky veličin • StatisticsActvity - zobrazuje statisitky z uložených ponorů
3.2.2
LogBookDatabase
Tato třída se stará o správu databáze. Zajišťuje přístup k databázi ze všech částí aplikace. Třída také obsahuje veškeré operace, které se nad databází provádí. Obsahuje tedy definici všech potřebných dotazů ve formě metod, které jako výsledek vracejí kurzor na data v aplikaci. Výjimkou jsou dotazy insert, update a delete. Tato třída také zajišťuje, že se při prvním zapnutí aplikace, nebo po aktualizaci, vytvoří v zařízení databázový soubor s potřebnou strukturou.
3.2.3
CursorAdapter
Pro zobrazení výpisu dat z databáze jako seznam se využívá Activity, případně ListActivity s připojeným ListView. Data z databáze jsou ale získaná ve formě kurzoru na tato data, ale samotný ListView s kurzorem pracovat neumí. Proto se využívá třída CursorAdapter, konkrétně třída SimpleCursorAdapter, která ji rozšiřuje, ten ovšem neumožňuje data před zobrazením transformovat, což je pro zobrazení datumu v této aplikaci potřebné. Proto bylo vytvořeno několik vlastních tříd rozšiřujících CursorAdapter, které nám toto umožní současně s obarvením jednotlivých řádků zvlášť jiná barva pro sudé a liché řádky. Při implementaci těchto vlastních CursorAdapterů byl využit návrhový vzor View Holder, který slouží pro optimalizaci tvorby jednotlivých řádků v seznamu. Řádky v seznamu jsou reprezentovány pomocí třídy View, každý View s konkrétním řádkem je vytvářen, až když by se měl uživateli zobrazit. Jednotlivé View se v rámci seznamu recyklují, takže není potřeba, aby se pro každý řádek v seznamu vytvářel nový View. Ovšem při plnění View daty konkrétního řádku je nutné nejprve jednotlivá textová pole ve View nalézt pomocí operace findViewById(), která je výpočetně značně náročná. View Holder je založen na tom, že výsledky operace findViewById() se ukládají do samostatné malé třídy, která se následně pomocí setTag() připojí k View. Tudíž volání operace findViewById() je nutné pouze při prvním 32
3.3. Ukládání dat plnění View daty, při dalším plnění se již použijí odkazy na textová pole uložené v samostatné třídě[9].
3.3
Ukládání dat
Většina dat aplikace je ukládána do databáze. Platforma Android obsahuje databázi SQLite a umožnuje každé aplikaci mít i více vlastních databází, které jsou uloženy v zařízení jako databázové soubory SQLite[11]. K těmto souborům má přístup pouze aplikace, které patří. Pro přístup k databázovým souborům slouží třída LogBookDatabase, která rozšiřuje třídu SQLiteOpenHelper. V databázi se nachází čtyři tabulky - tabulka ponorů, lokalit, výstroje a vztahová tabulka mezi ponory a výstrojí. Schéma databáze je na obrázku 3.3. Kromě databáze aplikace využívá také Shared Preferences. To je další prostor, kam si aplikace mohou ukládat data. Data jsou zde ukládána jako dvojice klíč a hodnota. Využívá se to zejména k ukládání uživatelského nastavení aplikace[12]. V této aplikaci jsou zde uložena nastavení jednotek veličin.
3.4
Požadavky aplikace
Aplikace klade na zařízení určité požadavky, které musí být splněny, aby na zařízení mohla být spuštěná a zárověň všechny její funkce byly plně funkční. Tyto požadavky je tedy možné rozdělit na minimální a doporučené. Minimální požadavky: • OS Android verze 2.2 nebo vyšší - tento požadavek je zde z důvodu, že integrované mapové podklady nejsou se staršími verzemi kompatibilní. Doporučené požadavky: • Internetové připojení - nutné pro fungování integrovaných mapových podkladů a také pro umožnění zálohování na webové úložiště. • GPS modul - pro možnost zjednodušeného zadávání souřadnic potápěčských lokalit. • Paměťová karta - pro možnost zálohovat na ni data aplikace. • Účet na Dropbox - pro možnost zálohovat data aplikace na webové úložiště.
33
3. Realizace
Obrázek 3.3: Schéma databáze
34
Kapitola
Testování Testování je velmi důležitá součást vývoje jakéhokoliv softwaru. Jen tak je možné zajistit kvalitu výsledné aplikace. Proto byla aplikace v průběhu celého vývoje při každé větší změně důkladně testována. Díky tomu bylo nalezeno a odstraněno velké množství chyb. Na závěr vývoje bylo provedeno následující uživatelské testování a také testování na více různých zařízeních. Aplikace byla otestována na čtyrech telefonech: HTC Desire, HTC Desire HD, Samsung Galaxy S II, Samsung Galaxy ACE S5830i a na dvou tabletech: Samsung Galaxy Note 10.1 a Google Nexus 7. Díky tomuto testování byla nalezena řada nedostatků v grafickém rozhraní, protože zařízení obsahují obrazovky s velmi rozdílnými velikostmi a ne vždy se rozhraní správně této velikosti přizpůsobilo.
4.1
Uživatelské testování
Tohoto testu se účastnili dva participanti, kteří měli připravený telefon HTC Desire s nainstalovanou aplikací. V samotné aplikaci nebyla žádná data, ale na paměťové kartě byla připravená záloha s testovacími daty. Participanti následně postupovali podle tohoto scénáře: • Vytvořte dva nové ponory, pro každý vytvořte vlastní lokalitu, kde u jedné nastavíte souřadnice pomocí GPS a u druhé pomocí mapy. U obou ponorů libovolně vyplňte údaje a připojte alespoň jeden kus výstroje. • Po uložení druhého ponoru jste si uvědomil, že u prvního ponoru jste zapomněl napsat něco do poznámky. První ponor tedy upravíte a do poznámky něco připíšete. 35
4
4. Testování • Nyní si vámi vložené ponory zobrazíte na mapě. • Následně si uvědomíte, že jste již ponory kdysi zapisoval a že zálohu máte na paměťové kartě. Zálohu tedy z paměťové karty obnovíte. • Po obnovení zálohy si chcete v seznamu ponorů vyhledat pouze ty, které byly uskutečněny v České republice a následně si je chcete zobrazit na mapě. • Aplikaci následně ukončíte.
4.1.1
Výsledek testu
Jelikož jsou oba participanti uživatelé OS Android, ovládání samotného telefonu ani základní ovládání aplikace (například kde se nachází menu) jim nedělalo problém. V průběhu testu nenastal žádný větší problém, participanti neměli problém jednotlivé prvky UI snadno najít. Až na jednu nejasnost, kdy při nastavování souřadnic u lokality pomocí mapy nebylo participantům zcela jasné, že po umístění značky na mapu mají stisknout hardwarové tlačítko zpět. Proto bylo přidáno tlačítko, které tento problém odstraňuje. Kromě tohoto byly nalezeny pouze drobné chyby ve formě překlepů a chyby, které již byly objeveny dříve při běžném testování.
4.2
Chyby a možnosti řešení
Naprostá většina nalezených chyb se dala celkem snadno nalézt a opravit. Bohužel však v aplikaci existují tři chyby, které nemají jednoduché řešení. Nejedná se však o zásadní chyby, které by ohrožovaly stabilitu aplikace, či konzistenci dat v ní. • Omezení maximálního oddálení mapy - mapu nelze oddálit tak, aby bylo možné vidět celou zeměkouli. Problém tedy nastane, pokud máme například jeden ponor v Evropě a jeden v Jižní Americe a chceme si je zobrazit na mapě. Aplikace se pokusí nastavit oddálení a vycentrovat mapu tak, aby na ní byly zobrazeny všechny značky. Zde ale narazí na limit při nastavení oddálení a následně zobrazí výsek mapy mezi těmito značkami, kde se ale žádná značka nenachází. Řešení: jelikož se jedná o limit v samotném Google Maps API v2, jediné řešení by bylo využít jiné mapové podklady. 36
4.2. Chyby a možnosti řešení • Obrovské cache soubory - jedná se opět o problém s Google Maps API v2, kdy na některých zařízeních vytváří na paměťové kartě obrovské (stovky MB) cache soubory. Řešení: tento problém je již zmíněn na oficiálním issue trackeru, takže by se mohl dočkat opravy. • Vyhledávání ve výpisech je localized - sensitive, tedy při vyhledávání „ceska republika“ uživatel očekává i výsledky obsahující „Česká republika“, které ale nedostane, protože SQLite databáze nemá localized - insensitive porovnávání řetězců a nelze ji o něj ani doplnit. Řešení: zatím žádné.
37
Kapitola
Další vývoj Ačkoliv aplikace splňuje veškeré požadavky na ni kladené a je možné ji bez problémů ihned začít používat, existuje řada možností, jak aplikaci vylepšit. Nejvýznamnější jsou například: • Vyřešit problém s localized - sensitive vyhledáváním. Přestože se nejedná o zásadní problém, řadě uživatelů to může velmi vadit, protože dnes jsou lidé zvyklí vyhledávat na internetu podle klíčových slov bez interpunkce. • Vylepšit GUI. Momentální GUI je sice přehledné a intuitivní, není ale příliš vzhledné. Zejména obrazovkám s detaily záznamů chybí nějaká grafika. Také by se GUI dalo rozšířit o speciální verzi pro tablety, momentální GUI je na tabletech sice funkční, ale zdaleka nevyužívá možnosti plynoucí z mnohem větší obrazovky. Viz obrázek B.3. • Pravidelné zálohování. Lidé sice mají možnost vytvářet zálohy, ale často na to zapomínají a vzpomenou si, když je už příliš pozdě. Tento problém by se dal vyřešit umožněním nastavení pravidelných záloh v určitých intervalech. • Import a export z CSV souborů. Tato funkcionalita by byla důležitá zejména pro uživatele jiných aplikací, kteří by chtěli přejít na používání této aplikace. Řada aplikací totiž nabízí možnost exportu do souboru CSV a uživatel by tak nemusel zdlouhavě přepisovat ponory do této aplikace, případně by pouze drobně upravil CSV soubor.
39
5
Závěr Všechny cíle této bakalářské práce byly naplněny - tedy proběhla analýza, návrh a realizace aplikace, která slouží jako potápěčský deník. Veškeré požadavky, které jsou v zadání, aplikace zcela splňuje (evidence ponorů včetně integrace s mapovými podklady a evidence potápěčské výstroje) a ještě je rozšiřuje o další funkce. Zejména se jedná o možnost zálohování na webové úložiště Dropbox, čímž se tato aplikace odlišuje od dalších podobných aplikací, protože žádná z nich tuto možnost nenabízí. Aplikace také klade důraz na přehlednost a intuitivnost uživatelského rozhraní, které by mělo být co nejvíce uživatelsky přívětivé. Proto také vznikly dvě verze aplikace tak, aby uživatelé starších i novějších verzí OS Android nalezli ovládací prvky, na které jsou zvyklí. Do budoucna by mohla být aplikace rozšířená a vylepšená podle námětů vypsaných v kapitole „Další vývoj“. Aplikaci by bylo možné také umístit do nabídky distribuční služby Google Play, díky čemuž by se aplikace mohla potencionálně rozšířit mezi velký počet uživatelů.
41
Literatura [1] LaTeX [online]. 2010, [cit. 2013-05-09]. Dostupné z: http:// www.latex-project.org/ [2] Business Insider: Dropbox Vs. Google Drive - Business Insider [online]. Duben 2013, [cit. 2013-05-09]. Dostupné z: http:// www.businessinsider.com/dropbox-vs-google-drive-2013-4 [3] Dropbox: Core API SDKs - Dropbox [online]. Březen 2013, [cit. 201305-09]. Dostupné z: https://www.dropbox.com/developers/core/sdk [4] Eclipse Foundation: Eclipse IDE [online]. 2013, [cit. 2013-05-09]. Dostupné z: http://www.eclipse.org/ [5] Evolus: Pencil [online]. 2012, [cit. 2013-05-09]. Dostupné z: http:// pencil.evolus.vn/ [6] Google: Activities | Android Developers [online]. [cit. 2013-05-12]. Dostupné z: http://developer.android.com/guide/components/ activities.html [7] Google: The AndroidManifest.xml File | Android Developers [online]. [cit. 2013-05-12]. Dostupné z: http://developer.android.com/ guide/topics/manifest/manifest-intro.html [8] Google: Layouts | Android Developers [online]. [cit. 2013-0512]. Dostupné z: http://developer.android.com/guide/topics/ui/ declaring-layout.html [9] Google: Making ListView Scrolling Smooth | Android Developers [online]. [cit. 2013-05-12]. Dostupné z: http: 43
Literatura //developer.android.com/training/improving-layouts/smoothscrolling.html#ViewHolder [10] Google: Menus | Android Developers [online]. [cit. 2013-0512]. Dostupné z: http://developer.android.com/guide/topics/ui/ menus.html [11] Google: Saving Data in SQL Databases | Android Developers [online]. [cit. 2013-05-12]. Dostupné z: http://developer.android.com/ training/basics/data-storage/databases.html [12] Google: Saving Key-Value Sets | Android Developers [online]. [cit. 2013-05-12]. Dostupné z: http://developer.android.com/training/ basics/data-storage/shared-preferences.html [13] Google: Tasks and Back Stack | Android Developers [online]. [cit. 2013-05-12]. Dostupné z: http://developer.android.com/guide/ components/tasks-and-back-stack.html [14] Google: Using DDMS | Android Developers [online]. 2012, [cit. 2013-0511]. Dostupné z: http://developer.android.com/tools/debugging/ ddms.html [15] Google: ADT Plugin | Android Developers [online]. Únor 2013, [cit. 2013-05-11]. Dostupné z: http://developer.android.com/tools/ sdk/eclipse-adt.html [16] Google: Android NDK | Android Developers [online]. Březen 2013, [cit. 2013-05-11]. Dostupné z: http://developer.android.com/tools/ sdk/ndk/index.html [17] Google: Android SDK | Android Developers [online]. Únor 2013, [cit. 2013-05-11]. Dostupné z: http://developer.android.com/sdk/ index.html [18] Google: Dashboards | Android Developers [online]. Květen 2013, [cit. 2013-05-06]. Dostupné z: http://developer.android.com/about/ dashboards/index.html [19] Google: Google Maps Android API v2 - Google Developers [online]. Únor 2013, [cit. 2013-05-10]. Dostupné z: https:// developers.google.com/maps/documentation/android/ 44
Literatura [20] Havryluk, M.: Roztříštěnost androidu. Nafouklá bublina, nebo skutečná hrozba? - iDNES.cz [online]. Srpen 2012, [cit. 2013-05-06]. Dostupné z: http://mobil.idnes.cz/roztristenost-androidu-0wy/mob_tech.aspx?c=A120711_114932_mob_tech_ham [21] Ho, D.: Notepad++ [online]. 2013, [cit. 2013-05-09]. Dostupné z: http: //notepad-plus-plus.org/ [22] Přispěvatelé Wikipedie: Android (operating system) - Wikipedia, the free encyclopedia [online]. Květen 2013, [cit. 2013-05-05]. Dostupné z: http://en.wikipedia.org/wiki/Android_(operating_system) [23] Přispěvatelé Wikipedie: Android version history - Wikipedia, the free encyclopedia [online]. Květen 2013, [cit. 2013-05-06]. Dostupné z: http: //en.wikipedia.org/wiki/Android_version_history [24] Přispěvatelé Wikipedie: Comparison of Android devices - Wikipedia, the free encyclopedia [online]. Květen 2013, [cit. 2013-05-05]. Dostupné z: http://en.wikipedia.org/wiki/ Comparison_of_Android_devices [25] Přispěvatelé Wikipedie: Open Handset Alliance - Wikipedia, the free encyclopedia [online]. Duben 2013, [cit. 2013-05-05]. Dostupné z: http: //en.wikipedia.org/wiki/Open_Handset_Alliance [26] Sparx Systems: Enterprise Architect [online]. 2013, [cit. 201305-09]. Dostupné z: http://www.sparxsystems.com/products/ea/ index.html [27] StatCounter: StatCounter Global Stats - Browser, OS, Search Engine including Mobile Market Share [online]. Květen 2013, [cit. 2013-05-07]. Dostupné z: http://gs.statcounter.com/#mobile_os-ww-monthly201305-201305-bar
45
Příloha
Seznam použitých zkratek API Application Programming Interface CSV Comma-Separated Values GPS Global Positioning System GUI Graphical User Interface OS Operating System SDK Software Development Kit UI User Interface UML Unified Modeling Language XML eXtensible Markup Language
47
A
Příloha
Snímky aplikace
Obrázek B.1: Domovská obrazovka a obrazovka s výpisem ponorů 49
B
B. Snímky aplikace
Obrázek B.2: Obrazovka s formulářem pro úpravu ponoru a obrazovka s mapou
Obrázek B.3: Domovská obrazovka na tabletu Samsung Galaxy Note 10.1
50
Příloha
Diagramy případů užití
51
C
C. Diagramy případů užití
Obrázek C.1: Diagram případů užití - detailní pohled na správu ponorů
52
Obrázek C.2: Diagram případů užití - detailní pohled na správu lokalit
53
C. Diagramy případů užití
Obrázek C.3: Diagram případů užití - detailní pohled na správu výstroje
54
Příloha
Obsah přiloženého CD
readme.txt ................................ stručný popis obsahu CD zdrojove_kody...............................zdrojové kódy aplikace text.....................................................text práce latex...............................zdrojové soubory textu práce bakalarska_prace.pdf ............... text práce ve formátu PDF DiveLogBook.apk ....... přeložená aplikace pro Android od 2.2 do 3.0 DiveLogBook_v3+.apk...přeložená aplikace pro Android od 3.0 včetně 55
D
