UNICORN COLLEGE. Katedra informačních technologií

UNICORN COLLEGE Katedra informačních technologií

BAKALÁŘSKÁ PRÁCE

Analýza, design a implementace aplikace selftestů pro iOS

Autor BP: Vratislav Kalenda Vedoucí BP: Mgr. Petr Buchlák

2013 Praha

ZADÁNÍ

PROHLÁŠENÍ Prohlašuji, že svou bakalářskou práci na téma Analýza a návrh systému pro SelfTesty jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též uvedeny v seznamu literatury a použitých zdrojů. Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a následujících autorského zákona č. 121/2000 Sb.

V Praze dne

…........….................... Vratislav Kalenda

PODĚKOVÁNÍ Děkuji vedoucímu bakalářské práce Mgr. Petru Buchlákovi za účinnou metodickou, pedagogickou a odbornou pomoc a za další cenné rady při zpracování této bakalářské práce.

Analýza, design a implementace aplikace selftestů pro iOS Analysis, design and implementation of selftest application for iOS platform

▪5▪

ABSTRAKT Předmětem této bakalářské práce je provést analýzu, návrh a implementaci selftestovací aplikace pro platformu iOS včetně následné distribuce. Požadavek na tvorbu aplikace vychází ze studie použitelnosti stávajícího selftestovacího řešení, která je také součástí této práce. Text je rozdělen do kapitol dle jednotlivých kroků v procesu tvorby softwaru. V každé kapitole je nejprve poskytnut teoretický úvod do řešené problematiky a poté je na příkladech ukázáno, jak byly nabyté poznatky aplikovány při tvorbě aplikace selftestů. První kapitola se věnuje analýze současného stavu a následně analyzuje klíčové vlastnosti a funkčnosti vytvářené aplikace a zasazuje ji do kontextu vzdělávacího procesu Unicorn College. Druhá kapitola řeší návrh aplikace sleftestů pro iOS. Nejprve je navrženo uživatelské rozhraní jak pro iPhone, tak pro iPad a s přihlédnutím k tomuto návrhu je specifikována architektura aplikace. Třetí kapitola pojednává o samotné implementaci aplikací na iOS. Kapitola poukazuje na vývojářské nástroje a specifika vývoje pro tuto platformu a seznamuje čtenáře se zajímavými knihovnami třetích stran, které byly během vývoje použity. Čtvrtá kapitola ukazuje, jak se iOS aplikace testují a představuje jednotlivé cíle testování v kontextu celého procesu vývoje. Tato práce se zaměřuje na akceptační testy, unit testy a beta testování. Pátá kapitola shrnuje různé formy distribuce aplikace a upozorňuje především na to, v čem se od sebe odlišují. Na závěr bakalářské práce je čtenáři představena výsledná aplikace ve formě ukázky uživatelského rozhraní a jsou shrnuty přínosy realizace tohoto projektu. Cílem práce je tedy vyvinout selftestovací aplikaci pro studenty školy a celý proces její tvorby popsat v bakalářské práci.

▪6▪

K práci nebudou přiloženy zdrojové kódy aplikace, protože se jedná o obchodní tajemství společnosti Unicorn College s.r.o. Zdrojové kódy budou k dispozici k nahlédnutí při obhajobě této závěrečné práce. Klíčová slova: iOS, Vývoj aplikací pro mobilní telefony, Self testy

▪7▪

ABSTRACT This bachelor thesis deals with analysis, design, implementation and distribution of native selftest application for iOS platform. The need to create this application comes from the result of usability study of the current selftesting solution. Usability study is included in the bachelor thesis. The text is separated to individual chapters which are describing each step of software development process. Each chapter starts with a theoretic introduction into a given field of software development. The use of theory in practice is shown on examples from the development of selftest application. The first chapter deals with analysis of the current state of the selftesting solution for iOS. This analysis serves as a foundation for describing key features and properties of the application being developed. The second chapter describes the design of the selftest application. It contains the proposed user interface design and the application architecture, that was created to support it. The third chapter discusses the implementation of the selftest application. It shows the tools needed for iOS development and talks about specific techniques and patterns that are used during implementation. It also introduces interesting third party libraries that were used in the application. The fourth chapter shows various approaches to testing iOS applications. It explains the test goals and type of used tests in the context of the development process. This thesis focuses on acceptance tests, unit tests and beta testing. The fifth chapter provides summary of different distribution methods for iOS applications and shows their differences. The resulting native selftesting application is presented at the end of the bachelor thesis. Benefits resulting from this project for Unicorn College are also summed up in this chapter. To summarize: The goal of this thesis is to develop a selftesting application for iOS devices and describe the development process in the following text.

▪8▪

The source code will not be included in bachelor thesis as it is considered to be a trade secret of Unicorn College s.r.o. Keywords: iOS, Mobile application development, Self tester

▪9▪

OBSAH 1. Úvod.................................................................................................................................12 1.1 Popis jednotlivých kapitol........................................................................................13 1.2 Konvence použité v této práci..................................................................................14 2. Analýza.............................................................................................................................15 2.1 O Unicorn College....................................................................................................16 2.2 Současný stav systému selftestů...............................................................................16 2.2.1 Selftesty v procesu výuky.................................................................................17 2.2.2 Analýza použitelnosti selftestů na iOS zařízení................................................18 2.2.3 Shrnutí problému a návrh řešení.......................................................................26 2.3 Analýza v kontextu vývoje mobilních aplikací........................................................27 2.3.1 App Definition Statement – Definice aplikace.................................................27 2.3.2 Definice aplikace: Selftesty Unicorn College...................................................28 2.3.3 Definice funkčních požadavků pomocí User stories........................................29 2.3.4 Vybrané User stories aplikace selftestů............................................................31 2.3.5 Nefunkční požadavky.......................................................................................32 2.3.6 Metodika kategorizace nefunkčních požadavků...............................................32 2.3.7 Nefunkční požadavky aplikace selftestů...........................................................34 3. Design...............................................................................................................................35 3.1 Proces návrhu aplikací pro iOS................................................................................36 3.2 Návrh uživatelského rozhraní...................................................................................38 3.2.1 Zásady návrhu GUI pro iOS.............................................................................40 3.2.2 Prototyping........................................................................................................42 3.3 Uživatelské rozhraní selftestů pro iOS.....................................................................48 3.3.1 Uživatelské rozhraní iPhone verze....................................................................48 3.3.2 Uživatelské rozhraní iPad verze........................................................................53 3.4 Architektura a návrhové vzory v iOS aplikacích......................................................58 3.4.1 Model-View-Controller....................................................................................60 3.4.2 Delegace............................................................................................................61 3.4.3 Notification Center............................................................................................62 3.5 Architektura aplikace Selftestů.................................................................................63 3.5.1 High level pohled na architekturu aplikace......................................................63 3.5.2 Prezentační vrstva.............................................................................................64 3.5.3 Prezentační vrstva iPhone verze.......................................................................65 3.5.4 Prezentační vrstva iPad verze...........................................................................66 3.5.5 Integrační vrstva................................................................................................67 3.5.6 Datová vrstva....................................................................................................67 3.5.7 Datový model....................................................................................................68 3.5.8 Komunikace se serverem Selftestů...................................................................69 4. Vývoj................................................................................................................................74 4.1 Vývojové prostředí Xcode........................................................................................74 4.2 Jazyk Objective-C.....................................................................................................75 4.2.1 Historie..............................................................................................................75 4.2.2 Specifika jazyku................................................................................................76 4.3 Knihovny použité při vývoji.....................................................................................80 4.3.1 SBJson...............................................................................................................80 4.3.2 MBProgressHUD..............................................................................................81 4.3.3 Core Plot...........................................................................................................82 ▪ 10 ▪

5. Testování..........................................................................................................................83 5.1 Akceptační testy.......................................................................................................84 5.1.1 Úvod..................................................................................................................84 5.1.2 Frank – Nástroj pro akceptační testy na platformě iOS....................................85 5.1.3 Příklad akceptačního testu................................................................................86 5.2 Unit testy...................................................................................................................88 5.2.1 Úvod..................................................................................................................88 5.2.2 Unit testy v kontextu iOS..................................................................................88 5.2.3 Příklad unit testu...............................................................................................89 5.3 Beta testování za pomoci služby TestFlight.............................................................90 5.3.1 Úvod..................................................................................................................90 5.3.2 TestFlight..........................................................................................................90 6. Distribuce.........................................................................................................................93 6.1 Ad-Hoc distribuce.....................................................................................................94 6.2 Celosvětová distribuce skrze AppStore....................................................................95 6.2.1 Schvalovací proces............................................................................................96 6.3 Distribuce za pomocí firemního portálu...................................................................96 7. Aplikace Selftesty pro iOS...............................................................................................98 7.1 iPhone verze...........................................................................................................100 7.2 iPad verze...............................................................................................................103 8. Přínosy aplikace.............................................................................................................107 8.1 Přínosy pro Unicorn College..................................................................................107 8.2 Statistiky stažení a hodnocení aplikace na AppStore.............................................108 9. Závěr...............................................................................................................................109 10. CONCLUSION............................................................................................................110 11. Seznam Zdrojů.............................................................................................................111 11.1 Knižní zdroje........................................................................................................111 11.2 Internetové zdroje.................................................................................................112 12. Seznam Ilustrací...........................................................................................................115 13. Seznam tabulek.............................................................................................................117 14. Seznam příloh...............................................................................................................118 15. Příloha A: Obsah přiloženého CD................................................................................119 16. Příloha B: Technický Projekt.......................................................................................120

▪ 11 ▪

1.

ÚVOD

Tato bakalářská práce si klade za cíl vytvořit nativní aplikaci selftestů pro iOS pro vysokou školu Unicorn College. Následující text nás provede procesem tvorby této mobilní aplikace – od analýzy požadavků, až po distribuci hotové aplikace. Problematika vývoje mobilních aplikací je relativně složitá. Pro lepší pochopení je potřeba proces tvorby aplikace dekomponovat na jednotlivé kroky, které jsou potřebné provést pro úspěšné vytvoření aplikace.

Ilustrace 1: Proces vývoje mobilní aplikace

Zdroj: Vlastní zpracování

Nejprve v rámci této práce bude vytvořen tzv. „technický projekt“, který analyzuje současnou použitelnost selftestů na iOS platformě, shrne klíčové funkcionality a další požadavky na vyvíjenou aplikaci a popíše její uživatelské rozhraní. Na základě těchto informací je potom v tomto dokumentu navržena architektura aplikace. Dle technického projektu bude provedena samotná implementace selftestovací aplikace. K implementaci se využije programovací jazyk Objective-C a nástroj Xcode, který slouží k vytváření nativních iOS aplikací. Během celého vývoje bude třeba aplikaci testovat, zda odpovídá požadavkům, které jsou na ni kladeny. Obzvláště na konci implementace bude potřeba ověřit připravenost aplikace na distribuci pomocí beta testování. Aplikace bude následně distribuována skrze AppStore poté, co bude vyvinutá a otestovaná. K napsání bakalářské práce na této téma mě vede především moje záliba v psaní mobilních aplikací. Doufám, že výsledná aplikace bude sloužit jako užitečná studijní pomůcka pro studenty Unicorn College.

▪ 12 ▪

1.1 Popis jednotlivých kapitol Text je rozdělen do kapitol dle jednotlivých kroků v procesu vývoje mobilních aplikace. V každé kapitole je nejprve poskytnut teoretický úvod do řešené problematiky a poté je na příkladech z vývoje aplikace selftestů pro iOS ukázáno, jak lze teoretické poznatky uplatnit v praxi. Kapitola „2. Analýza“ se věnuje analýze současného stavu a následně analyzuje klíčové vlastnosti a funkčnosti vytvářené aplikace a zasazuje ji do kontextu vzdělávacího procesu Unicorn College. Kapitola „3. Návrh“ řeší návrh aplikace sleftestů pro iOS. Nejprve je navrženo uživatelské rozhraní jak pro iPhone, tak pro iPad a s přihlédnutím k tomuto návrhu je specifikována architektura aplikace. Kapitola „4. Vývoj“ pojednává o samotné implementaci aplikací na iOS. Kapitola poukazuje na vývojářské nástroje a specifika vývoje pro tuto platformu a seznamuje čtenáře se zajímavými knihovnami třetích stran, které byly během vývoje použity. Kapitola „5. Testování“, jak se iOS aplikace testují a představuje jednotlivé cíle testování v kontextu celého procesu vývoje. Tato práce se zaměřuje na akceptační testy, unit testy a beta testování. Kapitola „6. Distribuce“ shrnuje různé formy distribuce aplikace a upozorňuje především na to, v čem se od sebe odlišují. V kapitole „7. Aplikace Selftesty pro iOS“ je čtenáři představena výsledná aplikace ve formě ukázky uživatelského rozhraní. Na závěr bakalářské práce v kapitole „8. Přínosy aplikace“ jsou shrnuty přínosy realizace tohoto projektu pro Unicorn College.

▪ 13 ▪

1.2 Konvence použité v této práci Informace obsažené v této práci jsou jak teoretického, tak praktického charakteru. Obzvláště v příkladech se budou vyskytovat ukázky části kódů nebo návrhové diagramy. Pro odlišení byly použity různé typografické konvence: 1. Neproporcionální písmo − všechny ukázky zdrojových kódů jsou psané tímto písmem a s tímto podbarvením. 2. Tučné písmo – zvýrazňuje důležité informace nebo klíčové pojmy 3. Kurzíva – text psavý kurzívou označuje nějakou dodatečnou informaci. Pokud je tento text navíc ohraničen uvozovkami, jedná se o citaci.

▪ 14 ▪

2. ANALÝZA Tato část bakalářské práce se věnuje analýze problematiky použitelnosti systému selftestů na iOS zařízení. Nejdříve si v podkapitole „2.1 O Unicorn College“ představíme vysokou školu, která představuje zadavatele této analýzy. Potom se v podkapitole „2.2 Současný stav systému selftestů“ zaměříme na analýzu současného systému selftestů na Unicorn College, a to především z pohledu jejich použitelnosti na iPhonu a iPadu. Z této analýzy vzejde potřeba nativní iOS aplikace selftestů. Nakonec v podkapitole „2.3 Analýza v kontextu vývoje mobilních aplikací“ zachytíme koncept této aplikace pomocí dokumentu definice aplikace, popíšeme funkční požadavky pomocí uživatelských příběhů a nefunkční požadavky roztřídíme dle metodiky FURPS+. V této podkapitole je před každou praktickou částí uveden úvod do teorie dané problematiky.

▪ 15 ▪

2.1 O Unicorn College Unicorn College s.r.o. je pražskou vysokou školou založenou v roce 2006, která poskytuje bakalářské vzdělání v následujících oborech: •

Management ICT projektů

•

Informační technologie

•

Ekonomie a management

Důraz při výuce je kladen především na znalosti, které jsou aplikovatelné do praxe. Cílem školy je vychovat takové absolventy, kteří mohou zastávat posty středního a vyššího managementu či pozice IT specialistů. Ze zprávy akreditační komise z roku 2010 se můžeme dočíst následující: „UC je velmi dobře materiálně vybavenou soukromou vysokou školou, která deklaruje těžiště svého vzdělávání do oblasti profesního bakaláře. Značný důraz klade na propojení vzdělávací a tvůrčí činnosti s praxí (výraznou podporu má v tomto ohledu ve firmě Unicorn). UC dbá na transparentnost procesů, včetně procesu přijímacího řízení (tj. na jasné dodržování nároku na kvalitu). Na velmi dobré úrovni je systém elektro nických opor studia, což umocňuje transparentnost celého vzdělávacího procesu. Tyto skutečnosti považuje sama vysoká škola za své silné stránky spolu se zdůrazněním, že absolventi školy zůstávají v oboru.“ 1

2.2 Současný stav systému selftestů Vysoká škola Unicorn College dává všem studentům 1. ročníku iPad. Nejedná se jenom o marketingový tah. Tablet je velmi cennou pomůckou při studiu. Student si na něm může číst studijní materiály, podívat se na záznamy z přednášek nebo si na něm vyhledat potřebné informace na internetu. Velká výhoda tabletu oproti notebooku je jeho zvýšená mobilita, rychlost použití a dlouhá výdrž.

1

GERŠLOVÁ a kol. Zpráva Akreditační komise o hodnocení Unicorn College s.r.o. Praha [online] vyd. listopad 2010 dostupné z URL: http://www.akreditacnikomise.cz/attachments/article/252/CZ_hodnoceni_unicorn_college_2010.pdf ▪ 16 ▪

V rámci podpory vzdělávání poskytuje Unicorn College svým studentům systém selftestů. Student si může díky selftestům ověřit svoje znalosti před testem nebo před zkouškou. Selftesty byly vyvinuty jako webová aplikace v době, kdy tablety a mobilní zařízení nebyly rozšířené, a proto jejich použití na mobilních zařízení není optimální. Unicorn College by ráda zpřístupnila selftesty na iPadech a iPhonech, a proto se rozhodla vyvinout řešení pro iOS zařízení. 2.2.1

Selftesty v procesu výuky

Proces výuky je klíčovým procesem školy.2 V tomto procesu vzniká přidaná hodnota, kdy díky nárůstu know-how studenta se zvyšuje jeho cena na trhu práce.

Pro

úspěšné absolvování studia musí každý student během semestru plnit průběžné hodnocení semestru a na jeho konci složit zkoušky. Selftesty umožňují studentovi ověřit si objektivně své znalosti před každým testem nebo zkouškou a tím přispívají k hladkému průběhu procesu výuky. Student může dle výsledků dosažených v selftestu zintenzivnit studijní úsilí a tím se vyhnout nesplnění průběžného hodnocení nebo vyhození od zkoušky. Ilustrace 2: Proces vzdělávání

Zdroj: BOCEK, F.: Analýza a návrh systému pro SelfTesty [online]. Praha, 2011 [cit. 2013-04-18]. Bakalářská práce (Bc.). Unicorn College. 2

BOCEK, F.: Analýza a návrh systému pro SelfTesty [online]. Praha, 2011 [cit. 2013-04-18]. Bakalářská práce (Bc.). Unicorn College. ▪ 17 ▪

2.2.2

Analýza použitelnosti selftestů na iOS zařízení

Použitelnost selftestů na mobilních zařízení iOS je limitována hlavně špatnou ergono mií uživatelského rozhraní selftestů, které bylo navrženo především pro použití prostřednictvím internetového prohlížeče počítače. K jednotlivým selftestům se navíc nelze dostat jinak, než že se student přihlásí do školního informačního systému Unicorn Universe (dále také jako „UU“) a otevře si kartu předmětu, ze kterého se chce otestovat. Teprve na kartě předmětu jsou k dispozici odkazy na selftesty. UU není optimalizováno pro přístup z mobilního zařízení a množství přenášených dat je enormní. Následující text analyzuje jednotlivé kroky, které je potřeba vykonat k tomu, aby se student dostal k selftestům z vybraného předmětu, a popisuje konkrétní nedostatky, které je potřeba odstranit pro pohodlné používání selftestů na iOS zařízení.

▪ 18 ▪

2.2.2.1 Přihlášení do UU Uživatel se nejprve musí přihlásit do školního informačního systému Unicorn Universe. Většina studentů se do systému přihlašuje na adrese www.unicorncollege.cz. Existuje také přístup pomocí mobilní brány m.unicornuniverse.eu, která dovoluje přihlášení se pomocí PIN kódu, ale její zprovoznění je poměrně složité (vyžaduje skenování QR kódu nebo opsání velmi dlouhého hesla) a většina studentů o této metodě neví.

Ilustrace 3: IPhone - přihlášení skrze stránku školy


Nedostatky: 1. Velmi malé vstupní pole pro přihlašovací údaje v poměru ke zbytku stránky. 2. Uživatel udělá velmi často chybu při zadávání přihlašovacích údajů do skrytých polí.

▪ 19 ▪

Ilustrace 4: iPhone - přihlášení pomocí mobilního kódu


Nedostatky: 1. Zprovoznění této formy přihlašování vyžaduje naskenování QR kódu, což na prvním iPadu není možné - nemá fotoaparát. Na ostatních iOS zařízení vyžaduje instalaci QR čtečky. Alternativou ke QR skenu je opsání šestatřicetimístného kódu.

▪ 20 ▪

2.2.2.2 Přístup na kartu předmětu Po přihlášení se zobrazí uživateli portál novinek (nebo diář, pokud využil mobilního přihlášení). Student musí buď znát kód předmětu, nebo se musí ke kartě proklikat. K libovolnému vyučovanému předmětu se z portálu novinek lze dostat skrze následující odkazy: UCL Portál → Předměty → Odkaz na vybraný předmět

Ilustrace 6: iPhone - portál novinek

Ilustrace 5: iPhone - zadávání kódu předmětu



Nedostatky: 1. Odkazy a ostatní ovládací prvky jsou moc malé. Špatně se mačkají, a to i na iPa du. Skoro každá akce tedy vyžaduje přiblížení stránky, aby se uživatel trefil na odkaz nebo tlačítko. 2. Přechod na kartu předmětu vyžaduje 3 přechody mezi stránkami nebo znalost jeho kódu. 3. Zadávání kódu z mobilního zařízení je obtížné kvůli jeho formátu. Pro příklad si vezmeme zadání kódu předmětu testování: ▪ 21 ▪

TST13S.CZ/FULLTIME Kód obsahuje velká písmena, číslice, tečku a lomítko. Tyto znaky nejsou k dis pozici na stejné stránce standardní klávesnice (a to ani na iPadu), a proto musí uživatel během psaní velmi často mezi klávesnicemi přepínat.

2.2.2.3 Spuštění selftestů z karty předmětu Poté, co se student dostane na kartu předmětu, může spustit selftest z předem vybraných okruhů.

Ilustrace 7: iPhone - karta předmětu


Nedostatky: 1. Odkaz na selftesty je velmi malý, na iPhone si musí uživatel přiblížit stránku, aby ho mohl zmáčknout.

▪ 22 ▪

2.2.2.4 Vyplnění selftestu Uživateli se zobrazí po zmáčknutí odkazu test k vyplnění.

Ilustrace 8: iPhone - selftest


Ilustrace 9: iPhone - selftest (na šířku)


▪ 23 ▪

Nedostatky: 1. Text je příliš malý, na iPhonu se na výšku špatně čte. 2. Test může být hodně dlouhý a uživatel se v něm může na mobilu ztratit. 3. Na iPadu lze zvolit odpověď jedině tím, že uživatel klikne na radio button, který je vlevo vedle odpovědi. 4. Dotyková plocha na zvolení odpovědi je velmi malá. Obvzlášť na iPhonu se stává, že bez přiblížení uživatel vybere jinou odpověď než chtěl.

2.2.2.5 Vyhodnocení selftestu Po odeslání testu se zobrazí uživateli jeho výsledek. Ilustrace 10: iPhone - vyplněný selftest


Nedostatky: 1. U otázky není přehledně označeno, zda uživatel odpověděl správně. Odpovězená otázka má červeným písmem napsaný počet dosažených bodů a zeleně vybarvenou správnou odpověď. Pokud je počet bodů nenulový a je vybrán ra-

▪ 24 ▪

dio button u zeleně zabarvené odpovědi, potom uživatel odpověděl správně. Problémem je, že na malé obrazovce mobilního zařízení se tyto dva znaky správně odpovězené otázky špatně hledají. 2. Po dokončení testu není snadné se dostat k testu z jiného okruhu nebo z jiného předmětu. 2.2.2.6 Přenesená data Pro používání selftestů na mobilních zařízení je také důležité množství přenesených dat. Tablety a mobilní telefony jsou k internetu připojeny stále ještě často pomocí technologie EDGE, která dosahuje v našich podmínkách rychlosti 150 kbit/s. Důležité je také vzít v úvahu FUP limity přenesených dat. V České Republice jsou běžné FUP limity od 50MB – do 1GB měsíčně. Měření bylo provedeno pomocí počítače a internetového prohlížeče Google Chrome. Před měřením byla vymazána cache. Krok

Přenesená data

Doba načtení

1. Přihlášení do UU

742 KB

6,5 sekund

2. Přístup na kartu předmětu

849 KB při zadazání kódu 1 154 KB při použití odkazů

9,3 sekund při zadání kódu 17,3 sekund při použití odkazů

3. Spuštění selftestů z karty předmětu

76 KB

4,2 sekund

4. Vyplnění selftestu

70 KB

1,3 sekundy

5. Vyhodnocení selftestu

22 KB

0,7 sekundy

Celkem

1 759 – 2 075 KB

22 – 30 sekund

Tabulka 1: Přenesená data a doba načtení stránek selftestů

Množství přenesených dat pro zobrazení jednoho selftestu je značně velké a při nízkých FUP se může uživatel rozmýšlet, zda se mu přístup k selftestům vyplatí.

▪ 25 ▪

2.2.3

Shrnutí problému a návrh řešení

Selftesty v současné podobně nedovolují pohodlné používání z iOS zařízení. Postup k jejich spuštění je složitý a časově náročný. Uživatelské rozhraní nevyhovuje dnešním standardům kladeným na mobilní aplikace. Řešením je vyvinout nativní iOS aplikaci, která by selftesty zpřístupnila jak na iPhonu tak na iPadu. Ilustrace 11: Návrh řešení


Aplikace by uživateli umožňovala rychlý přístup k selftestům pomocí pohodlného uživatelského rozhraní, na které jsou uživatelé Apple produktů zvyklí. Díky cachování selftestů v zařízení by se studenti mohli připravovat na zkoušky i tam, kde není datové pokrytí, jako třeba v metru nebo v zahraničí. Aplikace tak bude naplňovat heslo školy: „Studuj kdekoli“. Dalším benefitem je fakt, že aplikace bude veřejně dostupná prostřednictvím AppStore, a tím bude šířit povědomí o škole a zvyšovat její prestiž.

▪ 26 ▪

2.3 Analýza v kontextu vývoje mobilních aplikací Tato kapitola představuje techniky, které lze použít v rámci analýzy při tvorbě iOS aplikace. Teoretický výklad je podpořen praktickými ukázkami z analýzy, která byla provedena pro aplikaci Selftesty pro iOS. 2.3.1

App Definition Statement – Definice aplikace

App definition statement, neboli definice aplikace, je dokument, který stručně a výstižně definuje hlavní účel aplikace, cílovou skupinu uživatelů a obsahuje výčet klíčových funkcionalit a vlastností. 3 Tento dokument slouží k vyjasnění vize a představení hlavní myšlenky aplikace všem zainteresovaným osobám v celém procesu tvorby aplikace. Představuje také jakýsi „kontrakt“ mezi stakeholderem 4 a vývojářským týmem a pomáhá řídit očekávání obou stran. Definice aplikace vzniká následovně: Nejprve je potřeba definovat hlavní myšlenku a účel aplikace. Poté je dobré vymyslet co nejvíce různých funkcí, které by mohla aplikace mít (v tomto kroku se doporučuje metoda brainstormingu). Následně je třeba si definovat cílovou skupinu uživatelů (je dobré si klást otázky: „Co naši uživatelé chtějí?“, „Co je pro ně nejdůležitější?“, “Jaké mají osobnostní vlastnosti?“). Finálním krokem je potom profiltrování vymyšlených funkcí aplikace s její cílovou skupinou uživatelů. Měly by zůstat pouze ty funkce, které přinášejí uživatelům největší přidanou hodnotu.5

3 4 5

APPLE, iOS Human Interface Guidelines – App Design Strategies [online] [cit. 2013-04-07] Stakeholder – Osoba nebo organizace, která tvorbu aplikace finančně sponzoruje a má zájem na úspěšném dokončení projektu. APPLE, iOS Human Interface Guidelines – App Design Strategies [online] [cit. 2013-04-07] ▪ 27 ▪

2.3.2

Definice aplikace: Selftesty Unicorn College

Hlavním účelem aplikace Selftesty pro iOS je umožnit studentům kvalitně se připravit na test nebo na zkoušku tím, že si ověří své znalosti pomocí selftestu. Aplikace bude mít přehledné a jednoduché rozhraní, které uživateli dovolí rychle spustit test z vybraných tématických okruhů. Selftesty pro iOS budou také umožňovat přístup k selftestům i bez internetového připojení, aby se mohli studenti testovat naprosto kdekoli. Uživatelé selftestů pro iOS jsou: 1. Lidé vlastnící iPhone nebo iPad 2. Studenti, kteří se potřebují připravit na zkoušku nebo test z předmětu, který se vyučuje na UCL 3. Ti, kteří se učí za pohybu. Látku si opakují 5 minut před zkouškou, učí se při jízdě v autobuse nebo v metru 4. Rádi si ověřují, jak jsou v dané problematice dobří a mají radost ze zlepšení 5. Studenti uvažující o studiu na UCL, kteří si stáhli aplikaci selftestů v rámci zjiš ťování informací o škole A proto aplikace umožňuje: 1. Rychle spustit selftest z vybraného předmětu a témat 2. Vyplnit selftest pohodlně jedním prstem 3. Přehledně zobrazit výsledek selftestu atraktivním způsobem, který bude vyvolávat touhu po zlepšení 4. Uložit předmět a jeho témata do zařízení pro použití bez internetového připojení 5. Upravit počet otázek v testu A má následující vlastnosti: 1. Uživatelské rozhraní se podobá standardnímu rozhraní iOS, aby uživateli neodvádělo pozornost od studia

▪ 28 ▪

2. Aplikace je kvalitně zpracovaná a grafické provedení je v barvách školy, aby budila dobrý dojem a zvyšovala povědomí o škole 2.3.3

Definice funkčních požadavků pomocí User stories

Uživatelský příběh, neboli user story, popisuje funkcionalitu aplikace, která přináší hodnotu buď uživateli, nebo tomu, kdo za software zaplatil. Uživatelský příběh je složen z následujících částí: 1. Písemný popis uživatelského příběhu (tradičně psaný na kartičku z papíru) 2. Konverzace ohledně detailů uživatelského příběhu, která proběhla mezi vývojářským týmem a zákazníkem 3. Akceptační kritéria, podle kterých se napíšou během vývoje akceptační testy. Pokud jsou tyto testy úspěšné, uživatelský příběh je považován za implementovaný Přesto, že písemný popis je nejviditelnějším projevem uživatelského příběhu, není nejdůležitější. Klíčovým aspektem jsou právě konverzace se zákazníkem, které jsou potom transformovány na akceptační kritéria. 6 Uživatelské příběhy se vyplatí používat zejména kvůli tomu, že na rozdíl od případů použití se tolik nesoustředí na technické a procesní detaily (které často nejsou na začátku vývoje známy) a soustředí se na jádro věci. Jsou psány jazykem zákazníka, a proto je jim schopný dobře porozumět a dokáže je efektivně prioritizovat. 7 Pokud je to nutné, dají se pro jednotlivé uživatelské příběhy dopsat i případy použití, které popisují procesní stránku funkcionality více do hloubky. 8 V případě malých projektů to ale většinou není třeba. Příběhy, které pojednávají o podobné věci, lze seskupovat do „témat“. 9 Témata jsou užitečná pro organizaci většího počtu uživatelských příběhů. Struktura popisu uživatelských příběhů může být následující: „Jako , abych <účel>”.10 Uživatelský příběh tedy může 6

COHN, Mike: User Stories Applied for Agile Software Development, 13. vyd., Crawfodsville, Indiana: Pearson Education, 2009, s 4. 7 COHN, Mike: User Stories Applied for Agile Software Development, 13. vyd., Crawfodsville, Indiana: Pearson Education, 2009, s 13. 8 LAHANAS STEPHEN: Aligning User Stories, Use Cases and Requirements [online] [cit. 2013-04-17] 9 COHN, Mike: User Stories, Epics and Themes [online] [cit. 2013-04-17] 10 COHN, Mike: Advantages of the “As a user, I want” user story template [online] [cit. 2013-04-17] ▪ 29 ▪

vypadat následovně: „Jako student chci, aby mi školní informační systém ukazoval moje průběžné výsledky z předmětů, abych mohl průběžně sledovat, jak mi jde studium.“ Je dobré si všimnout, že uživatelský příběh v tomto formátu popisuje podobné věci jako definice aplikace, akorát na nižší úrovni; obsahuje cílového uživatele, funkcionalitu a účel. Je tedy jednoduché ověřit, zda je uživatelský příběh v souladu s definicí aplikace.

▪ 30 ▪

2.3.4

Vybrané User stories aplikace selftestů

Pro ukázku použití uživatelských příběhů při sběru funkčních požadavků uvádím uživatelské příběhy na téma předměty (zbytek uživatelských příběhů můžete nalézt v technickém projektu – příloha B této bakalářské práce): Téma: Předměty #1 – Zobrazení předmětů po spuštění aplikace Jako uživatel chci, aby se mi po spuštění aplikace zobrazil seznam předmětů, ze kterých jsou k dispozici testy, abych si mohl vybrat, z čeho se chci nechat otestovat. Akceptační kritéria: 1. 2. 3. 4. 5.

Předměty jsou zobrazeny abecedně Je zobrazen název předmětu a jeho zkratka Každý předmět je reprezentován předem danou ikonou U každého předmětu je vidět, zda je uložen v zařízení Jsou zobrazeny pouze předměty, u kterých jsou k dispozici testy

#2 – Aktualizace předmětů a témat Jako uživatel chci, aby se na požádání stáhl aktualizovaný seznam předmětů a jejich témat, abych měl přístup k novým nebo opraveným otázkám. Akceptační kritéria:

1. Uživatel může na požádání aktualizovat seznam předmětů 2. Pokud má uživatel témata nějakého předmětu uložena v zařízení, provede se aktualizace těchto témat #3 – Cachování předmětu Jako uživatel chci, aby jednou stáhnutá témata předmětu byla k dispozici, dokud nezažádám o jejich aktualizaci. Chci to z toho důvodu, abych nemusel stahovat témata pokaždé, když se chci nechat otestovat z daného předmětu. Akceptační kritéria:

1. Témata budou po prvním stažení uložena v zařízení a budou přístupná bez připojení na server selftestů do té doby, než si uživatel nevyžádá novou aktualizaci předmětů a témat 2. Aktualizace předmětů a témat vymaže cachované témata

▪ 31 ▪

#4 – Uložení předmětu do paměti zařízení

Jakožto uživatel chci mít možnost si uložit předmět a jeho témata do zařízení, abych se mohl otestovat i tam, kde nemám internetové připojení – třeba při jízdě metrem. Akceptační kritéria:

1. Témata daného předmětu jsou dostupné, i když server selftestů není k dispozici 2. Pokud uživatel provede aktualizaci předmětů a témat, tak témata uloženého předmětu budou aktualizována a znovu uložena do zařízení Uživatelské příběhy nemusí popisovat pouze funkcionality významné přímo pro uživatele aplikace, ale také funkcionality, které jsou důležité pro ostatní zainteresované strany: Téma: Ostatní #15 – Zobrazení loga Jako ředitel chci, aby při startu aplikace bylo zobrazeno logo školy. Tímto chci dosáhnout zvýšení veřejného povědomí o škole Unicorn College. Akceptační kritéria:

1. Logo Unicorn College je zobrazeno po dobu spouštění aplikace.

2.3.5

Nefunkční požadavky

Za účelem doručení softwaru zákazníkovi v očekávané kvalitě je zapotřebí, aby aplikace splňovala další požadavky, které nemají přímo funkční povahu. Těmto požadavkům se říká nefunkční požadavky.11 2.3.6

Metodika kategorizace nefunkčních požadavků

Nefunkční požadavky lze kategorizovat za pomocí metodiky FURPS. Každé písmeno tohoto akronymu označuje jednu kategorii požadavků, přičemž ve všech případech kromě písmene F se jedná o nefunkční požadavky. Jestliže si jednotlivé kategorie ne funkčních požadavků rozepíšeme, pak se jedná o požadavky na:

11 KRUCHTEN, Philippe: The rational unified process: an introduction, 3. ilustrované vydání, AddisonWesley Professional, 2004, str. 159 ▪ 32 ▪

●

Použitelnost (Usability) – Tyto požadavky souvisejí s lidským aspektem vyvíjeného softwaru. Definují například vzhled uživatelského rozhraní, jeho ergonomii nebo třeba nároky na uživatelskou nápovědu.

●

Spolehlivost (Reliablity) – Požadavky v této kategorii definují maximální možnou frekvenci a závažnost chyb při provozu SW, předvídatelnost chování, obnovitelnost systému po katastrofickém selhání a požadovanou přesnost výpočtů.

●

Výkonnost (Performance) – Definují rychlost zpracování požadavků, maximální odezvu uživatelského rozhraní, maximální využití procesoru, operační paměti aj.

●

Podporovatelnost (Supportability) – Požadavky podporovatelnosti určují testovatelnost, udržovatelnost a nasaditelnost systému. Tento typ požadavku je specifický v tom, že požadované vlastnosti můžou být vyžadovány nejen po vyvíjeném systému, ale i po procesu jeho vývoje. Může se požadovat například specifický standard psaní zdrojového kódu, nebo určitá metodika řízení projektu.12 Tento model se ještě obvykle rozšiřuje o dodatečnou kategorii označovanou

jako „+“. Do této kategorie spadají ostatní požadavky, které nespadají do ostatních kategorií. Příkladem takového požadavku může být zákaz použití knihoven s copyleft13 licencí.

12 KRUCHTEN, Philippe: The rational unified process: an introduction, 3. ilustrované vydání, Addison-Wesley Professional, 2004, str. 159 13 Koncept copyleft licencí je vysvětlen na url http://www.gnu.org/copyleft/copyleft.html ▪ 33 ▪

2.3.7

Nefunkční požadavky aplikace selftestů

Následující tabulka zachycuje nefunkční požadavky na systém. Pro jejich kategorizaci je použita metodika FURPS+ Kód

Název

Popis

Kategorie

U001

Dodržování HiG

Aplikace bude dodržovat zásady Human Interface Guidelines pro iOS zařízení

Usability

U002

Aplikace bude vyvedena Grafické rozhraní bude v barvách školy a v barvách Unicorn bude podporovat povědomí o Unicorn College College

Usability

U003

Vzhled front-endu bude navržen grafikem

Grafická podoba aplikace bude navržena profesionálním grafikem

Usability

U004

Aplikace bude efektivně a smysluplně využívat velikost obrazovky daného zařízení

Uživatelské rozhraní aplikace musí být navrženo tak, aby efektivně využívalo velikost obrazovky zařízení, na kterém běží. Aplikace bude mít odlišené GUI pro iPhony a pro iPady

Usability

R001

Aplikace při ukončení uloží svá data

Aplikace před úplným ukončením uloží veškeré změny do perzistentního úložiště

Reliability

R002

Aplikace bude vypočítávat výsledek testu s přesností na procenta

Aplikace bude vypočítávat výsledek testu s přesností na jednotky procent.

Reliability

P001

Aplikace musí v jakékoli chvíli odpovědět na vstup uživatele do dvou sekund

Aplikace musí reagovat na vstup uživatele maximálně do dvou sekund. Pokud probíhá akce, která má trvání delší než dvě sekundy, uživatel o tom musí být informován a daná úloha musí běžet na pozadí.

Performance

S001

Aplikace musí plně Podporovaná zařízení touto aplikací jsou: podporovat vybraná iOS iPhone4, iPhone4S, iPhone 5, iPad, iPad2, zařízení iPad3

Supportability

S002

Aplikace musí plně podporovat vybrané verze iOS

Aplikace musí podporovat verze iOS 5+

Supportability

S003

Aplikace musí být distribuovatelná skrze AppStore

Aplikace musí splňovat všechny podmínky pro přijetí do AppStoru

Supportability

Aplikace nebude Žádná součást systému nebude využívat Pls001 obsahovat komponenty s softwaru šířeného pod licencí CopyLeft CopyLeft licencí

Tabulka 2: Nefunkční požadavky na aplikaci

▪ 34 ▪

Ostatní

3.

DESIGN

Tato kapitola bakalářské práce se věnuje návrhu aplikace pro platformu iOS. V podkapitole „3.1 Proces Návrhu aplikací pro iOS“ si shrneme celý postup návrhu aplikace a shrneme si architektonická rozhodnutí, která je třeba v této fázi udělat. Podkapitola „3.2 Návrh uživatelského rozhraní“ poskytuje teoretický úvod do navrhování uživatelských rozhraní pro iOS. Jsou v ní uvedeny zásady návrhu a možné postupy jeho tvorby. V rámci podkapitoly „3.3 Uživatelské rozhraní selftestů pro iOS“ uplatníme teoretické poznatky při návrhu uživatelského rozhraní selftestovací aplikace. Architekturou iOS aplikací se zabývá podkapitola „3.4 Architektura a návrhové vzory v iOS“. Zde si představíme základní frameworky na platformě iOS a ukážeme si nejčastěji používané návrhové vzory. Ukázkou uplatnění teorie z předcházející kapitoly je podkapitola „3.5 Architektura aplikace Selftestů“. Ukážeme si, jak jsou poznatky o architektuře uplatněny v návrhu sleftestovací aplikace.

▪ 35 ▪

3.1 Proces návrhu aplikací pro iOS Ilustrace 12: Proces návrhu iOS aplikací


Vstup do procesu návrhu aplikace tvoří výstupy analýzy: dokument definice aplikace a sesbírané funkční a nefunkční požadavky na aplikaci. Cílem tohoto procesu je vytvořit návrh uživatelského rozhraní (také označováno pojmem GUI) a popis architektury. Proces návrhu začíná návrhem uživatelského rozhraní, které má obvykle značný dopad na celou architekturu14, jelikož iOS aplikace jsou především o interakci s uživatelem. Apple doporučuje začít navrhovat uživatelské rozhraní zpočátku na papíře, aby nebyl návrhář omezován tím, jak moc je dané rozhraní složité realizovat. 15 Dále radí používat prototypy pro získání prvotní zpětné vazby od uživatelů a vylepšovat GUI iterativním způsobem, kdy každou iterací vznikají komplexnější a detailnější prototypy, které nakonec vedou k finálnímu návrhu. 16 Návrh architektury začíná rozhodnutím, zda k realizaci uživatelského rozhraní použijeme předpřipravené vizuální komponenty MVC frameworku Cocoa Touch, nebo se rozhodneme pro implementaci vlastního systému uživatelského rozhraní nad frameworkem OpenGL ES17 (tato varianta je vhodná především pro audiovizuálně intenzivní aplikace, jakými jsou například hry). 14 15 16 17

APPLE, Design Your App with Care - Do Your Initial Design, [online] [cit. 2013-04-18] APPLE, Design Your App with Care - Do Your Initial Design, [online] [cit. 2013-04-18] APPLE, iOS Human Interface Guidelines - Prototype and Iterate, [online] [cit. 2013-04-18] APPLE, Design Your App with Care - Translate Your Initial Design into an Action Plan, [online] [cit. 2013-04-18] ▪ 36 ▪

Dalším významným rozhodnutím je, jakým způsobem budeme reprezentovat a ukládat data aplikace. Toto rozhodnutí závisí především na funkčních požadavcích aplikace. Často používanou možností pro ukládání strukturovaných dat je použití frameworku Core Data, který nabízí ORM 18 mapování nad SQLite databází. K dispozici je také datový model postavený nad serializací a deserializací objektů do souborů v sandboxovém prostředí aplikace.19 Nakonec je potřeba v rámci architektury určit, jakým způsobem bude mobilní aplikace komunikovat s okolními systémy (pokud je taková komunikace požadována). Způsob, obsah a periodicita komunikace se obvykle odvíjí od funkčních i nefunkčních požadavků. Protokol komunikace je dán rozhraním, které okolní systémy poskytují.

18 Objektově Relační Mapování – Technika přístupu k záznamům v databázi podobným způsobem, jako se přistupuje ke kolekci objektů. 19 APPLE, Archives and Serializations Programming Guide, [online] [cit. 2013-04-18]

▪ 37 ▪

3.2 Návrh uživatelského rozhraní Návrh uživatelského rozhraní začíná tím, že si vývojářský tým musí uvědomit, jaký styl aplikace vyvíjí: zda se jedná o tzv. „utility“, „productivity“ nebo „immersive“ aplikaci. Každý styl aplikace se vyznačuje specifickými vizuálními prvky, typem poskytnutých informací, a také jsou na každý styl kladeny jiná uživatelská očekávání. 20 Utility aplikace umožňují uživateli rychle vykonat úzce specifikovanou akci (například použít mobil jako vodováhu) nebo rychle získat požadovanou informaci (například převést km/h na míle/h). Aplikace tohoto typu využívají jednoduchého uživatelského rozhraní a nevyžadují obvykle žádné prvotní nastavení od uživatele, aby mohli plnit svoji funkci.21 Utitlity aplikace mají často stylizované rozhraní, které tématicky ladí s jejich účelem, ale drží se standardních ovládacích prvků, aby jejich použití uživatel snadno pochopil a mohl aplikaci ihned použít.

Ilustrace 13: Utility aplikace Weather

Zdroj: Apple

20 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str.3 21 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str.4 ▪ 38 ▪

Productivity aplikace nabízejí širší plejádu funkcí než utility aplikace, a uživatel v nich celkově tráví více času. Tento typ aplikací zahrnuje vše od mobilního bankovnictví až po sociální sítě. Aplikace tohoto typu mají obvykle hierarchické uživatelské rozhraní, které používá standardní ovládací a grafické prvky. 22 Familiárnost prvků rozhraní dovoluje uživateli soustředit se na funkcionality a informace, které aplikace poskytuje.

Ilustrace 14: Productivity aplikace Dropbox

Ilustrace 15: Productivity aplikace Twitter


Zdroj: https://itunes.apple.com/

22 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str.7 ▪ 39 ▪

Immersive aplikace, upozaďují uživatelské rozhraní, soustředí se primárně na mediální obsah a nabízejí uživateli způsob, jak strávit svůj volný čas. Do této kategorie spadají, hry, prohlížeče fotografií nebo přehrávače videa. Mezi immersive aplikace lze také řadit utility aplikace, které mají nestandardní uživatelské rozhraní. Tyto aplikace často poskytují velmi specifické uživatelské rozhraní, které je vyvíjeno exkluzivně pro danou aplikaci.23 Ilustrace 16: Immersive aplikace Converbot

Ilustrace 17: Immersive aplikace Compass

Zdroj: http://tapbots.com Zdroj: https://itunes.apple.com/

3.2.1

Zásady návrhu GUI pro iOS

Standardy a doporučené postupy při návrhu GUI pro iOS aplikace shrnuje dokument od Apple Human Interface Guidelines (zkratkou „HIG“). Dodržování zásad v něm uvedených je závazné pro aplikace vyvíjené pro distribuci skrze AppStore. 24 HIG uvádí sadu základních principů interakce s uživatelem (v originále „Human Interface Principles“), jejichž dodržení přispívá k tomu, aby v uživateli byly vyvolávány pozitivní emoce a aplikaci si zamiloval: 25

23 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str.13 24 APPLE, App Store Review Guidelines, [online] [cit. 2013-04-18] 25 APPLE, iOS Human Interface Guidelines – Human Interface Principles, [online] [cit. 2013-04-21] ▪ 40 ▪

1. Sladění vzhledu a funkce – Vzhled aplikace by měl odpovídat její funkcionalitě. Productivity aplikace by měla využívat standardní uživatelské prvky a dekorativní prvky by měli být potlačeny ve prospěch obsahu. Naopak imerzivní aplikace, jako například hry, by měly nabídnout hravé rozhraní, které odměňuje zvídavost.26 2. Konzistence – Aplikace, které jsou konzistentní, dovolují uživateli použít své zkušenosti a dovednosti z jiných aplikací. Používají paradigmata a zásady uživatelského rozhraní iOS takovým způsobem, že uživatel dokáže ihned použít aplikaci i bez manuálu nebo tutoriálu. Aplikace by měla být konzistentní také sama se sebou. Měla by používat na všech místech shodnou terminologii, zachovávat zavedená schémata ovládání a rozložení uživatelských prvků. Aplikace by si měla zachovat své fundamentální koncepty i mezi svými verzemi.27 3. Přímá manipulace – Na platformě iOS jsou uživatelé zvyklí ovládat objekty na obrazovce přímo svými prsty. Díky technologii Multi—Touch 28 mohou uživatelé používat sofistikovaná gesta, která jim poskytují pocit kontroly, který je větší, než kdyby s aplikací interagovali za pomocí myši nebo klávesnice. Rozhraní by proto mělo být navrženo tak, aby podporovalo gesta a umožňovalo přímé ovládání pomocí doteků. Například od aplikace zobrazující fotografie uživatel očekává, že bude moct fotku přiblížit nebo oddálit za pomocí pinch gesta29.30 4. Zpětná vazba – Uživatelé iPhonů a iPadů očekávají vizuální zpětnou vazbu při jakékoli akci, kterou provedou. Aplikace díky zpětné vazbě dává najevo, že přijala vstup od uživatele. Toto vizuální potvrzení je obzvlášť důležité pro uživatelské rozhraní na mobilech, kde se uživateli nedostává zpětná vazba pomocí doteku z důvodu absence klávesnice. Aplikace pro iOS proto obvykle při každém doteku na ovládací prvek spustí decentní animaci, aby uživatele ujistila o tom, že jeho dotek přijala. Indikátor aktivity se používá pro zpětnou vazbu 26 APPLE, iOS Human Interface Guidelines – Human Interface Principles, [online] [cit. 2013-04-21] 27 APPLE, iOS Human Interface Guidelines – Human Interface Principles, [online] [cit. 2013-04-21] 28 Mutli—Touch – Schopnost ovládat aplikaci pomocí gest, které jsou složeny z více než jednoho současného doteku. 29 Pinch gesto – Gesto složené z dvou doteků, při kterém prsty uživatele připomínají pinzetu. Pro přiblížení obsahu na obrazovce uživatel oddálí prsty od sebe. Pro oddálení uživatel stiskne prsty k sobě. 30 APPLE, iOS Human Interface Guidelines – Human Interface Principles, [online] [cit. 2013-04-21] ▪ 41 ▪

při dlouho trvajících operací na pozadí, aby uživatel nenabyl dojmů že se aplikace zasekla a nic nedělá.31 5. Metafory – V aplikaci by měli být použity vhodné metafory, které uživatelům pomohou velmi rychle pochopit smysl a účel jednotlivých ovládacích prvků na obrazovce.32 6. Uživatelská kontrola – Uživatel by vždy měl být iniciátorem akce v aplikaci. Program může dávat varování a doporučení, jakou akci provést, ale uživatel by měl být vždy ten, kdo nakonec udělá finální rozhodnutí. Chování aplikace by mělo být povědomé a předvídatelné, akce by měli být jednoduché a snadno zapamatovatelné. Uživatel také očekává, že bude v aplikaci schopný bez následků zastavit akci, která běží na pozadí.33 3.2.2

Prototyping

Prototypy umožňují vyřešit většinu problému s uživatelským rozhraní ještě ve stádiu návrhu. Umožňují jednoduše zachytit navrhovaný vzhled a chování aplikace a tím ušetřit čas a peníze.34 „Nejčastěji se odhaduje, že je 100krát levnější udělat změnu v návrhu před napsáním jediné řádky kódu, než čekat se změnou do doby, kdy je implementace již dokončena.“ —Jakob Nielsen35 Prototypy jsou často používány pro porovnání různých návrhů uživatelského rozhraní. Používají se k vizualizaci jak samotného vzhledu a rozložení ovládacích prvků, tak i k zaznamenání přechodů mezi jednotlivými obrazovkami. 36 Prototypy můžou řešit celou řadu problémů: koncept samotné aplikace, organizaci informací na obrazovce nebo srozumitelnost terminologie.

31 32 33 34

APPLE, iOS Human Interface Guidelines – Human Interface Principles, [online] [cit. 2013-04-21] APPLE, iOS Human Interface Guidelines – Human Interface Principles, [online] [cit. 2013-04-21] APPLE, iOS Human Interface Guidelines – Human Interface Principles, [online] [cit. 2013-04-21] GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str.138 35 NIELSEN J., Paper Prototyping: Getting User Data Before You Code, [online] [cit. 2013-04-21], vlastní překlad, originální znění: „The most common estimate is that it's 100 times cheaper to make a change before any code has been written than it is to wait until after the implementation is complete.“ 36 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str.142 ▪ 42 ▪

S prototypy se pracuje iterativním způsobem, kdy se v každé iteraci zkouší několik prototypů a postupně se vyřazují ty, které nesplňují požadavky uživatelů. Do prototypů, které postoupí do další iterace se zapracují připomínky od účastníků prototypování.37 Existují různé druhy prototypů. Liší se především v míře interaktivity, snadnosti jejich vytvoření a rychlosti s jakou se dají zapracovat změny:

Ilustrace 18: Porovnání prototypů



3.2.2.1 Papírové prototypy Papírové modely umožňují levně a velmi rychle prototypovat. Většina počátečních návrhů je ve formě papírového modelu. Umožňují odhalovat konceptuální chyby v návrhu a problémy s terminologií. Jsou dobré pro zachycení průchodu aplikací. Jejich nevýhodou je především jejich nevhodnost pro multimediální aplikace a pro aplikace, které mají velký rozsah dynamického obsahu.38 Ilustrace 19: Papírový prototyp



3.2.2.2 Obrázkový prototyp Obrázkový prototyp je vizualizace aplikace za pomocí obrázků. Detailnost tohoto prototypu se může pohybovat od konceptuálního wireframu 39, až po profesionální návrh od grafika. Obrázkové prototypy lze zobrazit na cílovém zařízení a tím získat představu o tom, jak bude uživatelské rozhraní v reálu vypadat. Tímto lze například odladit velikost textu. Nevýhodou obrázkových prototypů je hlavně malá interaktivita a složitější zpracování změn oproti papírovému prototypu. 40

Ilustrace 20: Wireframe iPad aplikace


39 Wireframe – Vizualizace rozmístění ovládacích prvků na obrazovce. 40 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str. 142, 148-150 ▪ 45 ▪

3.2.2.3 Interaktivní prototypy Interaktivní prototypy velmi dobře zachycují zobrazovací formát cílového zařízení a umožňují simulovat interakci s uživatelem. Jejich nevýhodou je množství času, které vyžaduje jejich příprava.41 K jejich tvorbě lze použít Powerpoint nebo Keynote. Časově náročnější je tvorba prototypů ve specializovaných programech, jako je například ProtoShare. Tyto prototypy se již velmi podobají výsledné aplikaci. 42 3.2.2.4 Spustitelné prototypy za použití storyboardů Pro prototypování lze také využít technologii storyboardů. Soryboardy zachycují celkové rozložení uživatelského rozhraní a definují přechody mezi jednotlivými obrazovkami.43 Tyto prototypy již vyžadují programátorské schopnosti a jsou časově náročné na přípravu. Jejich výhodou je především velmi velká interaktivita a podobnost s finální aplikaci. Část napsaného kódu lze potom využít při vývoji samotné aplikace. 44 Ilustrace 21: Ukázka storyboardu

Zdroj: Vlastní zpracování 41 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str. 142 42 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str. 151 43 APPLE, iOS Human Interface Guidelines - Prototype and Iterate, [online] [cit. 2013-04-22] 44 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str. 142 ▪ 46 ▪

3.2.2.5 Video prototypy Video prototypy jsou mocným nástrojem pro ukázání aplikace v kontextu reálného světa. Toto je obzvláště důležité pro aplikace, které pro svoje správné fungování kontext potřebují; aplikace pracující s lokací uživatele, aplikace poskytující dálkové ovládání k jiným produktům nebo aplikace, které intenzivně využívají senzory zařízení, jsou ideální kandidáti na video prototyp. Tento druh prototypu je velmi náročný na tvorbu a jeho úpravu, proto je potřeba zvážit, zda se jeho vytvoření vyplatí. 45 Dobře natočený a sestříhaný video prototyp se dá případně použít jako marketingový materiál nebo jako součást prezentace při hledání investorů.

45 GINSBURG, Suzanne: Designing the iPhone User Experience,, 1. vydání, Addison-Wesley 2010, str. 155 ▪ 47 ▪

3.3 Uživatelské rozhraní selftestů pro iOS Následující podkapitola představuje návrh uživatelského rozhraní aplikace Selftesty pro iOS. Návrh GUI byl proveden jak pro iPhone verzi, tak pro iPad verzi. Navržené rozhraní dodržuje zásady popsané v Human Interface Guidelines a jsou použity standardní ovládací prvky, jelikož selftesty pro iOS spadají do kategorie productivity aplikací. 3.3.1

Uživatelské rozhraní iPhone verze

Hlavním záměrem při návrhu rozhraní selftestů pro iPhone bylo vytvořit čisté, přehledné a jednoduché rozhraní, které uživateli dovoluje rychle spustit test a poté ho pohodlně vyplnit. Dotekové plochy ovládacích prvků jsou dostatečně velké i pro ovládání aplikace v dopravních prostředcích nebo při chůzi. Z technického hlediska je uživatelské rozhraní pro iPhone založeno na komponentě UINavigationController, která je součástí základního frameworku CocoaTouch. Do navigation stacku se postupně přidávají kontrolery; od kontroleru pro výběr předmětů až po kontroler s výsledkem testu. Ilustrace 22: Princip Navigation Controlleru


▪ 48 ▪

3.3.1.1 Průchod uživatelským rozhraním Následující obrázek shrnuje přechody mezi obrazovkami uživatelského rozhraní iPhone verze. Přechodem hlavního toku je označen takový přechod, který vede k využití funkcionalit aplikace.

Ilustrace 23: Průchod uživatelským rozhraní iPhone verze


▪ 49 ▪

3.3.1.2 Návrh uživatelského rozhraní Pro návrh uživatelského rozhraní iPhone verze byly použity papírové modely.

Ilustrace 24: Návrh iPhone GUI - Výběr předmětů


▪ 50 ▪

Ilustrace 25: Návrh iPhone GUI - Výběr témat

Ilustrace 26: Návrh iPhone GUI - Výběr témat - nastavení

Zdroj: Vlastní zpracování Zdroj: Vlastní zpracování

▪ 51 ▪

Ilustrace 27: Návrh iPhone GUI - Test

Ilustrace 28: Návrh iPhone GUI - Výsledek



▪ 52 ▪

3.3.2

Uživatelské rozhraní iPad verze

Hlavní ideou uživatelského rozhraní pro iPad je zredukovat počet obrazovek, a tím zrychlit pohyb v GUI. Výběr předmětu a témat je proto sloučen do jediné obrazovky. Další klíčovou myšlenkou bylo využít velké zobrazovací plochy iPadu pro zobrazení dodatečných informací. Pro jednotlivé předměty se tak zobrazuje graf minulých výsledků, který studentovi ukazuje jeho zlepšení v čase a v testu je k dispozici přehled otázek. Z technického hlediska je interface založen na komponentě MGSplitViewController, která dovoluje mít obrazovku tabletu rozdělenou na dvě části. Tato komponenta využívá takzvaného Master-Detail principu, kdy na levé „Master“ straně je vidět seznam položek (například seznam předmětů) a na pravé straně je vidět „Detail“ právě vybrané položky (například seznam témat vybraného předmětu).

Ilustrace 29: Rozložení GUI na iPadu


▪ 53 ▪

3.3.2.1 Průchod uživatelským rozhraním Následující ilustrace zachycuje přechody v uživatelském rozhraní iPad verze aplikace.

Ilustrace 30: Průchod uživatelským rozhraní iPadu


▪ 54 ▪

3.3.2.2 Návrh rozhraní iPad verze Pro návrh rozhraní iPad verze byly použity wireframy. Ilustrace 31: Návrh iPad GUI - Výběr předmětu, graf výsledků a výběr témat


▪ 55 ▪

3.3.2.3 Obrazovka testu Obrazovka testu na šířku při zavřeném seznamu otázek Ilustrace 32: Návrh iPad GUI - Obrazovka testu


▪ 56 ▪

Obrazovka testu na šířku s otevřeným panelem otázek Ilustrace 33: Návrh iPad GUI - Obrazovka testu s panelem otázek


▪ 57 ▪

3.4 Architektura a návrhové vzory v iOS aplikacích Z pohledu architektury komplexních informačních systémů často slouží mobilní aplikace jako prezentační vrstva. Většina business logiky se nachází na serveru a pomocí integrační vrstvy (za použití například XML nebo JSON protokolu) je ovládána prezentační vrstvou umístěnou na mobilním zařízení. Stejnou roli v architektuře má i aplikace selftestů pro iOS. Ilustrace 34: Obvyklá architektura IS, který využívá mobilní aplikaci


Architektura samotné aplikace pro iPhony a iPady vychází z frameworků, které jsou na platformě iOS k dispozici. Základ tvoří vrstva Core OS, která poskytuje nízkoúrovňové funkcionality ostatním vrstvám. Zajišťuje práci s vlákny, networking, přístup k souborovému systému, alokaci paměti, matematické výpočty a další základní služby. Core OS není obvykle v aplikaci využíván přímo; jeho funkcionality využívají ostatní vrstvy a frameworky.46

46 APPLE, iOS Technology Overview – Core OS Layer, [online] [cit. 2013-04-23] ▪ 58 ▪

Ilustrace 35: Frameworky pro vývoj iOS aplikací

Zdroj: APPLE, iOS Technology Overview – Core OS Layer

Nad touto základní vrstvou je postavena vrstva Core Services. Ta poskytuje fundamentální služby a každá aplikace ji nějakým způsobem využívá. Foundation framework definovaný v této vrstvě poskytuje definici základních tříd používaných při vývoji pro iOS a MacOS. Obsahuje například definici pole, řetězce znaků nebo časových zón.47 Dalším důležitým frameworkem je Core Data, který zajišťuje persistenci dat.48 V této vrstvě jsou dále dostupné služby jako iCloud, Automatic Reference Counting49, Grand Central Dispatch, In-App Purchase a další frameworky, které přímo nesouvisí s prezentační vrstvou.50 Vrstva Media zajišťuje vykreslování na obrazovku zařízení, ovládání kamery a práci s audiem. Core Graphics framework zajišťuje 2D vykreslování pomocí vektorů a bitmap. Core Animation umožňuje komplexní animace uživatelského rozhraní. OpenGL ES framework potom poskytuje metody pro 2D a 3D rendering za použití hardwarové akcelerace.51 Cocoa Touch vrstva poskytuje klíčové knihovny na tvorbu iOS aplikací. Zajišťuje knihovny pro zpracování doteků, multitasking, push notifikace a především UIKit framework, který zajišťuje životní cyklus aplikace a obsahuje standardní prvky uživatelského rozhraní. V rámci tohoto frameworku jsou také definovány třídy a roz-

47 APPLE, Foundation Framework Reference, [online] [cit. 2013-04-23] 48 APPLE, Core Data Framework Reference, [online] [cit. 2013-04-23] 49 Zkratkou ARC – Technologie automatického počítání referencí, která dokáže do značné míry automatizovat správu paměti díky statické analýze kódu při jeho kompilaci. 50 APPLE, iOS Technology Overview – Core Services Layer, [online] [cit. 2013-04-23] 51 APPLE, iOS Technology Overview – Media Layer, [online] [cit. 2013-04-23] ▪ 59 ▪

hraní, které tvoří základ Model-View-Controller architektury. 52 Tuto architekturu využívá většina productivity a utility aplikací a selftesty pro iOS nejsou v tomto výjimkou. 3.4.1

Model-View-Controller

Návrhový vzor Model-View-Controller (známý také jako MVC) je základním návrhovým vzorem pro většinu iOS aplikací. Tento vzor říká, jak má být rozdělena zodpovědnost mezi jednotlivými objekty v rámci aplikace a určuje jim jejich role a způsob, jakým mezi sebou komunikují. Ilustrace 36: Role a komunikace komponent v MVC modelu


Objekty modelu představují data se kterými aplikace pracuje a definují business logiku, která říká, jak lze s těmito daty zacházet nebo jak je zpracovat. Model obsahuje třídy řešící problematiku dané domény. Objekty modelu by neměly mít ponětí o tom, jakým způsobem budou prezentovány uživateli. View objekty jsou přímo viditelné části aplikace. Uživateli se tyto objekty objevují na obrazovce a on s nimi interaguje doteky. Jejich hlavním účelem je zobrazit data modelu uživateli a umožnit interakci s těmito daty. Controllery jsou prostředníky mezi view objekty a objekty modelu. Sledují změny v modelu a podle nich aktualizují view objekty. View objekty zase sdělují controlleru všechny akce uživatele a ten podle nich aktualizuje model. Controller je také zodpovědný za správu životního cyklu view a model objektů. V kontextu celé

52 APPLE, iOS Technology Overview – Cocoa Touch Layer, [online] [cit. 2013-04-23] ▪ 60 ▪

aplikace pak controller koordinuje přechody mezi jednotlivými částmi uživatelského rozhraní.53

3.4.2

Delegace

Delegace je dalším často používaným návrhovým vzorem ve světě iOS. Pomocí mechanizmu delegování může vybraný objekt – delegát – jednat jménem jiného objektu, který delegaci svých pravomocí umožňuje. Tímto lze vkládat chování specifické pro danou aplikaci do tříd frameworku bez potřeby jejich podědění. 54 Ilustrace 37: Příklad delegace - Tabulka se ptá svého delegáta, zda má zvýraznit řádek


53 APPLE, Streamline Your App with Design Patterns, [online] [cit. 2013-04-23] 54 APPLE, Streamline Your App with Design Patterns, [online] [cit. 2013-04-23] ▪ 61 ▪

3.4.3

Notification Center Ilustrace 38: Princip fungování notification centra


Notifikační centrum je subsystém Foundation frameworku umožnující rozesílání zpráv skrze centralizované místo zvané NSNotificationCenter. Odběratelé se mohou přihlásit k odběrům zpráv různého typu a notifikační centrum jim odebírané zprávy zašle ihned, jakmile je obdrží od jiných objektů.55 Tímto způsobem lze jednu zprávu zaslat více příjemcům a odesílatel o nich nemusí nic vědět.56 Tento fakt přispívá k malé míře provázání jednotlivých komponent (low–coupling), a tím zlepšuje architekturu celé aplikace.

55 APPLE, Streamline Your App with Design Patterns, [online] [cit. 2013-04-23] 56 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str. 325 ▪ 62 ▪

3.5 Architektura aplikace Selftestů Následující kapitola shrnuje architekturu aplikace Selftesty pro iOS. 3.5.1

High level pohled na architekturu aplikace

Aplikace Selftesty pro iOS slouží v podstatě jako prezentační vrstva pro server selftestů, se kterým komunikuje pomocí JSON API a sama o sobě obsahuje velmi málo business logiky. Ilustrace 39: Architektura aplikace Sleftesty pro iOS


▪ 63 ▪

3.5.2

Prezentační vrstva

Selftesty pro iOS jsou víceméně standardní Cocoa Touch aplikací. Jejich architektura je z velké části založena na architektonickém vzoru Model-View-Controller, který je běžný pro mobilní aplikace. Jelikož je aplikace relativně jednoduchá, tak veškerá business logika (jako například vyhodnocení testu), je umístěna v třídě příslušného modelu. Ilustrace 40: Architektura prezentační vrstvy


Uživatelské rozhraní je definováno pomocí .xib souborů, které jsou potom kontrolerem za běhu aplikace dodatečně doplněny o prvky uživatelského rozhraní, které nelze namodelovat v interface builderu. Sdílení funkcionality uživatelského rozhraní mezi iPhone a iPad částmi je dosaženo tím, že sdílená funkcionalita je umístěna do společného kontroleru, ze kterého jsou poděděny specifické implementace pro iPhone a iPad. Ty potom přetěžují metody, ve kterých se chování jednotlivých zařízení odlišují.

▪ 64 ▪

3.5.3

Prezentační vrstva iPhone verze

Prezentační vrstva u iPhone verze je založena na UINavigationControlleru. Kontrolery, které jsou výše v navigační hierarchii, samy vytvářejí podřízené kontrolery, které jsou pod nimi, předají jim relevantní data a přidají je do navigation stacku. Důležitou komponentou je UCLStateManager, který při spuštění aplikace zodpovídá za inicializaci uživatelského rozhraní do stavu, v jakém se nacházelo při jejím vypnutí. Informace o současném stavu uživatelského rozhraní získává pomocí notifikací, které posílají do NSNotificationCenter jednotlivé kontrolery.

Ilustrace 41: Diagram fungování StateManageru


▪ 65 ▪

3.5.4

Prezentační vrstva iPad verze

Prezentační vrstva u iPad verze je založena na MGSplitViewControlleru, který dovoluje pokročilé rozdělení obrazovky tabletu na Master-Detail pohled a následnou manipulaci s nimi. Kontrolery zde již nevytvářejí podřízené kontrolery a nerozhodují o přechodech v uživatelském rozhraní. Místo toho posílají zprávy do NSNotificationCenter o akcích uživatele. Tyto zprávy odebírá objekt typu UCLSplitViewOrchestrator, který na ně reaguje a řídí přechody mezi jednotlivými obrazovkami. State manager v iPad verzi zodpovídá pouze za inicializaci rozhraní do počátečního stavu – nesnaží se obnovit rozhraní do stavu před vypnutím.

Ilustrace 42: Prezentační vrstva iPad verze


▪ 66 ▪

3.5.5

Integrační vrstva

Komunikaci s API serveru selftestů zajišťuje integrační vrstva. V jejím jádru je třída UCLDataFetchManager, která je zodpovědná za stažení předmětů témat a otázek, a jejich uložení do databáze. Stahování dat ze serveru probíhá asynchronně a neblokuje tak vlákno uživatelského rozhraní. Pro parsování JSONu, který server posílá. je použita knihovna SBJSon. Prezentační vrstva předává UCLDataFetchManageru při volání jeho služeb callback bloky, které se zavolají ve chvíli, kdy bylo dokončeno stahování, nebo když se vyskytne chyba. 3.5.6

Datová vrstva

Datová vrstva je postavena na frameworku CoreData. Datový model je popsán v .xcdatamodel souboru a jako úložiště se využívá SqlLite databáze. Do datového úložiště se ukládají následující kategorie dat: 1. Stáhnutá data ze serveru selftestů – Předměty, témata a otázky 2. Dosažené výsledky uživatele 3. Aktuální stav uživatelského rozhraní (pro potřebu UCLStateManageru)

▪ 67 ▪

3.5.7

Datový model

Následující obrázek je grafické znázornění datového modelu aplikace selftestů pro iOS: Ilustrace 43: Grafické znázornění datového modelu


Popis jednotlivých entit a jejich vlastností lze nalézt v technickém projektu aplikace selftesty pro iOS (příloha B této bakalářské práce).

▪ 68 ▪

3.5.8

Komunikace se serverem Selftestů

3.5.8.1 Specifikace API Programátorské rozhraní serveru selftestů se nachází na adrese: http://testguru.herokuapp.com/api Po přístupu na tuto adresu pomocí webového prohlížeče se zobrazí přehled dostupných API metod. Rozhraní podporuje dva formáty odpovědi: JSON a XML. Selftesty pro iOS využívají JSON rozhraní. Aplikace volí následující dvě metody: 1. api/list.json – Vrátí všechny předměty, pro které jsou k dispozici selftesty 2. api/course/.json – Vrátí témata daného předmětu a jejich otázky. Místo je třeba dosadit konkrétní ID předmětu, které bylo předtím získáno ze zavolání api/list.json. Obě dvě výše uvedené metody berou volitelný URL parametr client, který pro server identifikuje typ klienta. Pokud je tento parametr vyplněn, posílá server selftestů pouze předměty a témata, která jsou danému klientovi určena. Tento mechanizmus slouží především jako záruka kvality otázek. Do aplikace jsou posílány jenom ta témata, která prošla kontrolou správnosti a korekturou. Pro aplikací Selftesty pro iOS byl určen následující identifikátor typu klienta: uclselftester.

▪ 69 ▪

3.5.8.2 Metoda api/list.json Po přístupu na následující adresu je navrácen seznam předmětů ve formátu JSON: http://testguru.herokuapp.com/api /list.json?client=uclselftester Ukázka odpovědi serveru: [

{ }, { }, { }, { }, {

]

code: "NOS", name: "Počítačové sítě a operační systémy", id: 18 code: "CAR", name: "Architektura počítačů", id: 19 code: "SEC", name: "Bezpečnost a ochrana dat", id: 20 code: "EA1", name: "Business English A", id: 21

code: "OPM", name: "Provozní management", id: 16 },

Kolekce předmětu: Název vlastnosti

Typ

Popis

code

string

Třípísmenný kód předmětu

name

string

Oficiální název předmětu

id

integer

ID předmětu na serveru.

Tabulka 3: Vlastnosti kolekce předmětu

▪ 70 ▪

3.5.8.3 Metoda api/course/.json Po přístupu na následující adresu je navrácen seznam témat a jejich otázek ve formátu JSON (pro ukázku byl použit předmět NOS): http://testguru.herokuapp.com/api /course/18.json?client=uclselftester

Ukázka odpovědi serveru: [

]

{

id: 379, topic: "Principy operačních systémů", questions: [ text: "Jaký je rozdíl mezi síťovým modelem a síťovou architekturou?" answers: [ { text: "Síťová architektura specifikuje počet a úkoly jednotlivých vrstev, síťový model je rozšíření architektury o protokoly, tj, způsob, jak jednotlivé vrstvy mají plnit své úkoly", correct: false, choice: "a" }, { text: "Síťový model specifikuje logickou topologii sítě, síťová architektura specifikuje fyzickou topologii sítě", correct: false, choice: "b" }, { text: "Síťový model specifikuje počet a úkoly jednotlivých vrstev, síťová architektura je rozšíření modelu o protokoly, tj, způsob, jak jednotlivé vrstvy mají plnit své úkoly", correct: true, choice: "c" }, { text: "Síťový model specifikuje topologii sítě, síťová architektura specifikuje přímo zařízení, která na síti fungují", correct: false, choice: "d" } ], ... ]

}, ...

Kolekce tématu: Název vlastnosti

Typ

Popis

id

integer

ID tématu na serveru.

topic

string

Oficiální název tématu

questions

Pole kolekcí typu otázka Toto pole obsahuje 1 až N otázek pro dané téma

Tabulka 4: Vlastnosti kolekce tématu

▪ 71 ▪

Kolekce otázek: Název vlastnosti

Typ

Popis

text

string

Text otázky

answers

Pole kolekcí typu odpověď

Obsahuje 1 až N možných odpovědí na otázku pro dané téma

Tabulka 5: Vlastnosti kolekce otázek

Kolekce odpovědi: Název vlastnosti

Typ

Popis

text

string

Text odpovědi

correct

boolean

True, pokud je tato odpověď správná, jinak false

choice

string

Písmeno odpovědi

Tabulka 6: Vlastnosti kolekce odpovědi

▪ 72 ▪

3.5.8.4 Komunikační schéma Ilustrace 44: Komunikační schéma


Po prvním spuštění si aplikace vyžádá od serveru seznam předmětů, který si uloží do databáze. Seznam předmětů je zobrazen uživateli. Po zvolení předmětu uživatelem si aplikace zažádá o témata a otázky daného předmět, která si rovněž uloží do databáze. Uživatel si poté může vybrat témata ze zobrazeného seznamu a spustit test. Při opakovaném průchodu aplikací se nejdříve ověřuje, zda témata pro daný předmět již nejsou uložena v databázi. Pokud jsou v úložišti přítomna, znovu se ne-

▪ 73 ▪

stahují. Uživatel může kdykoli vyvolat aktualizaci uložených předmětů, témat a otázek ze serveru.

4.

VÝVOJ

Tato kapitola se věnuje samotnému vývoji aplikací pro iOS. V podkapitole „4.1 Vývojové prostředí Xcode“ si krátce představíme balíček nástrojů, který se k vývoji aplikací používá. Podkapitola „4.2 Jazyk Objective-C“ popisuje jazyk, který se k vývoji používá, shrnuje jeho historii a upozorní na jeho zajímavé vlastnosti. Poslední podkapitola „4.3 Použité knihovny při vývoji“ představuje zajímavé knihovny třetích stran, které obsahuje aplikace selftestů pro iOS.

4.1 Vývojové prostředí Xcode K vývoji nativních aplikací pro iOS se používají vývojářské nástroje Xcode od firmy Apple.57 Xcode je kompletní sada nástrojů, která podporují celý proces tvorby mobilních aplikací – od návrhu uživatelského rozhraní, přes samotné psaní zdrojového kódu, optimalizaci, testování, až po distribuci skrze App Store. 58 Ilustrace 45: Nástroj Xcode

Zdroj: https://developer.apple.com/xcode/

57 DANIEL, Steven: Xcode 4 iOS Development, 1. vydání, Packt Publishing, Birmingham, 2011, str. 8 58 APPLE, Start Developing iOS Apps Today – Tools, [online] [cit 2013-04-23] ▪ 74 ▪

4.2 Jazyk Objective-C Pro vývoj nativních aplikací pro platformy iOS a Mac OS X se používá jazyk Objective-C. Objective-C je striktní nadmnožinou jazyka C. Přidává objektově orientované paradigmata do jinak procedurálního jazyka. Výsledkem je objektově orientovaný jazyk, který je mimořádně výkonný, má vynikající překladač (neboli kompilátor), podporuje dynamické chování a má přímý přístup ke knihovnám napsaných pro jazyk C. 59 4.2.1

Historie

Za tvůrce Objective-C lze považovat Brada Coxe a Tima Love. Jejich záměrem při tvorbě tohoto jazyka bylo přidat do C schopnosti jazyka SmallTalk. Prvotně se tento jazyk jmenoval „Objektově orientované programování v C“, zkráceně OOPC. Název Objective-C získal společně s vydáním prvního formálního popisu jazyka v roce 1986. V roce 1988 byl Objective-C adoptován jako hlavní vývojářský jazyk firmou NeXT Computer. Byl obohacen o mnoho tříd a frameworků, které poskytly základ pro nové aplikace, vývojářské nástroje (za zmínku stojí hlavně Interface Builder) a operační systém NEXTSTEP. Objective-C a NEXTSTEP společně tvořily inovativní vývojářské prostředí, které v té době jako jedno z mála dokázalo plně podporovat aplikace s objektově orientovanou architekturou. Především z důvodu velkého rozšíření C++ však NeXT a Objecitve-C zůstaly spíše kuriozitou, než rozšířenou platformou. Zlom nastal v roce 1996, kdy Apple koupil firmu NeXT Computer a použil jejich vývojářské nástroje, operační systém a hlavně programovací jazyk Objective-C jako základní stavební kameny pro jejich nový operační systém Mac OS X. Dnes se Objective-C používá jak na osobních počítačích, tak především na mobilních zařízeních na platformě iOS.60

59 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str. 3 60 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str. 4 ▪ 75 ▪

4.2.2

Specifika jazyku

Následující text si neklade za cíl poskytnout komplexní přehled o vlastnostech a konstruktech Objective-C, ale spíše se snaží poukázat na zajímavosti a specifické vlastnosti tohoto jazyka. 4.2.2.1 Syntaxe volání metod Objective-C má velmi exotickou syntaxi pro volání metod nad objekty (technicky přesný termín je posílání zpráv místo volání metod). 61 Je využívána tzv. závorková syntaxe, díky které vypadá kód v tomto jazyce velmi odlišně od kódu psaném v jiných jazycích. Volání metody vypadá následovně: [ukazatelNaObjekt nazevMetody];

Volání metody s parametry vypadá potom takto: [ukazatelNaObjekt nazevMetodyPrvniParametr:parametr1 aDruhyParametr:parametr2];

Pro větší přehlednost lze volání metody rozdělit na několik řádků: NSString * string = [s stringByReplacingOccurrencesOfString:@"Foo" withString:@"Bar" options:NSLiteralSearch range:NSMakeRange(20,10)];

Volání metod lze samozřejmě vnořovat, čehož se na rozdíl od ostatních jazyků využívá relativně běžně: //Navrátí seřazené otázky dle jejich pořadí -(NSArray *)sortedQuestions{ return [[self questions]sortedArrayUsingDescriptors: [NSArray arrayWithObject: [NSSortDescriptor sortDescriptorWithKey:@"order"ascending:true]]]; }

Výhoda této syntaxe je především v tom, že jméno metody, pokud je dobře zvoleno, dokumentuje samo o sobě, co metoda dělá, jaké přijímá parametry a v jakém

61 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str. 30 ▪ 76 ▪

kontextu je používá. Nevýhodou jsou potom někdy až příliš dlouhé názvy metod. Jako odstrašující příklad uveďme konstruktor systémové třídy NSBitmapImageRep: - (id)initWithBitmapDataPlanes:(unsigned char **)planes pixelsWide:(NSInteger)width pixelsHigh:(NSInteger)height bitsPerSample:(NSInteger)bps samplesPerPixel:(NSInteger)spp hasAlpha:(BOOL)alpha isPlanar:(BOOL)isPlanar colorSpaceName:(NSString *)colorSpaceName bitmapFormat:(NSBitmapFormat)bitmapFormat bytesPerRow:(NSInteger)rowBytes bitsPerPixel:(NSInteger)pixelBits

4.2.2.2 Bloky Blok je podobný klasické C funkci. Navíc však umožňuje zachytit a pracovat s proměnnými, které byly přítomny v kontextu jeho definice a pracovat s nimi během své exekuce. Bloky se dají uložit do proměnné a dají se předávat jako parametry ostatním metodám. Díky tomu je lze použít jako callback mechanizmus při definování různých API.62 Bloky jsou vlastně implementací closure v jazyce Objective-C.

Ilustrace 46: Příklad definice bloku

Zdroj: http://developer.apple.com/

62 APPLE, Blocks Programming Topics - Introduction, [online] [cit. 2013-04-23] ▪ 77 ▪

Pro příklad se pojďme podívat na to, jak je v rámci aplikace Selftesty pro iOS definováno API UCLDataFetchManagera, který se stará o získávání dat ze serveru selftestů: @interface UCLDataFetchManager : NSObject //Pro přehlednost vypuštěno }

{

//***API*** /// Navrátí v rámci completionBlocku pole stažených předmětů, nebo error, pokud se nějaký vyskytl /// Tato operace je asynchronní -(void)fetchSubjectsFromServerDelegateWithCompletionCallback: (void (^)(NSArray * subjects, NSError * error))completionBlock; /*Navrátí pro předaný předmět stažená témata v rámci completionBlocku, nebo error, pokud se nějaký vyskytl. Completion block vrací předmět, pod kterým jsou témata navázána. Tato operace je asynchronní */ -(void)fetchTopicsFromServerForSubject:(UCLSubject *)subject withCompletionCallback: (void (^) (UCLSubject * subject, NSError * error))completionBlock; @end

Pro získání předmětů ze serveru potom UCLSubjectController zavolá API me-

todu DataFetchManagera a předá mu vlastní completionBlock, který bude zavolán, až se stahování dokončí: /// Stáhne seznam předmětů ze serveru -(void)loadSubjectsFromServer{ // Získání reference na delegáta aplikace, // který v sobě obsahuje sdílené služby UCLSelfTesterAppDelegate *d = [UCLSelfTesterAppDelegate sharedInstance]; // Zažádej o stažení předmětů a předej completionBlock [[d dataFetchManager]fetchSubjectsFromServerDelegateWithCompletionCallback: ^(NSArray *fetchedSubjects, NSError *error) { //Zkontroluj, zda nedošlo k chybě během stahování if(error == nil){ //Zobraz stažené předměty uživateli [self fetchedSubjectsData:fetchedSubjects]; }else{ //Zobraz uživateli informaci o chybě [self fetchingSubjectDataFailedWithError:error]; } }];

}

// // // //

Zavolání této API Metody neblokuje vykonávání dalšího kódu ani hlavní event loop aplikace. Předměty se stáhnou asynchronně a po jejich stáhnutí je zavolán completionBlock.

4.2.2.3 Kategorie Kategorie je pojmenovaný fragment definice třídy. Díky kategoriím lze rozšířit funkcionalitu jakékoli třídy o statické i instanční metody. 63 Lze tak přidat funkce i do třídy frameworku, od kterého nemáme zdrojové kódy.


Tuto techniku využívá například AppKit framework k tomu, aby přidal metodu na vykreslení (-draw) do objektů typu NSString, NSImage nebo třeba NSAttributedString.64 V aplikaci Selftesty pro iOS se kategorie používá například pro nahrávání obrázků, které jsou specifické pro dané zařízení: // Definice kategorie rozšiřující UIImage @interface UIImage (UCLAdditions) // Navrátí obrázek s daným jménem pro aktuální zařízení +(UIImage*)imageForDeviceNamed:(NSString*)name; @end //Implementace kategorie @implementation UIImage (UCLAdditions) +(UIImage*)imageForDeviceNamed:(NSString*)name{ if([[UIDevice currentDevice]userInterfaceIdiom] == UIUserInterfaceIdiomPhone ) { return [UIImage imageNamed:[NSString stringWithFormat:@"%@~iPhone",name]]; }else{ return [UIImage imageNamed:[NSString stringWithFormat:@"%@~iPad",name]]; } } @end


4.3 Knihovny použité při vývoji Při vývoji Selftestů pro iOS byly použity knihovny třetích stran. Tato podkapitola se věnuje těm nejzajímavějším z nich. 4.3.1

SBJson

Knihovna SBJson je striktní parser a generátor JSONu. 65 Pomocí této knihovny lze z řetězce obsahující JSON objekt překonvertovat na objekt NSDictionary, se kterým pak lze dále pracovat. Selftesty pro iOS využívají SBJson k parsování odpovědí ze serveru selftestů. Tato funkcionalita je implementována v rámci třídy UCLDataFetcher, která mimo jiné zajišťuje právě překlad staženého JSONu na NSDictionary: //Na začátku souboru s definicí třídy DataFetcheru je nahrána SBJson knihovna #import "SBJson.h" @implementation UCLDataFetcher ... /// Tato funkce je zavolána po úspěšném stažení všech požadovaných dat ze serveru -(void)connectionDidFinishLoading:(NSURLConnection *)connection{ // Konverze stažených dat na řetězec znaků NSString *jsonString = [[NSString alloc] initWithData:dataBuffer encoding:NSUTF8StringEncoding]; // Rozparzování JSONu za pomocí SBJson NSDictionary *results = [jsonString JSONValue]; // Předání výsledného slovníku ke zpracování [self invokeCompletionBlockWithSuccess:results]; } @end

// Informování DataFetchManagera o úspěšném stažení dat [manager dataFetchSucceed:self];

65 BRAUTEST, Stig: json-framework on GitHub, [online] [cit. 2013-04-24] ▪ 80 ▪

4.3.2

MBProgressHUD

Třída MBProgressHUD je náhražka nezdokumentovaného a neupravitelného indikátoru aktivity UIProgressHUD, který je poskytován v rámci frameworku UIKit. 66 Indikátor aktivity slouží především k tomu, aby uživatel neměl pocit, že se aplikace zasekla, když probíhá operace na pozadí a také aby případně znemožnil interakci s uživatelským rozhraním, pokud to povaha probíhající operace vyžaduje. Ilustrace 47: MBProgressHUD v akci

Zdroj: http://www.cocoacontrols.com

Aplikace selftestů pro iOS tento indikátor aktivity používá vždy, když stahuje data ze serveru. Základní použití je jednoduché: //Pro zobrazení indikátoru aktivity [MBProgressHUD showHUDAddedTo:self.view animated:YES]; //Pro skrytí indikátoru aktivity [MBProgressHUD hideHUDForView:self.view animated:YES];

66 BUKOVINSKY Matej: MBProgressHUD on GitHub, [online] [cit. 2013-04-24] ▪ 81 ▪

4.3.3

Core Plot

Core Plot je framework pro 2D data vizualizaci, který je silně integrován s frameworky od firmy Apple (především s

Core Animation, Core Data a Cocoa

Bindings).67 Umožňuje vývojáři vykreslit různé typy grafů z poskytnutých dat a tyto grafy posléze animovat. V Selftestech pro iOS se používá na vykreslení grafu výsledků v iPad verzi. Ilustrace 48: Propagační obrázek frameworku Core Plot

Zdroj: https://code.google.com/p/core-plot/

67 Tým frameworku Core Plot, Core Plot – Project summary, [online] [cit. 2013-04-24] ▪ 82 ▪

5.

TESTOVÁNÍ

Testování je důležitou činností při tvorbě jakéhokoli softwaru. Následující kapitola se věnuje testování v kontextu vývoje aplikací pro platformu iOS. Existuje spoustu různých typů testů. Tato práce se zaměřuje na akceptační testy, unit testy a beta testování. Různé druhy testů ověřují různé aspekty výsledné aplikace. Tento princip zachycuje následující obrázek:


První testy, které se při vývoji aplikace píšou, jsou takzvané akceptační testy. Udávají směr návrhu a vývoje aplikace. O těchto testech pojednává podkapitola „5.1 Akceptační testy“. Během psaní samotného zdrojového kódu se používají unit testy, které ověřují funkčnost jednotlivých komponent. Tento druh testování shrnuje podkapitola „5.2 Unit testy“ Posledním typem testů, který se provádí ke konci vývoje, je tzv. beta testování. Aplikaci dostanou do rukou k otestování externí testeři a stakeholdeři. Jeden ze způsobů, jak provádět beta testing popisuje kapitola „5.3 Beta testování za pomoci služby TestFlight“

▪ 83 ▪


Každá podkapitola začíná teoretickým úvodem do problematiky a poté pokračuje praktickým příkladem.

5.1 Akceptační testy 5.1.1

Úvod

Nápad automatizovaných akceptačních testů se zrodil jako součást eXtreme Programming – agilní metodiky vývoje software . Tyto testy se označují jako akceptační, pro tože popisují, co aplikace musí dělat, aby byla stakeholderem akceptovatelná. Akceptační testy se píší od začátku vývoje, ještě před tím, než je napsaný jediný řádek kódu a představují počítačem ověřitelné požadavky na aplikaci. 68 Akceptační testy jsou základem metodiky jménem Behaviour-Driven-Development (zkráceně „BDD“). V rámci BDD se akceptační testy píšou společně se stakeholdery již na začátku projektu v rámci analýzy. Jsou psány jazykem, kterým rozumí jak

68 WYNNE M., HELLESØY A.: Behaviour-Driven Development for Testers and Developers, Pragmatic Programmers, 2012, USA, str. 5 ▪ 84 ▪

stakeholdeři, tak i programátoři a tím přispívají ke vzájemnému pochopení toho, jak má aplikace fungovat.69 Jedním z cílů BDD je, aby byly nejdřív napsány testy (které ze začátku neprochází) a podle nich se až programovala samotná aplikace. Akceptační testy se pak tedy stávají jakousi indikací, zda je implementace dané funkcionality hotova; projde-li test, funkcionalita je naprogramována. 5.1.2

Frank – Nástroj pro akceptační testy na platformě iOS

Pro akceptační testy na iOS existuje nástroj jménem Frank 70. Tento nástroj umožňuje pouštět testy napsané v BDD testing frameworku cucumber71 na iPhone simulátoru. Při spuštění testu Frank sestaví speciální verzi testované aplikace, do které přidá Frank server, který poskytuje potřebnou podporu automatizace pro vykonávání testů. Takto upravená aplikace je poté spuštěna na simulátoru a vůči ní jsou spouštěny testy. Ilustrace 51: Architektura nástroje Frank

Zdroj: http://blog.thepete.net/

69 WYNNE M., HELLESØY A.: Behaviour-Driven Development for Testers and Developers, Pragmatic Programmers, 2012, USA, str. 6 70 Více o tomto nástroji lze nalézt na http://testingwithfrank.com 71 Cucumber – BDD testing framework napsaný v ruby. Více o tomto frameworku lze nalézt na http://cukes.info/ ▪ 85 ▪

5.1.3

Příklad akceptačního testu

Pro vytvoření akceptačního testu použijeme user story o seznamu předmětů: #1 – Zobrazení předmětů po spuštění aplikace Jako uživatel chci, aby se mi po spuštění aplikace zobrazil seznam předmětů, ze kterých jsou k dispozici testy, abych si mohl vybrat, z čeho se chci nechat otestovat. Akceptační kritéria: 6. Předměty jsou zobrazeny abecedně 7. Je zobrazen název předmětu a jeho zkratka 8. Každý předmět je reprezentován předem danou ikonou 9. U každého předmětu je vidět, zda je uložen v zařízení 10. Jsou zobrazeny pouze předměty, u kterých jsou k dispozici testy

Akceptační test vytvoříme tím, že převedeme akceptační kritéria na popis chování aplikace a doplníme je o potřebný kontext: Feature: Subject list display As an user I want to see list of Subjects when I launch the App So I can choose the subject from which I want to be tested Scenario: Display list of subjects after they have been downloaded Given I reset the device and start the app Then I should see a navigation bar titled "Vyberte předmět" Then I should see subjects ordered alphabetically Then each subject should have name, code and corresponding icon When I touch "Architektura" Then I wait for 2 seconds And I navigate back Then I should see "Uloženo v mezipaměti"

Rozeberme si teď jednotlivé části akceptačního testu. Část „Feature“ je čistě pro člověka. Popisuje funkcionalitu, kterou testujeme a počítač ji nijak neinterpretuje. Každá „Feature“ může mít více „Scenario“, neboli scénářů. Každý scénář představuje jeden test. Scénář se skládá z názvu (který není interpretován počítačem) a jednotlivých kroků – co řádek, to krok. Takto napsaný akceptační test je sice validní, ale při spuštění neprojde, a to ani ve chvíli, kdy aplikace odpovídá specifikaci. Je totiž potřeba definovat v ruby všechny kroky, které nejsou součástí testovacího frameworku. Je důležité si všimnout, že defi▪ 86 ▪

nice kroků není součástí akceptačního testu. Kroky jsou definovány v odděleném souboru, aby akceptační test zůstal čitelný i pro ty, kteří neprogramují. Krok „I should see subjects ordered alphabetically“ je jedním z kroků, které musely být pro tento test nadefinovány: Then(/^I should see subjects ordered alphabetically$/) do subjectNames = get_cell_labels_with_tag(1).reverse! if(subjectNames != subjectNames.sort) raise "Subjects are not sorted" end end # Helper method def get_cell_labels_with_tag(tag) allSubElements = frankly_map( "tableViewCell label", "accessibilityLabel") elementsWithTag = [] allSubElements.each do |accesibilityLabel| tags = frankly_map("view marked:'#{accesibilityLabel}'","tag") foundTag = tags.first elementsWithTag << accesibilityLabel if(tags.include? tag) end return elementsWithTag end

Ve chvíli, kdy je akceptační test napsaný, všechny jeho kroky jsou nadefinovány a aplikace splňuje specifikaci, test projde:


▪ 87 ▪

5.2 Unit testy 5.2.1

Úvod

Díky unit testům lze zajistit, že jednotlivé komponenty aplikace odpovídají technické specifikaci po celou dobu vývoje aplikace. Díky unit testování lze vytvářet robustní a bezpečné aplikace.72 5.2.2

Unit testy v kontextu iOS

Vývojářský nástroj Xcode poksytuje prostředí pro psaní unit testů založené na opensource frameworku SenTestingKit. Tento framework poskytuje potřebné třídy a nástroje příkazové řádky, které dovolují vytvářet testy a poté je spouštět proti simulátoru nebo reálnému zařízení. Xcode nabízí dva druhy unit testů: Logické testy a Aplikační testy. Logické testy ověřují funkčnost jednotlivých komponent aplikace a umožňují psát testovací případy zaměřené na otestování komponenty v izolaci od zbytku aplikace. Tyto testy běží pouze na simulátoru. Aplikační testy ověřují funkcionalitu komponenty v kontextu celé aplikace. Využívají se zejména pro testování prezentační vrstvy. 73

72 APPLE, Xcode Unit Testing Guide – About Unit Testing, [online] [cit. 2013-04-25] 73 APPLE, Xcode Unit Testing Guide – Unit-Testing Overview, [online] [cit. 2013-04-25] ▪ 88 ▪

5.2.3

Příklad unit testu

Jako příklad si ukážeme logický unit test, který ověřuje správnou funkcionalitu vytvá ření předmětů a jejich načítání z databáze. #import "UCLSubjectTests.h" #import "UCLSubject.h" @implementation UCLSubjectTests // Runs before every test case - (void)setUp { [super setUp]; //Set-up disposable In Memory managed object context NSArray *bundles = [NSArray arrayWithObject: [NSBundle bundleForClass:[self class]]]; NSManagedObjectModel *mom = [NSManagedObjectModel mergedModelFromBundles:bundles]; STAssertNotNil(mom, @"ManangedObjectModel ist nil"); NSPersistentStoreCoordinator *psc = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:mom]; STAssertTrue( [psc addPersistentStoreWithType:NSInMemoryStoreType configuration:nil URL:nil options:nil error:NULL] ? YES : NO, @"Should be able to add in-memory store"); }

context = [[NSManagedObjectContext alloc] init]; context.persistentStoreCoordinator = psc;

//This code is ran after every test case - (void)tearDown { [super tearDown]; } //This test case verifies correct subject creation - (void)testSubjectCreation{ UCLSubject * subject = [UCLSubject subjectWithEntityID:1 andName:@"TestSubject1" andCode:@"TS1" inManagedContext:context]; STAssertEqualObjects(@"TestSubject1", subject.name, @"Constructed subject should have correct name"); STAssertEqualObjects(@"TS1", subject.code, @"Constructed subject should have correct code"); STAssertEquals(1,subject.entityID.intValue,@"Constructed subject should have correct entity ID"); } // This test case verifies fetching of subjects from database - (void)testSubjectFetching { [UCLSubject subjectWithEntityID:1 andName:@"TestSubject1" andCode:@"TS1" inManagedContext:context]; [UCLSubject subjectWithEntityID:1 andName:@"TestSubject2" andCode:@"TS2" inManagedContext:context]; NSArray * subjects = [UCLSubject fetchAllSubjectsInContext:context]; STAssertTrue(subjects.count == 2, @"There should be two subjects in total"); } @end

▪ 89 ▪

Takto napsaný test lze potom spustit proti iOS simulátoru. V konzoli dostane vývojář informaci o výsledcích proběhnutých testů: UCLSelfTesterTests.octest(Tests)' started at 2013-04-25 16:16:46 +0000 Test Suite 'UCLSubjectTests' started at 2013-04-25 16:16:46 +0000 Test Case '-[UCLSubjectTests testSubjectCreation]' started. Test Case '-[UCLSubjectTests testSubjectCreation]' passed (0.054 seconds). Test Case '-[UCLSubjectTests testSubjectFetching]' started. Test Case '-[UCLSubjectTests testSubjectFetching]' passed (0.028 seconds). Test Suite 'UCLSubjectTests' finished at 2013-04-25 16:16:46 +0000. Executed 2 tests, with 0 failures (0 unexpected) in 0.082 (0.084) seconds

5.3 Beta testování za pomoci služby TestFlight 5.3.1

Úvod

Beta testování je formou externího uživatelského akceptačního testu, kdy skoro hotovou aplikaci dostanou do ruky lidé, kteří nejsou přímo členové vývojového týmu. Může se jednat o stakeholdery nebo vybrané koncové uživatele. Pomocí jejich zpětné vazby lze aplikaci zlepšit a doladit takovým způsobem, aby co nejlépe naplňovala po třeby cílových skupin. 5.3.2

TestFlight

Beta testování na platformě iOS je relativně komplikovanou záležitostí. Každé iOS zařízení, které se účastní testování, musí mít nainstalovaný provisioning profil, který musí obsahovat UDID (Unique Device IDentifier) každého zařízení, na kterém aplikace poběží. Při kompilování musí být beta build podepsán vývojářským certifikátem, který je asociován s výše zmíněným provisioning profilem. Takto připravený build již lze nasadit na zařízení.74 TestFlight je webová služba snažící se co nejvíce zjednodušit proces beta testování. Zdarma poskytuje distribuci beta buildů přes internet a dovoluje vývojá řům získat cennou zpětnou vazbu od uživatelů společně s dalšími užitečnými metrikami.75

74 ESCOZ, Demystifying iOS certificates and provisioning files, [online] [cit. 2013-04-25] 75 Více o TestFligh lze naléz na url: https://testflightapp.com ▪ 90 ▪

Ilustrace 53: Jak funguje TestFlight

Zdroj: http://testflightapp.com

S Test Flightem se beta testuje v následujících krocích: 1. Vývojář si na Test Flight vytvoří účet 2. Rozešle e-mailové pozvánky do beta testu potenciálním testerům, nebo s nimi sdílí recruitment link Ilustrace 54: Formulář k přihlášení do beta testu


▪ 91 ▪

3. Testeři se zaregistrují do TestFlightu ze svého zařízení a TestFlight odešle vývojářům UDID těchto zařízení za účelem vytvoření provisioning profilů 4. Vývojář hromadně vyexportuje ID zařízení do Apple Provisioning Portalu a přidá tato zařízení do provisioning profilu této aplikace. Ilustrace 55: Buildy Selftestů pro iOS nahrané v Test Flight


5. Vývojář zkompiluje beta build aplikace za použití svého certifikátu a výše zmíněného provisioning profilu a nahraje build do TestFlightu 6. Vývojář vybere testery, kterým má být testovací build doručen prostřednictvím e-mailu 7. Testeři si nainstalují testovací build z e-mailu a začnou testovat. Odpovědí na tento e-mail pošle tester zpětnou vazbu vývojáři

▪ 92 ▪

Ilustrace 56: E-mail s novým testovacím buildem


8. Vývojář získává v reálném čase zpětnou vazbu a další metriky od uživatelů

6.

DISTRIBUCE

Distribuce je finálním krokem v procesu tvorby iOS aplikací. Apple od každého vývojáře vyžaduje, aby byl členem „iOS Developer Programu“, pokud chce své aplikace jakkoli distribuovat. Typ požadovaného členství závisí na zvolené formě distribuce. 76

76 APPLE, Choosing an iOS Developer Progam, [online] [cit. 2013-04-25] ▪ 93 ▪

Ilustrace 57: Formy distribuce


Pro Ad-Hoc distribuci je potřeba členství „iOS Developer“, které stojí $99 ročně. Ad-Hoc distribuce je určena především k testování aplikací a věnuje se jí podkapitola „6.1 Ad-Hoc distribuce“. Celosvětovou distribuci a prodej aplikací zajišťuje AppStore, což je jediný oficiální obchod s aplikacemi pro iOS. Tento obchod je provozován firmou Apple a pro dis tribuci aplikace touto cestou je taktéž potřeba členství „iOS Developer“. Této formě distribuce se věnuje podkapitola „6.2 Celosvětová distribuce skrze AppStore“. K distribuci in-house aplikací v rámci jedné firmy je třeba členství „iOS Developer Enterprise“. Členství stojí $299 ročně. O této formě distribuce pojednává podkapitola „12.3 Distribuce za pomocí firemního portálu“.

6.1 Ad-Hoc distribuce Ad-Hoc distribuci jsme se již krátce věnovali v kapitole o beta testování za pomocí TestFlightu. V následujícím textu rozvineme výklad o provisioning profilech, ad-hoc buildech a instalaci aplikace na zařízení. Každý člen iOS Developer Programu má právo nasadit aplikaci až na 100 iOS zařízení. K tomu, aby zařízení mohli aplikaci spustit, musí nejprve vývojář vystavit tzv. provisioning profile. Ten obsahuje informace o identitě vývojářů (veřejný klíč

▪ 94 ▪

distribučního certifikátu vývojáře), kteří mají právo tento provisioning profile používat, unikátní identifikátory zařízení, pro které je profil vystaven a AppID aplikace, která je s tímto profilem svázána.77 Ilustrace 58: Části provisioning profilu


Při kompilaci Ad-Hoc buildu se spojí samotná aplikace s vybraným provisioning profilem a výsledná zkompilovaná aplikace je poté podepsána distribučním certifikátem vývojáře. Build aplikace je uložena do .ipa archivu. 78 Ilustrace 59: Kompilace Ad-Hoc buildu aplikace


Samotná instalace na zařízení probíhá ve dvou krocích. Nejdřív je potřeba na zařízení nahrát provisioning profil, který je platný pro dané zařízení a pro aplikaci, kterou chceme nainstalovat. Poté lze nainstalovat samotnou aplikaci. Ilustrace 60: Instalace Ad-Hoc buildu


Způsobů instalace je hned několik. Lze použít deployment skrze Xcode, nahrát .ipa archiv do iTunes a následně je synchronizovat s cílovým zařízením nebo umístit 77 APPLE, App Distribution Guide, [online] [cit 2013-04-25] 78 APPLE, App Distribution Guide, [online] [cit 2013-04-25] ▪ 95 ▪

balíček na webový server a otevřít odkaz v zařízení. K distribuci Ad-Hoc buildů samo zřejmě lze také použít výše zmiňovaný TestFlight.

6.2 Celosvětová distribuce skrze AppStore AppStore je internetový obchod s iOS aplikacemi, který je dostupný přímo z iPhonu nebo iPadu. K dnešnímu datu nabízí více než 800 000 aplikací pro iPhonu, iPad a iPod touch. Počet stáhnutých aplikací z AppStore překročil 40 miliard. 79 Ilustrace 61: Logo AppStore

Zdroj: Apple

Vývojáři, kteří se rozhodnou pro distribuci skrze AppStore si mohou určit, za jakou cenu se jejich aplikace bude prodávat a v jakých zemích bude aplikace dostupná. Apple si účtuje 30% z ceny aplikace jako provizi za její distribuci. 80

6.2.1

Schvalovací proces

Každá aplikace která má být distribuována skrze AppStore, musí projít schvalovacím procesem. Tento proces trvá obvykle 5 pracovních dnů a na konci je aplikace buď uvolněna k distribuci, nebo s odůvodněním zamítnuta. Schvalování aplikace je kontrolní mechanizmus, který zabezpečuje, že v AppStore jsou jenom kvalitní aplikace, které neobsahují extrémně násilný, nebo explicitní obsah. V rámci procesu schvalování pracovníci Applu zkoumají, zda aplikace není v rozporu s „App Store Review Guidelines“. Jedná se o závazný dokument, který popisuje, co vše musí aplikace splňovat, aby mohla být dostupná v AppStore. 81 79 APPLE, Apple Updates iOS to 6.1, [online],[cit. 2013-04-25] 80 APPLE, iOS Developer Program – 3. Distribute, [online] [cit. 2013-04-26] 81 APPLE, App Store Review Guidelines, [online] [cit. 2013-04-26] ▪ 96 ▪

Na ukázku se pojďme podívat na pár podmínek, které jsou v „App Store Review Guidelines“ uvedeny:82 1. Aplikace, které padají, budou zamítnuty 2. Aplikace, které používají neveřejné API iOS, budou zamítnuty 3. Aplikace, které jsou příliš podobné již existujícím aplikacím na AppStore, budou zamítnuty 4. Aplikace, které rychle vybíjejí baterku, nebo generují velké množství tepla, budou zamítnuty 5. Aplikace obsahující hru na způsob ruské rulety budou zamítnuty 6. Aplikace napodobující uživatelské rozhraní iPodu budou zamítnuty 7. Aplikace, které stahují zdrojový kód v jakékoli podobě, budou zamítnuty

6.3 Distribuce za pomocí firemního portálu Pro nasazení aplikací uvnitř firmy neplatí omezení nasazení na 100 zařízení. Postup přípravy in-house aplikace je téměř stejný jako příprava Ad-Hoc buildu. Místo normálního certifikátu se však používá „enterprise distribution certificate“ a „enterprise provisioning profile“. Firemní provisioning profil má životnost jeden rok, proto je potřeba po roce rozdistribuovat všem zaměstnancům obnovený provisioning profil. Pro distribuci aplikace mezi zaměstnance firmy se obvykle používá web server, na který je aplikace uložena. Pro zaměstnance je pak vyroben webový firemní portál, kde mohou najít všechny firemní aplikace.83

82 APPLE, App Store Review Guidelines, [online] [cit. 2013-04-26] 83 APPLE, Distributing Enterprise Apps for iOS Devices, [online] [cit 2013-04-26] ▪ 97 ▪

7.

APLIKACE SELFTESTY PRO IOS

Aplikace selftestů pro iOS byla vyvinuta v plném rozsahu specifikace a prošla na první pokus procesem schválení aplikace pro distribuci skrze AppStore. Aplikace je od 8. listopadu 2012 dostupná široké veřejnosti jak na iPhonu, tak na iPadu pod názvem „Selftesty Unicorn College“. Aplikace vznikla ve spolupráci s Filipem Procházkou, který vytvořil grafický návrh a podílel se také na návrhu uživatelského rozhraní.

Zdroj: Filip Procházka

▪ 98 ▪

Ilustrace 63: Selftesty Unicorn College - Profil aplikace v AppStore otevřený na iPadu


▪ 99 ▪

7.1 iPhone verze Následující stránky obsahují screenshoty GUI z finální verze aplikace.

Ilustrace 64: Promo obrázek úvodní obrazovky aplikace


▪ 100 ▪



Ilustrace 67: iPhone aplikace Nastavení

Ilustrace 68: iPhone aplikace - Vybraná témata



▪ 101 ▪

Ilustrace 69: iPhone aplikace - Test

Ilustrace 70: iPhone aplikace - Výsledek



Ilustrace 71: iPhone aplikace - Výsledek (na šířku)


▪ 102 ▪

7.2 iPad verze Následující stránky obsahují screenshoty GUI z finální verze aplikace.

Ilustrace 72: Promo obrázek iPad verze aplikace


▪ 103 ▪

Ilustrace 73: iPad aplikace - hlavní obrazovka


▪ 104 ▪

Ilustrace 74: iPad aplikace - Obrazovka testu


▪ 105 ▪

Ilustrace 75: iPad aplikace - Obrazovka výsledku


▪ 106 ▪

8.

PŘÍNOSY APLIKACE

Tato kapitola se v krátkosti zmiňuje o přínosech aplikace Selftesty pro iOS pro vysokou školu Unicorn College a nabízí pohled na statistiky stažení a hodnocení aplikace na AppStore.

8.1 Přínosy pro Unicorn College Aplikace Selftesty Unicorn College v kombinaci s iPadem nebo iPhonem umožňuje studentům UCL studovat kdekoliv a kdykoliv a vhodně podporuje proces výuky. Selftesty pro iOS vytvářejí přirozenou symbiózu s marketingovou kampaní UCL a iPad poskytovaný studentům prvního ročníku se díky nim stává opravdu cennou učební pomůckou. Tato aplikace je v tuto chvíli jediná selftestovací pomůcka na českém AppStoru a jediná aplikace oficiálně publikovaná českou vysokou školou. V souvislosti s aplikací bylo na internetu publikována řada článků. Škola vydala rozhovor s tvůrci aplikace s titulkem „Vyvinout mobilní aplikaci? Žádný problém... Naši studenti to umí!„ 84. O aplikaci se zmiňuje také ředitel UCL Marek Beránek v rámci článku „Z kvality v žádném případě slevovat nebudeme“ 85, který byl publikován na ihned.cz. Aplikace je zmíněna v článku „Absolventi Unicorn College jsou žádaným „zbožím“ na trhu práce“ 86, který vyšel na portále studenta.cz. Projekt selftestů pro iOS tedy posloužil i jako marketingový materiál pro propagaci školy.

84 Článek je dostupný na url: http://www.unicorncollege.cz/studium/rozhovory/kalenda-prochazka.html 85 Článek je dostupný na url: http://unicorn.ihned.cz/c1-57471150-z-kvality-v-zadnem-pripade-slevovatnebudeme 86 Článek je dostupný na url: http://www.studenta.cz/absolventi-unicorn-college-jsou-zadanym-zbozim-natrhu-prace/magazin/article/1005 ▪ 107 ▪

8.2 Statistiky stažení a hodnocení aplikace na AppStore Ke dni 25. 4. 2013 si aplikaci z AppStore stáhlo 647 lidí a aplikace má 6 hodnocení s průměrnou známkou 4,8 hvězdiček z 5. Ilustrace 76: Graf počtu stažení

Zdroj: iTunes Connect

▪ 108 ▪

9.

ZÁVĚR

Předmětem této bakalářské bylo provést analýzu, návrh a implementaci selftestovací aplikace pro platformu iOS včetně její případné distribuce. V rámci této práce vznikl technický projekt, který obsahuje studii použitelnosti stávajícího systému selftestů na iOS zařízení. Tato studie ukázala na potřebu vyvinout nativní iOS aplikaci. Technický projekt dále obsahuje analýzu požadavků na aplikaci selftestů a specifikuje její architekturu. Dle technického projektu byla vyvinuta nativní selftestovací aplikace pro iPhony a iPady, která je dostupná široké veřejnosti pomocí distribučního kanálu AppStore pod názvem „Selftesty Unicorn College“.

Aplikace vhodně podporuje proces vzdě-

lávání a je naplněním hesla školy: „studuj kdekoli“. Aplikace byla stažena více než šesti sty lidmi a její hodnocení na AppStore je pozitivní. Z marketingového hlediska je pro UCL přínosem to, že jako jediná česká vysoká škola má svoji oficiální aplikaci na AppStore, což zvyšuje prestiž této vysoké školy. Z teoretického hlediska je tato bakalářská práce přínosná především kvůli zmapování celého procesu tvorby aplikace pro platformu iOS – od analýzy, až po samotnou distribuci. V rámci bakalářské práce došlo k naplnění všech stanovených cílů a požadavků, které na ni byly kladeny a proto tuto práci považuji za úspěšnou.

▪ 109 ▪

10. CONCLUSION This bachelor thesis dealt with analysis, design, implementation and distribution of native selftest application for iOS platform. The technical project has been created as a part of this thesis. This document contains usability study which surfaced the need to create a native selftest application. The technical project analyzes key features and properties of the application and describes its GUI and architecture. Native selftestinng application was developed according to the aforementioned technical project. It is available on the AppStore under the name of „Selftesty Unicorn College“. The created application supports the education process of the uni versity and it holds true to the school motto: „study anywhere“. This application has been downloaded more than six hundred times and it has positive reviews on AppStore. There is also a benefit from the marketing point of view. UCL became the first and only Czech university having an official application on AppStore. The theoretical aspect of this bachelor thesis is beneficial mainly because it describes the whole iOS development process. I consider my bachelor thesis successful as it accomplished all assigned goals.

▪ 110 ▪

11. SEZNAM ZDROJŮ 11.1 Knižní zdroje BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009 493 s. ISBN 978-1-4302-2369-6 COHN, Mike: User Stories Applied for Agile Software Development, 13. vyd., Crawfodsville, Indiana: Pearson Education, 2009 268 s. ISBN 0-321-20568-5 DANIEL, Steven: Xcode 4 iOS Development, 1. vydání, Packt Publishing, Birmingham, 2011 409 s. ISBN 978-1-849691-30-7 GINSBURG, Suzanne: Designing the iPhone User Experience, 1. vydání, Addison-Wesley, 2010 294 s. ISBN 978-0-321-69943-5 KRUCHTEN, Philippe: The rational unified process: an introduction, 3. ilustrované vydání, Addison-Wesley Professional, 2004 310 s. ISBN 0-321-19770-4 WYNNE M., HELLESØY A.: Behaviour-Driven Development for Testers and Developers, Pragmatic Programmers, USA, 2012 336 s. ISBN 1934356808

▪ 111 ▪

11.2 Internetové zdroje APPLE. App Store Review Guidelines, [online] [cit. 2013-04-26] Dostupný pro členy iOS developer programu z URL: APPLE. App Distribution Guide, [online] Poslední aktulizace 2013-04-23 [cit 2013-0425] Dostupný z URL: APPLE. Apple Updates iOS to 6.1, [online],[cit. 2013-04-25] Dostupný z URL: APPLE. Blocks Programming Topics - Introduction, [online] [cit. 2013-04-23] Dostupný z

URL:

APPLE. Design Your App with Care [online] Poslední aktualizace 2013-04-12 [cit. 2013-04-18]

Dostupný

z

URL:

APPLE. Distributing Enterprise Apps for iOS Devices, [online] [cit 2013-04-26] Dostupný z URL: APPLE. Core Data Framework Reference, [online] Datum akualizace: 2011-02-17 [cit. 2013-04-23]

Dostupný

z

URL:

APPLE. Foundation Framework Reference, [online] Datum aktualizace 2012-07-17 [cit.

2013-04-23]

Dostupný

▪ 112 ▪

z

URL:

APPLE. Choosing an iOS Developer Progam, [online] [cit. 2013-04-25] Dostupný z URL: APPLE. iOS Developer Program – 3. Distribute, [online] [cit. 2013-04-26] Dostupný z URL: APPLE. iOS Human Interface Guidelines [online] Datum akualizace 2012-12-17 [cit. 2013-04-07]

Dostupný

z

URL:

APPLE. iOS Technology Overview, [online] Poslední aktualizace 2012-09-19 [cit. 201304-23] Dostupný z URL: APPLE. Start Developing iOS Apps Today, [online] Poslední aktualizace 2013-04-23 [cit 2013-04-23]

Dostupný

z

URL:

APPLE, Streamline Your App with Design Patterns, [online] Datum aktualizace 201304-23 [cit. 2013-04-23] Dostupný z URL: APPLE. Xcode Unit Testing Guide, [online] Poslední aktualizace 2012-01-09 [cit. 201304-25] Dostupný z URL: BRAUTEST, Stig. json-framework on GitHub, [online] [cit. 2013-04-24] Dostupný z URL: BOCEK, F.: Analýza a návrh systému pro SelfTesty [online]. Praha, 2011 [cit. 2013-0418]. Bakalářská práce (Bc.). Unicorn College. BUKOVINSKY Matej. MBProgressHUD on GitHub, [online] [cit. 2013-04-24] Dostupný z URL:

▪ 113 ▪

COHN, Mike. Advantages of the “As a user, I want” user story template [online] Vyd. 2008-04-25 [cit. 2013-04-17] Dostupný z URL: COHN, Mike. User Stories, Epics and Themes [online] Vyd. 2011-10-24 [cit. 2013-0417] Dostupný z URL: GERŠLOVÁ a kol. Zpráva Akreditační komise o hodnocení Unicorn College s.r.o. Praha [online] vyd. Listopad 2010, 6 s. (PDF) [cit. 2013-04-10] Dostupný z URL: LAHANAS Stephen. Aligning User Stories, Use Cases and Requirements [online] Vyd. 2013-01-15

[cit.

2013-04-17]

Dostupný

z

URL:

NIELSEN J. Paper Prototyping: Getting User Data Before You Code, [online] Vyd. 200304-14 [cit. 2013-04-21] Dostupný z URL: SCOZ Eduardo. Demystifying iOS certificates and provisioning files, [online] Publikováno

2011-02-17

[cit.

2013-04-25]

Dostupný

z

URL:

Tým frameworku Core Plot. Core Plot – Project summary, [online] [cit. 2013-04-24] Dostupný z URL:

▪ 114 ▪

12. SEZNAM ILUSTRACÍ Ilustrace 1: Proces vývoje mobilní aplikace.........................................................................12 Ilustrace 2: Proces vzdělávání..............................................................................................17 Ilustrace 3: IPhone - přihlášení skrze stránku školy............................................................19 Ilustrace 4: iPhone - přihlášení pomocí mobilního kódu....................................................20 Ilustrace 5: iPhone - zadávání kódu předmětu.....................................................................21 Ilustrace 6: iPhone - portál novinek.....................................................................................21 Ilustrace 7: iPhone - karta předmětu.....................................................................................22 Ilustrace 8: iPhone - selftest.................................................................................................23 Ilustrace 9: iPhone - selftest (na šířku).................................................................................23 Ilustrace 10: iPhone - vyplněný selftest...............................................................................24 Ilustrace 11: Návrh řešení.....................................................................................................26 Ilustrace 12: Proces návrhu iOS aplikací.............................................................................36 Ilustrace 13: Utility aplikace Weather..................................................................................38 Ilustrace 14: Productivity aplikace Dropbox........................................................................39 Ilustrace 15: Productivity aplikace Twitter..........................................................................39 Ilustrace 16: Immersive aplikace Converbot........................................................................40 Ilustrace 17: Immersive aplikace Compass..........................................................................40 Ilustrace 18: Porovnání prototypů........................................................................................43 Ilustrace 19: Papírový prototyp............................................................................................44 Ilustrace 20: Wireframe iPad aplikace.................................................................................45 Ilustrace 21: Ukázka storyboardu.........................................................................................46 Ilustrace 22: Princip Navigation Controlleru.......................................................................48 Ilustrace 23: Průchod uživatelským rozhraní iPhone verze.................................................49 Ilustrace 24: Návrh iPhone GUI - Výběr předmětů ...........................................................50 Ilustrace 25: Návrh iPhone GUI - Výběr témat....................................................................51 Ilustrace 26: Návrh iPhone GUI - Výběr témat - nastavení.................................................51 Ilustrace 27: Návrh iPhone GUI - Test.................................................................................52 Ilustrace 28: Návrh iPhone GUI - Výsledek........................................................................52 Ilustrace 29: Rozložení GUI na iPadu..................................................................................53 Ilustrace 30: Průchod uživatelským rozhraní iPadu.............................................................54 Ilustrace 31: Návrh iPad GUI - Výběr předmětu, graf výsledků a výběr témat...................55 Ilustrace 32: Návrh iPad GUI - Obrazovka testu.................................................................56 Ilustrace 33: Návrh iPad GUI - Obrazovka testu s panelem otázek.....................................57 Ilustrace 34: Obvyklá architektura IS, který využívá mobilní aplikaci................................58 Ilustrace 35: Frameworky pro vývoj iOS aplikací...............................................................59 Ilustrace 36: Role a komunikace komponent v MVC modelu.............................................60 Ilustrace 37: Příklad delegace - Tabulka se ptá svého delegáta, zda má zvýraznit řádek....61 Ilustrace 38: Princip fungování notification centra..............................................................62 Ilustrace 39: Architektura aplikace Sleftesty pro iOS..........................................................63 Ilustrace 40: Architektura prezentační vrstvy......................................................................64 Ilustrace 41: Diagram fungování StateManageru.................................................................65 Ilustrace 42: Prezentační vrstva iPad verze..........................................................................66 Ilustrace 43: Grafické znázornění datového modelu............................................................68 Ilustrace 44: Komunikační schéma......................................................................................73 Ilustrace 45: Nástroj Xcode..................................................................................................74 Ilustrace 46: Příklad definice bloku......................................................................................77 Ilustrace 47: MBProgressHUD v akci..................................................................................81 ▪ 115 ▪

Ilustrace 48: Propagační obrázek frameworku Core Plot.....................................................82 Ilustrace 49: Ověření různých aspektů aplikace...................................................................83 Ilustrace 50: Druhy testů v průběhu procesu vývoje mobilních aplikací.............................84 Ilustrace 51: Architektura nástroje Frank.............................................................................85 Ilustrace 52: Průběh akceptačního testu...............................................................................87 Ilustrace 53: Jak funguje TestFlight.....................................................................................91 Ilustrace 54: Formulář k přihlášení do beta testu.................................................................91 Ilustrace 55: Buildy Selftestů pro iOS nahrané v Test Flight...............................................92 Ilustrace 56: E-mail s novým testovacím buildem...............................................................92 Ilustrace 57: Formy distribuce..............................................................................................93 Ilustrace 58: Části provisioning profilu................................................................................94 Ilustrace 59: Kompilace Ad-Hoc buildu aplikace................................................................94 Ilustrace 60: Instalace Ad-Hoc buildu..................................................................................95 Ilustrace 61: Logo AppStore................................................................................................95 Ilustrace 62: Ikona aplikace..................................................................................................98 Ilustrace 63: Selftesty Unicorn College - Profil aplikace v AppStore otevřený na iPadu....99 Ilustrace 64: Promo obrázek úvodní obrazovky aplikace..................................................100 Ilustrace 65: iPhone aplikace - Výběr témat......................................................................101 Ilustrace 66: iPhone aplikace - Výběr předmětu................................................................101 Ilustrace 67: iPhone aplikace - Nastavení..........................................................................101 Ilustrace 68: iPhone aplikace - Vybraná témata.................................................................101 Ilustrace 69: iPhone aplikace - Test...................................................................................102 Ilustrace 70: iPhone aplikace - Výsledek...........................................................................102 Ilustrace 71: iPhone aplikace - Výsledek (na šířku)...........................................................102 Ilustrace 72: Promo obrázek iPad verze aplikace...............................................................103 Ilustrace 73: iPad aplikace - hlavní obrazovka...................................................................104 Ilustrace 74: iPad aplikace - Obrazovka testu....................................................................105 Ilustrace 75: iPad aplikace - Obrazovka výsledku.............................................................106 Ilustrace 76: Graf počtu stažení..........................................................................................108

▪ 116 ▪

13. SEZNAM TABULEK Tabulka 1: Přenesená data a doba načtení stránek selftestů.................................................25 Tabulka 2: Nefunkční požadavky na aplikaci......................................................................34 Tabulka 3: Vlastnosti kolekce předmětu..............................................................................70 Tabulka 4: Vlastnosti kolekce tématu..................................................................................71 Tabulka 5: Vlastnosti kolekce otázek...................................................................................72 Tabulka 6: Vlastnosti kolekce odpovědi..............................................................................72

▪ 117 ▪

14. SEZNAM PŘÍLOH A. Přiložené CD obsahující technický projekt, text práce, obrázky návrhu uživatelského rozhraní a propagační materiály aplikace. B. Technický projekt

▪ 118 ▪

15. PŘÍLOHA A: OBSAH PŘILOŽENÉHO CD Obsah CD je organizován do následujících složek: ●

Bakalářská práce – Obsahuje samotnou bakalářskou práci

●

Návrh GUI – Obsahuje modely uživatelského rozhraní

●

Propagační materiály – Obrázky, které byly vytvořeny za účelem propagace aplikace

●

Technický projekt – Obsahuje technický projekt, který byl vytvořen jako podklad pro samotnou realizaci aplikace

▪ 119 ▪

16. PŘÍLOHA B: TECHNICKÝ PROJEKT

▪ 120 ▪

UNICORN COLLEGE. Katedra informačních technologií

Recommend Documents