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
Mobilní aplikace pro výuku jazyků Tadeáš Sosín
Vedoucí práce: Ing. Vladislav Skoumal
13. května 2014
Poděkování Zde bych chtěl poděkovat svým rodičům za podporu při studiu nejen na vysoké škole a vedoucímu práce Ing. Vladislavu Skoumalovi za věnovaný čas.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval(a) samostatně a že jsem uvedl(a) 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 13. května 2014
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2014 Tadeáš Sosín. 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 Sosín, Tadeáš. Mobilní aplikace pro výuku jazyků. Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2014.
Abstrakt Cílem práce je vytvořit projekt, který usnadní výuku slovní zásoby. Aplikace nabízí inteligentní zobrazování slov na základě předchozích odpovědí. Výhody aplikace jsou komunitou vytvářené balíčky slov a jednoduchý grafický design. Práce popisuje vývoj mobilní aplikace od analýzy až po testování. Technická část se zaměřuje především na uživatelské prostředí a funkční prototyp. Klíčová slova slovní zásoba
mobilní aplikace, Android, drátěný model, výuka jazyků,
Abstract The aim of the thesis is to realize a project which makes the process of learning new vocabulary easier. Application offers intelligent testing based on previous answers. Advantages of the application are vocabulary packages created by community and simple graphic design. Thesis describes the development of mobile application from the analysis to testing. Technical part concerns mainly with user interface and functional prototype. Keywords mobile application, Android, wireframe, language teaching, vocabulary ix
Obsah Úvod
1
1 Specifikace cíle, průzkum 1.1 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Uživatelský průzkum . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Analýza trhu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 3 5
2 Analýza 2.1 Persony . . . . . 2.2 Případy užití . . 2.3 Požadavky . . . . 2.4 Doménový model 2.5 Procesy . . . . .
. . . . .
. . . . .
3 Návrh 3.1 Drátěný model . . . 3.2 Platforma . . . . . . 3.3 Architektura . . . . 3.4 Schéma databáze . . 3.5 Diagram komponent
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
9 9 12 20 21 22
. . . . .
25 25 33 35 36 37
4 Realizace 41 4.1 Volba nástrojů . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4.2 Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.3 Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5 Testování 49 5.1 Automatizované testy . . . . . . . . . . . . . . . . . . . . . . . 49 5.2 Ruční testování . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 xi
Závěr
53
Literatura
55
A Seznam použitých zkratek
59
B Obsah přiloženého CD
61
xii
Seznam obrázků 2.1 2.2 2.3 2.4
Diagram: Diagram: Diagram: Diagram:
Obecné případy užití . . . . . . . . . . Případy užití Správa vlastních balíčků Případy užití Správa cizích balíčků . . Doménový model . . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
12 15 19 22
3.1 3.2 3.3 3.4 3.5 3.6 3.7
Screenshot: Axure RP 7 . . . . . . . . . . . . . . . Drátěný model: Navigation drawer . . . . . . . . . Drátěný model: Obrazovka učení . . . . . . . . . . Drátěný model: Obrazovka statistiky balíčku . . . Drátěný model: Obrazovka s doporučenými balíčky Diagram komponent . . . . . . . . . . . . . . . . . Databázový model . . . . . . . . . . . . . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
26 28 29 30 31 38 39
4.1 4.2
Model REST komunikace . . . . . . . . . . . . . . . . . . . . . . . Diagram nasazení . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44 47
xiii
Úvod Výuka jazyků provází velkou část populace nejen studentským životem. Každý kdo se učí cizímu jazyku musí pro jeho zvládnutí vedle gramatické stránky ovládat i jeho slovní zásobu. Ne vždy je však výuka slovní zásoby tak efektivní jak by mohla být. Například složité vyhledávání slov dle oblastí zájmu, mnoho učebnic pro výuku nebo časté opakované čtení již zvládnutých slov může snížit tuto efektivitu. Tyto důvody nás vedly k vytvoření mobilní aplikace, která uživatelům zpříjemní a zefektivní jejich výuku. Vedle chytré výuky slov aplikace disponuje podpůrnými funkcemi jako sdílení vytvořených balíčků mezi uživatele aplikace. Uživatelé tak mohou vyhledat balíček slov podle jazykové úrovně nebo třeba jeho specializace a ihned započít výuku. Dále mezi podpůrné funkce patří například připomínání učení v daný čas nebo možnost vybrat si učební metodu. Práce začíná uživatelským průzkumem kvůli lepšímu pochopení základních potřeb při výuce. Posléze je provedena analýza konkurenčních řešení sloužící k posouzení současné situace aplikací zabývajících se touto problematikou. Samotná kapitola ohledně analýzy práce je založena právě na těchto průzkumech. Analýza prochází od tvorby pomocných person až po rozbor jednotlivých procesů aplikace. Návrh má za cíl především vytvořit kvalitní uživatelské rozhraní. Z toho důvodu je vedle vytvoření drátěného modelu provedeno i jeho následné testování na zástupcích cílových skupin. Na konci kapitoly je rozebrána architektura práce, schéma databáze a diagram komponent. Realizační část rozebírá volbu nástrojů pro vývoj a podpůrné činnosti. Samotná sekce implementace zmiňuje zajímavosti z průběhu programování prototypu. Kapitola je následně zakončena diagramem nasazení. 1
Úvod
Kapitola testování se věnuje především způsobům testování mobilní aplikace. Rozbor se zaobírá jak ručním tak automatizovaným testováním, ve kterém je představeno několik nástrojů pro automatické testy.
2
Kapitola
Specifikace cíle, průzkum 1.1
Cíl práce
Cílem této práce je vytvořit aplikaci pro výuku slovní zásoby, která by uživatelům umožnila učit se nová slova co nejefektivněji. Výsledná aplikace bude prvotně zaměřena na jednu z mobilních platformem. Analýza aplikace bude uzpůsobena požadavkům dotazovaných lidí. Tím a vyvarováním se chyb konkurenčních aplikací chceme dosáhnout uplatnění aplikace na mobilním trhu.
1.2
Uživatelský průzkum
Průzkum se zaměřuje především na objasnění potřeb běžných uživatelů, které budou zahrnuty do následné analýzy. Pochopení těchto potřeb a aktuálních návyků uživatelů při výuce slovní zásoby pomůže k vytvoření kvalitní analýzy aplikace. Dotazovaní lidé jsou zástupci jednotlivých skupin potencionálních uživatelů aplikace. Jedná se o zástupce studentů i pracujících. První otázka je na všeobecné informace o respondentovi, aby mohl být zařazen do jedné z výše uvedených skupin. Dotazování na úroveň jazyků je důležité pro porovnaní s ostatními respondenty. Další otázky jsou zaměřeny především na pochopení studijních pomůcek uživatelů a jejich postoj k elektronickým formám učení. Cílem je zjistit jak moc se liší postoje k eletronickým pomůckám při výuce a případně co se od podobné aplikace očekává. 3
1
1. Specifikace cíle, průzkum
1.2.1
Ukázkový respondent
Základní informace: • žena • 27 let • vdaná • jedno dítě • dokončené středoškolské vzdělání Jaké papírové a elektronické pomůcky v současné době používáte pro studium jazyků? • papírové – učebnice od nakladatelství POLYGLOT – slovníky – výhoda nepravidelná slovesa nebo gramatika • elektronické – webová stránka Help for English – aplikace Next Level English Vocabulary – webový slovník od Seznam.cz – aplikace Color dict Co očekáváte od aplikace na učení slovíček? • více způsobů učení • možnost nastavit si upomínku aplikace na konkrétní čas • pochvala za úspěchy • widget na plochu • tématické okruhy tvořené podle učebnic • souboje s ostatními uživateli, bodování, hodnocení, žebříčky
1.2.2
Shrnutí
Žádnému respondentovi nevadí využívat při výuce elektronické pomůcky, jednotlivé požadavky byly poměrně jednotné. Především se jednalo o zpříjemnění výuky, pro některé to znamenalo automatické připomínání a jiní viděli jako zpříjemnění výuky sociální zapojení aplikace. Socíálním prvkům jako hry s kamarády nebo sdílení statistik davají přednost mladší generace, starší generace upřednostňují pouze samostatnou výuku. 4
1.3. Analýza trhu
1.3
Analýza trhu
Následující rešerše aktuálních řešení aplikací pro výuky jazyků se snaží zmonitorovat situaci především na mobilních platformách, ale kvůli důležitému přehledu se aspoň minimálně podívá i na řešení na jiných platformách.
1.3.1
Next level english vocabulary
Jedná se o aplikaci, kterou český uživatel najde jako jednu z prvních na platformě Android, jelikož se objevuje v předních příčkách při vyhledávání. Nabízí více druhů učení slovní zásoby [16]. Uživatelské rozhraní je místy nepřehledné, zvláště když se na obrazovkách objevuje mnoho textu. Uživateli nabízí tyto funkce: • Výuka pomocí flashcards1 • Nastavení úrovně uživatele • Vytvoření vlastní lekce – placená verze • Poslech zvukové stopy u vybraných slov
1.3.2
Slovíčka
Aplikace získává výukové balíčky prostřednictvím uživatelů, kteří své vytvořené balíčky mohou vystavit pro ostatní uživatele [28]. Díky tomuto přístupu aplikace nabízí dostatečné množství balíčků. Vzhled aplikace nerespektuje doporučení Android design guidelines, vypadá poměrně zastarale vůči aktuálnímu designu aplikací. Dále je například stahování balíčku velice nepraktické a uživatelsky nepřívětivé. Poslední update na platformě Android se objevil před rokem, takže je pravděpodobné, že další podpora aplikace byla ukončena. Klady aplikace: • Balíčky vytvářené samotnou komunitou • Možnost jednoduché výuky ve webovém prohlížeči Zápory aplikace: • Nepřehlednost • Zastaralý vzhled 1
Karta s informací na obou stranách. Jedna strana jako otázka, druhá jako odpověd.
5
1. Specifikace cíle, průzkum
1.3.3
PowerVocab
Tato aplikace se snaží využít hlavně sociální prvky ve výuce, takže by se dalo říct, že se jedná o učení hrou [23]. Uživatelé mohou spustit výuku i sami, ale hlavní důraz je kladen na hry mezi uživateli, kde musí uživatel prokázat znalost slovní zásoby. Špatně zodpovězená slova poté lze procvičovat mezi jednotlivými hrami. Dle velkého počtu stažení oproti konkurenci je možné vidět, že aplikace je úspěšná především z důvodů sociálních prvků, protože ostatní faktory aplikace jsou průměrné až podprůměrné, například přeplněné a občas nepřehledné grafické uživatelské prostředí.
1.3.4
English 4 kids
Aplikace je statická, obsahuje deset kategorií pro výuku a žádné další možnosti. Cílovou věkovou kategorií jsou děti [17]. Výuková metoda je od jiných aplikací odlišná v tom, že učené slovo je vysloveno anglicky a poté hned zobrazeno, přičemž po celou dobu je jako pozadí nastaven obrázek učeného slova. Do rešerše je tato aplikace vybrána jako jediný zástupce aplikací, které se zaměřují na výuku dětí. Velice pozitivně se dá hodnotit zvuková stopa použítá v aplikaci u všech slov nabízených k učení.
1.3.5
Anki
Rozšířená multiplatformní aplikace [9], která je zaměřená na výukovou metodu flashcards, nejedná se pouze o výuku jazyků, ale balíčky pro učení obsahují znalosti z různých oborů. Systém balíčků umožňuje jak vlastní vytváření, tak stáhnutí vytvořených balíčků jinými uživateli. Mobilní aplikace se snaží dodržovat Android design guidelines, tudíž pro nové uživatele je uživatelsky přívětivá a poměrně přehledná. Obsahuje bohaté možnosti nastavení, avšak v některých případech není jasné k čemu dané nastavení slouží. Samotná výuka neobsahuje žádné výrazné nedostatky. Celkově se jedná na mobilní platformě Android o jednu z nejlépe hodnocených aplikací, využívající učební metodu flashcards. Anki je dostupné i na jiných platformách než jen na platformě Android. Například ho lze využívat na platformě Windows, Mac, iOS, Ubuntu a dalších. Výuku lze spustit i ve webovém prohlížeči, avšak nejlepší kvalitu dosahují aplikace pro platformy Android a iOS. 6
1.3. Analýza trhu
1.3.6
Shrnutí
Nabízená funkcionalita aplikací je dostačující, avšak tato funkcionalita je rozprostřena mezi všechny aplikace. Mnoho aplikací má špatně navržené grafické rozhraní, především z důvodů nerespektování doporučení pro vzhled nativních aplikací. Aplikace, která se bude snažit přebrat od svých konkurentů to nejlepší a zároveň omezí své zápory na minimum, by si mohla na trhu najít své místo.
7
Kapitola
Analýza 2.1
Persony
Vytvoření virtuálních reprezentantů cílových skupin, pomůže k uvědomění si pro koho je aplikace vytvářena a jaké jsou potřeby daných zástupců [26]. Jelikož student základní školy má jiné priority a potřeby ve výuce než dospělý vydělávající člověk. Případně o co se naopak dané persony nezajímají nebo co je obtěžuje.
2.1.1
Vytvořené persony
Tomáš Věk: 18 let Povolání: student střední školy Bydliště: Město Albrechtice Profil: Společenský a sportovně založený. Aktuálně navštěvuje střední školu se zaměřením na informační technologie, kde má problémy s angličtinou. Polovina jeho testů je totiž tvořena pouze slovní zásobou. Doma se nikdy nepřinutí k učení, jediná jeho výuka probíhá ve vlaku cestou do školy. Tomášovy cíle: • Hledá aplikaci, u které by vydržel déle než hodinu • Chce aby ho učila jen slovíčka, která využije na test • Chce lehce začít procvičovat, když jede vlakem • Chce mít přehled o tom, jak moc daná slovíčka na test již umí 9
2
2. Analýza • Nechce pokaždé sám vkládat slova na test • Chtěl by upozornění, že se má jít učit Naše cíle: • Aby informoval kamarády o aplikaci • Aby vytvořil balíček slov na test a nenechal si ho jen pro sebe • Motivovat Tomáše aby u aplikace vydržel • Nabídnout Tomášovi i jiná slova než jen na test Martina Věk: 31 let Povolání: zástupce manažera v české firmě Bydliště: Praha Profil: Ambiciozní sympatická žena se zájmém o literaturu, která pracuje na pozici zástupce manažera. Dostala nabídku na povýšení, když se do jisté doby zvládne naučit další světový jazyk. Již má za sebou půlroční kurz španělštiny a nyní potřebuje především nabrat slovní zásobu. Martininy cíle: • Chce se učit nejprve všeobecnou slovní zásobu a poté jen zaměřenou na svůj obor • Chce maximalizovat svou schopnost učit se nová slova • Chce vidět kolik slov již umí, případně kolik slov je ze specifické oblasti • Na stolním počítači má v excelu slovní zásobu z kurzu, kterou by se ráda naučila Naše cíle: • Provést Martinu učebním procesem • Nabídnout Martině možnost sdílet její balíčky
10
2.1. Persony
Petr Věk: 12 let Povolání: student základní školy Bydliště: Krnov Profil: Mladý student plný energie, který ve volném čase chodí do turistického kroužku. Jeho sen je jednou cestovat, a proto ve škole pilně studuje anglický jazyk. Petr je společenský člověk, často vyhledává kontakt s kamarády, ať už kvůli hraní her nebo jejich doučování anglického jazyka. V poslední době se začal vzdělávat v anglickém jazyce i ve svém volném čase. Petrovy cíle: • Doma se chce anglický jazyk učit zábavnou formou • Chtěl by motivovat i svého kamaráda Jirku do učení • Nechce sepisovat slova, která by se chtěl učit Naše cíle: • Aby šířil aplikaci mezi svými vrstevníky • Ukázat mu slovní balíčky odpovídající jeho jazykové úrovni
Lenka Věk: 22 let Povolání: student vysoké školy Bydliště: Ostrava Profil: Poměrně pohodlná studentka, která má ráda noční život a brouzdání po internetu. Ve škole se rozhodla, že nechce navštěvovat kurz angličtiny, který trvá tři semestry, a proto se nyní připravuje na cambridgskou zkoušku PET, kterou potřebuje místo školou nabízeného kurzu. S gramatikou a mluvením nikdy neměla v cizím jazyce problém, ale ve slovní zásobě pro složení zkoušky PET má značné nedostatky. Lenčiny cíle: • Potřebuje mít výuku kdykoliv dostupnou – hodně cestuje v MHD • Hledá individuální plán výuky, nechce se učit jen 20 slov denně • Chtěla by vědět za jak dlouho slovo zapomene 11
2. Analýza Naše cíle: • Zajistit potřebné balíčky slov pro základní zkoušky • Umožnit uživateli vlastní přizpůsobení učení
2.2
Případy užití
Následující grafy a scénáře užití znázorňují, jak bude aplikace používána uživatelem. Po každém diagramu případu užití následuje popis jednotlivých scénářů.
2.2.1
Obecné případy užítí
Obrázek 2.1: Diagram: Obecné případy užití Přihlášení Stručný popis Přiřazení uživatele pod emailovou adresu
12
2.2. Případy užití Hlavní aktéři Uživatel Vstupní podmínky Žádné Hlavní scénář • Uživatel klikne na tlačítko „Přihlásit se“. • Aplikace zobrazí obrazovku pro vložení emailové adresy. • Uživatel vyplní emailovou adresu a požádá o ověření. • Aplikace pošle na danou emailovou adresu ověřovací email. • Uživatel ověří email, který mu byl zaslán. • Aplikace spojí uživatele s daným emailovým účtem. Výstupní podmínky Žádné Alternativní scénáře Žádné
Spustit výuku Stručný popis Spuštění výuky slov. Hlavní aktéři Uživatel Vstupní podmínky Uživatel musí vlastnit aspoň jeden neprázdný balíček slov. Hlavní scénář • Uživatel vybere balíček, který se chce učit, a klikne na něj. • Aplikace zobrazí obrazovku s výukou. Výstupní podmínky Žádné Alternativní scénáře Žádné
Změnit typ výuky Stručný popis Uživatel si změní v průběhu výuky její typ.
13
2. Analýza Hlavní aktéři Uživatel Vstupní podmínky Uživatel musí vlastnit aspoň jeden neprázdný balíček slov. Hlavní scénář •
Spustit výuku • Uživatel otevře menu a vybere možnost „Typ výuky“. • Aplikace zobrazí obrazovku s výběrem typu výuky. • Uživatel vybere požadovaný typ výuky. • Aplikace se vrátí na obrazovku s výukou slov, nyní se změněným typem výuky dle uživatelova výběru. Výstupní podmínky Žádné Alternativní scénáře Žádné
2.2.2
Správa vlastních balíčků
Zobrazit vlastní balíčky Stručný popis Zobrazení vlastních balíčků uživatele. Hlavní aktéři Uživatel Vstupní podmínky Žádné Hlavní scénář • Uživatel klikne na tlačítko „Správa balíčků“. • Aplikace zobrazí obrazovku s jeho balíčky. Výstupní podmínky Žádné Alternativní scénáře Žádné Zobrazit vlastní balíček Stručný popis Zobrazení vlastního balíčku uživatele
14
2.2. Případy užití
Obrázek 2.2: Diagram: Případy užití Správa vlastních balíčků
Hlavní aktéři Uživatel Vstupní podmínky Uživatel musí mít vytvořený alespoň jeden balíček slov. Hlavní scénář • Zobrazit vlastní balíčky. • Uživatel klikne na vlastní balíček. • Aplikace zobrazí obrazovku detailu balíčku. 15
2. Analýza Výstupní podmínky Žádné Alternativní scénáře Žádné
Vytvořit balíček Stručný popis Vytvoření nového balíčku uživatele Hlavní aktéři Uživatel Vstupní podmínky Žádné Hlavní scénář • Uživatel klikne na tlačítko „Vytvořit balíček“. • Aplikace zobrazí obrazovku pro vyplnění údaju nového balíčku. • Uživatel vyplní údaje a potvrdí vytvoření. • Aplikace vytvoří nový balíček. • Aplikace zobrazí obrazovku balíčku, aby uživatel mohl provádět případné další úpravy. Výstupní podmínky Žádné Alternativní scénáře Žádné
Vložit nové slovo Stručný popis Vloží nové slovo do balíčku. Hlavní aktéři Uživatel Vstupní podmínky Uživatel musí mít vytvořený alespoň jeden balíček Hlavní scénář • Zobrazit vlastní balíček. • Uživatel klikne na tlačítko pro přidání nového slova. • Aplikace zobrazí obrazovku pro vyplnění potřebných údajů. 16
2.2. Případy užití • Uživatel vyplní údaje o novém slovu a potvrdí jeho přidání. • Aplikace uloží nové slovo do balíčku. • Aplikace zobrazí detail balíčku, aby uživatel mohl prodávět případné další úpravy. Výstupní podmínky Žádné Alternativní scénáře Žádné
Odstranit balíček Stručný popis Odstraní uživatelův balíček. Hlavní aktéři Uživatel Vstupní podmínky Uživatel musí mít vytvořený alespoň jeden balíček Hlavní scénář • Zobrazit vlastní balíček. • Uživatel zobrazí menu a vybere možnost „Odstranit“. • Aplikace odstraní balíček. Výstupní podmínky Žádné Alternativní scénáře Žádné
Publikovat balíček Stručný popis Publikuje uživatelův balíček pro ostatní uživatele. Hlavní aktéři Uživatel Vstupní podmínky Uživatel musí mít vytvořený alespoň jeden balíček Hlavní scénář • Zobrazit vlastní balíček. • Uživatel zobrazí menu a vybere možnost „Publikovat“. 17
2. Analýza • Aplikace zobrazí obrazovku pro vyplnění dodatečných údajů o balíčku. • Uživatel vyplní údaje a potvrdí publikování balíčku. • Aplikace publikuje balíček. Výstupní podmínky Žádné Alternativní scénáře Žádné
Sdílet balíček Stručný popis Nasdílí uživatelův balíček pro konkrétní uživatele. Hlavní aktéři Uživatel Vstupní podmínky Uživatel musí mít vytvořený aspoň jeden balíček Hlavní scénář • Zobrazit vlastní balíček. • Uživatel zobrazí menu a vybere možnost „Sdílet“. • Aplikace zobrazí obrazovku s možnostmi sdílení balíčku. • Uživatel určí s kým chce balíček sdílet a potvrdí sdílení. • Aplikace nasdílí balíček. Výstupní podmínky Žádné Alternativní scénáře Žádné
2.2.3
Správa cizích balíčků
Zobrazit balíčky na stáhnutí Stručný popis Zobrazení balíčků, které uživatel může stáhnout. Hlavní aktéři Uživatel Vstupní podmínky Žádné
18
2.2. Případy užití Hlavní scénář • Uživatel klikne na tlačítko „Stáhnout balíčky“. • Aplikace otevře obrazovku, kde uživatel může vyhledat balíčky ke stáhnutí. Výstupní podmínky Žádné Alternativní scénáře Žádné
Obrázek 2.3: Diagram: Případy užití Správa cizích balíčků Zobrazit balíček na stáhnutí Stručný popis Zobrazení detailu balíčku, který uživatel může stáhnout Hlavní aktéři Uživatel Vstupní podmínky Žádné
19
2. Analýza Hlavní scénář • Zobrazit balíčky na stáhnutí. • Uživatel si vybere konkrétní balíček a klikne na něj. • Aplikace otevře obrazovku s detailem balíčku na stáhnutí. Výstupní podmínky Žádné Alternativní scénáře Žádné
Stáhnout balíček Stručný popis Stáhnutí vybraného balíčku. Hlavní aktéři Uživatel Vstupní podmínky Žádné Hlavní scénář • Zobrazit balíček na stáhnutí. • Uživatel klikne na tlačítko „Stáhnout“. • Aplikace zobrazí obrazovku na potvrzení Stáhnutí balíčku. • Uživatel potvrdí stáhnutí. • Aplikace stáhne balíček. • Aplikace zobrazí obrazovku s výukou daného balíčku. Výstupní podmínky Žádné Alternativní scénáře Žádné
2.3
Požadavky
Na základě dosavadní analýzy, porovnání konkurenčních aplikací a dotazování lidí, byly vytyčeny tyto základní požadavky na aplikaci. 20
2.4. Doménový model
2.3.1
Funkční požadavky
• Aplikace umožňuje učení slovíček z balíčků, které si uživatel může vybrat • Aplikace provádí uživatele učením, pokud má zájem • Aplikace umožňuje synchronizaci mezi zařízeními • Uživatel může spravovat vlastní balíčky • Uživatel může sdílet vlastní balíček konkrétním uživatelům • Uživatel může publikovat balíček mezi uživatele • Aplikace obsahuje statistiky o učení • Aplikace umožňuje nastavení připomínky pro učení • Aplikace obsahuje motivační systém • Aplikace umožňuje sociální zapojení kamarádů
2.3.2
Nefunkční požadavky
• Aplikace podporuje platformu Android minimální verze 4.0 a vyšší • Základní funkce jsou dostupné bez nutnosti připojení k internetu • Aplikace předpokládá situace s nestabilním internetovým připojením • Vzhled aplikace by se měl držet standardních zvyků a doporučení • Uživatelské rozhraní by mělo být přehledné
2.4
Doménový model
Následující doménový model byl vytvořený pomocí nástroje Enterprise Architect, kvůli lepší orientaci v problematice. Popisované domény jsou znázorněny pomocí tříd v ClassDiagramu jazyka UML.
2.4.1
Definice domén
Student Účet studenta neboli uživatele aplikace vlastnící stáhnuté nebo vytvořené balíčky slov. Účet je vytvořen automaticky při prvním spuštění aplikace. Při přihlášení pod emailovou adresu může dojít ke spojení účtů a jejich balíčků. Toto spojení nastává, když se účet bez vyplněné emailové adresy přihlásí pod emailovou adresu jiného účtu.
21
2. Analýza Balíček Skupina karet k výuce specifického jazyka. Karta Konkrétní vyučované slovo. Karta obsahuje učené slovo a jeho překlad do cizího jazyka. Kromě této dvojce slov může karta také obsahovat příkladovou větu. Jazyk Specifikovaný cizí nebo nativní jazyk. Sdílení Propojení balíčku se specifikovaným uživatelem. Uživatel má práva, které mu nastaví autor balíčku.
2.4.2
Diagram
Obrázek 2.4: Diagram: Doménový model
2.5 2.5.1
Procesy Přihlášení
Uživatel spojí nepřihlášené mobilní zařízení s emailovým účtem. Nejprve je zařízení spojeno pouze s annonymním účtem bez vyplněné emailové adresy. Uživatel vyplní emailovou adresu, na kterou mu je odeslán email k potvrzení. Po potvrzení emailové adresy je k účtu přiřazena emailová adresa, kterou uživatel může využít pro přihlášení i na jiných zařízení. Pokud se uživatel přihlasuje pod emailovou adresu, která již je spojená s jiným účtem dochází ke spojení těchto dvou účtů v jeden. Balíčky obou účtů zůstanou zachovány. 22
2.5. Procesy
2.5.2
Správa vlastních balíčků
Uživatel bude moct spravovat vlastní obsah balíčků pomocí jejich vytváření, přidávání slov a dalších úprav. Slova do balíčku bude moct přidávat nejen v jeho detailu, ale i během učení kvůli většímu pohodlí uživatele. Balíčky slov bude uživatel moct sdílet mezi své kamarády a známe, kterým bude schopen nastavit jejich vlastní práva. Tímto bude například učitel moct vytvořit balíček slovní zásoby na test a rozšířit ho mezi své studenty. Pro šíření balíčku mezi širší věřejnost bude sloužit možnost publikování. Publikováním uživatel docílí, že jeho balíček budou moct jiní uživatelé najít v seznamu balíčků ke stáhnutí.
2.5.3
Správa cizích balíčků
Uživatel bude mít přístup k publikovaným balíčkům ostatními uživateli, kde bude moct vyhledávat balíčky, o které má zájem. Pro tyto učely slouží atributy balíčku jako jsou učený jazyk, obtížnost nebo zaměření. Pomocí nich bude moct filtrovat balíčky, které ho zajímají. Případně samotná aplikace bude doporučovat balíčky ke stáhnutí podle aktuálních balíčků uživatele. Publikovaným balíčkům může úpravy dělat pouze samotný autor nebo uživatel, kterému je balíček nasdílen a má právo na úpravu.
2.5.4
Výuka
Poté co si uživatel pořídí svůj první balíček, ať již vytvořením nebo stáhnutím, tak bude moct spustit výuku slov. Jako hlavní a výchozí metoda výuky bude nastavena výuková metoda pomocí flashcards. Tato metoda uživateli zobrazí kartičku se slovem v nativním jazyce, poté co si uživatel zkusí říct slovo v učeném jazyce, by měl kartičku obrátit, aby viděl jaké mělo být správně přeložené slovo. Na základě výsledku uživatel zvolí, jak byla kartička obtížná. Aplikace dle odpovědí uživatele zobrazuje další kartičky a určuje jejich opakování. Metoda je efektivní právě kvůli chytrému učení a opakování karet. Denně bude doporučené množství nových slov určené na 20. Čím déle se bude uživatel vzdělávat v jednom balíčku, tím více mu bude přibývat slov k opakování. Mezi nimi budou zařazena i nová slova, proto nebude doporučeno uživateli zvýšit denní limit nových slov. Během výuky bude moct uživatel kdykoliv změnit její styl. Jiné metody ve výuce jsou důležité především proto, aby uživatel u učení vydržel. Neboť velké množství uživatelů se nechce kvůli stereotypnímu učení k němu vracet, zvláště u mladší generace.
23
2. Analýza Příklady metod výuky: • flashcards • volení správné odpovědi z více možností • spojování správných dvojic slov – dvojící se rozumí slovo a jeho překlad • učení hrou – hry s kamarády, pexeso a další Na konci každého učebního cyklu aplikace zobrazí uživateli přehled statistik daného balíčku, kde uživatel uvidí, z jaké části již balíček ovládá.
24
Kapitola
Návrh 3.1
Drátěný model
Drátěný model neboli wireframe slouží k zobrazení grafického návrhu kostry aplikace. Ná základě wireframe mohou být jednotlivé elementy umístěny tak, aby splnily stanovené požadavky jako přehlednost, srozumitelnost aplikace a další. Dále mohou sloužit jako prvotní ukázka pro marketingové účely nebo jiné prezentování aplikace. Hlavní výhoda wireframe spočívá v jednoduchosti úprav, případné změny návrhu jsou lehce proveditelné a zaberou méně času, než kdybychom upravovali již hotovou aplikaci. Proto bylo návrhu věnováno poměrně velké zastoupení času, abychom s ním byli spokojeni, dříve než započne fáze programování.
3.1.1
Výběr nástroje
V poslední době se kromě známých nástrojů na tvorbu návrhu jako Axure objevuje poměrně velké množství nových nástrojů, proto jsme se rozhodli provést výběr nástroje, a tak se seznámit i s případnými novinkami. Wireframe by šlo nakreslit v jakémkoliv grafickém editoru, ale z důvodu efektivity a následných případných úprav jsme se rozhodli vybrat jeden z plnohodnotných nástrojů. Většina těchto nástrojů je efektivní z důvodů předpřipravených komponent, generování základních prototypů a nebo exportace do webové podoby, kdy je testování snadné jak na klasických počítačích, tak i na mobilních zařízeních. 3.1.1.1
Axure
Axure vznikl jako jeden z prvních nástrojů pro výrobu wireframe, původně určených pro internetové stránky [5]. Dnes již jedenáct let od své první verze 25
3
3. Návrh se stal standardem pro velké množství uživatelů při vytváření prototypů různých softwarových projektů. Axure je rozsáhlé prostředí a to sebou nese pár nevýhod jako horší orientace pro nové uživatele. Nástroj je složitější pro zorientování než jednoduché webové aplikace pro tvorbu wireframe jako FluidUI. Základní licence stojí 289 $, Axure případně nabízí možnost vyzkoušet nástroj v měsíční zkušební verzi. Předpřipravené komponenty, generování webové podoby wireframe, propracovaná tvorba návrhu včetně animací vedou k tomu, že je Axure často využívaným nástrojem při tvorbě návrhu.
Obrázek 3.1: Screenshot: Axure RP 7
3.1.1.2
FluidUI
Poměrně nový nástroj, první verze byla spuštěna v roce 2012 [10]. Jedná se o tvorbu wireframe primárně pro mobilní zařízení. Veškerá tvorba probíhá ve webovém prohlížeči pomocí předpřipravených komponent, tímto se FluidUI stává velice lehce použitelné pro nové uživatele. Jeho silná stránka je právě lehká použitelnost, předpřipravené komponenty a snadné testování. Vytvořený návrh lze okamžitě spustit na vygenerovaném URL, takže ho lze rychle otestovat i na mobilních zařízeních. FluidUI má dvě hlavní nevýhody, omezený počet komponent a především jeho styl placení. Nenabízí žádné trvalé licence, ale platby probíhají měsíčně. Nejdražší licence stojí 49 USD měsíčně. Neplacená licence nabízí na projektu 26
3.1. Drátěný model vytvoření jen deseti obrazovek, takže je pouze k vyzkoušení a nikoliv na celý návrh aplikace. 3.1.1.3
Balsamiq Mockups
Nástroj, který se snaží zaujmout svou jednoduchostí. Na scéně wireframe nástrojů je od roku 2008, takže vedle Axure se také jedná o poměrně často využívaný nástroj. Jelikož se nástroj snaží především o jednoduchost, základem je vytváření pomocí předpřipravených prvků, které vytváří samotná komunita a jsou dostupné ke stažení [6]. Nástroj samotný nabízí standardní funkce jako většina jiných nástrojů. Za poměrně velký zápor se dá považovat absence exportu do webové podoby, jelikož se tato funkce ukázala jako velice užitečná při testování. 3.1.1.4
Devhand Sketchlt
Další z řady wireframe nástrojů, tento nástroj nenabízí nic, co by jiné nástroje nenabízely. Standardní funkcionalitě nelze nic vytknout, avšak tento nástroj má oproti svým konkurentům více nevýhod jako například velice málo předpřipravených komponent nebo omezení pouze na platformu Windows [27]. Klady nástroje jsou možnost vygenerování webové verze návrhu a nízká cena licence. 3.1.1.5
Shrnutí
V dnešní době se objevuje stále více nástrojů, které nabízejí snadné a rychlé navržení wireframe aplikace. Většina nástrojů se liší pouze v ceně licence, jinak nabízí velice podobnou funkcionalitu. Proto záleží čistě na uživateli, kterému nástroji dá přednost. Avšak pro nové uživatele je velice výhodné najít si nástroj, který má již předpřipravené komponenty, které urychlí počáteční tvorbu. Jelikož Axure se ukázal až na cenu licence jako nadprůměrný nástroj a máme s ním již zkušenosti, tak si vybereme pro tvorbu návrhu právě nástroj Axure. Co se týče licence, tak měsíční zkušební doba by nám měla stačit na vytvoření kvalitního návrhu.
3.1.2
Návrh drátěného modelu
Při návrhu wireframe jsme se snažili dbát na obecný postup, kdy je vhodné vytvářet návrh od nejjednoduššího po složitější. Prvotní návrh zobrazoval holé 27
3. Návrh obrazovky aplikace, pouze s jejich popisem. Na těchto obrazovkách byl znázorněn přesun mezi nimi a celá navigace aplikace, až poté byly speficikovány elementy na jednotlivých obrazovkách.
3.1.2.1
Navigace aplikace
Navigace aplikace je vytvořena pomocí vyjíždějícího bočního panelu, kde uživatel může lehce přejít na akci, kterou právě vyžaduje. Tento druh navigace byl vybrán především z důvodů rychlého začátku učení, jelikož uživatel v panelu uvidí své učené jazyky a jejich balíčky, kdy následným kliknutím na konkrétní balíček spustí jeho výuku. Za výhodu pro uživatele považujeme, že tento panel lze otevřít z téměř jakékoliv obrazovky a tudíž může uživatel, začít výuku kdekoliv se bude v aplikaci nacházet. Případně pokud uživatel má právě spuštěnou výuku, tak lehce změní výuku na jiný balíček.
Obrázek 3.2: Drátěný model: Navigation drawer
28
3.1. Drátěný model 3.1.2.2
Výuka
Druhou nejdůležitější částí po celkové navigaci aplikace se při návrhu wireframe stala samotná výuka, jelikož jsme chtěli, aby byla pro uživatele co nejvíce pohodlná a interakce s aplikaci nezastínila samotné učení. Pomocí wireframe je znázorněna pouze výuka pomocí flashcards, jelikož se jedná o hlavní výukovou metodu. Při výuce rozhoduje uživatel jak moc danou kartu ovládá, musí tedy vybrat jednu ze třech možností. Na výběr máme dva základní druhy ovládání. Klasické tlačítka a nebo přetahnutí karty na místo, určující její znalost. Klasické tlačítka mají výhodu, že nepřekvapí a nezmatou ani uživatele, kteří mají velmi malé zkušenosti s využíváním mobilních aplikací. Naproti tomu Drag and Drop je v dnešní době poměrně hojně využívaný a při rozumném použití dodá aplikaci eleganci a zjednodušší uživateli jeho úkony. Výše zmíněný systém Drag and Drop v naší aplikaci nepřinese zjednodušení uživatelova úkolu, rozhodovaní jak kartu ovládá, ale ani jej neudělá složitějším. Přesunutí karty na danou oblast lze jednoduše provést jedním prstem a proto by uživatel neměl být nijak zatížen. Tento úkon je srovnatelný s úkonem při výběru z tlačítek. Rozhodující faktor pro zvolení jedné z těchto výběrových metod je tedy elegance, která je větší při získání znalosti o kartě pomocí jejího přesunutí na místo, určující znalost karty.
Obrázek 3.3: Drátěný model: Obrazovka učení
29
3. Návrh Na konci výuky jsme chtěli zobrazit uživateli statistiky a podpořit ho v dosavadním snažení. Obrazovka se statistikami se měnila v průběhu jejího vytváření od zobrazovaní statistik za aktuálně provedený úsek výuky až po poslední verzi, kdy se jako statistiky zobrazuje celková znalost balíčku. Statistiky za aktuálně provedený úsek byly zrušeny především z důvodu, že vypovídající hodnota o znalosti slova po jedné správné odpovědi není moc velká. Naproti tomu celkový pohled na balíček, může uživateli pomoct v různých situacích, například když je nutné ovládat balíček na test aspoň z devadesáti procent. Ve výsledné aplikaci bude uživateli zdůrazněn jeho dosavadní pokrok pomocí animace přesouvající slova v grafu, které se právě naučil, do sloupce již naučených slov. Touto animací a vhodnou textací obrazovky bude cíleno na pozitivní motivaci a podporu uživatele.
Obrázek 3.4: Drátěný model: Obrazovka statistiky balíčku
3.1.2.3
Správa balíčků
Wireframe vytvořený pro správu balíčků se snaží dodržet standardy vybrané platformy, aby uživatel byl schopný předpovídat chování jednotlivých možností aplikace při vytváření a následné správě balíčků. Vytvoření návrhu této časti aplikace je důležité především z důvodů následného testování pro získaní 30
3.1. Drátěný model zpětné odezvy, abychom si ověřili, že vytvořená správa je pro uživatele přehledná a lehce pochopitelná. Přechody mezi obrazovkami ve správě balíčků byly vytvořeny především podle aktuální potřeby uživatele. Například uživatele bez jakéhokoliv balíčku aplikace směřuje pro jeho vytvoření a nebo případné stáhnutí. Nejdůležitější součastí správy balíčků je stahování publikovaných balíčků jinými uživateli, jelikož uživatel by měl být schopen efektivně vyhledat balíček, který ho zajímá. Proto se vedle samotného vyhledávání balíčků objevuje jejich zobrazovaní dle vyučujících jazyků nebo výpis nejstahovanějších, nejlépe hodnocených případně doporučených balíčků.
Obrázek 3.5: Drátěný model: Obrazovka s doporučenými balíčky
3.1.3
Testování
Vytvořený drátěný model aplikace byl otestován zástupci potencionálních skupin uživatelů kvůli ověření, že aplikace je přehledná a srozumitelná pro jednotlivé uživatele. Po testování byl návrh upraven, aby obsahoval jednotlivé nápady a připomínky testovaných lidí. Pro uživatelské testování byl vytvořen scénář, podle kterého se měli testovaní uživatelé řídit, jednalo se o seznam cílových akcí bez dalších pomocných textů. Uživateli byla pouze popsána akce čeho by měl dosáhnout a následně byl pozorován jak se mu akci daří splnit. Tímto pozorováním jak uživatel plní zadané akce lze zjistit, která část aplikace nebyla navrhnuta, tak aby ji uživa31
3. Návrh tel intuitivně vykonal. Na konci testování měl uživatel prostor pro vyjádření svých postřehů, připomínek nebo pozitivních ohlasů na aplikaci. Testovací scénář lze najít v přílohách práce. 3.1.3.1
Testovaní zástupci
Vydělávající člověk Základní informace: • Žena • 30 let • Poměrně nový uživatel smartphone Během testování se objevily dvě hlavní připomínky. První z nich byla, že aplikace, které kombinují herní principy nejsou vůbec u tohoto uživatele oblíbené a většinou je rychle odinstaluje. Jako důsledek toho bylo, že prvotní návrh aplikace neobsahuje herní a sociální prvky, jelikož by tato problematika byla sama o sobě dost složitá, kdybychom ji chtěli s co nejlepší kvalitou. Druhá připomínka byla k textaci některých tlačítek. Především tlačítko, které vedlo k stáhnutí publikovaných balíčků, se jmenovalo „Obchod balíčků“, uživatel měl okamžitě pocit, že bude potřeba za něco platit a takovou aplikaci by dále netestoval. Taková textace by vedla k odrazení uživatelů, a proto byla upravena. Další poznatky uživatele: • Nechci se ihned přihlašovat • Než vytvořím vlastní balíček, chci zkusit již nějaký vytvořený • Vytvořila jsem balíček, ale není jasný přechod k učení Vysokoškolský student Základní informace: • Muž • 23 let • Běžný uživatel Narozdíl od výše uvedeného testovaného uživatele student vysoké školy neměl s navigací v aplikaci žádný problém. Systém ovládání uživateli přišel intuitivní, dokonce aplikaci proklikal sám celou a nepotřeboval k tomu ani 32
3.2. Platforma připravený scénář, přesto splnil všechny jeho úkoly. Drátěný model aplikace hodnotil velice pozitivně a jediná poznámka, která by mohla být využita pro budoucí vývoj aplikace byla k výukové metodě. Jako další výukovou metodu navrhnul, že by se karta přetahovala na místo, kde by byl zobrazený její překlad. Takových míst by se na obrazovce objevilo více a jen jeden překlad by byl správný.
3.2
Platforma
Za mobilní aplikaci je možno považovat aplikaci na přenosném zařízení jako mobilní telefon nebo tablet běžící na jedné z mobilních platforem. V praxi to znamená, že pokud by se chtěla vyvinout nativní aplikace pro jednotlivé platformy, tak by se musela vyvinout několikrát, jelikož každá platforma má své speficika při vývoji. Proto je v této kapitole diskutováno vedle vývoje nativních aplikací také o možnostech multiplatformního vývoje. Na závěr kapitoly je ujasněno, který typ vývoje bude použit. Pro tvorbu prototypu je na základě zadání zvolena platforma Android.
3.2.1
Nativní aplikace
Nativní vývoj je intuitivní volba většiny vývojařů, jelikož jedině díky němu mají plnou podporu a možnosti využití daného operačního systému. Aplikace může v takovémto připadě využít možnosti systému jako jsou alespoň pro OS Android například spolupráce s ostatními aplikacemi, systémové vyhledávání, synchronizace na pozadí ve vhodnou dobu a další. Nesporná výhoda je také vytváření nativního uživatelského rozhraní, které má velký vliv na uživatelskou přívětivost. Mezi mobilními platformami se poměrně liší daný standard na uživatelské rozhraní, a proto je vhodné tento standard na jednotlivých platformách dodržovat. Nevýhoda využití nativního vývoje souvisí s náklady na vývoj aplikace, jelikož pro jednotlivé platformy je potřeba vyvíjet aplikaci zvlášť. Proto jako důsledek vzrostou potřebné náklady pro vytváření aplikace na více platformách.
3.2.2
Multiplatformní vývoj
Na začátku sekce bylo zmíněno, že při vývoji aplikace na více platforem by se muselo vyvíjet několikrát v případě, že bychom chtěli nativní aplikaci pro jednotlivé platformy. Avšak existuje i možnost vyvíjet HTML5 aplikace případně tzv. hybridní aplikace, které jsou vyvíjené jako webové aplikace využívající zapouzdření do nativního kontejneru přímo na zařízení.
33
3. Návrh Vývoj HTML5 aplikací může ušetřit náklady za multiplatformní vývoj, avšak také se tím vzdáváme mnoha funkcí nativní platformy, jelikož rozvoj webové platformy nestíhá krok s tempem aktualizací a fragmentací jednotlivých mobilních platforem. Při vývoji musíme počítat s možným odlišným chováním prohlížečů, které by vývojářský tým měl doladit. Zápory ale nekončí jen fragmentací prohlížečů, dále jsou takovéto aplikace několikrát výkonostně pomalejší oproti nativním aplikacím. HTML5 udělal velký krok dopředu co se týče webových aplikací, avšak podle mého názoru nahradit nativní aplikace nedokáže. Hybridní aplikace se nachází ve středu mezi nativními a HTML5 aplikacemi, jelikož využívají technologii webových aplikací, která je zapouzdřena v nativním kontejneru pro danou platformu. Největší síla hybridních aplikací je v abstraktní vrstvě, která umožňuje volání nativních funkcí pomocí JavaScriptu. Při kompilaci je abstraktní vrstva specifikována pro jednotlivé platformy, takto vzniklá aplikace se poté může distribuovat pomocí jednotlivých distrubučních kanalů mobilních platforem. Avšak podobně jako u HTML5 aplikací se i zde objevuje zápor, že ne všechny nativní funkce API jsou dostupné. 3.2.2.1
Appcelerator Titanium
Platforma Appcelator Titanium [3], vyvíjená společností Appcelator Inc od roku 2008, umožňuje vývoj mobilních i desktopových aplikací pomocí webových technologií. Titanium mobile SDK umožňuje vytvářet aplikace s použitím jazyka JavaScript, který je na zařízení interpretován do nativního zdrojového kódu. Grafické rozhraní je možné vytvořit pomocí HTML a CSS, ale také lze využít nativní prvky uživatelského rozhraní díky JavaScript kódu. Titanium nabízí vytváření zásuvných modulů, díky kterým může vývojář doplnit požadovanou nativní funkci a tu následně volat pomocí JavaScriptu. Využitím zásuvných modulů se Titanium stává lehce rozšiřitelné. 3.2.2.2
PhoneGap
PhoneGap framework [1], vývíjený společností Adobe, zapouzdřuje HTML5 aplikace a umožňuje tedy jejich šíření pomocí distribučních kanálů všech hlavních mobilních platforem. V případě potřeby lze využít funkce nabízené systémem pomocí speciálního objektu, který nám zpřístupní funkce akcelerometru, kamery, GPS a další. Seznam funkcí se liší dle zvolené platformy a její verze, proto se dokumentace 34
3.3. Architektura neustále aktualizuje o novou funkcionalitu, kde lze zobrazit i ukázku zdrojového kódu.
3.2.3
Závěr
Z důvodu zvolené platformy Android chceme vytvořit především kvalítní aplikaci pro tento systém a multiplatformnost není naše hlavní priorita, proto vytvoříme nativní aplikaci.
3.3
Architektura
Navrhnutá architektura aplikace se dělí na tři základní vrstvy. Jedná se o vrstvy pro komunikaci se serverem, vnitřní logiku aplikace a ukládání dat do databáze. Vedle popisu vrstev jsou v této sekci uvedeny jejich navrhnuté knihovny.
3.3.1
Data storage layer
Vrstva ukládající data uživatele je navrhnuta tak, aby co nejjednodušeji komunikovala s vrstvou pro komunikaci se serverem. Pro práci s databází byla proto využita knihovna Sprinkles [20], která mapuje potřebné objekty do databáze. Hlavní výhoda této knihovny je dobrá spolupráce s knihovnou pro komunikaci se serverem, tato dvojce knihoven poté slouží jako snadné a spolehlivé ukládání dat ze serveru do lokální databáze. Knihovna Sprinkles se dále stará o to, aby při budoucích aktualízacích databáze, zůstala data konzistentní pro všechny uživatele bez ohledu na to, z které verze právě aktualizují aplikaci.
3.3.2
Business logic layer
Vrstva zajišťuje aplikační logiku, jedná se například o vybrání vhodných karet pro učení z balíčku a další podporované operace. Při získávání a ukládání dat se volají funkce zbylých dvou vrstev. Toto oddělení ulehčí připadné změny databázové nebo serverové logiky. Pro získávání potřebných dat je využit model, kdy je volána služba, která získá data ze serveru a v případě potřeby je uloží do databáze. Původní objekt, který požadoval data je následně upozorněn na novou aktualizaci dat. Tímto způsobem se oddělí volání webových služeb od grafických komponent aplikace.
3.3.3
Network layer
Siťová vrstva, obsahuje pouze jednoduchou třídu, která zpracovává požadavky aplikace vůči serveru. Komunikaci usnadňuje využití knihovny Retrofit [22], 35
3. Návrh jedná se o Android REST klienta. Knihovna Retrofit byla využita především kvůli jednoduchosti a dobré spolupráci s výše zmíněnou knihovnou Sprinkles. Vzorový příklad použítí: @GET( " / group /{ i d }/ u s e r s " ) L i s t <User> g r o u p L i s t ( @Path ( " i d " ) int groupId ) ; Tímto způsobem specifikovaná funkce kontaktuje vzdálený server, získaná odpověď je automaticky namapována do konkrétního objektu.
3.3.4 3.3.4.1
Další knihovny Ottobus
Knihovna [21] je založena na principu posílání událostí poslouchajícím objektům. Tímto způsobem se kód může stát více generickým, jelikož jednotlivé objekty na sobě nebudou nijak závislé. Například dva komunikující fragmenty nepotřebují o sobě nic vědět. Pro posílání a přijímání událostí je potřeba vytvořit singleton instanci sběrnice, ke které se poslouchajicí objekty musí přihlásit. Objekty, které pouze posílají události, ale žádné nepřijímají, se nemusí přihlašovat. Dobrou zvyklostí je deklarovat sběrnici uvnitř vytvořeného potomka třídy Application. Jednotlivé události se identifikují podle druhu přijímaného argumentu, proto je vhodné kvůli zvýšení čitelnosti kódu pro události vytvořit nové objekty, i když by obsahovaly například jen primitivní datový typ. 3.3.4.2
Butter Knife
Knihovna [25] usnadňujicí prací s potomky třídy View, kdy odpadá potřeba zbytečného kódu při jejich vyhledávání z konkrétního layoutu. Knihovna je využita především z důvodů zlepšení čitelnosti kódu.
3.4
Schéma databáze
Schéma databáze (obrázek 3.7 se nachází na konci kapitoly) je založeno na navrhnutém doménovém modelu aplikace, avšak také klade důraz na jednoduchost databáze v mobilním zařízení. Z tohoto důvodu se do databázového modelu nepromítá doména Student, která v doménovém modelu znázorňuje uživatele aplikace. Výsledná databáze v mobilním zařízení je velice jednoduchá, jedná se pouze o základní strukturu pro ukládání balíčků slov. Proto databáze neobsahuje například žádné smyčky nebo složené klíče. Persistence uživatelů bude probíhat na straně serveru, který není součástí této práce. 36
3.5. Diagram komponent
3.5
Diagram komponent
Pro lepší pochopení návrhu aplikace v obrázku 3.6 lze vidět jednotlivé komponenty aplikace. Následuje výpis jednotlivých komponent s jejich popisem.
3.5.1
Server REST API
REST rozhraní serveru umožnující synchronizaci potřebných dat.
3.5.2
Retrofit
Použítá knihovna implementující rozhraní pro komunikaci se serverem. Využívá Java objekty do kterých namapuje příjaté JSON odpovědi od serveru.
3.5.3
DAO
Implementace přistupu k lokální databázi. V této komponentě je využita knihovna Sprinkles.
3.5.4
Synchronization
Komponenta zajišťující synchronizaci dat mezi lokální a serverovou databází. Synchronizace probíhá obousměrně.
3.5.5
Bussiness logic & UI
Zjednodušená komponenta starající se o vlastní logiku aplikace a její uživatelské rozhraní. Komponenta není dále rozepsaná kvůli jednoduchosti, i když by se dala rozdělit na více komponent.
3.5.6
SyncManager
Komponenta systému zajišťující spouštění automatické synchronizace. Výhodou využítí této komponenty spočívá například v zvýšení životnosti baterie nebo opakování při selhání synchronizace.
37
3. Návrh
Obrázek 3.6: Diagram komponent
38
3.5. Diagram komponent
Obrázek 3.7: Databázový model
39
Kapitola
Realizace Následující kapitola se zabývá realizací softwarového díla od volby nástrojů až po diagram nasazení.
4.1
Volba nástrojů
Před samotným programováním bylo nutné vybrat nejen vývojové prostředí, ale také další podpůrné nástroje jako například verzovací systém.
4.1.1
Vývojové prostředí
V současné době lze vyvíjet pro platformu Android v několika vývojových prostředích. Avšak výběr omezíme pouze na vývojové prostředí Eclipse [8] a Android Studio [12], jelikož s těmito nástroji máme největší zkušenosti. 4.1.1.1
Eclipse
Vývojové prostředí primárně určené pro programovací jazyk Java je officiálně podporovaným prostředím platformy Android. Eclipse nabízí kvalitní integraci všech nástrojů, což by mohlo být považováno za hlavní výhodu. Eclipse je možné stáhnout v balíčku s Android SDK a není třeba nic dále nastavovat a vývojové prostředí je ihned po rozbalení připraveno pro vývoj. Eclipse výužívá rozšíření funkčnosti pomocí pluginů, kdy jeho základní verze obsahuje pouze integrované prostředky pro vývoj v jazyce Java. Pravděpodobně z tohoto důvodu bylo vybráno jako oficiální prostředí platformy Android. 4.1.1.2
Android Studio
Android Studio je nové vývojové prostředí, které bylo představeno poměrně nedávno v roce 2013. Prostředí je založeno na IntelliJ IDEA, díky kterému 41
4
4. Realizace získává výborné možnosti práce s kódem jako navigace v kódu, našeptávání a mnohé další. Dále poskytuje prostředí integraci Android vývojařských nástrojů potřebných pro vývoj a ladění. Android Studio ještě není ve finální fázi, ale teprve se nachází ve fázi early access preview, avšak žádné zásadní chyby by nemělo obsahovat. Vývojové prostředí nabízí mnoho integrovaných vylepšení pro vývojáře jako jsou drag-and-drop editor pro tvorbu vzhledu, předvytvořené šablony často používaných komponent nebo třeba podpora pro Google Cloud Platform. 4.1.1.3
Výběr nástroje
Vybraným nástrojem pro tvorbu aplikace je Android Studio. Především z důvodů, že prostředí poměrně dobře známe a jsme spokojeni s jeho možnostmi. Za dobu jeho používání jsme nezaznamenali žádnou závažnou chybu, která by nás od této volby odradila.
4.1.2
Verzovací systém
Jako verzovací systém byl zvolen open-source software git. Zvolené Android Studio umožnuje práci se všemi klasickými verzovacími systémy včetně gitu, a proto jsme zvolili ten, s kterým jsme již zvyklí pracovat. Jako vzdálené uložiště jsme využili nabízený neomezený prostor od hostitelské služby Bitbucket [4]. Při vývoji se hlavní strom vývoje nachází minimálně na straně serveru a v lokálním repozitáři vývojáře, tím pádem je riziko ztráty dat minimalizováno.
4.1.3
Ticket systém
Jako systém pro správu úkolů byl zvolen software Trello [11], jedná se o webovou aplikaci, kde lze velice jednoduše spravovat jednotlivé projekty (tzv. Boards). Systém využívá paradigma známého jako Kanban, což v překladu znamená slovo cedule. Proto i jednotlivé úkoly v Trellu jsou znázorněny malými obdelníky, které lze posouvat v rámci jednotlivých seznamů. Tímto se dostává úkol od fáze návrhu až k realizaci.
4.1.4
Apiary
Webová služba [2] pro otestování komunikace aplikace vůči serveru. Jedná se o mock server, který dokáže na předpřipravené dotazy odpovídat stanovenými odpovědmi. Apiary usnadňuje udržování aktuální dokumentace rozhraní komunikace nebo její případné ladění. Apiary také pomůže v budoucnosti při testovaní vlastního serveru pro komunikaci s aplikací, kdy apiary může být 42
4.2. Implementace prostředníkem komunikace, tedy lehce při problémech uvidíme, která strana komunikace nedodržuje stanovený standard.
4.1.5
Monitorování
Pro sledování aplikace, především pádů, byl využit nástroj Crittercism [7], kterým bude zajištěna následná podpora uživatelů. Jedná se o nástroj, který v reálném čase informuje nejen o pádech aplikace. V případě pádu odešle aplikace na server podrobný výpis problému. Pro integraci nástroje stačí přidat závislost na knihovnu Crittercism a následně v kódu provést její inicializaci. V kombinaci s rozlišením druhu verze aplikace poté můžeme nastavit, aby se pády odesílaly pouze v případě, že se nejedná o ladící verzi aplikace.
4.2
Implementace
V této práci byl implementován pouze prototyp, jedná se o nativní Android aplikaci. Prototyp obsahuje návrh jednotlivých obrazovek a slouží především k zobrazení a otestování grafického rozhraní aplikace. Logika učení je v prototypu omezena pouze na opakované zobrazovaní jednotlivých kartiček v balíčku, případně se uživatel může učit všechny slova daného jazyka. Prototyp je připravený na budoucí rozšíření funkčnosti, kdy lze lehce integrovat sofistikovanější učení, komunikaci se serverem nebo například synchronizaci aplikace.
4.2.1 4.2.1.1
Zajímavosti Gradle
Gradle je nástroj sloužící k automatizaci. Jedná se především o sestavování projektů, ale zvládne také testování, publikování nebo třeba nasazení [14]. Android Studio si tento nástroj zvolilo jako svůj sestavovací systém, a proto jsme jej mohli v naší implementaci využít. Gradle nám umožnil pomocí jediného řádku v sestavovacím skriptu přidat potřebnou závislost na jednotlivé knihovny. Příklad přidání závislosti knihovny Sprinkles: compile ’ se . e m i l s j o l a n d e r : s p r i n k l e s : 1 . 2 . 4 ’ Gradle nám také umožnil pro kvalitnější budoucí publikování aplikace rozdělit sestavování do jednotlivých variant, kdy specifikujeme o jakou variantu se 43
4. Realizace jedná, jestli debug, beta nebo release. Pro jednotlivé varianty můžeme vytvořit vlastní Java soubory, které mohou obsahovat například vlastní konstanty, dle kterých se může aplikace přizpůsobit. Například odesílání pádu aplikace na server se provádí pouze v případě, že se nejedná o ladící variantu. 4.2.1.2
REST komunikace
V popisu vrstvy zabívající se logikou aplikace v kapitole Návrh bylo zmíněno, že aplikace získává potřebná data ze serveru pomocí samostatné služby, která následně původní objekt upozorní na vypracování požadavku. Toto řešení bylo zvoleno především pro oddělení grafického vzhledu aplikace a logiky získávající data. K realizaci tohoto řešení jsme využili knihovny Sprinkles a Retrofit, které na svých stránkách uvádějí dobrou vzájemnou podporu. Pro komunikaci objektů a případné upozornění původního objektu jsme využili knihovnu OttoBus. Všechny zmíněné knihovny byly představeny v kapitole Návrh v sekci Architektura. Při využitých knihovnách následně může jakýkoliv objekt požádat službu o konkrétní data, mezitím může být odkázán na současné data v lokální databázi. Samostatná služba kontaktuje server pomocí knihovny Retrofit, přijatá data poté může aktualizovat v lokální databázi pomocí knihovny Sprinkles. Na konci procesu je vyslána událost pomocí OttoBus, která upozorní registrované objekty o změně dat. Obrázek [18] pro názornou ukázku komunikace:
Obrázek 4.1: Model REST komunikace 44
4.2. Implementace Prototyp aplikace nevyužívá synchronizaci, proto je z daného schématu implementovaná pouze část. Budoucí rozšíření aplikace o chybějící části schéma by mělo být bez problémů a nebude potřeba měnit současnou strukturu prototypu. 4.2.1.3
Intenty
Dalším řešeným problémem bylo, jak by jsme co nejvíce zpříjemnili uživatelům přidávání nových slov. Z tohoto důvodu aplikace počítá s budoucím standardem intentů, které by mohly využívat slovníkové aplikace. Především by se jednalo o vyvolání intentu, když by uživatel vyhledal ve slovníku slovo, které jej zajímá. Intent by informoval aplikaci, která by dané slovo uložila i s případným překladem poskytnutým od slovníku. Tento systém uživateli umožní využívat svůj oblíbený slovník a zároveň naše aplikace ukládá jeho nová slova. Až v případě, že by se chtěl učit dané slova, by otevřel aplikaci pro učení. Jedinou podmínkou aby slovníky vysílaly tyto informace je jejich implementace intentového standardu. V prvotní etapě aplikace by to především znamenalo, vlastnoruční úpravu open-source slovníků jako například QuickDic Dictionary nebo posléze kontaktovat autory jiných slovníkových aplikací. 4.2.1.4
Výuka
Při výuce slov jsme museli řešit, v jakém pořadí by se měla slova z balíčku zobrazovat a případně jestli do budoucna počítat i s jinými metodami výuky. Vhodné zobrazování karet by mělo být nejlépe založeno na provedené studii zabívající se optimálním procesem učení, která není součástí této práce. Z tohoto důvodu a jiných budoucích rozšíření je prototyp navržen tak, aby bylo možné vykonat změny ve výukové logice. Samotná výuka je rozdělena na dvě hlavní komponenty. První komponenta se stará pouze o zobrazování slov na obrazovku a hlášení odpovědí, které uživatel zvolil. Druhá komponenta slouží pro poskytování jednotlivých slov první komponentě a následné zpracování výsledků. Při dodržení jednotlivých rozhraní komponent bude možné jednotlivé komponenty libovolně zaměnovat. Tímto způsobem lehce dosáhneme volnosti při přidávání nových metod výuky nebo případném obměňování výukové logiky. Jednotlivé karty slov mají v současně navrhnuté databázi dva parametry, které budou sloužit pro určování, jak moc uživatel, jednotlivou kartu ovládá. První parametr je číslo, které se bude pohybovat mezi stanoveným intervalem například <0:100). Nové slova by mohly poté být vytvořený s nulovou počáteční hodnotou. Prvotní zodpovězení karty by dle správnosti přiřadilo 45
4. Realizace stanovené nenulové čislo, aby následné zodpovězení karty mohlo upravovat dané číslo pomocí přenásobení konstantou s ohlednem na správnost odpovědi. Ohodnocení slova by se limitně blížilo k stanovené horní hranici, po překročení stanoveného limitu by se slovo považovalo za naučené. Druhý parametr při ohodnocování slouží k tomu, aby se karty nezobrazovaly několikrát denně za sebou. Jelikož výpovědní hodnota odpovědí, by se zmenšovala a uživatel by se bez tohohle parametru mohl dostat k výsledku, že slovo již ovládá, ale ve skutečnosti by si na něj za tři dny nevzpomněl. Proto druhý parametr obsahuje datum, které ovlivní frekvenci výskytu. Pokud uživatel správně odpovídá, prodlužuje se interval pro následovné zobrazení karty. Pokud uživatel i po několika týdnech správně odpovídá na vybrané slovo, lze s velkou pravděpodobností prohlásit, že slovo ovládá. Implementovaná výuka je dostatečně flexibilní, aby mohla být rozšířena na základě budoucích potřeb. Komponenty lze vyměnit za jiné a vytvořené parametry při implementaci mají pouze doporučené využití. Logika zobrazování slov není nijak omezena v práci s těmito parametry. Přesto zvolený způsob použití by měl být společný pro všechny karty v databázi a připadné pozdější úpravy se budou muset provést nad celou databází.
4.3
Diagram nasazení
Pro zlepšení představy způsobu nasazení naší aplikace byl vytvořen následující diagram. Diagram znázorňuje využití aplikace vůči serveru.
46
4.3. Diagram nasazení
Obrázek 4.2: Diagram nasazení
47
Kapitola
Testování Testování by mělo být nedílnou součástí každého vývojového cyklu produktu, jelikož pomůže včas odhalit chyby, jejichž pozdní odstranění by mohlo být mnohem nákladnější. Ideálně by mělo testování probíhat od počáteční fáze vývoje produktu, jelikož může například pozitivně ovlivnit budoucí funkcionalitu nebo vzhled aplikace. Následující kapitola se bude zabívat především způsobem testování Android aplikace.
5.1
Automatizované testy
Výhoda automatizovaných testů spočívá především v časové úspoře a omezení lidského faktoru ve vykonávání jednotlivých testů. Tím se sníží pravděpodobnost špatného provedení testovacího scénáře a potřeba ručně vykonávat opakující se základní testování. Obecně automatické testování je výhodné pro velké množství stálých testů. Avšak automatizované testování je také o úspoře času, a proto se nevyplatí psát rozsáhlé testy pro krátkodobé aplikace. Narozdíl od toho u aplikací, které budou vyvíjeny v mnoha verzích, se tyto testy velice vyplatí [15]. Kromě výhod automatizace se také objevují i její nevýhody, především se jedná o prvotní časovou investici při jejich vytváření. Dále je nutné, aby testy byly aktuální a jakákoliv změna aplikace byla do nich zanesena. I přes tyto nevýhody je vhodné ve velkém množství případu tento druh testování využít.
5.1.1
Unit testy
Jedná se o testování jednotlivých komponent aplikace bez ohledu na jiné. Obvykle se za samostatně testovatelnou jednotku v objektově orientovaném programování považuje třída, ve které je možné testovat například její rozhraní, stavy nebo různé hraniční podmínky. Zásada jednotkových testů je, že 49
5
5. Testování musejí být rychlé, spolehlivé a opakovatelné. Framework pro testování obsahuje Instrumentation API [24], které dovoluje pomocí testů kontrolovat životní cyklus Android komponent a uživatelské vstupy, jako jsou dotykové události nebo stisk kláves. Pomocí Instrumentation můžeme tedy například zavolat metodu getActivity(), která spustí libovolnou obrazovku, a posléze otestovat, jestli se vytvořil její očekávaný stav. Unit testy budou v naší aplikace využity pouze pro několik základních případů testování.
5.1.2
MonkeyRunner
API poskytující nástrojem monkeyrunner [13] umožnuje ovládat zařízení mimo kód aplikace. Monkeyrunner umožnuje vytvořit program v jazyce Python, který je schopen například nainstalovat aplikaci na zařízení, pořídít snímek obrazovky a porovat jej s očekávaným stavem. Další výhodou je možnost testovat na více zařízeních nebo Android emulátorech, ke kterým se lze najednou připojit a spouštět jednotlivé testy. Standardní monkeyrunner funkcionalita jde rozšířit pomocí pluginů, které se píší v jazyce Java. Výsledný soubor poté musí být předán jako parametr v příkazové řádce. Příklad spuštění testovacího skriptu s vlastním rozšířením může vypadat takto: monkeyrunner s c r i p t . py −p l u g i n p l u g i n . j a r
5.1.3
Robotium
Robotium [19] je open-source testovací nástroj podobný nástroji Selenium, zaměřený na black-box testování na platformě Android. Výhody tohoto nástroje jsou jeho jednoduchost, díky snadnému psaní testovacích scénářů, široké možnosti testování nebo jeho otevřenost, kdy je možné upravit nástroj dle svých potřeb. V případě, že potřebujeme otestovat hybridní aplikaci využívající komponentu WebView je nutné využít verzi čtyři a vyšší. Robotium je využívaným nástrojem pro automatizované testování. Za nevýhodu nástroje lze považovat například nemožnost testování více procesů. I přesto je Robotium vhodný nástroj pro vytvoření automatizovaných testů většiny aplikací, pro získání případné časové úspory. 50
5.2. Ruční testování
5.2
Ruční testování
Proces při kterém je produkt ručně testován, tedy provádí se sled událostí, jako by je vykonával koncový uživatel. Tímto způsobem testování lze objevit i takové chyby, s kterými automatizované testy nepočítají, jako například logické chyby nebo nesrovnalosti v grafickém rozhraní. Vhodné je pro efektivní testování vytvořit scénáře, dle kterých se následně tester může řídit. Pro naše potřeby prozatím testovací scénaře vytvářet nebudeme a manuální testování bude sloužit především pro odhalení nesrovnalostí s grafickým návrhem a logických chyb.
51
Závěr Práce měla za cíl vytvořit aplikaci, která by usnadnila výuku slovní zásoby. Na základě provedené analýzy konkurenčních řešení vyplynul nedostatek především v podobě nepřehledného uživatelského rozhraní. Na základě provedených průzkumů vznikl návrh všech potřebných požadavků na aplikaci, které byly posléze implementovány. Cíl práce se podařilo naplnit v podobě interaktivního prototypu, který umožňuje rychlé zorientování v jeho funkčnosti. Všechny body zadání se podařilo splnit, včetně následné podpory provozu, kdy aplikace informuje okamžitě o jakémkoliv jejím pádu. Díky tomu může být případná oprava problému provedena v co nejkratším časovém úseku. V budoucnosti by plně dokončený projekt, včetně serverové strany, mohl na základě stávajících průzkumů implementovat sociální prvky, jako jsou například hry mezi přáteli, které se ukazují jako velmi populární. Do následujících verzí aplikace by bylo vhodné přidat více druhů výukových metod, aby uživatelé měli větší prožitek z výuky.
53
Literatura [1]
Adobe Systems Inc.: PhoneGap. [online], 2014, [cit. 2014-05-09]. Dostupné z: http://www.appcelerator.com/
[2]
Apiary Ltd.: Apiary. [online], 2014, [cit. 2014-04-16]. Dostupné z: http: //apiary.io/
[3]
Appcelerator Inc.: Enterprise ment Platform. [online], 2014, http://www.appcelerator.com/
[4]
Atlassian Inc.: Free source code hosting for Git and Mercurial by Bitbucket. [online], 2014, [cit. 2014-04-16]. Dostupné z: https:// bitbucket.org/
[5]
Axure Software Solutions, Inc.: Company | Axure. [online], 2014, [cit. 2014-03-15]. Dostupné z: http://www.axure.com/company
[6]
Balsamiq Studios, LLC: Balsamiq Mockups - Balsamiq. [online], 2014, [cit. 2014-03-15]. Dostupné z: http://balsamiq.com/products/ mockups/
[7]
Crittercism Inc.: Mobile Application Performance Management. [online], 2014, [cit. 2014-04-16]. Dostupné z: http://www.crittercism.com/
[8]
Eclipse Foundation Inc.: Eclipse. [online], 2014, [cit. 2014-04-15]. Dostupné z: http://www.eclipse.org/
[9]
Elmes, D.: Anki. [online], 2014, [cit. 2014-03-12]. Dostupné z: http:// ankisrs.net/
Mobile Application Develop[cit. 2014-05-09]. Dostupné z:
[10] Fluid Software: The team behind Fluid UI. [online], 2014, [cit. 2014-0315]. Dostupné z: https://www.fluidui.com/aboutus 55
Literatura [11] Fog Creek Software Inc.: Trello. [online], 2014, [cit. 2014-04-16]. Dostupné z: https://trello.com/ [12] Google Inc.: Getting Started with Android Studio | Android Developers. [online], 2014, [cit. 2014-04-15]. Dostupné z: http:// developer.android.com/sdk/installing/studio.html [13] Google Inc.: monkeyrunner. [online], 2014, [cit. 2014-04-28]. Dostupné z: http://developer.android.com/tools/help/ monkeyrunner_concepts.html [14] Gradleware Inc.: Gradle - Build Automation Evolved. [online], 2013, [cit. 2014-04-17]. Dostupné z: http://www.gradle.org/ [15] Hlava, T.: Automatizované testování softwaru | Testování softwaru. [online], 2014, [cit. 2014-04-28]. Dostupné z: http: //testovanisoftwaru.cz/automatizovane-testovani/ [16] Krimsky, J.: Next level english vocabulary. [online], Únor 2014, [cit. 2014-03-12]. Dostupné z: https://play.google.com/store/apps/ details?id=info.krimsky.bvs [17] Manuel, O.: English 4 kids. [online], Leden 2014, [cit. 2014-0312]. Dostupné z: https://play.google.com/store/apps/details?id= com.oman.english4spanishkids [18] Paolinelli, F.: My little android warehouse: Rest interaction in Android. [online], Únor 2014, [cit. 2014-04-17]. Dostupné z: http://mytechaddiction.blogspot.cz/2014/02/rest-interactionin-android.html [19] Robotium: Robotium. [online], 2014, [cit. 2014-04-28]. Dostupné z: https://code.google.com/p/robotium/ [20] Sjölander, E.: Sprinkles. [online], 2014, [cit. 2014-05-01]. Dostupné z: https://github.com/emilsjolander/sprinkles [21] Square Inc.: Otto. [online], 2014, [cit. 2014-05-01]. Dostupné z: http: //square.github.io/otto/ [22] Square Inc.: Retrofit. [online], 2014, [cit. 2014-05-01]. Dostupné z: http: //square.github.io/retrofit/ [23] Trymph Inc.: PowerVocab Vocabulary Word App. [online], Únor 2014, [cit. 2014-03-12]. Dostupné z: https://play.google.com/store/apps/ details?id=com.applimobile.powervocab 56
Literatura [24] Vogel, L.: Android application testing with the Android test framework - Tutorial. [online], 2013, [cit. 2014-04-28]. Dostupné z: http: //www.vogella.com/tutorials/AndroidTesting/article.html [25] Wharton, J.: Butter Knife. [online], 2014, [cit. 2014-05-01]. Dostupné z: http://jakewharton.github.io/butterknife/ [26] Řezníček, J.: Tvoříme persony pro obsahový marketing. [online], Červen 2013, [cit. 2014-03-14]. Dostupné z: http://www.vceliste.cz/tvorimepersony-pro-obsahovy-marketing/ [27] Šalom, L.: Interactive Wireframing Tool | Devhand SketchIt. [online], 2014, [cit. 2014-03-15]. Dostupné z: http://www.devhand.com/ [28] Švejda, L.: iSlovíčka. [online], 2012, [cit. 2014-03-12]. Dostupné z: http: //islovicka.cz/?a=d
57
Příloha
Seznam použitých zkratek API Application Programming Interface CSS Cascading Style Sheet DAO Data Access Object GPS Global Positioning System HTML HyperText Markup Language JSON JavaScript Object Notation OS Operating System REST Representational State Transfer SDK Software Development Kit UI User Interface UML Unified Modeling Language URL Uniform Resource Locator
59
A
Příloha
Obsah přiloženého CD
readme.txt...................................stručný popis obsahu CD apk ....................... adresář se spustitelnou formou implementace src impl...................................zdrojové kódy implementace thesis ...................... zdrojová forma práce ve formátu LATEX text ....................................................... text práce thesis.pdf ............................. text práce ve formátu PDF 61
B
