Rozšíření informačního systému EPI, s.r.o. na mobilní platformu Android

Evropský polytechnický institut, s.r.o. Kunovice, ČR

Rozšíření informačního systému EPI, s.r.o. na mobilní platformu Android Bakalářská práce

Autor:	Antonín Šajboch
Pedagogický vedúci:	Ing. Jindřich Petrucha, PhD
Študijný odbor:	Elektronické počítače
Akademický rok	2012/2013

Obsah práce

1.	Analýza platformy Android
2.	Analýza informačního systému rozvrhu a možnosti zpracování dat
3.	Návrh vzhledu aplikace mobilního rozvrhu
4.	Návrh funkcionality aplikace mobilního rozvrhu
5.	Realizace projektu EPIrozvrh a popis kódu
6.	Testování funkcionality aplikace EPIrozvrh a uvedení do provozu

Abstrakt Cílem práce bylo vytvořit aplikaci školního rozvrhu pro mobilní platformu Android. Tato aplikace pravidelně automaticky stahuje nové aktualizace rozvrhu ze školní databáze a je přístupná i v režimu offline. V této práci je provedena analýza platformy Android a princip vývoje aplikací pro tuto platformu včetně jejího vývojového prostředí. Dále jsou zde také popsány principy programování, vývojové diagramy popisující architekturu celé aplikace. Všechny tyto informace jsou využity v praktické části, kde je detailně popsáno, jak aplikace pracuje s daty včetně jejího třídění a zobrazování. Součástí práce je kromě hotové aplikace veškerá dokumentace a videonávod.

Abstract The aim was to create an application school schedule for the Android mobile platform. This application automatically downloads regular updates schedule from the school database and can be accessed in offline mode. This paper is an analysis of the Android platform and the principle of development applications for the platform, including its development environment. Furthermore, there are also described principles of programming, flowcharts describing the architecture of the application. All this information is used in the practical part, where is described in detail how the application works with data including the sorting and displaying. The work done by excluding all documentation and video tutorials.

Úvod

Díky mobilním technologiím můžeme být neustále v kontaktu se svou rodinou, přáteli i dalšími lidmi po celém světě. Mobilní telefony se postupem času stali „malými počítači“. Obdobně jako počítače obsahují procesor, datové úložiště, paměť RAM, ale také operační systém. Takto vybavený mobilní telefon nám může poskytnout bohatou sadu služeb. Běžnou součástí mobilního telefonu se stalo bezdrátové připojení k internetu. Díky tomuto připojení se k emailům či svým datům dostaneme téměř odkudkoliv.

Android není jenom operační systém, ale je také celou platformou pro vývoj aplikačního softwaru. Android nabízí vývojáři aplikací velkou míru svobody při tvorbě a přístupu k funkcím zařízení. K těmto funkcím se přistupuje přes standardizované programové rozhraní (API).

V rámci modernizace na „Evropském polytechnickém institutu s.r.o.“, dále jen EPI, jsem se rozhodl rozšířit informační systém na mobilní platformu Android. Toto rozšíření se bude týkat rozvrhu hodin. Díky tomuto rozšíření bude mít student, učitel nebo zaměstnanec školy možnost přistupovat k rozvrhu školy pomocí aplikace ve svém mobilním zařízení s OS Android.

Aplikace bude obsahovat vlastní databázi rozvrhu, která se bude automaticky aktualizovat ze školního serveru. Aktualizace však bude možná jen za předpokladu úspěšného připojení do sítě internet. Jinak bude aplikace čerpat ze své vlastní databáze, která již byla aktualizována dříve.

V první kapitole bude podrobně analyzována platforma Android a princip vývoje aplikací na této platformě. Dále zde bude popsáno vývojové prostředí pro tvorbu aplikací pro OS Android, princip vývoje aplikací, základní struktura aplikace a pravidla vizuálního návrhu.

Druhá kapitola bude popisovat stávající informační systém s cíleným zaměřením na rozvrh hodin, který bude analyzován velmi podrobně. Také zde bude popsáno multiplatformní rozšíření rozvrhu hodin, které bude vytvořeno na základě předchozí analýzy rozvrhu hodin.

Třetí kapitola bude popisovat návrh vzhledu aplikace v kombinaci s navigačními prvky. Tento návrh vzhledu předchází vývoji aplikace. To znamená, že na základě tohoto návrhu bude vytvořen reálný vzhled aplikace s navigačními prvky, které tato kapitola popisuje.

Další kapitola, tedy kapitola čtvrtá, bude definovat architekturu aplikace a způsob, jakým bude aplikace uchovávat své data. Popis architektury aplikace bude postaven na UML diagramech.

Pátá kapitola bude popisovat již hotovou aplikaci a rozebírat jednotlivé části aplikace. Budou zde ukázky zdrojového kódu v kombinaci s diagramy tříd a ukázky konečného vzhledu aplikace. Části zdrojového kódu budou popsány a podrobně vysvětleny.

Kapitola číslo šest se zabývá testováním funkcionality hotové aplikace. Testování aplikace bude rozděleno na dvě části. V první části se bude jednat o obecné testování aplikace, tedy o to zda se aplikace nechová nepředvídatelně. Tyto testy budou prováděny na principu testování aplikací, které zveřejnila firma Google v dokumentu „App Quality“ na portále pro vývojáře aplikací pro OS Android. [40] Ve druhé části se bude provádět individuální testování aplikace. To znamená, jestli se aplikace chová přesně tak, jak bylo definováno a nedochází například ke zkreslování informací nebo ke špatnému zobrazení na různých zařízeních.

Cílem této práce je vytvořit aplikaci pro mobilní zařízení se systémem Android, která bude poskytovat přístup k aktuálnímu rozvrhu hodin a tuto aplikaci uvést do provozu na EPI.

V této práci bude použito hodně anglických výrazů, které nelze věrohodně přeložit, nebo neexistuje v českém jazyce synonymum překládaného slova. Aby nedocházelo ke skloňování nebo špatnému překladu těchto slov, budou tato slova označena kurzívou a nebudou skloňována a překládána.

Analýza platformy Android

Tento OS podporují přední prodejci mobilních telefonů a tabletů, mezi které patří například Samsung, HTC, Sony Ericsson a Motorola. Nejenom přední výrobci mobilních telefonů, ale i přední výrobci osobních počítačů jej využívají pro své produkty, zejména pro tablety. Mezi tyto přední výrobce osobních počítačů patří například Asus, Acer, atd.

Vývoj platformy Android

Společnost Android Inc. byla založena ve Spojených státech amerických v roce 2003 a jejím zakladatelem byl Andy Rubin. V roce 2005 ji odkoupila společnost Google Inc. a vydala první verzi operačního systému Android v mobilním telefonu s názvem Google mobile, ale tato verze nebyla úspěšná. Google přepracoval tento operační systém a po roce jej znovu vydal pro mobilní telefon HTC, tato verze již úspěšná byla. Uživatelů operačního systému Android začalo přibývat. Dne 5. listopadu v roce 2007, několik společností, včetně Google, HTC, Motorola, Intel, T-Mobile, a NVIDIA, vytvořilo OHA. [19][11 s. 4]

OHA je uskupení výrobců mobilních telefonů, telekomunikačních operátorů a technologických firem, stojící za vývojem OS Android. Cílem tohoto seskupení je vyvinutí otevřeného standardu pro mobilní zařízení. Od října 2008 je Android k dispozici jako open-source.

Verze	Kódové jméno	Verze API
1.5	Cupcake	3
1.6	Donut	4
2.0/2.1	Eclair	6/7
2.2	FroYo	8
2.3	Gingerbread	9
3.0 – 3.2	Honeycomb	12 – 14
4.0	Ice Cream Sandwich	15
4.1/4.2	Jelly Bean	16/17

Tabulka č. 1: Rozdělení platformy Android podle dostupných verzí

Zdroj: [20]

Předcházející tabulka reprezentuje seznam používaných verzí operačního systému. Každá verze operačního systému obsahuje číslo verze, kódové označení a verzi API. Z této tabulky je tedy zřejmé, že OS Android je k dispozici v široké škále verzí.

Android Architektura

Následující obrázek, který se skládá z pěti vrstev, zobrazuje hlavní komponenty OS Android. Každá z těchto vrstev má svůj specifický význam a ten je rozebrán níže.

Obrázek č. 1: Pohled na Architekturu platformy Android

Zdroj: [12]

Základním kamenem platformy Android je Linuxové jádro 2.6, což je nejnižší vrstva.Na obrázku č. 1 je tato vrstva označena jako Linux Kernel. Toto Linuxové jádro je nejčastěji používaným open-source jádrem díky jeho stabilitě, flexibilitě a dalším výhodám. [13][10, s. 19]

Toto linuxové jádro obsahuje ovladače nutné ke komunikaci ostatních vrstev s hardwarem zařízení. Dále je toto jádro obohaceno o specifické funkce, jako je speciální sdílená paměť, meziprocesorová komunikace, alokace operační paměti pro procesy atd.

Tyto specifické funkce jsou důležité pro provoz na mobilních zařízeních zejména kvůli nízké operační paměti a méně výkonným procesorům (CPU).

Další v pořadí je vrstva, která je na obrázku č. 1 označena jako Libraries (knihovny). Tato vrstva obsahuje řadu C/C++ nativních knihoven. Knihovny jsou používané různými komponentami systému Android. Jsou nezbyté pro vývoj aplikací většího rozsahu.

Některé z těchto knihoven:

• Media Libraries - tato knihovna podporuje přehrávání a nahrávání mnoha známých audio a video formátů, jako jsou například AAC, AMR atd., podporuje také obrazové soubory,
• SQLite - všestranný relační databázový systém, který je přístupný všem aplikacím,
• LibWebCore - moderní jádro webového prohlížeče implementováno do webového prohlížeče OS Android, ale také je obsaženo v grafické komponentě web view přístupné pro vývojáře,
• SGL - základní 2D grafický engine,
• 3D libraries -obsahují implementace založené na OpenGL ES 1.0 API, využívá 3D hardwarovou akceleraci (pokud je k dispozici), nebo vysoce optimalizované softwarové 3D rastrování. [13]

Další částí je virtuální stroj Dalvik, který je na obrázku označen jako Android Runtime. Virtuální stroj Dalvik zajišťuje, že každá aplikace běží ve vlastním procesu, s vlastní instancí. [12]

Z toho plyne, že zajišťuje nezávislost aplikací na hardware a každá aplikace je obsluhována vlastním vláknem. Další důležitou vlastností virtuálního stroje Dalvik je nejenom nezávislost aplikace na hardware, ale zejména nezávislost na instrukční sadě procesoru. Díky tomu je možné provozovat aplikace na architektuře x86 i na procesorech ARM. Samozřejmě to neplatí za použití nativních knihoven, které by bylo nutno přeložit zvlášť.

Platforma Android nabízí široké možnosti při vytváření designu aplikace. Taktéž je možno plně využívat funkce hardwaru zařízení (GPS). Mohou také pracovat s informacemi o poloze, spouštět služby na pozadí či přidat oznámení. [10, s. 25]

V poslední vrstvě s názvem „Aplications“ jsou aplikace, které jsou dodávané s téměř každým zařízením pracujícím na platformě Android, například webový prohlížeč, seznam kontaktů a další.

Princip vývoje aplikací

Vývoj aplikací pro mobilní zařízení je od vývoje aplikací pro stolní počítače nebo servery poněkud odlišný. Mobilní zařízení mají ve většině případů malou obrazovku, mohou a nemusí mít fyzickou klávesnici, ovládají se dotykem (velké prsty na malé obrazovce jsou nepřesné), operační paměť a rychlost CPU je v porovnání se stolními počítači malá. [1, s. 22] [14]

Tyto předpoklady je proto důležité znát a implementovat je do vyvíjené aplikace, například vytvářet všechny tlačítka a ovládací prvky dostatečně velké, aby bylo možné snadné ovládání.

Mobilní zařízení, tedy konkrétně mobilní telefony, jsou navíc odlišné v tom, že jejich primární funkce je přijímat hovory, přijímat textové zprávy a zprávy MMS. Tyto služby jsou pro uživatele naprosto prioritní. Určitě by se nikomu nelíbilo, kdyby mobilní telefon přestal pracovat kvůli nějaké aplikaci. Při běhu aplikace můžou nastat různé jevy, které znemožní tyto primární funkce telefonu.

Jevy, které znemožní primární funkce telefonu:

• dojde k takovému vytížení procesoru, že mobilní telefon nebude schopný přijmout hovor,
• aplikace nezmizí do pozadí, když telefon upozorní uživatele na příchozí hovor nebo si chce uživatel přečíst textovou zprávu,
• aplikace způsobí pád systému.

Mark L. Murphy, vývojář mobilních aplikací pro Android, napsal ve své knize Android 2: Průvodce programováním mobilních aplikací: „Aplikace spuštěné v telefonu se musí neustále potýkat s tím, že jsou spuštěné právě v telefonu“. [1, s. 22]

Platforma Android se snaží o kompromis tak, že aplikace spuštěné v mobilním telefonu můžou využívat největší možnou část operační paměti a procesoru, ale zároveň jsou zajištěny již zmiňované primární funkce mobilního telefonu. Nabízí poměrně rigidní a oddělený aplikační rámec, ve kterém musí běžet veškeré aplikace, aby nenarušovali základní funkci ostatních aplikací nebo samotného telefonu. [14]

Programovací jazyk, ve kterém se píší aplikace pro mobilní zařízení s OS Android, je obdobný jako programovací jazyk Java. Využívá se stejné syntaxe a některých negrafických objektů. Grafické objekty si platforma Android definuje sama. Předchozí znalost programovacího jazyku Java je předpokladem pro pochopení vývoje aplikací pro platformu Android.

Android emulátor

Android SDK obsahuje virtuální zařízení Android Virtual Device (AVD), které simuluje běh mobilního telefonu v počítači. Emulátor umožňuje ladění a testování aplikací bez použití fyzického zařízení. [17][16][1, s. 28]

Emulátor však nepodporuje všechny hardwarové a softwarové prvky typické pro mobilní zařízení. Poskytuje však celou řadu kontrolních a navigačních kláves, které je možné ovládat pomocí kliknutí myši nebo klávesnice.

Pro použití emulátoru se nejprve musí vytvořit virtuální zařízení v AVD Manager, který se spustí z vývojového prostředí nebo z příkazové řádky. Při vytváření AVD je potřeba vytvořit konfiguraci. V každé konfiguraci je možno zadat verzi platformy Android, velikost obrazovky, velikost paměťové karty, popřípadě se dá zvolit některé z fyzicky existujících zařízení (Nexus 7). Každé AVD funguje nezávisle s vlastním skladovacím prostorem pro uživatelská data.

Části AVD jsou:

• Hardwarový profil - definuje funkce hardware virtuálního zařízení. Může určit, zda má virtuální zařízení fotoaparát, kolik má paměti, atd.
• Mapování systémového obrazu - definuje, jaká verze platformy Android poběží na virtuálním zařízení.
• Další možnosti - umožňují zadat rozměry obrazovky, vzhled, emulaci SD karty atd. [17][18]

Vývojové prostředí

Oficiálně podporované vývojové prostředí pro aplikace Android je IDE Eclipse s doinstalovaným zásuvným modulem Android Developer Tools (ADT). Vývojáři ovšem nejsou nuceni pracovat s vývojovým prostředím Eclipse, ale mohou si zvolit jiné IDE, například NetBeans nebo jednoduchý textový editor a kompilace pomocí příkazové řádky.

Nástroje pro vývoj aplikací pro platformu Android jsou obsaženy v Android Software Development Kit (SDK), které jsou dostupné pro všechny známé operační systémy GNU/Linux, Windows i Mac OS. [15]

Sada SDK se skládá z balíků, které je možné stáhnout a nainstalovat popřípadě aktualizovat samostatně pomocí Android SDK Manager. Vyjde-li nová verze platformy Android nebo jsou k dispozici aktualizace SDK Tools, je možno pomocí SDK Manager stáhnout tyto aktualizace do používaného vývojového prostředí.

Balíčky pro Android SDK:

• SDK Tools - obsahuje nástroje pro ladění, testování aplikací a další nástroje, které jsou nezbytné k rozvoji aplikací,
• SDK Platform - je k dispozici pro každou verzi Android, obsahuje soubor (android.jar) s knihovnami,
• zdrojové kódy pro Android SDK,
• dokumentace offline - kopie nejnovější dokumentace pro platformu Android.

Struktura projektu

Překladový systém operačního systému Android je založen na speciální stromové struktuře adresářů v projektu. Je to velmi podobné jako v jakémkoli jiném Java projektu. Platforma Android využívá XML souborů pro definování statických parametrů, které definují danou aplikaci. XML soubory jsou využity i při vytváření statického designu aplikace.

XML je značkovací jazyk využívaný pro různé účely a obsahuje různé typy dat. Zpracování XML je podporováno řadou nástrojů a programovacích jazyků. XML neobsahuje předdefinované značky (tagy), proto je třeba definovat vlastní značky, které budou použity. [4, s. 17]

Po vytvoření nového projektu v Android SDK se vytvoří v kořenovém adresáři několik položek, včetně následujících:

• AndroidManifest.xml je XML soubor popisující vyvíjenou aplikaci a komponenty,
• build.xml je skript pro kompilaci a instalaci aplikace na telefon,
• assets/ je složka obsahující statické soubory, které je potřeba přibalit k aplikaci,
• bin/ je složka ve které se nachází aplikace po kompilaci,
• libs/ je složka uchovávající java archívy třetích stran,
• src/ je složka uchovávající zdrojové kódy aplikace,
• res/ je složka uchovávající prostředky a to jsou například ikony, zabalené návrhy grafického rozhraní (GUI) se zkompilovaným zdrojovým kódem.

Soubor AndroidManifest.xml je základem jakékoliv aplikace pro Android. Tento soubor se automaticky vygeneruje po vytvoření aplikace. Deklaruje se zde obsah, práva a služby aplikace.

V souboru AndroidManifest.xml můžeme naleznout následující elementy:

• permission zprostředkovává práva jiným aplikacím, aby mohli využívat logiku či data aktuální aplikace,
• uses-permission jsou práva, které bude aplikace potřebovat, aby mohla správně fungovat,
• instrumentation deklarují zdrojový kód, který je potřeba volat při výskytu klíčových systémových událostí,
• uses-library připojují některé android komponenty, například mapovací služby.

Základní objekty při tvorbě aplikace

Grafická část aplikace je nejdůležitější částí vývoje aplikací pro mobilní zařízení. Platforma Android si zakládá na jednoduchosti ovládání, které by mělo být intuitivní. Proto je při tvorbě vzhledu důležité dodržovat zásady, které byly vyvinuty na základně zkušeností uživatelů Android. [32]

Grafické uživatelské prostředí (GUI) pro Android aplikace je sestaveno s použitím hierarchie objektů View a ViewGroup, které jsou základními stavebními kameny pro vytváření designu aplikace. Každý grafický element musí být potomkem jedné z těchto tříd. ViewGroup je neviditelná skupina prvků View a ViewGroup. ViewGroup je taktéž nazývaný kontejner. Tento kontejner může obsahovat jak prvky View, tak prvky ViewGroup. [24]

View je dále nedělitelný element, který slouží pro zobrazení nebo interakci s uživatelem. Na obrázku č. 2 je vyobrazena tato hierarchie jednotlivých elementů.

Vzhled aplikace se skládá ze dvou základních elementů, vizuální komponenta (potomek třídy View) a layout (v překladu nákres, potomek třídy ViewGroup), viz obrázek č. 2. V této práci bude použito označení komponenta a layout.

Obrázek č. 2: Hierarchie grafických elementů

Zdroj: [24]

Rozložení prvků zachycuje obrázek č. 2, kde lze vidět, že prvek ViewGroup, tedy layout, je rodičovským prvkem a může obsahovat další prvky. Typickými zástupci layoutu jsou LinearLayout a RelativeLayout sloužící pro specifické rozmístění jakýchkoliv grafických prvků. [22][23]

Ačkoli je technicky vzato možné vytvářet všechny vizuální komponenty a layouty prostřednictvím zdrojového kódu obvyklejší je používat XML soubor s návrhem uživatelského rozhraní.

Dynamické vytváření instancí vizuálních komponent prostřednictvím zdrojového kódu se používá, když vizuální komponenty nejsou známé při kompilaci, například naplnění sloupce na základě dat získaných ze sítě internet.

Android považuje návrhy založené na XML za prostředky (resources), a proto jsou uloženy v adresáři res/layout v Android projektu. XML soubor obsahuje strom elementů s atributy identifikující rozložení elementů a jejich bližší vlastnosti. [1, s. 42]

Atributy v XML návrhu popisují jak má daný element vypadat nebo jak se má chovat. Pokud má nějaká vizuální komponenta, například TextView, hodnotu atributu android:textColor=„0000FF“, znamená to, že text, který se zobrazí, bude modrý.

Téměř vše, co se dá vytvořit pomocí XML, lze vytvořit pomocí zdrojového kódu. Místo použití atributu v XML návrhu android:textColor, se může použít metoda setTextColor(int). Avšak obrovskou výhodou vytváření designu pomocí XML návrhu oproti vytváření designu pomocí zdrojového kódu, je možnost využití nástrojů pro návrh GUI systému Android. Díky těmto nástrojům se vytváření uživatelského prostřední značně zjednoduší, protože veškeré úpravy jsou viditelné v reálném čase. Další výhodou XML návrhu je větší přehlednost a srozumitelnost.

Elementy vytvořené v XML lze jednoduše používat ve zdrojovém kódu a to pomocí takzvaných identifikátorů. Každý element, který je potřeba jakkoli zpracovat, musí mít následující atribut android:id=“@id/jedinecne_id“, aby jej bylo možné identifikovat ve zdrojovém kódu. Takový atribut musí mít jedinečnou hodnotu, aby nedošlo k jeho záměně s jiným elementem.

Vizuální komponenty

Rodičovským prvek vizuálních komponent je View. View je dále nedělitelná jednotka, která se používá pro vykreslení na obrazovku a komunikaci s uživatelem. [21]

Komunikací s uživatelem se myslí interaktivní ovládání, například nějaká akce po kliknutí, po táhnutí, po dlouhém kliknutí nebo zadání textu či čísla uživatelem. Některé vizuální komponenty jsou již přeprogramované a připravené k použití.

Přeprogramované vizuální komponenty:

• TextView slouží pro zadání nějakého textu či čísla,
• Button je tlačítko, které po zmáčknutí vyvolá programově definovanou funkci,
• CheckBox je zaškrtávací políčko, které když je zaškrtnuto nabývá hodnoty true, pokud není, nabývá hodnoty false.

Výrazem CustomView se označují vizuální komponenty, které si programátor sám vytvořil. Tyto vizuální komponenty se vytvářejí programově, poté se na ně může odkazovat v XML návrhu. Tvorba CustomView je velmi užitečná při vytváření netypických prvků, které nejsou v základní nabídce vizuálních komponent. CustomView by měl být potomek třídy View nebo ViewGroup, jinak by nebylo možné jej správně vykreslit. CustomView může mít definované vlastní atributy v XML.

Aplikační principy platformy Android

Android aplikace jsou zkompilované zdrojové soubory, které jsou s dalšími prostředky zabalené do balíku s koncovkou apk. Ten slouží k instalaci na zařízení s OS Android a k další distribuci aplikace. [25]

Základní vlastností platformy Android je možnost v aplikaci využívat funkcionalitu jiné aplikace. Díky tomu se zamezí opakovanému vytváření stejné funkcionality a usnadní se tím práce vývojářů. Právě kvůli tomu byly aplikace navrženy jako balíky několika aplikačních komponent, u kterých lze vytvářet instance. Existují čtyři typy aplikačních komponent: Activity, Service, Broadcast receiver a Content provider.

Základní struktura aplikace

Aktivity jsou stavebními kameny pro tvorbu uživatelského rozhraní aplikace. Aplikace může mít neomezený počet aktivit, což je možné chápat jako analogii oken či dialogů aplikace pro stolní počítač. [1 s. 23]

Ačkoli je možné, aby aplikace neměli UI, většina zdrojového kódu aplikace bez UI bude obsahovat převážně dodavatele obsahu a služby.

Jak uživatel prochází mezi obrazovkami aplikace, tak instance aktivit prochází různými stavy. Těmto stavům se říká životní cyklus aktivity. Například, když je aplikace spuštěna poprvé, jde aktivita do popředí systému, říká se, že získala focus.

Během procesu změny stavu aktivity, volá Android řadu metod životního cyklu aktivity, v němž se nastavilo UI a další komponenty. Pokud uživatel provede činnost, která spustí jinou aktivitu nebo se přepne do jiné aplikace, systém zavolá další sadu metod životního cyklu aktivity.

Díky volání metod během změny stavu aktivity je možné definovat chování aplikace v určitých fázích životního cyklu aktivity, kdy je aktivita přesouvána do popředí nebo do pozadí systému, tedy aktivita získává nebo ztrácí focus.

Aktivity také zabraňují zbytečnému využívání procesoru, pokud jej daná aktivita nepotřebuje. Princip životního cyklu aktivity je nesmírně důležitý pro správnou činnost celého mobilního zařízení. Například pokud je obsluhována nějaká aplikace, a najednou přijde příchozí hovor, právě spuštěná aktivita spuštěné aplikace přejde do pozadí a do popředí přejde aplikace pro obsluhu telefonních hovorů. Po úspěšném či neúspěšném dokončení hovoru aktivita aplikace pro obsluhu telefonních hovorů přejde do pozadí, a do popředí přejde aktivita aplikace, která byla předtím spuštěna.

Během života aktivity systém zavolá několik metod životního cyklu aktivity v pořadí podobném pyramidě, viz schéma č. 1. To znamená, že každá fáze životního cyklu aktivity je samostatný krok na této pyramidě. [26]

Jakmile systém vytvoří instanci aktivity, každá metoda zpětného volání posune stav aktivity po pyramidě směrem nahoru. Samotný vrchol pyramidy je stav, kdy aktivita komunikuje s uživatelem (má focus).

Schéma č. 1: Stavový diagram životního cyklu aktivity

Zdroj: [26]

Celý životní cyklus aktivity se skládá ze sedmi metod zpětného volání: onCreate(), onStart(), onResume(), onPause(), onRestart(), onStop(), onDestroy(). V závislosti na složitosti aktivity pravděpodobně nebude potřeba implementovat veškeré metody zpětného volání. Nicméně je důležité každé této metodě porozumět a umět ji použít, aby aktivita pracovala přesně tak, jak se od ní očekává. [6, s. 133]

Vlivy změn stavů aktivit na správné chování aplikace:

• aplikace nesmí selhat, pokud uživatel příjme telefonní hovor nebo přepne do jiné aplikace,
• aplikace nespotřebovává cenné systémové zdroje, zatímco je aplikace neaktivní,
• aplikace neztrácí rozpracované data či pokrok v aplikaci, pokud uživatel přepne do jiné aplikace,
• aplikace nesmí selhat, pokud dojde k rotaci obrazovky.

Existuje několik situací, ve kterých aktivita přechází mezi různými stavy. Při každém přechodu aktivity do jiného stavu jsou volány již zmiňované metody zpětného volání, jak je vidět na schématu č. 1. Nicméně jenom tři stavy mohou být statické. To znamená, že aktivita může existovat jenom v jednom ze tří stavů po delší dobu.

Stavy, ve kterých se aktivity můžou nacházet:

• Resumed - v tomto stavu je aktivita v popředí a uživatel s ní může pracovat,
• Paused - v tomto stavu je aktivita částečně pozastavena,
• Stopped - aktivita je v tomto stavu pro uživatele úplně skrytá, čili je považováno, že je v pozadí. [6, s. 134]

Další stavy (Created a Started) jsou přechodné a systém mezi nimi přechází. To znamená, že poté, co se zavolá metoda onCreate(), aktivita přejde do stavu Created. Pak se zavolá metoda onStart() a poté, jakmile aktivita přejde do stavu Started, se zavolá metoda onResume(). Po tomto volání přejde aktivita to statického stavu Resumed, kde zůstává po delší dobu. Doba, po kterou aktivita zůstane ve stavu Resumed, se odvíjí od toho, jak uživatel pracuje s danou aktivitou.

Přechody mezi stavy by měli být rychlé, proto by v metodách zpětného volání nemělo docházet ke zbytečnému zdržování. Například při odchodu z aplikace není vhodné ukládat mnoho dat do souboru nebo přistupovat k síťovým prostředkům.

Pozastavení a obnovení aktivity

Během používání aktivity je někdy nutno aktivitu překrýt jinými grafickými komponenty, například dialog, což způsobí, že se zavolá metoda onPause(). Aktivita poté přejde do stavu Paused, kde zůstává tak dlouho, jak je v popředí vyvolaná grafická komponenta. Tím, že přejde aktivita do stavu Paused by se měli zastavit činnosti, které nejsou v tomto stavu potřebné, třeba přehrávání videa. [27]

Poté se uživatel může vrátit zpět k aktivitě. Pokud tak učiní, zavolá se metoda onResume() a aktivita přejde do stavu Resumed. V této části by se měla obnovit veškerá předešlá činnost aktivity.

Když aktivita obdrží volání onPause(), může to být známkou toho, že se aktivita na okamžik odmlčí. Uživatel se poté může vrátit zpět. Nicméně je to obvykle první náznak toho, že uživatel opouští aktivitu. [27]

Zastavení a restartování aktivity

Správné zastavení a restartování aktivity je důležitý proces v životním cyklu, který umožňuje uživatelům vnímat, že aplikace je stále aktuální a neztrácí progres. Aktivitu zastaví systémové volání metody onStop() a restartuje ji.

Metoda onStop() se volá v těchto případech:

• uživatel se vrátí k dříve otevřené aplikaci nebo otevře jinou aplikaci. Jakmile se uživatel vrátí k aplikaci, zavolá se metoda onRestart(),
• uživatel vyvolá v aplikaci činnost, která spustí jinou aktivitu v rámci aplikace,
• mezitím co uživatel používá aplikaci, obdrží telefonní hovor.

Pokud aktivita obdrží systémové volání onStop(), přesune se do stavu Stopped. Jakmile je v tomto stavu, systém může zahodit její instanci a uvolnit tak operační paměť, pokud jí má nedostatek. V extrémních případech systém může zrušit činnost celé aplikace bez volání metody onDestroy(). [28]

Existuje několik situací, ve kterých se aktivita ukončí v důsledku přirozeného průběhu aplikace, např. zmáčkne-li uživatel tlačítko zpět nebo dojde k otočení obrazovky, dojde k volání metody finish(). Pokud je tedy aktivita zničena, je zničena i její instance, ale systém si pamatuje, že taková instance existovala. Pokud uživatel například pomocí tlačítka zpět přejde na již zničenou instanci aktivity, systém vytvoří novou instanci zničené aktivity pomocí sady uložených dat.

Uložená data, nazývající se instance state, obsahují informace o stavu zničené aktivity a další doplňující informace identifikující danou aktivitu. Takto uložená data se uchovávají v objektu nazývaném Bundle, jenž je kolekcí dvojic klíč-hodnota. [29]

Je-li potřeba uložit jiná data, která jsou důležitá pro obnovení činnosti aktivity do objektu Bundle, musí se uložit v metodě zpětného volání onSaveInstanceState(Bundle). Systém volá tuto metodu, pokud uživatel opouští aktivitu a předá své metodě onSaveInstanceState(Bundle) objekt Bundle. Při návratu uživatele k aktivitě systém zavolá metody onRestoreInstanceState(Bundle) a OnCreate(). Metodě onRestoreInstanceState(Bundle) předá objekt Bundle s informacemi, které byly uloženy při předcházejícím systémovém volání onSaveInstanceState(Bundle). Tento děj volání metod pro uložení nebo načtení z objektu Bundle je vyobrazen na schématu č. 2.

Schéma č. 2: Ukládání proměnných do objektu Bundle (stavový diagram)

Zdroj: [29]

Způsob uchování aktivity

Aplikace většinou obsahují více aktivit. Každá aktivita by měla být navržena s ohledem na určitý typ akce, kterou může uživatel provést. Například emailové aplikace mají jednu aktivitu pro zobrazení seznamu všech emailů a druhou aktivitu pro zobrazení jednotlivých emailů. Aktivita v určité aplikaci může spustit aktivitu z jiné aplikace. [30]

Android všechny aktivity vkládá do zásobníku s názvem Back stack. Tento zásobník je typu LIFO, to znamená, že aktivita, která je do zásobníku umístěna jako první, opustí zásobník jako poslední, viz obrázek č. 3.

Jak můžeme vidět na obrázku č. 3, aktivita číslo 1 spouští aktivitu číslo 2, přičemž se uloží aktivita číslo 1 do zásobníku. Poté aktivita číslo 2 spustí aktivitu číslo 3, aktivita číslo 2 se uloží do zásobníku. Po zmáčknutí navigačního tlačítka „Zpět“ v aktivitě číslo 3 se tato aktivita zahodí a obnoví se aktivita číslo 2.

Obrázek č. 3: Vkládání aktivit do zásobníku a jejich rušení

Zdroj: [30]

Služby

Služba je část aplikace, která může provádět některé činnosti dlouhodobě na pozadí a neposkytuje žádné UI, přičemž jiná aplikační komponenta může spustit službu a ta bude pracovat v pozadí, i když uživatel přepne do jiné aplikace. Navíc se komponenta může vázat neboli komunikovat s touto službou, dokonce může provádět mezi procesorovou komunikaci (IPC). [31]

Služby mohou pokračovat ve své činnosti, i když byla aktivita, ze které byla tato služba spuštěna, ukončena. Používají se ke stahování či nahrávání dat, přehrávání hudby po ukončení aktivity, atd. Službu lze kdykoliv bezproblémově ukončit. [1, s. 23]

Služby se vyskytují ve dvou stavech:

1. Started - služba je spuštěna, když aplikační komponenta, například aktivita, spustí službu voláním metody startService(). Po spuštění může služba běžet po dobu neurčitou, i když aplikační komponenta, která ji spustila, byla ukončena. Obvykle takto spuštěná služba provádí jednu činnost a nevrací žádný výsledek. Po dokončení činnosti se sama vypne. Používá se například pro stahování dat ze sítě.
2. Bound - aplikační komponenta spouští službu a váže se na ni voláním metody bindService(). Vázaná služba nabízí rozhraní klient-server, jenž dovoluje aplikační komponentě komunikovat se spuštěnou službou. Ke stejné službě může získat přístup více aplikačních komponent, ale pokud se všechny odpojí, služba přestane existovat.

Pravidla vizuálního návrhu pro platformu Android

Společnost Google Inc. navádí vývojáře aplikací, aby vytvářeli vizuální návrh zajímavý, ale zároveň jednoduchý. Uživatel by měl být schopen se v každé aplikaci co nejrychleji zorientovat. Například se upouští od klasických tlačítek, místo nich se používají tlačítka tvořené z ikon, protože člověk se snáze a rychleji orientuje podle obrázků. Do vizuálního návrhu patří také návrh textů. Upřednostňují se krátké jednoduché texty obsahující co nejvíce informací.

UI operačního systému Android se skládá ze tří obrazovek (Home screen, All apps screen, Recents screen), ze kterých je možné přistupovat do aplikace. Každá aplikace, běžící na platformě Android od verze API 16, má tři společné navigační panely, pomocí kterých je možné ovládat aplikaci. [34]

Obrázek č. 4: Vizuální rozvržení aplikace

Zdroj: [34]

Následující číselný seznam odpovídá číslům na obrázku č. 4:

1. Main ActionBar umožňuje vývojáři vytvořit vlastní hierarchii pro navigaci v aplikaci. Panel také slouží k informování uživatele o jeho umístění v aplikaci,

1. View Controll umožňuje uživateli přepínat mezi různými zobrazeními, která aplikace poskytuje. Zobrazení se většinou skládají z různých funkčních aspektů nebo různého uspořádání dat,
2. Content Area je místo pro samotnou aplikaci,
3. Split ActionBar je další panel, který se používá, pokud je Main ActionBar přeplněn.

Mobilní zařízení a obrazovky

Android obsluhuje mobilní zařízení s různou fyzickou velikostí, rozlišením a hustotou obrazovek (dpi). Jelikož mobilní zařízení využívají různé fyzické rozměry a typy obrazovek, jsou kategorizovány do čtyř kategorií v závislosti na jejich úhlopříčce (small, normal, large, xlarge), což můžeme vidět na obrázku č. 5. Do čtyř kategorií je také kategorizována hustota obrazovky (dpi), kategorie jsou: ldpi, mdpi, hdpi, xhdpi (viz obrázek č. 7).

Obrázek č. 5: Fyzické rozměry a hustota obrazovky

Zdroj: [35], vlastní zpracování

Pixel zobrazovaný na velké obrazovce s rozlišením 1280 × 800 bude větší než pixel na menší obrazovce se stejným rozlišením. Pokud by se používala jednotka pixel na menších obrazovkách, některé prvky by byly hůře viditelné. Aby k tomuto nedocházelo, platforma Android zavedla jednotku virtuálního pixelu dp, který se počítá na základě hustoty obrazovky (dpi) podle vzorce:

[math]\mathit{px}=\frac{\mathit{dp}\ast \mathit{dpi}}{160}[/math] [35]  

Podle tohoto vzorce Android automaticky dopočítá pro každé mobilní zařízení jednotku dp. Tím se zajistí, že zobrazovaný bod, text nebo odsazení bude na všech mobilních zařízeních téměř totožné, avšak může dojít k nepatrným nepřesnostem.

Pokud se vytvoří vizuální objekt o konstantních rozměrech v jednotkách dp a zobrazí se na dvou zařízeních s různě velkými obrazovkami, bude mít tento objekt na obou zařízeních stejné fyzické rozměry.

Při návrhu vizuálního layoutu se musí brát ohled na to, že při zobrazení layoutu pro obrazovkou small bude na obrazovce xlarge ve většině případů spoustu nevyužitého místa. Proto se v některých situacích vytváří layout pro každou kategorii velikosti obrazovky zvlášť. Poté se umístí do adresářové struktury tak, aby layout vytvořený pro obrazovky small byl ve složce určené právě pro ně.

Adresářová struktura pro umístění layout:

• res/layout/layout.xml - Layout pro normal obrazovky (výchozí)
• res/layout-small/layout.xml - Layout pro small obrazovky
• res/layout-large/layout.xml - Layout pro large obrazovky
• res/layout-xlarge/layout.xml - Layout pro xlarge obrazovky

Pokud se tak neučiní, bude se načítat výchozí layout, který je umístěný v adresáři res/layout/.

Při vytváření obrázku nebo ikony aplikace nelze v grafickém editoru použít jednotku virtuálního pixelu dp, proto se využívá kategorií hustot obrazovky, kde se určí u jednotlivých hustot obrazovek střední hodnota. Střední hodnota kategorie mdpi je 160dpi, což znamená, že jestliže se dosadí tato hodnota do vzorce a za jednotku dp se dosadí hodnota 1, zjistí se, že velikost jednoho dp je jeden pixel. Z toho plyne, že pro obrazovky s hustotou mdpi je jeden pixel stejně velký jako dp. Tento poměr 1:1 je vidět i na obrázku č. 6, kde se při špatném zobrazení používají jednotky pixel a při správném zobrazení jednotky dp. Vytváření obrázků a ikon v grafických editorech se proto vytváří nejprve pro obrazovky s hustotou mdpi, a poté se zvětšují nebo zmenšují do požadovaných hustotních kategorií. Velikost stran obrázku se vypočítá podle předcházejícího vzorce.

Upravený obrázek se pak umístní do adresářové struktury na místo:

• res/drawable-ldpi/obrazek.png - obrázek pro hustotu obrazovky ldpi
• res/drawable-mdpi/obrazek.png - obrázek pro hustotu obrazovky mdpi
• res/drawable-hdpi/obrazek.png - obrázek pro hustotu obrazovky hdpi
• res/drawable-xhdpi/obrazek.png - obrázek pro hustotu obrazovky xhdpi

Rozdíl mezi špatně a správně vytvořeným a zobrazeným obrázkem je jasně viditelný na obrázku č. 6, kde při špatném zobrazení je na první pohled jasné, že při nepoužití dp dochází k rozdílnému zobrazení prvku na různých obrazovkách.

Obrázek č. 6: Zobrazení prvků na různých velikostech obrazovky

Zdroj: [35]

Při použití zobrazovacích jednotek pixel (obrázek č. 6, druhá řada) jsou jednotlivé prvky na různých obrazovkách rozdílné. Liší se velikostí i uspořádáním, přičemž tlačítko na větším rozlišení obrazovky je menší (obrázek č. 6, druhá řada, třetí sloupec), než to stejné tlačítko zobrazené na obrazovce s menším rozlišením (obrázek č. 6, druhá řada, první sloupec), kdežto v případě zobrazování prvků pomocí zobrazovacích jednotek dp jsou prvky na všech obrazovkách stejně veliké (obrázek 6, první řada).

Grafický styl

Pro vytvoření graficky moderní a uživatelsky příjemné aplikace je vhodné brát ohled na doporučované principy tvorby UI od firmy Google. Principy se vztahují na vhodný výběr barev, umístění objektů a výběr písma. Dokonce se tyto principy vztahují i na tvorbu jednoduchých a srozumitelných textů.

Grafické motivy

Google poskytuje několik základních grafických motivů, které definují vizuální styl a vlastnosti prvků. Grafický motiv je šablona, která zajišťuje, aby poskytované grafické prvky měli definované vlastnosti, tvar a vzhled. Například dialog má v jednom grafickém motivu odlišné barevné a tvarové kombinace než v jiném motivu. [36][2, s. 48]

Motivy jsou navrženy tak, aby vypadali vzhledně a čitelně na všech zařízeních s OS Android. Není potom nutné u některých prvků nastavovat velikostní rozměry, protože prvek v tomto motivu má pro různé velikosti obrazovek předem dopočítanou velikost. Dopočítané velikosti však nejsou prioritní, proto ji vývojář může změnit.

Mezi grafické motivy od verze API 11 patří:

• Holo Light,
• Holo Dark,
• Holo Light s tmavým ActionBar. [36]

Mezi grafické motivy do verze API 11 patří:

• Theme,
• Theme Light,
• Theme Black. [36]

Zpětná odezva

Grafické prvky ovládané uživatelem mají grafickou nebo zvukovou odezvu tak, aby bylo uživateli jasné, zda kliknul na ovládací prvek. Tato grafická odezva také slouží k odlišení vybraných a neaktivních. Grafická odezva je reprezentována změnou barvy či průhledností prvku. Uvádí se, že aktivní prvek je neprůhledný, neaktivní prvek je průhledný ze 70 % a vybraný prvek je poloprůhledný s okrajem.

Navigace

Navigace napříč aplikací je funkce systému Android, která zajišťuje, aby uživatel mohl aplikací bezproblémově procházet. Tato navigace se dělí na dvě části. První část je do verze API 11, kde jako hlavní navigační prvek vystupuje tlačítko zpět. Druhý pramen je od verze API 11, kde k tlačítku zpět přibylo tlačítko s obecným označením „nahoru“ a ovládací lišta ActionBar.

Obrázek č. 7: Princip navigace pomocí tlačítka zpět a up

Zdroj: [37]

Tlačítko „Zpět“ pracuje na principu návratu k předchozí aktivitě, která byla jako poslední vložena do zásobníku. Například po otevření aplikace Gmail z hlavního menu dojde k zobrazení seznamu příchozích emailů. Pokud se otevře některý email z tohoto seznamu, dojde k zobrazení aktivity pro čtení jednotlivých emailů. Zmáčkne-li se v této fázi aplikace tlačítko „Zpět“, vyvolá se předchozí aktivita pro zobrazení seznamu příchozích emailů. Zmáčknutím tlačítka „Zpět“ v tomto místě dojde k opuštění aplikace. Celý tento proces využití tlačítka „Zpět“ je vyobrazen na obrázku č. 7.

Zavedením tlačítka „Nahoru“ (API 11) se tvoří určitá hierarchie dané aplikace. Tlačítko „Nahoru“ se nachází v levé horní části obrazovky, což znamená, že se nachází v  ActionBar. Reprezentuje jej špičatá závorka spolu s ikonou aplikace. Toto tlačítko slouží pro návrat do předem určené části aplikace. [38][37]

Například při čtení příchozích emailů pomocí aplikace Gmail dojde ke zmáčknutí tlačítka „Nahoru“ a do popředí přejde aktivita pro zobrazení seznamu emailů. Na funkci tohoto tlačítka nemají vliv dříve spuštěné aktivity. Dokonce na toto tlačítko nemá vliv ani aktivita, která se nachází v horní části zásobníku, což neplatí při použití tlačítka „Zpět“. Celý tento popisovaný děj je zachycen na obrázku č. 7.

Možnosti využití ActionBar

ActionBar, viz obrázek č. 10, je lišta, která slouží pro zobrazení různých nástrojů a navigací. Tato lišta je umístněna v horní části obrazovky a často v ní bývá umístěna ikona aplikace, vyhledávání, sdílení, informační popisky, nastavení atd. ActionBar je tedy vývojáři definovaná lišta, která obsahuje navigační a ovládací prvky. [38]

Možnost zobrazení ActionBar přibyla ve verzi API 11. Pokud je potřeba, aby se ActionBar zobrazil, je třeba nastavit doporučenou verzi na vyšší nebo stejnou jako API 11 v souboru AndroidManifest.xml.

Kód pro nastavení minimální a doporučené verze API:

<uses-sdk android:minSdkVersion="8"

android:targetSdkVersion="11" />

ActionBar obsahuje řadu ikon reprezentujících různé funkce, další rozbalovací menu a navigační prvky. Tyto funkce a navigační nástroje si vývojář vytváří sám, což vývojáři umožní lehce vytvořit vlastní navigační hierarchii. [38]

Obrázek č. 8: Lišta ActionBar

Zdroj: [39]

Popis jednotlivých částí obrázku č. 8:

1. logo aplikace sloužící jako navigační tlačítko nahoru, pokud jej doprovází šipka vlevo,

1. pokud aplikace obsluhuje jiné view, jsou zobrazena v tomto rozbalovacím menu,
2. slouží pro přídavná akční tlačítka,
3. rozbalovací menu obsahující méně používané akční položky, jako nastavení atd.

Nastavení je místo v aplikaci, kde uživatelé mohou modifikovat chování aplikace nebo si aplikaci přizpůsobit, například vzhled aplikace. Položce nastavení se klade malý důraz, protože není často používanou položkou. Většinou se použije pouze k určitému přizpůsobení a poté se víckrát nepoužívá. Proto se položka nastavení umisťuje do přídavného menu, které je reprezentováno třemi tečkami umístěnými nad sebou, nebo hardwarovým tlačítkem. Položky v nastavení by měli být srozumitelné běžným uživatelům a měli by mít jednoduchý popisek, který trefně a jednoduše popisuje to, co daná položka ovládá či modifikuje.

Testování aplikace

Kvalita aplikace přímo ovlivňuje dlouhodobý úspěch aplikace ve smyslu počtu instalací, hodnocení aplikace a udržení si uživatelů. Uživatelé inteligentních zařízení s OS Android očekávají vysoce kvalitní aplikace s důrazem na jejich správnou funkčnost, ale i na design. Při návrhu by měla být respektována metodika pro tvorbu designu aplikace.

Firma Google publikovala na vývojářském portálu dokument pod názvem „App Quality“, který definuje sérii testů pro posouzení úrovně kvality aplikace. [40]

Před publikováním aplikace by měl vývojář podrobit svou aplikaci sérii těchto testů, které hodnotí aplikaci z pohledu správného fungování na různých zařízeních Android, definovaného způsobu navigace v rámci aplikace a designu aplikace. Účelem dokumentu „App Quality“ je tedy definovat základní kvalitativní metriky při testování.

Dokument obsahuje 3 části:

1. základní parametry kvality [41],

1. parametry kvality aplikací pro tablety [42],
2. pokročilé metody zvyšování kvality [43].

První část dokumentu "Základní parametry kvality" se skládá ze čtyř sérií testů:

• design aplikací a interakce s uživatelem,
• funkcionalita,
• výkon a stabilita,
• Obchod Play.

Druhá část dokumentu se zaměřuje na parametry kvality aplikací určené i pro tablety. Tato metodika definuje následující části:

• test základní funkcionality aplikací,
• optimalizace designu aplikace pro velké displeje,
• využití nových prvků designu pro velké displeje,
• správné použití velikosti grafiky a písma,
• úprava velikosti widgetů pro tablety,
• implementování plné funkcionality aplikace na tabletu (pokud existuje aplikace pro telefon),
• správné nastavení cílové verze API,
• prezentace grafiky pro tablety na obchodě Play.

Třetí část dokumentu se zabývá publikováním aplikace na Google Play ve spojení s kvalitou aplikace.

Tento dokument definuje následující části:

• reagovat na přání a stížnosti uživatelů,
• zlepšení stability aplikace a odstranění chyb,
• maximální rychlost reakce uživatelského rozhraní,
• profesionální vzhled a estetika aplikace,
• správná funkcionalita všech funkcí aplikace.