Vývoj mobilních aplikací pro platformu Apple ios

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Vývoj mobilních aplikací pro platformu Apple iOS

BAKALÁŘSKÁ PRÁCE Vojtěch Bělovský

Brno, podzim 2013

Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádě cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: RNDr. Jaroslav Škrabálek

ii

Poděkování Rád bych poděkoval RNDr. Jaroslavu Škrabálkovi za vedení mé práce, cenné rady a vstřícný přístup při konzultacích. Dále bych rád poděkoval třineckému týmu společnosti Tapmates za ochotu podělit se o znalosti a zkušenosti. Především pak designérovi Denisovi Rojcykovi za ochotu spolupracovat na testovací aplikaci. Další poděkování patří Petru Kaletovi za jeho vstřícnost a podporu. V neposlední řadě bych chtěl poděkovat Tomáši Skopalovi za jeho rady a připomínky k práci. Poděkování patří také mým rodičům, kteří mě během studia ze všech sil podporovali.

iii

Shrnutí Práce obsahuje tři kapitoly. V první z nich je srovnána tvorba nativních mobilních aplikací s alternativními způsoby tvorby. Konkrétně je srovnána tvorba mobilních aplikací pomocí HTML5 s nativním způsobem tvorby. Nakonec je přidáno hodnocení hybridních aplikací. Druhá kapitola této práce obsahuje stručný popis syntaxe programovacího jazyka Objective-C. Dále jsou v druhé kapitole popsány vývojové nástroje pro tvorbu iOS aplikací a novinky v operačním systému iOS 7. V poslední kapitole je popisována testovací aplikace, která byla vyvíjena ve společnosti Tapmates. Veškeré poznatky ze všech kapitol jsou shrnuty v závěru práce.

iv

Klíčová slova Mobilní aplikace, HTML5, Objective-C, Android, iOS, BlackBerry, Windows Phone, Xcode, Mantle, AFNetworking

v

Obsah 1. Úvod .................................................................................................................................. 1 2. Úvod do vývoje mobilních aplikací .................................................................................. 2 2.1. Seznámení se s platformami ....................................................................................... 2 2.1.1 Android.................................................................................................................. 2 2.1.2 iOS......................................................................................................................... 3 2.1.3 Windows Phone..................................................................................................... 3 2.1.4 BlackBerry ............................................................................................................ 3 2.1.5 Shrnutí informací o platformách ........................................................................... 4 2.2 Nativní vs. HTML5 vývoj mobilních aplikací ............................................................. 4 2.2.1 Úvod a definice ..................................................................................................... 5 2.2.2 Uživatelská příjemnost a prožitek z používání aplikace ....................................... 6 2.2.3 Výkonnost ............................................................................................................. 7 2.2.4 Monetizace ............................................................................................................ 7 2.2.5 Náklady na multiplatformní vývoj ........................................................................ 8 2.2.6 Fragmentace .......................................................................................................... 8 2.2.7 Dostupnost kvalifikovaných vývojářů .................................................................. 9 2.2.8 Kontrola nad distribucí .......................................................................................... 9 2.2.9 Bezpečnost ............................................................................................................ 9 2.2.10 Shrnutí nativního vs. HTML5 vývoje aplikací.................................................. 10 2.3 Hybridní aplikace ....................................................................................................... 10 3. Objective-C ...................................................................................................................... 13 3.1 Úvod do syntaxe Objective-C .................................................................................... 13 3.1.1 Struktura hlavičkového souboru ......................................................................... 13 3.1.2 Struktura implementačního souboru ................................................................... 14 3.1.3 Deklarace atributů, propert a metod třídy ........................................................... 14 3.1.4 Deklarace metod podrobněji ............................................................................... 16 3.1.5 Implementace metod ........................................................................................... 18 3.1.6 Zasílání zpráv ...................................................................................................... 19 3.1.7 Property a atributy třídy ...................................................................................... 20 3.1.8 Možnosti vlastností propert ................................................................................. 20 3.1.9 Vytváření propert ................................................................................................ 22 3.1.10 Inicializace tříd .................................................................................................. 23 3.2 Nástroje pro vývoj iOS aplikací................................................................................. 24 vi

3.2.1 Xcode .................................................................................................................. 24 3.2.2 iOS Simulator ...................................................................................................... 25 3.2.3 Insturments .......................................................................................................... 25 3.2.4 Interface Builder .................................................................................................. 25 3.3 Novinky v iOS7 ......................................................................................................... 25 3.3.1 Hlavní rysy iOS 7 ................................................................................................ 26 3.3.2 Převod aplikace do stylu iOS 7 ........................................................................... 26 4. Vlastní aplikace – Issue manager .................................................................................... 28 4.1 Popis aplikace ............................................................................................................ 28 4.2 Rozbor aplikace ......................................................................................................... 29 4.2.1 Rámec Mantle – modely aplikace ....................................................................... 29 4.2.2 Knihovna AFNetworking - Síťová komunikace ..................................................... 31 5. Závěr ................................................................................................................................ 35 Literatura ............................................................................................................................. 37 Přílohy ................................................................................................................................. 40 Příloha A – změny v iOS 7 .............................................................................................. 40 Příloha B – grafický návrh aplikace Issue manager......................................................... 46 Příloha C – ukázky kódu ze souboru BCIssue.m ............................................................. 53 Příloha D – ukázky kódu ze seznamu pro výběr spoluracovníků ................................... 56 Příloha E – Elektronické přílohy .................................................................................... 67

vii

1. Úvod Je několik cílů této práce. Jednak poskytnout čtenářům obecné informace o nativních a alternativních způsobech vývoje mobilních aplikací tak, aby byl čtenář na základě těchto informací schopný rozhodnout jaký způsob vývoje použít. Dále se v práci zaměřím na vývoj mobilních aplikací pro platformu iOS. Popíši základy syntaxe programovacího jazyka Objective-C a seznámím čtenáře s novinkami ve vývoji pro novou verzi operačního systému iOS 7, který vyšel 18.září 2013 [1]. Text práce je pojat tak, aby bylo možné jej využít jako výukový materiál na FI MU. Nakonec čtenáře obeznámím s pokročilými vývojovými postupy pro platformu iOS jako je implementace vlastního uživatelského rozhraní, práci s knihovnami třetích stran jako například AFNetworking a Mantle. Tyto postupy jsou v práci podrobně popsány a věřím, že budou pro čtenáře přínosem.

1

2. Úvod do vývoje mobilních aplikací Cílem druhé kapitoly je poskytnout čtenáři informace o vývoji mobilních aplikací. Stručně popíšeme čtyři nejvýznamnější platformy na trhu a dále diskutujeme výhody a nevýhody různých přístupů k vývoji mobilních aplikací. Po přečtení této kapitoly by se měl čtenář dostatečně orientovat v této problematice a umět se na základě poskytnutých informací rozhodnout, v jakém případě je vhodné zvolit vývoj nativní, hybridní nebo HTML5 aplikace.

2.1. Seznámení se s platformami Mobilní aplikaci definujeme jako aplikaci běžící na přenosném zařízení jako je mobilní telefon nebo tablet. Na trhu se vyskytují mobilní zařízení běžící na různých mobilních platformách. Kvůli této diverzifikaci vzniká problém při vývoji aplikací. Zákazníci, kteří si chtějí nechat vyvinout mobilní aplikace, si často přejí, aby jejich aplikace fungovala na více platformách. V praxi to znamená, že pokud chceme, aby aplikace byla nativní a fungovala na čtyřech platformách, pak musíme aplikaci vyvinout v podstatě čtyřikrát, protože každá platforma má svá specifika pro vývoj aplikací. Nyní si stručně přiblížíme jednotlivé platformy a ukážeme rozdíly mezi nimi. Pro tento účel jsem vybral čtyři platformy s největší penetrací na trhu. Jsou to Android, iOS, Windows Phone a BlackBerry [2]. Pro přehlednost je přidána tabulka 2.1, jež znázorňuje zastoupení těchto čtyř mobilních platforem na trhu. Na závěr této kapitoly shrneme informace o vybraných platformách a řekneme si, proč vznikly multiplatformní způsoby vývoje aplikací. V následující kapitole se pak budeme zabývat přímo problémy multiplatformního a nativního vývoje.

2.1.1 Android Android je platforma s otevřeným zdrojovým kódem určena pro mobilní zařízení založená na jádru Linux vyvíjená konsorciem Open Hnadset Alliance. Jádro operačního systému Android je založeno pro běh na různém hardwaru, systém tak může být použit bez ohledu na chipset, velikost nebo rozlišení obrazovky daného zařízení [3]. V současnosti Android používá přes 81% uživatelů tzv. chytrých telefonů [2]. Na vývoj nativních aplikací pro Android je nejčastěji používán Eclipse1 s Android Developer Tools plugin, který doporučuje přímo Android [4].

1

Eclipse je vývojová platforma s otevřeným zdrojovým kódem

2

2.1.2 iOS Operační systém iOS je vyvíjen společností Apple Inc. Původně byl vytvořen pro zařízení iPhone a nyní se používá i v dalších mobilních zařízeních firmy Apple jako jsou iPod touch, iPad, iPad mini a Aplle TV druhé generace. Na rozdíl od Androidu a Windows Phonu, je iOS licencováno pouze pro zařízení od firmy Apple. Na vývoj nativních aplikací pro iOS se používá především Xcode1, který Apple poskytuje vývojářům zdarma. Aplikace pro iOS jsou distribuovány přes App Store, na kterém bylo k říjnu 2013 přes 1 000 000 aplikací, z toho bylo 475 000 nativních i pro iPady [5], ty byly celkem stáhnuty více než 50 miliard krát [6].

2.1.3 Windows Phone Windows Phone je operační systém pro chytré telefony vyvíjený společností Microsoft. Jeho předchůdcem byl Windows Mobile, který se dnes už dále nevyvíjí a se současnou platformou Windows Phone není ani kompatibilní. Díky partnerství se společností Nokia, která na Windows Phone přešla ze Symbianu, má dnes Windows Phone zhruba 4% podíl na trhu [2]. Na vývoj aplikací pro Windows Phone se používá Visual Studio od společnosti Microsoft s Windows Phone SDK2 Tools.

2.1.4 BlackBerry BlackBerry je operační systém pro mobilní zařízení vyvíjený společností BlackBerry Limited(dříve Research In Motion). Nejnovější verze je BlackBerry 10. Slouží jako operační systém pro zařízení Q5, Q10, Z10 a Z30. Na oficiálních stránkách BlackBerry Limited je pro vývoj nativních aplikací doporučováno vývojové prostředí Eclipse s BlackBerry SDK.

1 2

vývojové prostředí pro psaní iOS aplikací Software development kit

3

Tabulka 2.1: Přehled platforem [2][29]

2.1.5 Shrnutí informací o platformách Z tabulky 2.1 shrnující vybrané operační systémy lze vyčíst, že způsoby vývoje aplikací na jednotlivé platformy se kromě BlackBerry a Androidu hodně liší. Pokud by vývojář chtěl vyvíjet nativní aplikace pro všechny čtyři platformy zároveň, musel by ovládat práci ve třech různých vývojových prostředích se čtyřmi různými SDK, programovat ve třech různých jazycích a znát rozhraní pro programování aplikace (dále jen API) pro každou platformu. V praxi by to pro firmu zabývající se multiplatformním vývojem nejspíš znamenalo mít čtyři vývojářské týmy. To by se ale dle mého názoru žádné firmě moc nevyplatilo. Existují totiž alternativní způsoby, jak vyvíjet aplikace na více platforem zároveň. A to buď pomocí HTML51 nebo pomocí nástrojů pro tvorbu multiplatformních aplikací (někdy též nazývané jako hybridní aplikace). Následuje popis vlastností vývoje nativních a HTML5 aplikací, kde si vysvětlíme výhody a nevýhody každého přístupu. V další podkapitole přidáme informace o hybridních aplikacích a shrneme naše veškeré poznatky o současné situaci v tomto odvětví informatiky.

2.2 Nativní vs. HTML5 vývoj mobilních aplikací Struktura této kapitoly je inspirována dokumentem „Native vs. HTML5 mobile app development“, který lze nalézt na webu www.appcelerator.com [7]. Většina textů v této kapitole jsou parafrázemi těchto textů obohacené o mé znalosti a zkušenosti v této oblasti. V této kapitole se budeme věnovat srovnání nativního a multiplatformního vývoje 1

HyperText Markup Language 5

4

HTML5 aplikací. I když se na první pohled může zdát, že HTML5 je vzhledem k jeho vlastnosti „napiš jednou – funguje kdekoliv“1 lepší možnost jak vyvíjet mobilní aplikace, ukazuje se, že má jazyk HTML5 až příliš mnoho slabin na to, aby byl používán místo nativních jazyků. Výhodu multiplaformnosti HTML5 aplikací však vyvažují horší možnosti monetizace, slabší výkonnost a celkově nepropojenost aplikace s možnostmi cílových zařízení. Přesto všechno mají HTML5 aplikace své místo v určitém segmentu mobilních aplikací. Slabiny HTML5 aplikací jsou způsobeny tím, že standardy HTML5 se nedokážou vyvíjet dost rychle na to, aby udržely tempo s neustále se vyvíjejícími se operačními systémy všech platforem. Ty poskytují nativním aplikacím možnosti, které jim umožňují vítězit v mnoha dalších aspektech. Pro představu velikosti trhu uvádím počty aplikací čtyř vybraných platforem.  iOS - 1 000 000 [5]  Android - 1 000 000 [8]  BlackBerry - 250 000 [9]  Windows Phone - 130 000 [10] Více než dva milióny nativních aplikací je dostatečný důvod, proč se zajímat o toto téma. Abychom mohli rozhodnout, který přístup k vývoji mobilních aplikací je lepší, pojďme se nyní hlouběji ponořit do výhod a nevýhod jednotlivých přístupů.

2.2.1 Úvod a definice Nativní mobilní aplikace je program přizpůsobený danému zařízení a platformě, na které dané zařízení funguje. Jsou vyvíjeny tak, aby využívaly možnosti daného zařízení. Skrze API poskytované danou platformou mohou přistupovat k animacím a dalším možnostem zařízení. Tyto funkcionality, které jsou specifické pro každý typ zařízení, přidávají na uživatelské příjemnosti a prožitku uživatele z používání dané aplikace. Využívání možností operačního systému je považováno za největší rozdíl mezi nativními a HTML5 aplikacemi. HTML5 je pátá verze jazyka HTML a nabízí základní kameny pro budování webových stránek. Je to první verze HTML podporující multimédia bez nutnosti mít v zařízení nějaké zásuvné moduly pro jejich prezentaci. HTML5 standard byl vytvořen tak, aby byly webové aplikace přístupné a použitelné skrze jakýkoli prohlížeč na jakémkoli zařízení. HTML5 aplikace mají také možnost tzv. offline módu a používání aplikace 1

z anglického write once – run anywhere

5

pomocí dočasné paměti, což znamená, že je nyní možné pracovat s HTML5 aplikací i bez připojení k internetu. Vytvoření úspěšné mobilní aplikace, která splňuje „napiš jednou – funguje kdekoliv“ není podmíněna specifikací samotnou, ale implementací standardů do prohlížeče každého výrobce. Hlavní faktory ovlivňující úspěch aplikace: 1. Uživatelská příjemnost a prožitek z používání aplikace 2. Výkonnost 3. Monetizace 4. Náklady na multiplatformní vývoj 5. Fragmentace 6. Dostupnost kvalifikovaných vývojářů 7. Kontrola nad distribucí 8. Bezpečnost

2.2.2 Uživatelská příjemnost a prožitek z používání aplikace Uživatelská příjemnost a prožitek z používání aplikace je o tom, jak se uživatelé cítí, když používají naši aplikaci. Je o užitečnosti, snadném používání a možnostech aplikace. HTML5 standardy přináší webovým aplikacím více možností, které je přibližují nativním aplikacím jako přístup k pozici GPS nebo měřič rychlosti pro mobilní web aplikace. Ovšem ani tyto možnosti nepřinášejí uživateli ten samý prožitek jako nativní aplikace. Ty jsou totiž většinou výkonnější v porovnání s jejich webovými protějšky. Co je ale důležitější je fakt, že možnosti HTML5 reprezentují jen malý podíl nových nativních možností, které poskytují nové verze operačních systémů mobilních zařízení. Například Apple představil v iOS 7 okolo 1500 nových API [11]. Apple není jediná firma, které pokračuje ve vývoji operačního systému pro svá zařízení. Google také každoročně zveřejňuje a zpřístupňuje vývojářům tisíce nových API. Dle mého názoru HTML5 z hlediska možností využívání zdrojů operačních systémů daných platforem spíše čím dál tím více zaostává za možnostmi nativních aplikací. I když často převládá názor, že HTML5 v tomto ohledu nativní aplikace dohání. Můžeme se shodnout na tom, že HTML5 byl, co se týká webových aplikací velikým skokem kupředu. Byl to ale jen skok, protože s pokračujícím vývojem mobilních platforem již krok držet nestíhá.

6

2.2.3 Výkonnost Centrálním bodem uživatelské přívětivosti aplikace je její výkonnost. Výkonnost můžeme rozdělit do dvou kategorií: vykreslování a načítání obsahu. Pomalé vykreslování a načítání může znamenat konec úspěšnosti aplikace. Se vzrůstající výpočetní silou dnešních chytrých telefonů a tabletů, je tolerance pro zpožděné vykreslování a načítaní velmi nízká. Zákazníci si zvykli na rychlost, kterou nabízí především nativní aplikace, které nastavily standard pro to, co uživatel očekává od výkonnosti aplikace. Z pohledu výkonnosti uživatel bere v potaz okamžitou reakci aplikace na jeho požadavek. Je jednoduché v tomto ohledu srovnat nativní aplikaci, která je na zařízení umístěna lokálně a webovou aplikací, jež je načítána skrz prohlížeč, kde může být přístup dat pomalý nebo zcela scházet. Když je webová aplikace načtená, může být výkonnost aplikací srovnána pomocí akcí zařízení a gest1 specifických pro daný operační systém. Rozdíl mezi výkonem HTML5 aplikací a nativních je v tomto ohledu natolik velký, že i běžný uživatel snadno pozná rozdíl. Je například neakceptovatelné, aby v aplikaci jako je například kalendář trval přechod z jednoho dne na druhý (načtení a odanimování obsahu) několik sekund, což se u webových aplikací kvůli načítání obsahu z internetu a pomalých animací běžně stává.

2.2.4 Monetizace Distribuční služba App Store společnosti Apple Inc. představuje nejživější trh na světě se 400 miliony účty přímo spojenými s kreditními kartami uživatelů. Je největším trhem tzv. nákupů „na jedno kliknutí“2 a trhů vůbec. Uživatelé App Storu k dnešnímu datu stáhli přes 60 miliard aplikací. Mezi iOS developery třetích stran bylo k červnu 2013 vyplaceno přes 10 miliard dolarů [6]. Stejně jako iOS mají i Android, Windows Phone, BlackBerry a další mobilní platformy své distribuční služby, které můžou sloužit vývojářům k monetizaci jejich aplikací. Existují sice stránky jako App Center od sociální sítě Facebook nebo Mozilla Marketplace nabízející HTML5 aplikace. Je zatím ale předčasné tvrdit cokoliv o tom, nakolik můžou tyto služby pomoci s monetizací HTML5 aplikací. Kromě samotného prodeje aplikace se dá na aplikaci vydělávat tak, že nabídneme reklamní prostor firmám, které nám za něj pravidelně platí (PPC reklamy, bannery apod.). Tento přístup ovšem můžeme uplatnit jak u nativních, tak i HTML5 aplikací. Tento fakt podle mě hovoří spíše ve prospěch nativních aplikací. Ty můžou využít k šíření aplikace zázemí své platformy často čítající stovky miliónů uživatelů, a tím zvýšit výnosy 1 2

z anglického gesture „one-click“

7

z reklamy.

2.2.5 Náklady na multiplatformní vývoj Vývojáři hnáni touhou po vytvoření špičkové aplikace s výbornou uživatelskou přívětivostí často začínají s vývojem nativní aplikace na zařízení iPhone a iPad platformy iOS. Dalším krokem pro většinu z nich je vytvoření té samé aplikace pro platformu Android. Ale sestavení nového týmu pro vytvoření té samé aplikace pro všechny verze androidu je problematická. Ve většině případů to znamená zdvojnásobení až ztrojnásobení nákladů. Další náklady spojené s každým dalším vývojářským týmem se dají snadno vyčíslit. Vidíme, že multiplatformní vývoj nativních aplikací může být velmi nákladný a v porovnání s vývojem HTML5 aplikací je nativní vývoj mnohem dražší. Náklady na vývoj HTML5 aplikace jsou mnohem nižší především díky jejich multiplatformní povaze, kdy je jedna aplikace pomocí internetových prohlížečů daných platforem interpretována a funguje tak stejně na mnoha zařízeních. Jedinou podmínkou pro spuštění HTML5 aplikace totiž je, aby webový prohlížeč daného zařízení podporoval HTML5. To je dnes z velké části podporované většinou mobilních platforem [12]. K pochopení veškerých nákladů spojených s multiplatformním vývojem musíme prozkoumat ještě jeden důležitý faktor ovlivňující vývoj mobilních aplikací. Tím faktorem je fragmentace.

2.2.6 Fragmentace Se sedmi verzemi operačního systému Android, které k 1. listopadu 2013 užívalo více než 0.1% uživatelů a s minimálně 11 868 zařízeními implementujícími tento operační systém je jasné, že fragmentace této platformy je veliká [13][14]. Nejinak tomu je i u prohlížečů. Ty se s každou platformou liší. Nejde ale pouze o různorodost prohlížečů samotných, ale také o jejich verze, kterých je nyní celkem 52.[15] Víme, že každá z těchto verzí prohlížečů implementuje podporu HTML5 různým způsobem. To vede k potřebě testování a optimalizování HTML5 aplikací pro jednotlivé prohlížeče. Takže z výhody „napiš jednou – funguje kdekoliv“ máme „napiš jednou – optimalizuj všude“1. Když nakonec srovnáme nativní a HTML5 vývoj aplikací z hlediska fragmentace, dojdeme k závěru, že HTML5 je na tom stále o poznání lépe než vývoj nativní, jelikož pro vývoj nativní aplikace, která bude fungovat na více platformách, potřebujeme několik specializovaných týmů, které obstarají vývoj na každou platformu zvlášť. U vývoje HTML5 aplikace nám stačí tým

1

z anglického „write once – optimizme everyhwere“

8

jeden, který ovšem musí provést optimalizace pro prohlížeče každé platformy, na kterou je aplikace zacílena.

2.2.7 Dostupnost kvalifikovaných vývojářů Důležitým faktorem jakéhokoliv vývojářského projektu je mít dostatek vývojářů majících požadované schopnosti a zkušenosti. Obecně se věří, že je více vývojářů zabývajících jazykem JavaScript a HTML než jazykem Objective-C. Data z mnoha zdrojů tuto teorii podporují [16]. Důvodem, proč je pro nás toto srovnání důležitější než jiná (například JavaSript versus C nebo Java) je, že aplikace na platformu iOS jsou nejlépe monetizovatelné ze všech [17]. Proto dle mého názoru většina projektů primárně cílí na tuto platformu. Z tohoto srovnání je vidět, že pro vývoj HTML5 aplikací je snazší najít kvalifikované vývojáře než pro vývoj nativních aplikací.

2.2.8 Kontrola nad distribucí Jedním z největších výhod organizací zabývajícími se vývojem mobilních aplikací pomocí HTML5 je možnost zpřístupnit jejich aplikace uživatelům přímo skrz jejich prohlížeče. Ruku v ruce s touto možností jde i výhoda v tom, že neexistuje žádná vstupní kontrola aplikací. Schvalovací procesy, kterými musí procházet nativní aplikace umisťované do distribučních služeb, jako jsou App Store nebo Google Play, zde vůbec nejsou. Kontrolu má zcela v rukou společnost vyvíjející danou aplikaci. To může výrazně snížit čas vývoje a povyšování verzí aplikace.

2.2.9 Bezpečnost S novými možnostmi HTML5 přichází i více zodpovědnosti při programování. Jelikož aplikace psané v HTML5 můžou provádět více operací nad daty, které můžou ukládat i lokálně na každé zařízení (tzv. ukládání do dočasné paměti, aby aplikace mohly fungovat i bez internetu), vznikají nové bezpečnostní hrozby. Zdrojový kód webové aplikace je v prohlížeči volně přístupný a se správnými nástroji může útočník vložit škodlivý kód do aplikace, která ho vykoná spolu s ostatním kódem. Data mohou být modifikována a odeslána na server, kde mohou být opět poslána jinému uživateli a pak škodit. Dále může útočník použít techniky cross-site scripting, manipulovat s cookies nebo použít známou SQL injection, aby získal citlivá data jak ze serveru, tak i z mobilního zařízení. Útoky tohoto typu nejsou u nativních aplikací možné. 9

2.2.10 Shrnutí nativního vs. HTML5 vývoje aplikací Podle všech informací vítězí nativní způsob vývoje. Pokud máte dostatek prostředků, je vždy lepší zvolit vývoj nativní aplikace. Uživatelská přívětivost aplikace a vysoká výkonnost, to jsou atributy, které dnes uživatelé vyhledávají. Možná je to dáno tím, že se mobilní zařízení stávají čím dál větší součástí našeho každodenního života. Navzdory tomu existují případy, které doslova vyzývají k vývoji aplikace pomocí webové technologie HTML5. Kdy je použít? V případě, že naše aplikace přímo interaguje s obsahem dostupným pouze z internetu. Pokud aplikace potřebuje ke svému fungování internet a zároveň je možné pomocí HTML5 implementovat veškeré nezbytné funkcionality aplikace, je vhodné vzhledem ke sníženým nákladům na vývoj pro více platforem použít HTML5. To vše za předpokladu, že není třeba vykonávat náročné operace, které by mohly aplikaci zpomalit natolik, že by se stala nepoužitelnou.

Tabulka 1.2: Porovnání výhod a nevýhod nativního a HTML5 vývoje aplikací [7]

2.3 Hybridní aplikace Hybridní aplikace v kontextu mobilních aplikací je taková aplikace, která je napsaná stejnou technologií jakou jsou psané webové aplikace a je umístěna a vykonávána v nativním kontejneru přímo na zařízení. Je to sloučení webových technologií a vykonávání nativních aplikací. Hybridní aplikace používají web view komponentu dané platformy (UIWebView na 10

iOS, WebView na Androidu atd.) k prezentaci HTML a JavaScriptu ve formátu na celou obrazovku pomocí vykreslovacího jádra nativního prohlížeče. Síla hybridních aplikací ale tkví v implementaci abstraktní vrstvy, která umožňuje využívat funkcionality zařízení (jeho nativní API). To je něco, čeho pomocí webových aplikací nemůžeme dosáhnout kvůli bezpečnostním opatřením, která jsou mezi prohlížečem a API daného zařízení. Apache Cordova (dříve PhoneGap) je příklad JavaScriptové abstrakce vrstvy nad nativním API. Skrze tuto abstraktní vrstvu je v JavaSriptu zpřístupněno API zařízení. Při kompilaci je JavaSciptový kód namapován na nativní API specifické pro každé zařízení. Takto vzniklé aplikace se dají distribuovat skrz distribuční služby mobilních platforem. Tolik k výhodám hybridních aplikací. Mezi slabé stránky těchto aplikací patří například neúplnost nativních API. Jednoduše řečeno nástroje pro tvorbu hybridních aplikací nestíhají držet krok s inovacemi jednotlivých operačních systémů. Další slabou stránkou je vzhled a uživatelský prožitek aplikace. Ten sice může být vysoký, to ale znamená, že se musíme vzdát výhody „napiš jednou – funguje kdekoliv“. Pokud chceme dosáhnout špičkové úrovně nativních aplikací, musíme optimalizovat mnoho prvků pro každou platformu zvlášť (například UI, každá platforma má svůj „styl“ a nativní aplikace se ho snaží dodržet), a to opět zvyšuje náklady na vývoj, ale určitě ne tak výrazně jako při vývoji nativních aplikací. Neposledním faktorem je výkonnost aplikace, ta se může blížit nativním, ale neplatí to vždy. Pokud chceme vytvořit graficky náročnou hru, je lepší sáhnout po nativní implementaci. Obrázek 1 ukazuje výhody a nevýhody daných přístupů:

11

Obrázek 2.1: Výhody a nevýhody nativních, hybridních a HTML5 aplikací

12

3. Objective-C Jazyk Objective-C je objektově orientovaný jazyk, jež vznikl v 80. letech 20. století, když vývojáři Brad Cox a Tom Love rozšířili jazyk C o podporu objektově orientovaných vlastností jako má Smalltalk [18]. Společnost NeXT si tento jazyk vybrala pro vývoj jejich operačního systému NeXTSTEP, z něhož vychází operační systémy Mac OS X a iOS [19]. Dnes je Objective-C používán společností Apple a vývojáři, kteří cílí na tuto platformu. Cílem této práce není nahradit didaktickou literaturu, ale pouze uvést základy syntaxe Objective-C.

3.1 Úvod do syntaxe Objective-C V kapitole 3.1 si popíšeme základy syntaxe Objective-C. Vysvětlíme si, jak vypadá struktura zdrojových kódů, jak deklarovat property1, atributy a metody tříd a jak je implementovat. Ukážeme si, jak se v Objective-C zasílají zprávy objektům. Popíšeme vlastnosti propert v Objective-C a nakonec vysvětlíme inicializaci objektů. 3.1.1 Struktura hlavičkového souboru Představte si, že budete chtít definovat novou třídu Strom, abyste si později mohli vytvářet její objekty. V Objective-C se definice rozdělí do dvou souborů: hlavičkového (.h) a implementačního (.m) souboru. Hlavičkový soubor obsahuje všechny veřejné informace o objektu, zatímco implementační soubor obsahuje informaci o fungování objektu. Obsah implementačního souboru je privátní. Hlavičkový soubor třídy Strom se jmenuje Strom.h obsahuje veškeré informace o vlastnostech (propertách a atributech) a chování (funkcích) instancí této třídy. Předpokládejme, že třída Strom je podtřídou třídy Rostlina. Pak hlavičkový soubor třídy Strom bude vypadat následovně:

Obrázek 3.1: Struktura hlavičkového souboru

Ná řádku číslo 1 vidíte příkaz #import. Ten slouží k přenesení informace o jiných třídách. Slouží podobně jako #include v C/C++, ale navíc ošetřuje duplicitní vkládání 1

z anglického property

13

hlavičkových souborů. V našem případě importujeme informaci o třídě Rostlina do hlavičkového souboru Strom.h. Protože importujeme lokální soubor, je název hlavičkového souboru Rostlina.h uvnitř uvozovek. V případě, že byste načítali informace z nějakého frameworku, museli byste název souboru uzavřít mezi znaky „<“ a „>“. Například pro načtení informací o základních prvcích Foundation rámce by to vypadalo takto: / . Vše mezi klíčovými slovy @interface a @end popisuje veřejné rozhraní třídy. Bezprostředně za klíčovým slovem @interface vždy následuje jméno popisované třídy. Za ním je dvojtečka a následuje jméno rodičovské třídy. Každá třída v Objective-C musí být podtřídou právě jedné jiné třídy. V tomto případě je třída Strom podtřídou třídy Rostlina. Nyní se podívejme na odpovídající implementační soubor.

3.1.2 Struktura implementačního souboru Hlavičkový a implementační soubor dohromady definují danou třídu, tentokrát třídu Strom. Vše, co má být veřejné, je umístěno v hlavičkovém souboru. Nezapomeňte, že obsah implementačního souboru je privátní.

Obrázek 3.2: Struktura implementačního souboru

Stejně jako u hlavičkového souboru, začínáme naimportováním informace pomocí direktivy #import. Tentokrát ale ne o jiné třídě, nýbrž o třídě samotné. Pamatujte, že každý implementační soubor potřebuje naimportovat informace obsažené v jemu odpovídajícím hlavičkovém souboru. Veškerý kód, jenž implementuje třídu Strom, musí být umístěn mezi klíčovými slovy @implementatnion a @end. Jméno třídy, kterou implementujeme, následuje bezprostředně za klíčovým slovem @implementation.

3.1.3 Deklarace atributů, propert a metod třídy Náš hlavičkový soubor obsahuje veřejné rozhraní naší třídy. To je místo, kde deklarujeme atributy, property a metody, které chceme ostatním zpřístupnit. Nyní se podívejme, kam které deklarace patří. 14

Obrázek 3.3: Deklarace veřejných atributů, propert a metod

Pokud využíváme veřejné atributy třídy, pak jejich definice náleží mezi složené závorky hned za název rodičovské třídy. Často veřejné atributy nepoužijeme. V takovém případě složené závorky úplně vynecháváme a po názvu nadtřídy následuje rovnou deklarace vlastností a za nimi deklarace veřejných metod. - Poznámka: ve veřejném rozhraní třídy lze pomocí direktivy @private definovat také privátní atributy. Jak uvidíte dále, existuje ještě druhá možnost, jak definovat privátní atributy tříd. Pomocí privátního rozhraní. Já preferuji definování privátních atributů ve veřejném rozhraní třídy pomocí direktivy @private. To, co můžete vidět na obrázku 3.4, je privátní rozhraní, za kterým následuje implementační část. Privátní rozhraní použijeme v případě, že chceme mít v naší třídě nějaké privátní atributy, property nebo metody. Pokud ho chceme, musíme ho umístit do implementačního souboru. Z principu zapouzdření víme, že všechny prvky, které nemusí být veřejné, bychom měli deklarovat jako privátní. Toto privátní rozhraní se nazývá rozšíření třídy. Jeho syntaxe je podobná syntaxi veřejného rozhraní třídy v hlavičkovém souboru, až na to že neobsahuje informaci o rodičovské třídě. Za název třídy se připojují kulaté závorky. Implementace metod tříd musí být umístěna mezi klíčová slova @implementation a @end.

15

Obrázek 3.4: Deklarace privátních atributů, propert, metod a implementace metod

- Poznámka: od verze Xcode 4.3 není povinné předem deklarovat privátní metody. Překladač nově definovanou metodu bez předchozí deklarace chápe jako privátní [20]. Objekty v Objective-C nemohou mít privátní metody tak, jak je známe u C nebo C++, ale tím, že jejich deklaraci umístíme do implementačního souboru, je před ostatními objekty vlastně skryjeme.

3.1.4 Deklarace metod podrobněji Klíčovou vlastností objektově orientovaného programování je zasílání zpráv. Může chvíli trvat, než si člověk zvykne na syntaxi pro deklarování, implementaci a zasílání zpráv v Objective-C. Začneme deklarováním metod v hlavičkovém souboru. Pokud budeme chtít přistupovat k atributům třídy, budeme si muset nadeklarovat metody les, stariStromu a pocetLetokruhu, které nemají žádné parametry (proč se metody jmenují přávě takto, si vysvětlíme v části věnované propertám). Dále si nadeklarujeme dvě metody setLes: a setStariStrinu:, které přijímají jeden parametr. Na obrázku 3.5 můžeme vidět zdrojový kód:

16

Obrázek 3.5: Deklarace metod

- Poznámka: klíčovým slovem @class Les; kompilátoru říkáme, že později dodáme deklaraci a definici třídy Les (v implementačním souboru, to provedeme tak, že naimportujeme příslušný hlavičkový soubor třídy Les). Podívejme se nyní blíže na deklaraci funkce stariStromu, která je v podstatě getter1. Na začátku deklarace si můžeme všimnout znaménka mínus (-), které indikuje, že se jedná o metodu instance třídy. Kdyby na začátku deklarace metody bylo plus (+), jednalo by se o metodu třídy. Hned za znaménkem následuje návratový typ metody. Ten se uzavírá do kulatých závorek. Jelikož naše metoda nepřijímá žádný parametr, zbývá už jen poslední část deklarace, samotný název metody „stariStromu“, někdy též nazývaný selektor2. Každou deklaraci metody ukončujeme středníkem. Ve většině programovacích jazyků se metody přijímající nějaké parametry definují jako: návratovýTyp názevFunkce(datovýTyp paramtetr1,datovýTyp parametr2); V Objective-C to je jinak. V deklaraci metody, jež přijímá nějaký parametr, je obsaženo jméno parametru ve jméně deklarované metody: -(návratovýTyp) názevFunkcePříjmajícíParametr:(datovýTypParametru)parametr1; Stejně jako návratová hodnota metody je i datový typ parametru uzavřen v kulatých závorkách, podobně jako u přetypování v klasickém C. Pokud chceme deklarovat metody s více proměnnými, je zde opět rozdíl s klasickým céčkovským zápisem. V jazyce C se píší všechny parametry za sebe, oddělené čárkou a jsou uzavřeny v kulatých závorkách za jménem funkce. V Objective-C vypadá metoda přijímající dva parametry následovně:

1 2

z anglického getter, označení pro metodu vracející atribut instance třídy z anglického selector, název metody

17

-(návratovýTyp) názevFunkcePříjmajícíPrvníParametr:(datovýTypParametru)parametr1 druhýParametr:(datovýTyp)parametr2; Parametry parametr1 a parametr2 používáme v implementaci jako proměnné obsahující hodnoty, které byly metodě předány. Pořadí parametrů musí být při „volání metody“ (v Objective-C říkáme zasílání zprávy) zachováno. Celá signatura metody, jež jsme deklarovali výše, je: názevFunkcePříjmajícíPrvníParametr:druhýParametr: Součástí signatury jsou i datové typy proměnných. Vidíme, že název metody připomíná normální větu, to usnadňuje čitelnost kódu. Díky tomu, že pořadí parametrů je pevně dané a ke každému parametru máme něco jako popis (například ta část metody, která se jmenuje „prvníParametr:“), je menší pravděpodobnost, že by programátor spletl pořadí parametrů, a to i v případě, že by měly stejné datové typy. Takové chyby jsou nepříjemné a špatně se ladí. Objective-C nám svou syntaxí pomáhá takovýmto chybám předcházet. Nyní si ukážeme, jak implementovat metody a zasílat zprávy objektům.

3.1.5 Implementace metod Deklarací metod jsme přislíbili, že dodáme jejich implementaci. To se dělá v odpovídajícím implementačním souboru, v našem případě v souboru Strom.m. Metody, jež jsme deklarovali v hlavičkovém souboru, jsou v podstatě settry1 a gettry dané třídy. Musíme nyní nadeklarovat atributy třídy, které budou v sobě udržovat hodnoty. Aby byly privátní, uděláme to v implementačním souboru. Atributy třídy si pojmenujeme _les, _letokruhy a _stariStromu. Proč máme před názvy proměnných podtržítko, si vysvětlíme později. Na obrázku 3.6 můžeme vidět jak by vypadala implementace:

1

z anglického setter, označení pro metodu umožňující změnu atributu

18

Obrázek 3.6: Implementace metod v Objective-C

3.1.6 Zasílání zpráv Ačkoliv existuje několik způsobů, jak zasílat zprávy mezi objekty v Objective-C, nejčastější z nich se zapisuje za pomocí hranatých závorek. Například takto: [nějakýObjejkt udělejNěco]; Tomu odpovídá zápis z 24. řádku na obrázku 3.6, kde self je příjemce zprávy (ano, každý objekt může zasílat zprávy sám sobě) a prepocitejStariStromu je název metody, kterou příjemce bude volat. Vyjádřeno jinými slovy, objektu self je zaslána zpráva prepocitejStariStromu. Pokud metoda, která bude zasláním zprávy vyvolána, potřebuje předat nějaké argumenty, bude volání vypadat následovně: [nějákýStrom setLes:ukazatelNaInstanciTřídyLes]; Metodě třídy můžeme předávat jak primitivní datové typy, tak i třídy.

19

3.1.7 Property a atributy třídy Data tříd se v Objective-C ukládají stejně jako v C nebo C++ do atributů třídy. Property jsou v Objective-C jakousi nadstavbou těchto atributů. Property v Objective-C zjednodušují psaní kódu a zvyšují jeho čitelnost. Jednoduchou deklarací property totiž získáme kromě atributu také metody pro manipulaci s daty, tzv. gettry a settry. Jméno vygenerovaného atributu bude stejné jako je jméno property, pouze před ním bude umístěno podtržítko (níže uvedené propertě pocetListu by odpovídal vygenerovaný atribut pojmenovaný

_pocetListu).

Standardně

jsou

přístupové

metody

syntetizovány

kompilátorem, takže pro jejich získání nic dělat nemusíme než jen deklarovat propertu pomocí klíčového slova @property. Jména vysyntetizovaných metod se řídí následujícími konvencemi pro pojmenování: - metoda používaná pro přístup k datům property se jmenuje stejně jako properta, takže getter pro propertu pojmenovanou pocetListu se bude jmenovat také pocetListu. - metoda používaná pro nastavení hodnoty property začíná slovem set a za něj si přiřetězí kapitalizované1 jméno property. Například pro propertu pojmenovanou pocetListu bude vysyntetizován setter pojmenovaný setPocetListu:. Základní definice property v Objective-C se skládá z klíčového slova @property, za ním následuje datový typ a pak název property.

Obrázek 3.7: Deklarace property pocetListu, ktera je typu int

3.1.8 Možnosti vlastností propert Propertám můžeme nastavit různé vlastnosti a tím přizpůsobit jejich chování tak, aby vyhovovalo našim požadavkům. Většina této kapitoly parafrázuje informace které se dají nalézt v dokumentaci pro LLVM2 [21]. Následuje výčet a popis vlastností propert:

Readwrite vs readonly Readonly properta je pouze ke čtení, kompilátor setter pro takovou propertu vůbec nevysyntetizuje. V případě, že byste chtěli používat setter pouze pro vnitřní použití objektu, je možné použít tzv. rozšíření třídy a v implementačním souboru propertu 1 2

z anglického capitalized zkratka z anglického low lever virtual machine, je to infrastruktura pro překladač

20

definovat jako readwrite. Kompilátor pak vysyntetizuje i setter, ten bude ale viditelný pouze uvnitř třídy (více v sekci rozšíření třídy). Každá properta je v Objective-C standardně readwrite.

atomic vs nonatomic Properta v Objective-C může být atomická nebo neatomická. Standardně je každá properta atomická. To znamená, že vysyntetizované přístupové metody zajišťují, že getter vždy vrátí úplnou a validní hodnotu a setter do property nastaví úplnou a validní hodnotu, i když jsou volány zároveň z více vláken. Můžeme použít také neatomické property. Tím specifikujeme, že vysyntetizované přístupové metody jednoduše nastavují nebo vracejí hodnoty propert bez jakékoli synchronizace. V takovém případě není nijak garantováno, co se stane, pokud ke stejné propertě přistoupíme z více vláken zároveň. Z tohoto důvodu je rychlejší přistupovat k neatomickým propertám. 

Pozor: to, že má objekt property, které jsou atomické, neznamená, že práce s nimi je thread-safe. Mějme například objekt osoba, jež má atomické property jméno a příjmení. Představme si situaci, kdy v jednom vlákně program přistupuje k propertám pomocí gettrů a v dalším vlákně jim nastavuje nové hodnoty pomocí settrů. Atomicita propert nám zajišťuje, že gettry nám vrátí úplné řetězce (bez pádu programu), ale není zde nijak garantováno, že hodnoty jména a příjmení budou konzistentní. Pokud se stane, že první vlákno přistoupí k propertě jméno před změnou a k propertě příjmení přistoupí až po změně, dostaneme nekonzistentní pár jméno-příjmení.

Assign, weak, retain, copy - retain - dříve strong, lze použít obojí. Označuje propertu se silnou referencí na objekt. Od verze LLVM 3.1 je properta typu strong, není-li deklarováno jinak nebo pokud atribut, se kterým je asociována, nemá nastaveno vlastnictví1 jinak. Jelikož jsou objekty v Objective-C alokovány na haldě, je objekt držen v paměti, dokud na něj odkazuje alespoň jedna silná (strong, retain) reference jiného objektu [22]. V případě, že klesne počet silných referencí2 objektu na nulu, je automaticky

1 2

podle anglického ownership podle anglického retain count

21

dealokován. - assign - používá se pro primitivní datové typy jazyka C. Může se také použít pro objekty. Ale pokud přiřadíme odkaz na objekt do property typu assign, nezvýší se objektu počet silných referencí. Může se potom stát, že počet silných referencí na objekt klesne na nulu a odkaz bude odkazovat na neplatnou paměť. - weak - má podobné vlastnosti jako assign, ale v případě, že klesne počet silných referencí na odkazovaný objekt na nulu, je automaticky nastaveno, že pointer bude odkazovat na nil objekt. Tím je zabráněno neoprávněnému přístupu do uvolněné paměti. Proto se weak property používají především pro držení slabých referencí na objekty. - copy - používá se hlavně v případě tzv. změnitelných1 objektů, kdy nechceme, aby změny způsobené jinými objekty měly efekt na uložená data. Do property se uloží reference na kopii objektu, jež reprezentuje aktuální stav objektu. Reference na nový objekt je typu strong. Propertu name typu NSString s vlastnostmi weak a readonly vytvoříme tak, že mezi klíčové slovo @property a datový typ property vložíme kulaté závorky. Do nich vepíšeme vlastnosti, které požadujeme:

Obrázek 3.8: Deklarace property name typu NSString s vlastnostmi weak a readonly

3.1.9 Vytváření propert Property tříd se využívají velmi často. Pojďme si ukázat, jak na to. Začneme tím, že settry a gettry ve třídě Strom nahradíte propertami. V přiloženém výpisu z kódu vidíme zápis @property Les *les;. To je totéž jako bychom deklarovali getter les a setter setLes: a atribut _les. Properta pocetLetokruhu je deklarována jako readonly, to znamená, že se nám vysyntetizuje pouze getter pojmenovaný pocetLetokruhu a atribut _pocetLetokruhu.

1

z anglického mutable

22

Obrázek 3.9 Vytváření propert třídy



Poznámka: dříve se muselo v implementačním souboru syntetizovat settry a gettry za pomocí klíčového slova @synthesize. Od verze Xcode 4.5 to již není třeba. Pokud si nadefinujeme vlastní getter a setter např. pro propertu les, budeme muset použít klíčové slovo @synthesize pro vygenerování atributu _les. Příklad: @synthesize les = _les; Podtržítka, jež vidíte před názvy atributů odpovídajících propert, tam nemusí nutně být. Je to ale konvence, která usnadňuje čitelnost kódu. Každý, kdo čte cizí kód, na první pohled rozezná obyčejné proměnné od atributů třídy.

3.1.10 Inicializace tříd Abychom s instancemi tříd mohli pracovat, musíme je nejprve inicializovat. Procesu inicializace ještě předchází proces alokace paměti pro daný objekt. Inicializace objektu slouží k vytvoření objektu ve smysluplném a použitelném stavu. To znamená, že při inicializaci budou property a atributy třídy inicializovány a budou jim přiřazeny hodnoty, které budou sloužit jako výchozí a budou načteny nezbytné informace z externích zdrojů. V případě, že objekt neimplementuje žádnou inicializační metodu, Cocoa Touch1 zavolá inicializační metodu nejbližšího předka. Inicializační metoda je metoda jako každá jíná a musí být proto deklarována v hlavičkovém souboru. Pokud pouze překrýváme nějakou inicializační metodu předka, není deklarace nutná (vyplývá z OOP). Na následující ukázce kódu si předvedeme, jak se inicializační metody implementují.

1

Cocoa Touch je rámec pro tvorbu iOS aplikací

23

Obrázek 3.10: Implementace metod třídy

Podoba inicializačních metod a jejich deklarace se musí řídit těmito pravidly: -

každá inicializační metoda začíná slovem init a je typu id

-

na začátku vždy voláme inicializační metodu předka a výsledek uložíme do self

-

potom následuje kontrola, zda-li je objekt nil. Pokud je objekt nil, vracíme nil.

-

následuje samotná inicializace atributů třídy. Pokud vše proběhne v pořádku, vracíme nainicializovaný objekt. Můžou nastat situace, kdy bychom neměli nově vytvořený objekt vracet. Namísto něj bychom měli vyhledat již existující objekt, který odpovídá požadavkům (pokud máme nějaký unikátní identifikátor objektu, který se nesmí opakovat, nebo pokud jde o jedináčka1) nebo bychom měli vyhodit výjimku kvůli nevyhovujícím datům předaných pro inicializaci. V každém z těchto případů bychom měli paměť, kterou jsme pro nový objekt získali, správně uvolnit.

3.2 Nástroje pro vývoj iOS aplikací

3.2.1 Xcode Xcode je vývojový nástroj od společnosti Apple. Lze jej zdarma stáhnout a nainstalovat skrze App Store. Distribuce tohoto nástroje je omezena pouze pro platformu Mac OS X, takže každý, kdo chce vyvíjet aplikace pro iOS zařízení, musí mít také počítač společnosti Apple. V nástroji iOS Simulator lze testovat a vyvíjet aplikace zdarma. Pokud ovšem 1

podle anglického singleton

24

chceme aplikace testovat na zařízeních a umísťovat do App Storu, musíme zaplatit roční poplatek 99$ za licenci iOS Developer Program. Xcode jsem si oblíbil a pracuje se mi v něm dobře. Jeho nová verze (Xcode 5) je graficky velmi podobná předchozí. Hlavním přínosem nové verze Xcode jsou SDK pro OS X 10.8, OS X 10.9 a iOS 7.0.3 [23].

3.2.2 iOS Simulator K testování aplikací lokálně na počítači slouží iOS Simulator. S jeho pomocí můžeme testovat aplikaci na široké škále zařízení (iPhony a iPady různých generací), ale jak název tohoto nástroje napovídá, jde pouze o simulátor, proto i Apple doporučuje před vydáním aplikace její otestování přímo na koncových zařízeních. Z osobní zkušenosti můžu říci, že se jedná o celkem rychlý a kvalitní nástroj, který každému vývojáři může určitě pomoci. Občas se v něm objeví nějaké chyby, ty jsou ale pravidelně odstraňovány pomocí aktualizací.

3.2.3 Insturments Instruments je soubor nástrojů pro sběr dat o vaší aplikaci. Pomocí těchto nástrojů lze vaši aplikaci snadno analyzovat a optimalizovat pak slabá místa aplikace. Pomocí nástrojů programu Instruments lze například zjišťovat zatížení paměti a procesorů nebo vyhledávání tzv. zombie procesů.

3.2.4 Interface Builder Interface Builder je nástroj přímo integrovaný v nástroji Xcode. Slouží pro tvorbu grafického rozhraní aplikací. Výsledná grafická rozhraní se ukládají do tak zvaných .nib souborů. Já osobně Interface Builder nepoužívám, takže veškeré grafické rozhraní implementuji v kódu.

3.3 Novinky v iOS7 iOS 7 přináší mnoho změn především v grafickém rozhraní operačního systému, jako např. tlačítka bez okrajů nebo průsvitné prvky. Velkou změnou je také celkové rozvržení grafického rozhraní. Společnost Apple se rozhodla iOS 7 koncipovat podobně jako operační systém Metro od Windows, to znamená, že je důraz kladen na obsahovou část aplikací bez zbytečných grafických doplňků (jako byly nejrůznější okraje, textury a stíny). Předtím než by se měl vývojář pustit do předělávání své aplikace, měl by se seznámit 25

s novým prostředím iOS 7 a jeho odlehčeným „feelingem“. Mnoho velkých firem, jako např. American Airlines nebo New York Times předělaly své aplikace zásadním způsobem tak, aby vyhovovaly konceptům iOS 7 [24]. Přesto sdílím názor s Chrisem Laddem, že aplikace by si měly zachovat svou osobitost tak, aby byly v souladu s novým vzhledem iOS 7. Já osobně si myslím, že iOS 7 je krok kupředu, přestože to pro některé aplikace znamená kompletní předělání. Nový vzhled iOS 7 je čistý a práce s ním je velmi intuitivní. Některé změny nejsou velké, např. u seznamů není změna mezi iOS 6 a iOS 7 příliš znatelná. Zato změny v Informačním Centru1 nebo Počasí jsou znatelné a lze snadno rozpoznat rozdíly v rysech operačního systému iOS 7 a jeho předchozí verze [25]. Podrobnější ukázka změn mezi iOS 6 a iOS 7 se nachází v příloze A.

3.3.1 Hlavní rysy iOS 7 Respekt Uživatelské rozhraní přispívá k přehlednosti obsahu a napomáhá uživateli s ním interagovat, ale nikdy s obsahem nesoupeří. Čistota Text je čitelný v jakékoli velikosti, ikony jsou precizní a jasné, ozdoby jsou jemné a vhodné. Je kladen důraz na funkcionalitu, jež motivuje to, jak je vzhled aplikace navržen.

Hloubka Viditelné vrstvy a realistické pohyby prvků grafického rozhraní podtrhávají uživatelský prožitek a intuitivnost aplikace [28].

3.3.2 Převod aplikace do stylu iOS 7 Vzhledem k razantní změně uživatelského rozhraní iOS 7 oproti předchozím verzím, je nutné více než dřív předělat již existující aplikace. Vývojáři můžou stále využívat staré API a hierarchii objektů jako v předchozích verzích. Některé se ale chovají odlišně a především vypadají jinak. Aplikace pro iOS 7 by měly klást důraz na obsah, být jednoduché a uživateli především umožňovat rychlou a pohodlnou práci s aplikací. Množství toho, co je třeba v aplikaci předělat, aby vyhovovala konceptům, záleží na úrovni

1

podle anglického Notifications Center

26

customizace1 aplikace. Podle příručky k převodu aplikace na iOS 7 lze aplikace rozlišit na 3 druhy:

Standardní Aplikace obsahuje pouze standardní necustomizované prvky grafického rozhraní poskytované UIKit rámcem.

Customizované Aplikace se skládá z čistě customizovaných prvků, jež neobsahují žádné prvky UIKit rámce. Hybridní Aplikace se skládá z mixu standardních a customizovaných elementů včetně standardních elementů, které jsou upravené pomocí UIKit rámcem. Pro standardní aplikaci potřebujeme rozhodnout, zdali vzhled a koncepce aplikace vyhovuje prostředí iOS 7. Pokud se rozhodneme zachovat si dosavadní grafické rozvržení a model interakce s uživatelem, většina práce spojená s převodem aplikace na iOS 7 se bude skládat z malých změn a ujišťováním se, že aplikace správně interpretuje gesta uživatele. Customizované aplikace potřebují objektivní pohled na to, jestli současná logika a vzhled aplikace může být zachována, nebo je ji třeba předělat. V případě, že logika a vzhled aplikace vyhovuje konceptům iOS 7, budou změny minimální a pravděpodobně se budou týkat toho, jak využít nové možnosti operačního systému. Pokud bude třeba celou aplikaci navrhnout znovu, znamená to více práce. U hybridních aplikací je rozsah práce nutný pro převod na iOS 7 závislý na množství a způsobu customizace prvků uživatelského rozhraní. Navíc je třeba u hybridních aplikací zkontrolovat, zdali customizované objekty fungují správně se standardními prvky grafického rozhraní, které nabízí UIKit rámec[28].

1

podle anglického customization

27

4. Vlastní aplikace – Issue manager V této kapitole se budeme věnovat popisu aplikace, která byla vypracována ve spolupráci se společností Tapmates. Jedná se o aplikaci pro správu úkolů na webové hostingové službě GitHub, jež slouží jako podpůrný systém po vývoj softwaru. Budování této aplikace se skládalo z několika kroků. Od samotného nápadu a vymyšlení aplikace, přes specifikaci požadavků, grafický návrh (nachází se v přílze B) a samotné naprogramování aplikace. Zdrojový kód je dostupný na přiloženém CD. Pro správné fungování aplikace musí být zařízení připojeno k internetu.

4.1 Popis aplikace Aplikace, byla pracovně pojmenvána „Issue manager“ (dále uváděno bez uvozovek), jelikož se jedná o aplikaci pro správu úkolů na webové hostingové službě GitHub. I když už vyšel iOS 7, jedná se o aplikaci pro iOS 6.1. Je to proto, že aplikace byla vyvíjena v době, kdy ještě o iOS 7 nebyly žádné informace. Issue manager je nástroj určený pro vývojáře, testery, grafiky a pro vedoucí pracovníky vývojářských týmů. Umožňuje prohlížení, zadávání a uzavírání úkolů k vybraným projektům. Za klíčové vlastnosti tohoto nástroje byly určeny jednoduchost a rychlost, s jakou lze pomocí aplikace pracovat s úkoly na webové službě GitHub. Při prvním spuštění aplikace je uživatel požádán o přihlášení do služby GitHub. Po přihlášení následuje obrazovka, na které si uživatel vybere, které repozitáře chce pomocí aplikace Issue manager sledovat. Poté se dostane do hlavní části aplikace. Ta se skládá ze seznamů úkolů pro daného uživatele. Pokud si uživatel vybral více repozitářů, může mezi nimi přepínat pomocí listování1. Nahoře této obrazovky je navigační lišta. Ta obsahuje dvě tlačítka a popisek. Tlačítko vlevo slouží ke změně sledovaného spolupracovníka. Pomocí tlačítka vpravo můžeme přidat nový úkol do aktuálního repozitáře. Popisek na navigační liště se skládá ze jména repozitáře a ze jména uživatele. Pomocí listování se také můžeme dostat do seznamu repozitářů přihlášeného uživatele. A to tak, že z prvního repozitáře listujeme zleva doprava. Po tomto gestu vyjede seznam repozitářů a může být změněn a uložit pomocí tlačítka change. Podrobnější popis aplikace s danými obrazovkami je uveden v příloze B.

1

z anglického swipe gesture

28

4.2 Rozbor aplikace V této kapitole je rozebírána vzorová aplikace, která byla vyvinuta pro potřeby bakalářské práce. Je popisováno použití rámce Mantle, jenž usnadňuje práci s modely aplikace. Dále je čtenář seznámen s knihovou AFNetworking a použitím návrhového vzoru singleton. Poslední téma, které je v této kapitole popsáno je tvorba tabulky ve vzorové aplikaci. 4.2.1 Rámec Mantle – modely aplikace Pro práci s modely je v aplikaci použit rámec Mantle ve verzi 1.3. Mantle je použit proto, že výrazným způsobem zjednodušuje práci s daty, které poskytuje GitHub ve formátu JSON. Nyní jsou vypdány konkrétní výhody [26], které rámec Mantle přináší: -

s minimálním úsilím lze vytvořit objekty, které se dají mapovat z a do JavaSriptového objektového zápisu (dále jen JSON). Zpětný převod objektu je možný díky reverzibilním transformačním metodám. Pomocí metody +[MTLJSONAdapter JSONDictionaryFromModel:] můžeme převést jakýkoli objektový model implementující <MTLJSONSerializing> do JSONu.

-

pomocí rozšířitelné metody mergeValuesForKeysFromModel: můžeme snadno specifikovat jak sloučit data z nového modelu a aktualizovat, tak existující objekt.

-

MTLModel automaticky ukládá verzi objektového modelu, jenž byl použit pro archivaci.

Pokud

přepíšeme

decodeValueForKey:withCoder:modelVersion:,

bude

metodu při

rozbalení

archivovaných dat tato metoda zavolána. To nám v případě změny objektového modelu umožní pohodlnou aktualizaci dat. Z rámce Mantle aplikace využívá pouze převod dat z JSONu do objektů. V aplikaci je celkem sedm modelů. Reprezentují informace, se kterými aplikace pracuje. Jsou to modely pro úkol, štítek, milník, repozitář, uživatele, organizaci a komentář. Nyní budou uvedeny ukázky kódu objektu BCIssue a popsán jejich význam v programu. Jsou uvedeny pouze nejdůležitější části, zbytek kódu je uveden a popsán v příloze C.

29

Obrázek 4.1: Metoda JSONKeyPathsByPropertyKey

Objekt typu NSDictionary, který vrací metoda na obrázku 4.1, slouží ke specifikaci mapování JSONu na property objektu. Property, které jsou namapovány na objekt NSNull.null, nebudou ze vstupních dat nic načítat. V aplikaci toto nebylo potřeba, ale jako příklad uvádím, jak by to vypadalo pro propertu updatedAt: @“updatedAt“ : NSNull.null Pokud rodičovská třída také implementuje MTLJSONSerializing, můžete použít metodu [NSDictionary mtl_dictionaryByAddingEntriesFromDictionary:]

ke spojení

mapování současné a rodičovské třídy. K vytvoření samotného objektu z JSONu reprezentovaného

pomocí

objektu

NSDictionary

použijeme

tovární

metodu

[MTLJSONAdapter modelOfClass:fromJSONDictionary:error:]. Klíče, které nejsou nijak mapovány, jsou ignorovány.

Obrázek 4.2: Transformační metoda stateJSONTransformer

Na obrázku 4.2 je zobrazena transformační metoda pro propertu state. Syntaxe pro transformační metody je názevPropertyJSONTransformer. Transformační metody jsou vždy metody statické, takže na začátku jejich deklarace je znaménko plus (+). Transformační metodou říkáme programu, jak správně vytvořit danou propertu na základě dodaných dat v JSONu.

30

4.2.2 Knihovna AFNetworking - Síťová komunikace AFNetworking je knihovna třetích stran usnadňující síťovou komunikaci aplikací pro platformy Mac OS X a iOS. Je postavena nad objekty NSURLConnection, NSOperation a dalšími dobře známými technologiemi rámce Foundation [27]. Aplikace využívá knihovnu AFNetworking ke komunikaci s webovou službou GitHub, která zasílá veškerá data ve formátu JSON. Na obrázcích 4.3, 4.4, 4.5, 4.6 a 4.8 jsou ukázky kódů ze souboru BCHTTPClient.m. Obrázek 4.7 je ukázka kódu ze souboru BCIssue.m.

Obrázek 4.3: Inicializační metoda objektu BCHTTPClient

Na obrázku 4.3 můžeme vidět inicializační metodu objektu BCHTTPClient, jež je podtřídou objektu AFHTTPClient knihovny AFNetworking. Pomocí této metody ustavíme spojení mezi aplikací a serverem GitHub. Použitím jednoduchých metod (na řádcích 20 až 23), které poskytuje knihovna AFNetworking, snadno nastavíme hlavičky pro komunikaci skrz HTTP protokol.

Obrázek 4.4: Metoda sloužíci pro změnu dat na serveru

Obrázek 4.5: Metoda sloužící pro náhrání nových dat na server

31

Obrázek 4.6: Metoda sloužící pro získání dat ze serveru

Pomocí metod na obrázcích 4.4, 4.5 a 4.6 komunikuje aplikace se serverem GitHub. V success bloku jsou zpracovávána získaná data, viz obr. 4.7:

Obrázek 4.7: Metoda getIssuesFromRepository:forUser:withSuccess:failure:

Voláním metody z obrázku 4.7 získáváme úkoly pro daný repozitář a uživatele. Tato metoda je zatím nejsložitější, proto ji stručně popíšu. Na řádku číslo 144 si vytváříme parametry pro komunikaci se servrem GitHub. Dále je definována pomocná proměnná page, kterou máme kvůli stránkování. Server GitHub totiž zasílá pouze omezené množství dat (v tomto konkrétním případe maximálně 30 objektů v jazyce JSON), takže abychom dostali všechny, musíme volat dotaz opakovaně. Po definici proměnné issues, kterou používáme pro uložení všech načtených úkolů, následují definice dvou bloků. Blok mySuccessBlock se vykoná v případě, že se metoda getPath:parameters:success:failure (řádek 172) vykoná úspěšně. Naopak myFailureBlock se vykoná v případě, že tato operace bude neúspěšná. 32

Prvním definovaným blokem je myFailureBlock blok. Ten pouze předá dál chybu, která nastala. Druhým blokem je mySuccessBlock blok. V něm zpracováváme příchozí data a je rozhodováno, zdali je třeba poslat další požadavek, nebo jestli už máme všechna data. Za povšimnutí ještě stojí řádek číslo 165. Kompilátor na něm hlásí varování, které zní „Capturing 'mySuccessBlock' strongly in this block is likely to lead to a retain cycle“. Podle kompilátoru hrozí vznik tzv. „retain cycle“. Tímto pojmem se v Objective-C označuje zacyklení ukazatelů. V případě, že se ukazatele objektů zacyklí, dojde k úniku paměti1. Je to proto, že u zacyklených objektů nikdy neklesne počet silných referencí na nulu. V kódu na obrázku 4.7 se takové situaci předchází tak, že po dokončení načítání úkolů je nastaven mySuccessBlock na nil objekt, což má za následek uvolnění paměti.

Obrázek 4.8: Metoda sharedInstance

Pomocí metody sharedInstance v aplikaci tvoříme instanci objektu BCHTTPClient. Ta reprezentuje spojení mezi aplikací a servrem GitHub. Jedná se o použití tzv. „singleton patternu“ v Objective-C. V metodě definujeme statickou proměnnou nazvanou instance, která je inicializována pouze jednou, a to během přihlášení uživatele. To je zajištěno pomocí metody dispatch_once(), jež je poskytována GCD2. Tato metoda je „thread-safe“, takže nemusíme mít obavy, že by mohlo dojít k vícenásobné inicializaci. 4.2.3 Práce s UITableView Jelikož práce zobrazuje seznamy úkolů pro daného uživatele, je nejlepší tyto úkoly

1 2

memory leak Grand Central Dispatch

33

prezentovat

v tabulkách.

UITableViewController,

Pro

práci

s tabulkami

UITableView,

existují

v rámci

UITableViewCell

UIKit a

třídy

protokol

UITableViewDelegate. V této aplikaci využíváme třídy UITableViewCell, UItableView a protokol UITableViewDelegate. Místo třídy UITableViewController využíváme její rodičovskou třídu UIViewController. Kromě zobrazování úkolů jsou tabulky také používány k zobrazování seznamů spolupracovníků, milníků, štítků a repozitářů. Nejdříve popíšeme jednodušší tabulku pro zobrazování spolupracovníků při tvorbě nového úkolu (dále v textu označována jako tabulka spolupracovníků). Grafický návrh této komponenty se nachází v příloze B na obrázku B.6. Pokud chceme v aplikaci pro platformu iOS zobrazit plnohodnotnou tabulku obsahující data, budeme potřebovat čtyři komponenty; nyní bych rád čtenáře ještě jednou upozornil na to, že k tvorbě aplikace není využíván Interface Builder. Tři z těchto komponent odpovídají prvkům konceptu MVC1, poslední je reprezentace buňky v tabulce. Nejjednodušší je začít tvorbou tzv. „data sourcu“ (dále označován jako model). Model obsahuje data, která budou prezentována v tabulce. Druhým prvkem, který je potřeba pro tvorbu seznamu spolupracovníků je třída reprezentující buňku tabulky. Dalším prvkem seznamu pro výběr spolupracovníka je pohled (prvek view z MVC modelu). Pro reprezentaci grafického rozhraní se v Objective-C používá třída UIView. Posledním prvkem, který nám ještě zbývá vytvořit, abychom byli schopni sestavit seznam spolupracovníků, je řadič (prvek controller z MVC modelu). Řadič je prvek spojující tři předešlé komponenty. Reaguje na události a řídí změny v pohledu a v modelu. Kooperací všech těchto komponent nám vznikne plnohodnotný seznam spolupracovníků, ze kterého lze vybrat spolupracovníka, jenž má úkol splnit. Komentovaný kód k této kapitole se nachází v příloze D.

1

Model View Controller

34

5. Závěr Jedním z cílů této bakalářské práce bylo prostudovat vývoj mobilních aplikací a zhodnotit výhody a nevýhody nativního vývoje a alternativních způsobů vývoje. Myslím si, že tento cíl byl splněn i přesto, že se nepodařilo rozhodnout, který z přístupů k vývoji mobilních aplikací je nejlepší. Dané výhody a nevýhody byly uvedeny v druhé kapitole této práce a na základě nich se dle mého názoru v současnosti se nedá určit jasného vítěze. Každý přístup má svá pro a proti. Výběr technologií pro vývoj aplikace závisí na tom, jaké máme nároky na aplikaci a co od ní budeme požadovat. Pro aplikace, jako je klient sociálních sítí nebo internetový obchod pro firmu, je nejlepší volbou webová aplikace. V případě, že chceme cílit na více platforem, kde potřebujeme větší propojenost se zařízeními, jeví se jako nejlepší volba vyvíjet aplikaci pomocí nějakého multiplatformního nástroje. A konečně, vyžadujeme-li vysoký výkon nebo provázanost s danou platformou, je nativní cesta tou pravou. Dalším cílem této bakalářské práce bylo analyzovat a popsat programovací jazyk Objective-C. Tento cíl byl splněn v rámci možností, které bakalářská práce nabízí. Vzhledem k rozsahu tohoto tématu jsem vybral jen nejdůležitější prvky Objective-C a sepsal je tak, aby si i čtenář, který je vývojem mobilních aplikací nepolíben, odnesl z textu alespoň základní informace a udělal si obrázek o vývoji mobilních aplikací v Objective-C. Popis Objecitve-C spolu s popisem vývojového prostředí a novinek v iOS 7 jsou umístěny ve třetí kapitole. Popis rozsahu dostupné dokumentace a rozšiřujících zdrojů byl také jedním z cílů mé práce, a přesto se žádná kapitola v mé práci tomuto tématu nevěnuje. Protože stačí říct, že společnost Apple nabízí na internetu úplnou dokumentaci všech vývojářských rámců (vše lze najít na developer.apple.com) pro tvorbu iOS aplikací. Tato dokumentace neobsahuje pouze popis jednotlivých tříd a protokolů, ale je také plná tutoriálů a ukázek kódů, ze kterých je možno čerpat. Dalším rozšiřujícím zdrojem je webový portál stackoverflow.com. Cokoli nenajdete v dokumentaci od společnosti Apple, najdete na diskusním fóru stackoverflow. V neposlední řadě bylo mým cílem zhodnotit novinky, které přináší nový operační systém iOS 7. Myslím si, že nový operační systém přináší razantní změnu v uživatelském rozhraní a konceptech týkajících se této mobilní platformy. Tato změna může být vývojáři pozitivně využita k přehodnocení a případnému přetvoření svých aplikací. Nová verze iOS působí lehčím a svěžejším dojmem než předchozí verze tohoto operačního systému. Podobně by měly vypadat i aplikace, jež jsou pro tento operační systém tvořeny. Dle mého názoru tou nejzásadnější věcí, kterou iOS 7 přináší, je kompletní změna konceptu tohoto 35

operačního systému, kdy se ustupuje od grafických ozdob a dává se přednost jasnosti a přehlednosti obsahu. Posledním cílem mé bakalářské práce bylo vyvinout vzorovou testovací aplikaci. Myslím, že její rozsah dostatečně pokryl základní úkony při vývoji iOS aplikací, a tím byl splněn i poslední cíl mé bakalářské práce. Při vývoji vzorové aplikace jsem si odzkoušel práci s rámcem Mantle a knihovnami AFNetworking. Využil jsem singleton pattern pro sdílení instance spojení se serverem GitHub. Implementoval jsem kvalitně vypracovaný design dodaný společností Tapmates. Byla to náročná práce, ale hodně jsem se toho naučil. Na závěr bych chtěl uvést, že tato práce mě v oblasti vývoje mobilních aplikací velmi obohatila. Platforma iOS, přestože jsem nikdy nebyl stoupencem této značky, si získala mé sympatie. Vývoj aplikací na tuto platformu je velmi zajímavý a byl bych rád, kdybych se této problematice mohl věnovat i v budoucnu.

36

Literatura [1] STEELE, Billy. IOS 7 arrives on Apple devices September 18th. In: Engadget [online]. 2013 [cit. 2013-11-5]. Dostupné z: http://www.engadget.com/2013/09/10/ios-7-arrivesseptember-18th/ [2] FINGAS, Jon. Android tops 81 percent of smartphone market share in Q3. In: Engadged [online]. 2013 [cit. 2013-11-25]. Dostupné z: http://www.engadget.com/2013/10/31/strategy-analytics-q3-2013-phone-share/ [3] Android (operační systém). In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001-2013 [cit. 2013-11-5]. Dostupné z: http://cs.wikipedia.org/wiki/Android_(opera%C4%8Dn%C3%AD_syst%C3%A9m) [4] Developer Tools. Android Developers [online]. 2013 [cit. 2013-11-5]. Dostupné z: http://developer.android.com/tools/index.html [5] COSTELLO, Sam. How Many Apps Are in the iPhone App Store. In: About [online]. 2013 [cit. 2013-11-5]. Dostupné z: http://ipod.about.com/od/iphonesoftwareterms/qt/appsin-app-store.htm [6] PEREZ, Sarah. Apple’s App Store Hits 50 Billion Downloads, 900K Apps, $10 Billion Paid To Developers; iTunes Now With 575M Accounts. In: Techcrunch [online]. 2013 [cit. 2013-11-5]. Dostupné z: http://techcrunch.com/2013/06/10/apples-app-store-hits-50billion-downloads-paid-out-10-billion-to-developers/ [7] Native vs. HTML5 Mobile App Development. Appcelerator [online]. 2012 [cit. 201311-5]. Dostupné z: https://pages.appcelerator.com/NativevsHTML5MobileAppDevelopment.html [8] MILLIONS OF CHOICES. Apps - Google Play - Google [online]. 2013 [cit. 2013-115]. Dostupné z: https://play.google.com/intl/en-US_us/about/apps/index.html [9] DESTOUCHE, Jon. BlackBerry is Jammin’ Hope You Like Jammin’ To. In: Pocketberry [online]. 2013 [cit. 2013-11-5]. Dostupné z: http://www.pocketberry.com/2013/05/14/blackberry-is-jammin-hope-you-like-jammin-to/ [10] BRIX, Todd. Windows Phone developer updates & offers from Mobile World Congress. In: Windows [online]. 2013 [cit. 2013-11-5]. Dostupné z: http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/02/25/windows-phonedeveloper-updates-amp-offers-from-mobile-world-congress.aspx [11] THOMPSON, Mattt. IOS 7. In: NSHipster [online]. 2013 [cit. 2013-11-6]. Dostupné z: http://nshipster.com/ios7/ [12] HTML5 compatibility on mobile and tablet browsers with testing on real devices. Mobile HTML5 [online]. 2013 [cit. 2013-11-6]. Dostupné z: http://mobilehtml5.org [13] Dashboards. Android Developers [online]. 2013 [cit. 2013-11-6]. Dostupné z: http://developer.android.com/about/dashboards/index.html 37

[14] Android Fragmentation Visualized. In: OpenSignal [online]. 2013 [cit. 2013-11-6]. Dostupné z: http://opensignal.com/reports/fragmentation-2013/ [15] Mobiles. HTML5TEST how well does your browser support html5? [online]. 2013 [cit. 2013-11-6]. Dostupné z: http://html5test.com/results/mobile.html [16] Programing Language Populatiry [online]. 2012-2013 [cit. 2013-11-6]. Dostupné z: http://langpop.com [17] LOUIS, Tristan. How Much Do Average Apps Make?. In: Forbes [online]. 2013 [cit. 2013-11-6]. Dostupné z: http://www.forbes.com/sites/tristanlouis/2013/08/10/how-muchdo-average-apps-make/ [18] The History of Objective-C. In: Techotopia [online]. 2011 [cit. 2013-11-6]. Dostupné z: http://www.techotopia.com/index.php/The_History_of_Objective-C [19] SINGH, Amit. A Brief History of Mac OS X. In: OSXBook [online]. 2003 [cit. 201311-24]. Dostupné z: http://osxbook.com/book/bonus/ancient/whatismacosx/history.html [20] Private Method Declaration Objective-C. In: Stack Overflow [online]. 2012 [cit. 201311-25]. Dostupné z: http://stackoverflow.com/questions/9414410/private-methoddeclaration-objective-c [21] Objective-C Automatic Reference Counting (ARC). The LLVM Compiler Infrastructure [online]. 2007-2013 [cit. 2013-11-25]. Dostupné z: http://clang.llvm.org/docs/AutomaticReferenceCounting.html#property-declarations [22] Encapsulating Data. Mac Developer Library [online]. 2012 [cit. 2013-11-27]. Dostupné z: https://developer.apple.com/library/mac/documentation/cocoa/conceptual/ProgrammingWi thObjectiveC/EncapsulatingData/EncapsulatingData.html [23] What's New in Xcode. Apple Developer [online]. 2013 [cit. 2013-12-05]. Dostupné z: https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/Whats NewXcode/WhatsNewXcode.pdf [24] Apple Reinvents Its Wheel With iOS 7, Takes Developers Along For The Ride. In: TechCrunch [online]. 2013 [cit. 2013-12-05]. Dostupné z: http://techcrunch.com/2013/09/18/apple-re-invents-its-wheel-with-ios7-takes-developersalong-for-the-ride/ [25] IOS 7 vs iOS 6 Side-by-Side Visual Comparisons. OS X Daily [online]. 2013 [cit. 2013-12-05]. Dostupné z: http://osxdaily.com/2013/06/11/ios-7-vs-ios-6-visualcomparison/ [26] Mantle Reference. In: Cocoadocs [online]. 2013 [cit. 2013-12-22]. Dostupné z: http://cocoadocs.org/docsets/Mantle/1.3/ [27] THOMPSON, Mattt a Scott RAYMOND. AFNetworking Reference. In: Cocoadocs [online]. 2013 [cit. 2013-12-23]. Dostupné z: http://cocoadocs.org/docsets/AFNetworking/1.3.3/ 38

[28] IOS 7 UI Transition Guide. In: IOS Developer Library [online]. 2013 [cit. 2014-1224]. Dostupné z: https://developer.apple.com/library/ios/documentation/userexperience/conceptual/transitio nguide/ [29] Mobile application development. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2014-24-12]. Dostupné z: http://en.wikipedia.org/wiki/Mobile_application_development

39

Přílohy Příloha A – změny v iOS 7 V této příloze je ukázka změn uživatelského rozhraní a grafických elementů v iOS 7. Veškeré obrázky a popisky jsou převzaty z webových stránek www.osxdialy.com [25].

Obrázek A.1: Základní obrazovka (z angl. homescreen), Nalevo iOS7 a napravo iOS 6

Obrázek A.2: Základní obrazovka s jiným pozadím, nalevo iOS 7 a napravo iOS 6

40

Obrázek A.3: Aplikace Messages, v iOS 7(vpravo) byly odstraněny bubliny a celkově aplikace vypadá jemněji a čistěji

Obrázek A.4: Notifications center, v levo iOS 6 a v pravo iOS 7

41

Obrázek A.5: Aplikace pro zobrazení počasí, předělaná tak, že vypadá jako populární aplikace od Yahoo, nalevo je opět verze pro iOS 6 a napravo je verze pro iOS 7

Obrázek A.6: Aplikace Siri, vlevo pro iOS 6 a vpravo pro iOS 7

42

Obrázek A.7: Nástroj pro správu běžících aplikací (označovaný jako Multitasking) vypadá úplně jinak pro iOS 6 (nalevo) než pro iOS 7 (napravo)

Obrázek A.8: Aplikace pro správu elektronické pošty, vlevo pro iOS 6 vpravo pro iOS 7

43

Obrázek A.9: Srovnání ikon pro iOS 6 a iOS 7, rozdíly mezi některými jsou tak opravdu velké

44

Obrázek A.10: Porovnání elementů grafického rozhraní pro iOS 6 a iOS 7

45

Příloha B – grafický návrh aplikace Issue manager V této příloze jsou jednotlivé obrazovky aplikace. K některým z nich je přidán popis, co se na dané obrazovce nachází a jaké akce může uživatel vykonat.

Obrázek B.1: Přihlašovací obrazovka, ve výsledné aplikaci není logo webové služby GitHub kvůli autorských právům

46

Obrázek B.2: Návrh obrazovky na výběr repozitářů

Na této obrazovce si může uživatel vybrat repozitáře, které chce sledovat. Tuto volbu lze později libovolně měnit. Potvrzovacím tlačítkem „done“ se dostaneme do hlavní části aplikace. Tato obrazovka se objeví popřihlášení pouze při prvním spuštění aplikace.

47

Vybrané repozitáře se uloží do paměti a při dalším spuštění aplikce se již načtou vybrané repozitáře s úkoly.

Obrázek B.3: Návrh hlavní obrazovky

Na hlavní obrazovce se zobrazují všechny úkoly daného repozitáře pro daného uživatele. Mezi repozitáři lze snadno přepínat pomocí „swipe“ gesta. Pokud chceme změnit repozitáře, které se nám zobrazují, můžeme to udělat pomocí gesta „swipe“(zleva doprava) na prvním repozitáři. Modálně (v tomto případě zleva) zobrazí seznam repozitářů (obrázek 48

B.2). Pokud si aplikaci spustíte, zjistíte že obrazovka výsledné aplikace se do jisté míry liší od původního návrhu. Je to dáno tím, že během vývoje jsem se s týmem Tapmates shodl na některých změnách v prospěch přehlednosti aplikace. Na bocích navigační lišty vidíme dvě tlačítka. Pomocí Tlačítka vlevo se dostaneme do seznamu spolupracovníků (obrázek B.7), kde můžeme změnit uživatele, jehož úkoly sledujeme. Tlačítko vpravo slouží k přidání nového úkolu (obrázek B.5). Poslední akcí kterou může uživatel na této obrazovce provést je otevření detailu úkolu(obrázek B.4). To lze udělat pomocí kliknutí na vybraný úkol. Jeho detail se zobrazí modálně (v tomto případě zespoda).

Obrázek B.4: Detail úkolu

49

Na obrazovce detailu úkolu můžeme vidět oproti seznamu úkolů několik informací navíc. Zobrazí se nám podrobný popis úkolu a uživatel, který úkol vytvořil a kdy ho vytvořil. Pod detailem úkolu se nachází komentáře. Pod nimi je ikonka pro přidání nového komentáře. Na navigační liště se opět nacházejí dvě tlačítka. Jedno slouží jako akce „zpět do seznamu úkolů“ a druhé slouží k uzavření úkolu.

Obrázek B.5: Vytvoření nového úkolu

50

Pomocí této části aplikace můžeme vkládat nové úkoly do daného repozitáře. Povinný je pouze titulek úkolu. Pole Milestone, Assigned a Labels jsou klikací. Po kliknutí vyjede seznam možností (viz obrázek B.6). Pomocí tlačítka POST vytvoříme nový úkol a pomocí CANCEL se vrátíme do hlavního seznamu úkolů.

Obrázek B.6: Výběr spolupracovníka (pro výběr milníku a štítků vypadá obrazovka podobně)

51

Obrázek B.7: Výběr spolupracovníka

Na obrázku B.7 vidíme jednoduchý seznam spolupracovníků. Po kliknutí na jednoho z nich se načtou nové úkoly pro vybraného uživatele. Pokud uživatele měnit nechceme, dostaneme se zpět pomocí kliknutí na pravou část obrazovky (částečně viditelný seznam úkolů).

52

Příloha C – ukázky kódu ze souboru BCIssue.m V této příloze se nachází ukázky kódu objektu BCIssue, který slouží k reprezentaci úkolu na webové službe GitHub.

Obrázek C.1: Inicializační metoda pro reprezentaci prázdného repozitáře

Metodu z obrázku 4.1 volám v souboru BCIssueViewController.m v případě, že repozitář neobsahuje žádné úkoly pro vybraného uživatele. Je to jednoduchý a elegantní způsob jak vyřešit zobrazení prázdného repozizáře.

Obrázek C.2: Metoda copyWithZone

Pomocí metody copyWithZone: specifikujeme jak se má kopírovat objekt dané třídy. Metoda copyWithZone: slouží k vytvoření hluboké kopie objektu. Parametr zone se dnes již moc nepoužívá, o to v jaké zóně se kopíruje se stará běhové prostředí.

53

Obrázek C.3: Metoda dateFormatter

Pomocí metody dateFormatter specifikujeme jak se mají převést data z JSONu na objekt NSDate a naopak.

Obrázek C.4: Transformační metoda updatedAtJSONTransformer

Transformační metoda updatedAtJSONTransformer využívá k transformaci dat metodu dateFormatter.

Obrázek C.5: Transformační metoda labelsJSONTransformer

Pomocí metody labelsJSONTransformer můžeme převádět data z JSONu na objekty BCLabel a naopak. V bloku ForwardBlock je nainicializováno měnitelné pole, do kterého přidáváme

objekty

BCLabel,

modelOfClass:fromJSONDictionary:error:

jenž třídy

vytváříme

pomocí

MTLJSONAdapter.

metody V blocku

reverseBlock opět vytváříme měnitelné pole, které plníme objekty třídy NSDictionary.

54

Obrázek C.6: Transformační metoda htmlUrlJSONTransformer

Jednoduchá transformační metoda pro převod dat z JSONu na objekt typu NSURL.

Obrázek C.7: Transformační metoda assigneeJSONTransformer

Jednoduchá transformační metoda pro převod dat z JSONu na objekt typu BCUser. Metodě

mtl_JSONDictionaryTransformerWithModelClass:

předáváme

model

třídy

BCUser, pomocí něhož se provede převod.

55

Příloha D – ukázky kódu ze seznamu pro výběr spoluracovníků Příloha D obsahuje zdrojové kódy a jejich vysvětlení. Ty se do čtvrté kapitoly nevlezly kvůli jejich velikosti.

Zdrojový kód modelu (BCSelectAssigneeDataSource.h a BCSelectAssigneeDataSource.m)

Obrázek D.1: Hlavičkový soubor BCSelectAssigneeDataSource.h

V hlavičkovém souboru definujeme svou třídu, která reprezentuje model pro naši budoucí tabulku spolupracovníků. BCSelectAssigneeDataSource dědí ze základního objektu NSObject a je v souladu s protokolem UITableViewDataSource. Díky souladu s protokolem může být instance třídy BCSelectAssigneeDataSource nastavena jako properta dataSource objektu třídy UITableView. Dále je v hlavičkovém souboru jen deklarace property collaborators a inicializační metoda.

56

Obrázek D.2: Implementační soubor BCSelectAssigneeDataSource.m

Na obrázku D.2 vidíme implementaci modelu pro naši budoucí tabulku. Implementační metoda je jednoduchá, pouze nainicializujeme pole a naplníme jej hodnotami. Za ní následuje metoda tableView:cellForRowAtIndexPath:, která slouží k tvorbě

jednotlivých

buněk

tabulky.

Poslední

je

metoda

tableView:numberOfRowsInSection:, jež vrací počet řádků v dané sekci. Pokud má mít tabulka více sekcí, je nutné implementovat metodu numberOfSectionsInTableView:. Pokud metoda není implementována, bude mít tabulka jednu sekci. Zdrojový kód buňky tabulky (BCSelectAssigneeCell.h a BCSelectAssigneeCell.m) Dalším prvkem nezbytným pro vytvoření seznamu spolupracovníků, ze kterého můžeme vybírat, je buňka tabulky. 57

Obrázek D.3: Hlavičkový soubour BCSelectAssigneeCell.h

Instance třídy BCSelectAssigneeCell reprezentuje buňku tabulky. Vlastnosti buňky dědí z rodičovské třídy UITableViewCell. My ale potřebujeme, aby buňka naší tabulky vypadala jinak, než jak vypadá instance třídy UITableViewCell. Proto naši třídu BCSelectAssigneeCell upravíme tak, že jí přidáme nové property, díky kterým budeme moct vzhled buňky přizpůsobit našim potřebám. První přidanou propertou je separatorImgView, která nám slouží k zobrazení linky, jež odděluje jednotlivé buňky. Pomocí propertě avatarImgView můžeme vykreslit avatara uživatele (obrázek který reprezentuje uživatele). Properta avatarImgView je podtřídou UIImageView a rozšiřuje tuto třídu tak, že přidává kolem obrázku masku, jež nám ořezává obrázek (dělá zakulacené okraje kolem obrázku). Další propertou je myTextLabel. Díky ní můžeme do buňky snadno vložit jméno uživatele a upravit ji podle našich potřeb. Poslední properta se jmenuje checkboxImgView. Do této property uložíme obrázek zaškrtávacího políčka, který později vykreslíme.

Obrázek D.4: Definice konstant na začátku implementačního souboru BCSelectAssigneeCell.m

58

Obrázek D.5: Tovární metoda třídy BCSelectAssigneeCell

Pomocí tovární metody createAssigneCellWithTableView: vytváříme buňku pro naši tabulku. V případě že už máme instanci naší tabulky vytvořenou, vracíme již vytvořenou buňku, kterou získáme pomocí metody dequeReusableCellWithIdentifier:. V případě, že buňku ještě vytvořenou nemáme, ji na řádku 38 vytvoříme (naalokujeme pamět a nainicializujeme objekt třídy BCSelectAssigneCell). Na řádku 41 vložíme do property chechboxImgView instanci objektu UIImageView, které nastavíme obrázky zaškrtávacího políčka (jeden pro nezaškrtnutý stav a druhý pro zaškrtnutý stav). Na řádku 42 přidáme tento objekt jako „subview“ buňky; tím umožníme vykreslení obrázku uvnitř buňky. Kdybychom ho do buňky jako subview nepřidali, tak by sice obrázek zaškrtávacího políčka existoval, ale nikde by se nevykreslil. Dále v textu budeme slovo subview používat v tomto smyslu. Podobně to uděláme i s propertou pro obrázek avatara a separátoru (obrázek sloužící k oddělení buněk). Abychom mohli do property myTextLabel později vložit jméno uživatele, musíme už teď danou propertu inicializovat a nastavit požadované vlastnosti (font, barvu textu, barvu pozadí) a přidat ji jako subview do buňky. Samotný obrázek

avatara

a

jméno

uživatele

přiřazujeme

buňce

později

v

metodě

tableView:cellForRowAtIndexPath: v souboru BCSelectAssigneDataSource.m. Nakonec 59

ještě buňce nastavíme barvu označené buňky na průhlednou, protože chceme, aby označená buňka kromě obrázku zaškrtávacího políčka vypadala stejně jako neoznačená.

Obrázek D.6: Metoda layoutSubviews třídy BCSelectAssigneeCell

Pomocí metody layoutSubviews se rozmisťují jednotlivá subviews daného objektu. Tuto metodu implementují potomci třídy UIView. Tato třída a její potomci jsou při tvorbě iOS aplikací používáni pro interkaci s uživatelem. Více o této třídě se můžete dovědět z dokumentace. Metoda layoutSubviews je volána samovolně (nikdy se nesmí volat přímo). Pokud si chceme vynutit zavolání metody layoutSubviews, pošleme dané třídě zprávu setNeedsLayout

nebo

layoutIfNeeded.

Rozvržení

jednotlivých

subviews

třídy

BCSelectAssigneeCell děláme tak, že objektu frame vždy nastavíme hodnoty, jaké by měl mít daný prvek grafického rozhraní, a pokud se rám daného prvku od nově vytvořeného rámu liší, tak ho danému prvku přiřadíme.

60

Zdrojový kód pohledu tabulky (BCSelectAssigneeView.h a BCSelectAssigneeView.m)

Obrázek D.7: Hlavičkový soubor BCSelectAssigneeView.h

Podobně jako u třídy BCSelectAssigneCell si i ve třídě BCSelectAssigneView deklarujeme property, které nám umožní upravit vzhled aplikace. Properta tableView slouží

k uchovávání

samotné

tabulky

(instance

třídy

UITableView).

Propertu

backgroungImageView používáme k uchování a vykreslení pozadí obrazovky. Properta navigationBarView funguje jako rám pro tlačítka cancelButton, doneButton a pro nadpis, který je uložen v propertě theNewIssueLabel. Poslední propertou definovanou ve třídě BCSelectAssigneeView je properta form. Do ní uložíme obrázek rámečku tabulky (ohraničení tabulky).

Obrázek D.8: Definice konstant na začátku implementačního souboru BCSelectAssigneeView.m

61

Obrázek D.9: První část inicializační metody třídy BCSelectAssigneeView

Obrázek D.10: Druhá část inicializační metody třídy BCSelectAssigneeView

62

Obrázek D.11: První část metody layoutSubviews třídy BCSelectAssigneeView

Obrázek D.12: Druhá část metody layoutSubviews třídy BCSelectAssigneeView

K obrázkům D.9 až D.12 již není třeba žádný komentář, vše podstatné k těmto metodám bylo napsáno u předešlé třídy BCSelectAssigneeCell.

63

Zdrojový kód řadiče tabulky (BCSelectAssigneeViewController.h a BCSelectAssigneeViewController.m)

Obrázek D.13: Hlavičkový soubor BCSelectAssigneeViewController.h

V hlavičkovém souboru BCSelectAssigneeViewController.h jsou deklarovány privátní atributy a veřejnou inicializační metodu initWithController:. Atributy _selectAssigneeView a _dataSource nám slouží k uložení objektů tříd, které byly popsány výše. Do atributu _controller si při inicializaci uložíme řadič, jenž vyvolal inicializační metodu této třídy. Atribut _checkedAssignee nám slouží k uchování informace o tom, který uživatel je vybrán.

64

Obrázek D.14: Začátek implementačního souboru BCSelectAssigneeViewController.m

Jako první je ve třídě BCSelectAssigneeViewController implementována inicializační metoda initWithController:, která uloží řadič, který inicializaci vyvolal. Druhá implementovaná metoda ve třídě BCSelectAssigneeViewController je metoda loadView. V ní je inicializován pohled (prvek „view“ z modelu MVC). Na dalším řádku přiřazujeme tabulce delegáta (v tomto případě samotný řadič) a nakonec řadiči na řádku číslo 33 tento pohled nastavíme. Na dalších dvou řádcích jsou tlačítkům nastaveny akce, které se mají provést po tom, co na ně uživatel klikne. Na posledním řádku volám privátní metodu createModelWithCollaborators:withCheckedAssignee: pomocí které vytvářím model tabulky.

65

Obrázek D.15: Metody createModelWithCollaborators:withCheckedAssignee: a getIndexPathOfOassignee

Obrázek D.15 začíná implementací createModelWithCollaborators:withCheckedAssignee:. V této metodě inicializujeme model tabulky (často nazývaný jako data-source) a tabulce ho přiřazujeme. V druhé části metody zjišťujeme, zdali je už nějaký uživatel vybrán a pokud ano, nastavíme ho do atributu _checkedAssignee a zaškrtneme příslušnou buňku tabulky. Metoda getIndexPathOfAssignee vrací index, na kterém se nachází daný uživatel.

Obrázek D.16: Metody cancelButtonDidPress a doneButtonDidPress

66

Obrázek D.17: Metoda tableView:didSelectRowAtIndexPath:

Pomocí metody na obrázku D.17 zajišťujeme správné chování tabulky. Nativní chování je totiž odlišné od toho, které je požadováno. Nativně se tabulka chovala tak, že pokud byl zaškrtnutý jeden ze spolupracovníků a uživatel chtěl zaškrtnout jiného spolupracovníka, musel by nejdříve odškrtnout toho, co byl již zaškrtnutý a poté by šlo zaškrtnout nového. Navíc také po použití metody selectRowAtIndexPath: nešlo daný řádek odškrtnout.

Příloha E – Elektronické přílohy Elektronicke prilohy/IssueManager – zdrojový kód celé aplikace Elektronicke prilohy/text – text práce ve formátu PDF

67