18+ věcí, které by měl dobrý iOS vývojář zvládat

Začátky jsou vždy v každém oboru nejtěžší a hodně času zabere se vůbec v tématu zorientovat. Jinak tomu není i pří vývoji na iOS zařízení. Proto jsme vytvořili článek pro ty, kteří své znalosti teprve budují. Tento krátký dokument shrnuje, co potřebuje každý iOSák znát.

V článku najdete všechny základní oblasti vývoje, od výběru vývojového prostředí, architektury aplikace, tvorby UI, po monitorování aplikací nasazených v AppStore. Článek zároveň obsahuje mnoho odkazů na další relevantní zdroje ke každému tématu.

Pokud tě téma zaujala a jsi iOSák, co se rád učí a pracuje na sobě, tak to můžeš vyzkoušet s námi na pozici iOS vývojářa do našeho SKOUMAL remote-first týmu pro zakázkový vývoj! Ať už jsou tvé zkušenosti jakékoliv, tak ti určitě najdeme místo. Co nabízíme jsme shrnuli i pro tyinternety.cz.

iOS článek je rozdělen do přehledných "kapitol". Najdi si co potřebuješ.
 

Seznam kapitol:

• IDE
• Swift
• Reaktivní programování
• Architektura
• Návrhové vzory
• UI – UIKit
• Animace
• Grand Central Dispatch
• Notifikace
• Networking
• Databáze
• Profiling
• Podepisování
• Build konfigurace
• Správa verzí
• Package management
• Monitorování
• Mailing listy

IDE

Hned na začátek se musí každý rozhodnout v jakém prostředí vlastně iOS aplikace psát. Pro nativní vývoj má cenu porovnávat pouze dvě vývojová prostředí, jedno od Apple a druhé od JetBrains.

Xcode

Výchozí prostředí pro většinu iOS vývojářů. V poslední verzi (9 v době psaní článku) už je opět celkem stabilní, při práci v předchozích verzích musel mít člověk pevné nervy. Přesto podpora pro Swift stále není ani zdaleka tak dobrá jako pro Objective-C. Nová verze přichází s každou další iterací jazyka Swift (jednou ročně). Nevýhodou je rychlost, s jakou Apple zastarává starší verze Swiftu (například poslední Xcode podporuje pouze Swift 3.2 a novější). Jakmile se potom objeví chyba v nějaké starší aplikaci a je na vás ji opravit, strávíte nejdřív hodiny převodem do posledního Swiftu, opravou závislostí a dalších chyb, které tím vzniknou.

AppCode

JetBrains jsou známí svými výbornými IDE pro Java, potažmo Android development. Ani AppCode není výjimkou, jedna zásadní výtka tu ale je. Neobsahuje totiž možnost editovat Storyboardy (o nich více v sekci UI), takže stejně nakonec potřebujete i Xcode (pokud tedy UI nepíšete přímo v kódu). A střídat neustále dvě prostředí se nikomu moc nechce.

Swift

The Swift Programming Language Skvělá dokumentace jazyka přímo od Apple. Průběžně ji aktualizují, v tuto chvíli je pro verzi 4. Lze v ní i vyhledávat nebo stáhnout jako e-book. Občas, když si nejsem jistý jak nějaká konstrukce vypadá ve Swiftu (např. po pár dnech programování v C++), je tohle první místo kde hledám.

Protocol oriented development

Zajímavý přístup k programování, který je pro Swift celkem specifický. Pro pochopení POP je potřeba nejdřív rozumět vlastnostem Swiftu jako jsou protocoly a extensions. Články: 1 2

Reaktivní programování

Velmi populární trend na mobilních platformách (ale i jinde) je reactive programming. Je založené na asynchronním programování a práci s proudy dat. Ve swiftu se dá použít RxSwift a ReactiveSwift . V žádné reálné iOS aplikaci jsme ho zatím nepoužili, ale naši Android programátoři si tento přístup chválí.

Architektura

MVC (Model-View-Controller)

Apple pro iOS zvolil tuto architekturu . V případě iOS jsou ale view a controller hodně úzce spjaty a to pak vede k tomu, že se většina kódu nachází v UIViewController (často jsou to stovky řádků kódu). Je ale potřeba si uvědomit, že ať už zvolíme jakoukoliv architekturu, vždy budeme muset pracovat s MVC, protože samotný UIKit používá dělení na View a Controller.

MVVM (Model-View-ViewModel)

Tuto architekturu používáme prakticky ve všech našich projektech a zatím nám to vyhovuje. Pro úvod do této architektury doporučím například tento článek. Existuje samozřejmě mnoho dalších, kluci na Androidu používají například MVP.

Návrhové vzory

Návrhové vzory patří samozřejmě mezi jednu ze základních znalostí každého programátora, takže asi nemá cenu je detailně rozebírat v článku zaměřeném na iOS development. Zmíním tu alespoň dva, které se na této platformě nejvíce objevují. Singleton – Neslavný návrhový vzor, ale Apple ho používá asi ve všech svých frameworks, takže se mu žádný iOS vývojář nevyhne. Delegate – Opět velmi používaný, takové protokoly končí názvem Delegate nebo DataSource (např. UITableViewDelegate). Tyto protokoly implementujeme a další objekty na ně poté delegují práci, nebo od nich získávají touto cestou data.

UI – UIKit

K tvorbě UI na iOS slouží framework UIKit. Ten obsahuje všechny prvky UI které na iOS používáme.

Auto-layout

Samotné UI se vytváří na rozdíl od Androidu v grafickém editoru, tzv. Interface Builder (IB). Ten je součástí Xcode a automaticky se otevře pokud v projektu klikneme na jakýkoliv Storyboard. Pomocí vztahů mezi jednotlivými UIView definujeme jak bude výsledné UI vypadat. Těmto vztahům říkáme constraint (třída NSLayoutConstraint). Chvíli zabere se ve všech constraints zorientovat, ale po čase už to jde úplně automaticky. Články věnující se auto-layout: 1, 2 UI lze vytvářet také z kódu (existuje mnoho knihoven které ulehčují práci s constraints, např. SnapKit. Výhodou je lehčí práce ve více lidech, protože se vyhneme konfliktům ve storyboardech. Osobně preferuji vizuální reprezentaci kterou vidím v IB, takže tento přístup nepoužíváme. Lepším řešením konfliktů ve storyboardech je rozdělit aplikaci po jednotlivých screenech do vlastních souborů (mezi storyboardy lze vytvářet odkazy pomocí Storyboard Reference).

Pojmy

• Storyboard je soubor, který obsahuje jednu nebo více obrazovek aplikace. My aplikace nejčastěji dělíme do většího množství storyboardů, a to kvůli git konfliktům (mergovat storyboardy většinou není vůbec legrace).
• UIViewController si lze představit jako jednu obrazovku aplikace (mohou být i vnořené UIViewControllery, často se to ale nestává). Patří mu vždy jedno UIView, což už je skutečné UI které vidí uživatel.
• UIView je základní blok uživatelského rozhraní na iOS. Dědí z něj složitější prvky jako UILabel, UIImageView, UITableView apod. Přidáváním těchto subview vytváříme UI aplikace.

Doporučuji si projít tento materiál od Applu. Důležité věci jsou: různé druhy view controllerů (UINavigationController, UITableViewController, UITabBarController a další), životní cyklus (viewDidLoad, viewWillAppear, viewDidAppear atd.).

Size Classes

Displeje iOS zařízení jsou rozdělené do několika tříd (compact, regular). V interface builderu je možné definovat různé UI pro různé velikostní třídy.

Guidelines

Při tvorbě aplikací je také dobré řídit se Apple Human Interface Guidelines, a pokud nějaká část našeho UI těmto pokynům odporuje, pokusit se ji předělat.

Animace

UIKit má velmi dobrou zabudovanou podporu pro animace. Animovat můžeme různé vlastnosti UIView, jejich seznam je zde. Animace se provádí v blocích, pro které definujeme trvání, easing funkci a podobně. Dobré shrnutí všech možností je v článku od Mathew Sanserse (na blogu má i další skvělé články zaměřené na animace a přechody, doporučuji přečíst všechny). Často chceme vytvořit nějaké složitější animace, synchronizovat více navazujících efektů a podobně. K tomu slouží CAAnimation (respektive podtřídy) a CATransaction. Teprve s těmito třídami můžeme využít celou sílu frameworku CoreAnimation.

Grand Central Dispatch

Zkráceně GCD, umožňuje vykonávat práci na různých vláknech procesoru (Dispatch). Nejjednodušší a relativně časté použití je, když potřebujeme z nějakého callbacku (zavolaného na vedlejším vlákně) provést kód modifikující UI, nebo pracovat s Core Data. Dispatch umožňuje jedním řádkem kódu vložit práci do fronty hlavního vlákna.

Operation

Na vyšší úrovni můžeme použít také Operation a OperationQueue, které zapouzdřují GCD volání. V mnoha případech, kdy provádíme složitější práci na pozadí aplikace, použijeme právě tyto prostředky.

Notifikace

Na iOS rozlišujeme dva druhy notifikací: vzdálené a lokální. Popis je zde, novější zde. Notifikace mohou být doručeny i když je aplikace na pozadí, v takovém případě ji systém probudí a dostane omezený čas na reakci (více zde). Při práci s notifikacemi je třeba počítat s tím, že jejich doručení není spolehlivé a žádná kritická data bychom tímto způsobem neměli doručovat.

Networking

Ve Foundation frameworku najdeme několik tříd pro HTTP requesty (URLRequest, URLSession). Pokud potřebujeme provést jeden požadavek, mohou být dostačující. Pokud chceme kompletní řešení, používáme knihovnu Alamofire.

Databáze

CoreData

Nativní databázový framework vyvíjený Applem. Nejčastěji pro ukládání dat používá SQLite databázi, se kterou ale programátor přímo nepracuje. Určitě se vyplatí podívat, jak se Core Data používá a hlavně jaká jsou omezení (přístup z více vláken), protože ta se často týkají i dalších databázových knihoven na iOS (např. oblíbený Realm). CoreData vyžaduje trochu delší setup než jiné knihovny. Je potřeba vytvořit objekty které chceme uchovávat pomocí editoru integrovaného v Xcode. CoreData stále používáme i v nových projektech, protože je ověřené a spolehlivé. Další oblíbené: Realm, Couchbase Mobile (NoSQL)

Firebase

Firebase jsou nástroje od Googlu, z nichž většina cílí právě na mobilní aplikace. Je dobré alespoň tušit, jaké produkty tam jsou a kdy by se mohly hodit (realtime database, remote config a další, máme o tom dokonce video).

Profiling

Xcode zahrnuje řadu velmi užitečných nástrojů pro profilování aplikací – Instruments. Součástí je řada různých profilů, každý nám pomůže odhalit jiný druh problémů a sledovat jiné statistiky (např. memory leaks, network a další).

Podepisování

Než může být aplikace nainstalována na zařízení nebo vypuštěna na App Store, musíme ji podepsat certifikátem. Ke generování certifikátů a profilů slouží web developer.apple.com , nejnovější Xcode dokáže vytváření certifikátů a profilů provádět zcela automaticky.

Build konfigurace

Často je v průběhu vývoje potřeba pro různé skupiny lidí připravit build v různém stádiu. Pro tento účel používáme označení různých verzí aplikace:

• alpha – pouze interně v týmu, pro testera apod.
• beta – k otestování zákazníkem
• release – build který odpovídá verzi která je připravená k vypuštění

V Xcode si pro každou verzi vytvoříme konfiguraci (Project -> Info -> Configurations) v nastavení projektu. Pro každou konfiguraci lze poté nastavit jiné hodnoty v nastavení projektu, takže takto modifikujeme například Bundle Identifier nebo Display Name. Nakonec je potřeba vytvořit pro každou verzi schéma (Scheme) a v nastavení schématu vybrat pro sestavení odpovídající konfiguraci. Díky těmto nastavením můžeme mít na zařízení nainstalované i 3 různé verze současně a podle názvu je snadno rozlišíme. Aby mohla být aplikace na jednom iOS zařízení nainstalovaná vícekrát, musí mít odlišná Bundle Id. Za bundle id aplikace přidáváme suffix odpovídající konfiguraci, tzn. pokud sestavuji alpha konfiguraci, aplikace má bundle id ve formátu com.company.name.alpha.

Správa verzí

Nebudu tu popisovat jak pracovat s Gitem, materiálů je k tomu už spousta. Zmíním ale alespoň aplikace pro práci s gitem, které na macOS používáme. V obou případech je samozřejmostí integrace s Githubem i Bitbucketem (ten používáme my).

SourceTree

Vyvíjený přímo společností Atlassian (Bitbucket, Trello, Jira). Je zdarma i pro komerční využití, takže bude asi pro většinu lidí jednoduchou volbou.

GitKraken

Uživatelské rozhraní je velmi podobné SourceTree, ale některé funkce mi zde vyhovovaly více (především vestavěné řešení konfliktů), takže ho preferuji před SourceTree. Licence pro komerční využití je zpoplatněná.

Package management

V minulosti jsme pro stahování a instalaci knihoven používali CocoaPods. Problém s CocoaPods je, že zásadně zasahuje do Xcode projektu a to se nám nelíbilo. Naštěstí existuje Carthage, které pro spravování knihoven doporučujeme. Je možné, že v budoucnu začneme používat Swift Package Manager, který už také pomalu dospívá.

Monitorování

Když někomu aplikace spadne, chceme se o tom dozvědět ideálně jinak, než negativní recenzí na App Store. Naštěstí k účelu monitorování aplikace existují speciální knihovny. My používáme Fabric (nedávno koupený Googlem, takže je možné, že se časem stane součástí Firebase). Jakmile uživateli spadne aplikace, dokáže knihovna na server odeslat na jakém řádku spadla, typ zařízení a další užitečná data. Tohle všechno nám pak pomůže rychleji chybu zreplikovat a opravit. Další užitečnou součástí Fabricu jsou Answers. Ty umožňují sbírat obecné statistiky o užívání aplikace (kolik lidí, jak dlouho ji použilo a mnoho dalších) a také trackovat jakékoliv vlastní události.

Mailing listy

Mailing listy které posílají každý týden souhrn článků, nových knihoven, trendů apod. jsou velmi dobrý zdroj informací. Pro iOS vývojáře považuji za nejdůležitější iOS Dev weekly. 

Chceš víc?

Chtěl bys číst více článků nebo se rovnou stát součastí tímu? Pokud chceš nahlédnout pod pokličku, sdílej s námi svůj mail nebo nám jeden rovnou pošli.  Chci víc

Nakoukni!

Jak hledáme vývojáře do našeho týmu? Vláďa to prozradil v jedné z jeho přednášek pro xPORT VŠE Business Accelerator!