UNICORN COLLEGE. Katedra informačních technologií

Transkript

1 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

2 ZADÁNÍ

3 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

4 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.

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

6 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

7 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

8 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

9 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

10 OBSAH 1. Úvod Popis jednotlivých kapitol Konvence použité v této práci Analýza O Unicorn College Současný stav systému selftestů Selftesty v procesu výuky Analýza použitelnosti selftestů na ios zařízení Shrnutí problému a návrh řešení Analýza v kontextu vývoje mobilních aplikací App Definition Statement Definice aplikace Definice aplikace: Selftesty Unicorn College Definice funkčních požadavků pomocí User stories Vybrané User stories aplikace selftestů Nefunkční požadavky Metodika kategorizace nefunkčních požadavků Nefunkční požadavky aplikace selftestů Design Proces návrhu aplikací pro ios Návrh uživatelského rozhraní Zásady návrhu GUI pro ios Prototyping Uživatelské rozhraní selftestů pro ios Uživatelské rozhraní iphone verze Uživatelské rozhraní ipad verze Architektura a návrhové vzory v ios aplikacích Model-View-Controller Delegace Notification Center Architektura aplikace Selftestů High level pohled na architekturu aplikace Prezentační vrstva Prezentační vrstva iphone verze Prezentační vrstva ipad verze Integrační vrstva Datová vrstva Datový model Komunikace se serverem Selftestů Vývoj Vývojové prostředí Xcode Jazyk Objective-C Historie Specifika jazyku Knihovny použité při vývoji SBJson MBProgressHUD Core Plot

11 5. Testování Akceptační testy Úvod Frank Nástroj pro akceptační testy na platformě ios Příklad akceptačního testu Unit testy Úvod Unit testy v kontextu ios Příklad unit testu Beta testování za pomoci služby TestFlight Úvod TestFlight Distribuce Ad-Hoc distribuce Celosvětová distribuce skrze AppStore Schvalovací proces Distribuce za pomocí firemního portálu Aplikace Selftesty pro ios iphone verze ipad verze Přínosy aplikace Přínosy pro Unicorn College Statistiky stažení a hodnocení aplikace na AppStore Závěr CONCLUSION Seznam Zdrojů Knižní zdroje Internetové zdroje Seznam Ilustrací Seznam tabulek Seznam příloh Příloha A: Obsah přiloženého CD Příloha B: Technický Projekt

12 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

13 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

14 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

15 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

16 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 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: 16

17 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í 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 ]. Bakalářská práce (Bc.). Unicorn College. 2 BOCEK, F.: Analýza a návrh systému pro SelfTesty [online]. Praha, 2011 [cit ]. Bakalářská práce (Bc.). Unicorn College. 17

18 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

19 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 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 Zdroj: Vlastní zpracování 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

20 Ilustrace 4: iphone - přihlášení pomocí mobilního kódu Zdroj: Vlastní zpracování 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

21 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 Zdroj: Vlastní zpracování Zdroj: Vlastní zpracování 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

22 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 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 Zdroj: Vlastní zpracování 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

23 Vyplnění selftestu Uživateli se zobrazí po zmáčknutí odkazu test k vyplnění. Ilustrace 8: iphone - selftest Zdroj: Vlastní zpracování Ilustrace 9: iphone - selftest (na šířku) Zdroj: Vlastní zpracování 23

24 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 Vyhodnocení selftestu Po odeslání testu se zobrazí uživateli jeho výsledek. Ilustrace 10: iphone - vyplněný selftest Zdroj: Vlastní zpracování 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

25 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 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 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 KB 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

26 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í Zdroj: Vlastní zpracování 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

27 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 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 APPLE, ios Human Interface Guidelines App Design Strategies [online] [cit ] 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 ] 27

28 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

29 2. Aplikace je kvalitně zpracovaná a grafické provedení je v barvách školy, aby budila dobrý dojem a zvyšovala povědomí o škole 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 <typ uživatele> <chci/můžu/potřebuju/atd... >, 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 LAHANAS STEPHEN: Aligning User Stories, Use Cases and Requirements [online] [cit ] 9 COHN, Mike: User Stories, Epics and Themes [online] [cit ] 10 COHN, Mike: Advantages of the As a user, I want user story template [online] [cit ] 29

30 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

31 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: 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

32 #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 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 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

33 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 Koncept copyleft licencí je vysvětlen na url 33

34 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í

35 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

36 3.1 Proces návrhu aplikací pro ios Ilustrace 12: Proces návrhu ios aplikací Zdroj: Vlastní zpracování 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) APPLE, Design Your App with Care - Do Your Initial Design, [online] [cit ] APPLE, Design Your App with Care - Do Your Initial Design, [online] [cit ] APPLE, ios Human Interface Guidelines - Prototype and Iterate, [online] [cit ] APPLE, Design Your App with Care - Translate Your Initial Design into an Action Plan, [online] [cit ] 36

37 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 ] 37

38 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

39 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: Vlastní zpracování Zdroj: 22 GINSBURG, Suzanne: Designing the iphone User Experience,, 1. vydání, Addison-Wesley 2010, str.7 39

40 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: Zdroj: 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: GINSBURG, Suzanne: Designing the iphone User Experience,, 1. vydání, Addison-Wesley 2010, str APPLE, App Store Review Guidelines, [online] [cit ] 25 APPLE, ios Human Interface Guidelines Human Interface Principles, [online] [cit ] 40

41 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 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 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 gesta 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 ] 27 APPLE, ios Human Interface Guidelines Human Interface Principles, [online] [cit ] 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 ] 41

42 při dlouho trvajících operací na pozadí, aby uživatel nenabyl dojmů že se aplikace zasekla a nic nedělá 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 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í 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 APPLE, ios Human Interface Guidelines Human Interface Principles, [online] [cit ] APPLE, ios Human Interface Guidelines Human Interface Principles, [online] [cit ] APPLE, ios Human Interface Guidelines Human Interface Principles, [online] [cit ] GINSBURG, Suzanne: Designing the iphone User Experience,, 1. vydání, Addison-Wesley 2010, str NIELSEN J., Paper Prototyping: Getting User Data Before You Code, [online] [cit ], 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

43 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ů Zdroj: Vlastní zpracování 37 GINSBURG, Suzanne: Designing the iphone User Experience,, 1. vydání, Addison-Wesley 2010, str

44 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 Zdroj: Vlastní zpracování 38 GINSBURG, Suzanne: Designing the iphone User Experience,, 1. vydání, Addison-Wesley 2010, str

45 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 Zdroj: Vlastní zpracování 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,

46 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 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 GINSBURG, Suzanne: Designing the iphone User Experience,, 1. vydání, Addison-Wesley 2010, str APPLE, ios Human Interface Guidelines - Prototype and Iterate, [online] [cit ] 44 GINSBURG, Suzanne: Designing the iphone User Experience,, 1. vydání, Addison-Wesley 2010, str

47 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

48 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í 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 Zdroj: Vlastní zpracování 48

49 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 Zdroj: Vlastní zpracování 49

50 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ů Zdroj: Vlastní zpracování 50

51 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

52 Ilustrace 27: Návrh iphone GUI - Test Ilustrace 28: Návrh iphone GUI - Výsledek Zdroj: Vlastní zpracování Zdroj: Vlastní zpracování 52

53 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 Zdroj: Vlastní zpracování 53

54 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 Zdroj: Vlastní zpracování 54

55 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 Zdroj: Vlastní zpracování 55

56 Obrazovka testu Obrazovka testu na šířku při zavřeném seznamu otázek Ilustrace 32: Návrh ipad GUI - Obrazovka testu Zdroj: Vlastní zpracování 56

57 Obrazovka testu na šířku s otevřeným panelem otázek Ilustrace 33: Návrh ipad GUI - Obrazovka testu s panelem otázek Zdroj: Vlastní zpracování 57

58 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 Zdroj: Vlastní zpracování 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 APPLE, ios Technology Overview Core OS Layer, [online] [cit ] 58

59 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 ] 48 APPLE, Core Data Framework Reference, [online] [cit ] 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 ] 51 APPLE, ios Technology Overview Media Layer, [online] [cit ] 59

60 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 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 Zdroj: Vlastní zpracování 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 ] 60

61 aplikace pak controller koordinuje přechody mezi jednotlivými částmi uživatelského rozhraní 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 Zdroj: Vlastní zpracování 53 APPLE, Streamline Your App with Design Patterns, [online] [cit ] 54 APPLE, Streamline Your App with Design Patterns, [online] [cit ] 61

62 3.4.3 Notification Center Ilustrace 38: Princip fungování notification centra Zdroj: Vlastní zpracování 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 ] 56 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str

63 3.5 Architektura aplikace Selftestů Následující kapitola shrnuje architekturu aplikace Selftesty pro ios 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 Zdroj: Vlastní zpracování 63

64 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 Zdroj: Vlastní zpracování 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

65 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 Zdroj: Vlastní zpracování 65

66 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 Zdroj: Vlastní zpracování 66

67 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 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

68 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 Zdroj: Vlastní zpracování 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

69 3.5.8 Komunikace se serverem Selftestů Specifikace API Programátorské rozhraní serveru selftestů se nachází na adrese: 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/<id_předmětu>.json Vrátí témata daného předmětu a jejich otázky. Místo <ID_Předmětu> 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

70 Metoda api/list.json Po přístupu na následující adresu je navrácen seznam předmětů ve formátu JSON: /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

71 Metoda api/course/<id_předmětu>.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): /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

72 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

73 Komunikační schéma Ilustrace 44: Komunikační schéma Zdroj: Vlastní zpracování 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

74 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: 57 DANIEL, Steven: Xcode 4 ios Development, 1. vydání, Packt Publishing, Birmingham, 2011, str APPLE, Start Developing ios Apps Today Tools, [online] [cit ] 74

75 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 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 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 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str. 4 75

76 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 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

77 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 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: 62 APPLE, Blocks Programming Topics - Introduction, [online] [cit ] 77

78 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 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 * 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 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. 63 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str

79 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 (UCLAdditions) // Navrátí obrázek s daným jménem pro aktuální zařízení //Implementace 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]]; } 64 BUCANEK, James: Learn Objective-C for Java Developers, Apress, New York, 2009, str

80 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 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 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]; // Informování DataFetchManagera o úspěšném stažení dat [manager datafetchsucceed:self]; 65 BRAUTEST, Stig: json-framework on GitHub, [online] [cit ] 80

81 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: 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 ] 81

82 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: 67 Tým frameworku Core Plot, Core Plot Project summary, [online] [cit ] 82

83 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: Zdroj: Vlastní zpracování 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

84 Zdroj: Vlastní zpracování Každá podkapitola začíná teoretickým úvodem do problematiky a poté pokračuje praktickým příkladem. 5.1 Akceptační testy Ú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

85 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 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: 69 WYNNE M., HELLESØY A.: Behaviour-Driven Development for Testers and Developers, Pragmatic Programmers, 2012, USA, str Více o tomto nástroji lze nalézt na 71 Cucumber BDD testing framework napsaný v ruby. Více o tomto frameworku lze nalézt na 85

86 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

87 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: Zdroj: Vlastní zpracování 87

88 5.2 Unit testy Ú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 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 APPLE, Xcode Unit Testing Guide About Unit Testing, [online] [cit ] 73 APPLE, Xcode Unit Testing Guide Unit-Testing Overview, [online] [cit ] 88

89 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 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]; ist nil"); NSPersistentStoreCoordinator *psc = [[NSPersistentStoreCoordinator alloc] initwithmanagedobjectmodel:mom]; STAssertTrue( [psc addpersistentstorewithtype:nsinmemorystoretype configuration:nil URL:nil options:nil error:null]? YES : 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 should have correct name"); STAssertEqualObjects(@"TS1", 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 == should be two subjects in total"); 89

90 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 :16: Test Suite 'UCLSubjectTests' started at :16: 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 :16: Executed 2 tests, with 0 failures (0 unexpected) in (0.084) seconds 5.3 Beta testování za pomoci služby TestFlight Ú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 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 ESCOZ, Demystifying ios certificates and provisioning files, [online] [cit ] 75 Více o TestFligh lze naléz na url: 90

91 Ilustrace 53: Jak funguje TestFlight Zdroj: 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 ové 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 Zdroj: Vlastní zpracování 91

92 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 Zdroj: Vlastní zpracování 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 u 7. Testeři si nainstalují testovací build z u a začnou testovat. Odpovědí na tento pošle tester zpětnou vazbu vývojáři 92

93 Ilustrace 56: s novým testovacím buildem Zdroj: Vlastní zpracování 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 APPLE, Choosing an ios Developer Progam, [online] [cit ] 93

94 Ilustrace 57: Formy distribuce Zdroj: Vlastní zpracování 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

95 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 Zdroj: Vlastní zpracování 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 Zdroj: Vlastní zpracování 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 Zdroj: Vlastní zpracování 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 ] 78 APPLE, App Distribution Guide, [online] [cit ] 95

96 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ž 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 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 APPLE, Apple Updates ios to 6.1, [online],[cit ] 80 APPLE, ios Developer Program 3. Distribute, [online] [cit ] 81 APPLE, App Store Review Guidelines, [online] [cit ] 96

97 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 APPLE, App Store Review Guidelines, [online] [cit ] 83 APPLE, Distributing Enterprise Apps for ios Devices, [online] [cit ] 97

98 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

99 Ilustrace 63: Selftesty Unicorn College - Profil aplikace v AppStore otevřený na ipadu Zdroj: Vlastní zpracování 99

100 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 Zdroj: Filip Procházka 100

101 Zdroj: Vlastní zpracování Zdroj: Vlastní zpracování Ilustrace 67: iphone aplikace Nastavení Ilustrace 68: iphone aplikace - Vybraná témata Zdroj: Vlastní zpracování Zdroj: Vlastní zpracování 101

102 Ilustrace 69: iphone aplikace - Test Ilustrace 70: iphone aplikace - Výsledek Zdroj: Vlastní zpracování Zdroj: Vlastní zpracování Ilustrace 71: iphone aplikace - Výsledek (na šířku) Zdroj: Vlastní zpracování 102

103 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 Zdroj: Filip Procházka 103