uživatelská rozhraní iOS: storyboardy vs. NIBs vs. vlastní kód

často slyším, jak vývojáři iOS kladou nějakou variantu stejné klíčové otázky:

jaký je nejlepší způsob, jak vytvořit uživatelské rozhraní v systému iOS: prostřednictvím storyboardů, hrotů nebo kódu?

odpovědi na tuto otázku, explicitně nebo implicitně, mají tendenci předpokládat, že existuje vzájemně se vylučující volba, která je často řešena předem, před vývojem.

jsem toho názoru, že odpověď by měla mít podobu jedné nebo více protikladných otázek.

jaké je „nejlepší“ auto?

dovolte mi to vysvětlit příkladem mimo téma. Řekněme, že chci koupit auto a zeptám se vás na jednu jednoduchou otázku: „Jaká je nejlepší volba?“

můžete opravdu odpovědět tím, že navrhnete model nebo dokonce značku? Není pravděpodobné, pokud nenavrhnete Ferrari. Namísto, pravděpodobně byste odpověděli několika dalšími otázkami, jako:

• jaký je váš rozpočet?
• kolik míst potřebujete?
• záleží vám na spotřebě paliva?
• jak se cítíte o sportovních vozech?

je zřejmé, že neexistuje nic jako dobré nebo špatné auto, pokud není umístěno ve správném kontextu—existuje jen dobré nebo špatné auto založené na konkrétních potřebách.

zpět na iOS UI Design

stejně jako u našeho dotazu na auto, otázka „Jaký je nejlepší způsob, jak vyvinout iOS UI“, postrádá kontext. A překvapivě dost, odpověď nemusí být případ catch-all.

obecně řečeno, existují tři typy přístupů k návrhu uživatelského rozhraní, které můžete využít, každý s jeho klady a zápory, jeho fanoušky a nenávisti:

• iOS storyboardy: vizuální nástroj pro rozložení více pohledů aplikací a přechodů mezi nimi.
• NIBs (nebo XIBs): každý soubor hrotu odpovídá jedinému prvku zobrazení a může být rozložen ve staviteli rozhraní, což z něj činí také vizuální nástroj. Všimněte si, že název „hrot“ je odvozen od přípony souboru (dříve .hrot a teď .xib, ačkoli stará výslovnost přetrvávala).
• vlastní kód: tj. žádné nástroje GUI, ale spíše zpracování všech vlastních polohování, animací atd. programově.

žádná z těchto možností není univerzálně lepší než jakákoli jiná (navzdory tomu, co můžete slyšet).

storyboardy jsou například nejnovějším přírůstkem do sady nástrojů iOS UI. Bylo mi řečeno, že jsou budoucnost, že nahradí hroty a vlastní kód UIs. Storyboardy vidím jako užitečný nástroj, ale ne tak náhradu jako doplněk pro hroty a vlastní kód. Storyboardy jsou tou správnou volbou v některých, ale ne ve všech situacích.

dále, proč byste se měli staticky držet jedné možnosti, když je můžete použít všechny (ve stejném projektu)a vybrat mechanismus, který nejlépe vyhovuje konkrétnímu problému?

to je otázka, kterou lze podle mého názoru zobecnit na vyšší úrovni a jejíž odpověď je vysoce hodnocena v mém seznamu principů vývoje softwaru: neexistuje univerzální jazyk, rámec nebo technologie, která by byla univerzální nejlepší volbou pro každý problém vývoje softwaru. Totéž platí pro iOS UI design.

v tomto výukovém programu pro vývoj iOS prozkoumáme každou z těchto metod a představíme případy použití, ve kterých by měly a neměly být použity, a způsoby, jak je lze kombinovat.

iOS storyboardy

klasickou chybou začátečníka je vytvořit jeden masivní Projektový scénář iOS. I já jsem udělal tuto chybu, když jsem poprvé začal pracovat se storyboardy (pravděpodobně proto, že je to lákavá cesta).

jak název napovídá, Storyboard je deska s příběhem, který má vyprávět. Nemělo by se používat k míchání nesouvisejících příběhů do jednoho velkého svazku. Storyboard by měl obsahovat řadiče zobrazení, které jsou logicky vzájemně propojeny—což neznamená každý řadič zobrazení.

například má smysl používat storyboardy při manipulaci:

• sada pohledů pro autentizaci a registraci.
• vícestupňový tok zadávání objednávek.
• tok podobný průvodci (tj.
• master-detail sada pohledů (např. Seznamy profilů, detaily profilu).

mezitím je třeba se vyhnout velkým Storyboardům, včetně jednotlivých storyboardů pro celou aplikaci(pokud není aplikace relativně jednoduchá). Než půjdeme hlouběji, uvidíme proč.

pošetilost velkých scénářů iOS

Velké scénáře, kromě toho, že je obtížné procházet a udržovat, přidávají do týmového prostředí vrstvu složitosti: když více vývojářů pracuje na stejném souboru scénáře současně, konflikty řízení zdroje jsou nevyhnutelné. A zatímco storyboard je interně reprezentován jako textový soubor (ve skutečnosti soubor XML), sloučení je obvykle netriviální.

když vývojáři vidí zdrojový kód, připisují mu sémantický význam. Takže při manuálním slučování jsou schopni číst a rozumět oběma stranám konfliktu a podle toho jednat. Storyboard je místo toho soubor XML spravovaný Xcode a význam každého řádku kódu není vždy snadno pochopitelný.

Vezměme si velmi jednoduchý příklad: řekněme, že dva různí vývojáři změní pozici UILabel (pomocí autolayout), a ten tlačí jeho změnu, produkovat konflikt, jako je tento (všimněte si konfliktní id atributy):

<layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides><layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides>

samotný id neposkytuje žádný náznak o jeho skutečném významu, takže nemáte s čím pracovat. Jediným smysluplným řešením je vybrat jednu ze dvou stran konfliktu a druhou zlikvidovat. Budou existovat vedlejší účinky? Kdo ví? Ty ne.

pro usnadnění těchto problémů s návrhem rozhraní iOS je doporučeným přístupem použití více storyboardů ve stejném projektu.

kdy použít storyboardy

storyboardy se nejlépe používají s více propojenými řadiči zobrazení, protože jejich hlavní zjednodušení spočívá v přechodu mezi řadiči zobrazení. Do jisté míry je lze považovat za složení hrotů s vizuálními a funkčními toky mezi řadiči zobrazení.

kromě usnadnění navigačního toku je další nespornou výhodou, že eliminují kód boilerplate potřebný k pop, push, present a dismiss view controllers. Kromě toho jsou řadiče zobrazení automaticky přiděleny, takže není třeba ručně alloc a init.

a konečně, zatímco storyboardy se nejlépe používají pro scénáře zahrnující více řadičů zobrazení, je také obhajitelné použít Storyboard při práci s jedním řadičem zobrazení tabulky ze tří důvodů:

• schopnost navrhovat prototypy stolních buněk na místě pomáhá udržet kousky pohromadě.
• více šablon buněk může být navrženo uvnitř nadřazeného regulátoru zobrazení tabulky.
• je možné vytvořit statické zobrazení tabulky (dlouho očekávaný doplněk, který je bohužel k dispozici pouze ve storyboardu).

Dalo by se tvrdit, že více šablon buněk lze také navrhnout pomocí hrotů. Ve skutečnosti je to jen otázka preference: někteří vývojáři dávají přednost tomu, aby měli vše na jednom místě, zatímco jiní se nestarají.

kdy nepoužívat storyboardy iOS

několik případů:

• pohled má komplikované nebo dynamické rozvržení, nejlépe implementované s kódem.
• pohled je již implementován s hroty nebo kódem.

v těchto případech můžeme buď nechat pohled mimo scénář, nebo jej vložit do ovladače zobrazení. První z nich narušuje vizuální tok scénáře, ale nemá žádné negativní funkční nebo vývojové důsledky. Ten si zachovává tento vizuální tok, ale vyžaduje další vývojové úsilí, protože pohled není integrován do řadiče zobrazení: je pouze vložen jako součást, a proto musí řadič zobrazení interagovat s pohledem, spíše než jej implementovat.

obecné výhody a nevýhody

Nyní, když máme smysl pro to, kdy jsou storyboardy užitečné při návrhu uživatelského rozhraní iOS, a než se v tomto tutoriálu přesuneme k hrotům, projdeme jejich obecné výhody a nevýhody.

pro: výkon

intuitivně můžete předpokládat, že když je načten Storyboard, všechny jeho řadiče zobrazení jsou okamžitě instancovány. Naštěstí je to jen abstrakce a neplatí o skutečné implementaci: místo toho je vytvořen pouze počáteční řadič zobrazení, pokud existuje. Ostatní řadiče zobrazení jsou instance dynamicky, a to buď při segue se provádí nebo ručně z kódu.

pro: prototypy

storyboardy zjednodušují prototypování a zesměšňování uživatelských rozhraní a toku. Ve skutečnosti lze kompletní funkční prototypovou aplikaci s pohledy a navigací snadno implementovat pomocí storyboardů a několika řádků kódu.

Con: opětovná použitelnost

pokud jde o přesun nebo kopírování, scénáře iOS jsou špatně umístěny. Storyboard musí být přesunut spolu se všemi jeho závislými řadiči zobrazení. Jinými slovy, jeden řadič pohledu nemůže být jednotlivě extrahován a znovu použit jinde jako jediná nezávislá entita; je závislý na fungování zbytku scénáře.

Con: datový tok

při přechodu aplikace je často nutné předávat data mezi řadiči zobrazení. Vizuální tok scénáře je však v tomto případě přerušen, protože v nástroji pro tvorbu rozhraní není žádná stopa. Storyboardy se starají o manipulaci s tokem mezi řadiči zobrazení, ale ne tok dat. Cílový řadič tedy musí být nakonfigurován s kódem, který přepíše vizuální zážitek.

v takových případech se musíme spolehnout na prepareForSegue:sender, s kostrou if / else-if, jako je tato:

- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = ; if ("segue_name_1"]) { MyViewController *vc = (MyViewController *) ; ; } else if ("segue_name_2"]) { ... } else if ...}

považuji tento přístup za náchylný k chybám a zbytečně podrobný.

hroty

hroty jsou Starý(er) způsob, jak provádět návrh rozhraní iOS.

v tomto případě „Starý „neznamená“ špatný“,“ zastaralý „nebo“zastaralý“. Ve skutečnosti je důležité pochopit, že scénáře iOS nejsou univerzální náhradou za hroty; v některých případech zjednodušují implementaci uživatelského rozhraní.

s hroty lze navrhnout libovolný pohled, který může vývojář podle potřeby připojit k řadiči zobrazení.

pokud použijeme objektově orientovaný design na naše UIs, pak má smysl rozdělit pohled řadiče zobrazení na samostatné moduly, z nichž každý je implementován jako pohled s vlastním souborem hrotu (nebo s více moduly seskupenými do stejného souboru). Jasnou výhodou tohoto přístupu je, že každá komponenta se snáze vyvíjí, snáze testuje a snáze ladí.

hroty sdílejí problémy s konfliktem sloučení, které jsme viděli se storyboardy, ale v menší míře, protože soubory hrotu pracují v menším měřítku.

kdy použít hroty pro návrh uživatelského rozhraní iOS

podmnožina všech případů použití by byla:

• modální zobrazení
• jednoduché přihlašovací a registrační zobrazení
• nastavení
• vyskakovací okna
• opakovaně použitelné šablony zobrazení
• opakovaně použitelné šablony tabulkových buněk

mezitím…

pokud nepoužíváte hroty

měli byste se vyhnout použití hrotů pro:

• pohledy s dynamickým obsahem, kde se rozložení výrazně mění v závislosti na obsahu.
• zobrazení, která ze své podstaty nejsou ve staviteli rozhraní snadno určitelná.
• zobrazení řadičů s komplikovanými přechody, které lze zjednodušit pomocí Storyboardingu.

Obecné klady a zápory

obecněji se pojďme projít klady a zápory používání hrotů.

Pro: opakovatelnost

hroty se hodí, když je stejné rozvržení sdíleno ve více třídách.

jako jednoduchý případ použití by šablona zobrazení obsahující uživatelské jméno a textové pole hesla mohla být implementována s hypotetickými pohledy TTLoginView a TTSignupView, které by mohly pocházet ze stejného hrotu. TTLoginView by musel skrýt pole pro heslo a oba by museli zadat odpovídající statické štítky (například „zadejte své uživatelské jméno“ vs „zadejte své heslo“), ale štítky by měly stejnou základní funkčnost a podobné rozvržení.

Pro & Con: výkon

hroty jsou líně načteny, takže nepoužívají paměť, dokud nebudou muset. I když to může být výhoda, je zde latence pro líný proces načítání, což z něj dělá také nevýhodu.

iOS Custom Code (Programmatic UIs)

jakýkoli design rozhraní iOS, který lze provést pomocí storyboardů a hrotů, lze také implementovat pomocí raw kódu (samozřejmě byly doby, kdy vývojáři neměli luxus tak bohaté sady nástrojů).

možná ještě důležitější je, že to, co nelze udělat s hroty a storyboardy, lze vždy implementovat pomocí kódu-samozřejmě za předpokladu, že je to technicky proveditelné. Dalším způsobem, jak se na to dívat, je, že hroty a storyboardy jsou implementovány s kódem, takže jejich funkčnost bude přirozeně podmnožinou. Pojďme rovnou do kladů a záporů.

Pro: pod kapotou

největší výhoda programového vytvoření uživatelského rozhraní iOS: pokud víte, jak kódovat uživatelské rozhraní, pak víte, co se děje pod kapotou, zatímco to samé nemusí nutně platit pro hroty a storyboardy.

pro srovnání: kalkulačka je užitečný nástroj. Ale není špatné vědět, jak provádět výpočty ručně.

Toto není omezeno na iOS, ale na jakýkoli vizuální RAD nástroj (např. Vizuální prostředí HTML RAD představují typický hraniční případ: používají se ke generování (často špatně napsaného) kódu a tvrdí, že nejsou potřeba žádné znalosti HTML a že vše lze provést vizuálně. Ale žádný webový vývojář by implementoval webovou stránku, aniž by si zašpinil ruce: vědí, že ruční manipulace se surovým HTML a CSS povede k modulárnějšímu a efektivnějšímu kódu.

takže zvládnutí kódování uživatelských rozhraní iOS vám dává větší kontrolu a větší povědomí o tom, jak tyto kousky do sebe zapadají, což zvyšuje vaši horní hranici jako vývojáře.

Pro: pokud je Kód jedinou možností

existují také případy, kdy je vlastní kód iOS jedinou možností pro návrh uživatelského rozhraní. Typickými příklady jsou dynamická rozvržení, kde se prvky zobrazení pohybují a tok nebo rozvržení se výrazně upravují na základě obsahu.

Pro: Konflikty sloučení

zatímco hroty a storyboardy významně trpěly konflikty sloučení, kód nemá stejnou chybu. Celý kód má sémantický význam, takže řešení konfliktů není obtížnější než obvykle.

Con: Prototyping

je těžké zjistit, jak bude rozvržení vypadat, dokud jej neuvidíte v akci. Dále nemůžete vizuálně umístit pohledy a ovládací prvky, takže převedení specifikací rozvržení do hmatatelného zobrazení může trvat mnohem déle, ve srovnání s hroty a storyboardy, které vám poskytnou okamžitý náhled na to, jak se věci vykreslí.

Con: Refaktorování

refaktorování kódu, který byl napsán dávno nebo někým jiným, se také stává mnohem komplikovanějším: když jsou prvky umístěny a animovány pomocí vlastních metod a magických čísel, ladění relací může být náročné.

Pro: výkon

pokud jde o výkon, storyboardy a hroty podléhají režii načítání a analýzy; a nakonec jsou nepřímo přeloženy do kódu. Netřeba dodávat, že k tomu nedochází u kódovaných UIs.

Pro: Opakovatelnost

jakýkoli pohled implementovaný programově může být navržen opakovaně použitelným způsobem. Podívejme se na několik případů použití:

• dva nebo více pohledů sdílí společné chování, ale jsou mírně odlišné. Základní třída A dvě podtřídy řeší problém elegantně.
• projekt musí být vidlicový, s cílem vytvořit jednu kódovou základnu, ale generovat dvě (nebo více) různých aplikací, každá se specifickými úpravami.

stejný proces návrhu uživatelského rozhraní by byl mnohem složitější s hroty a storyboardy. Soubory šablon neumožňují dědičnost a možná řešení jsou omezena na následující:

• duplikujte soubory hrotu a scénáře. Potom, mají oddělené životy a žádný vztah k původnímu souboru.
• přepíše vzhled a chování kódem, který může fungovat v jednoduchých případech, ale může vést k významným komplikacím v jiných. Těžké přepisy s kódem mohou také způsobit, že vizuální design bude zbytečný a vyvine se v neustálý zdroj bolesti hlavy, např., když určitý ovládací prvek zobrazí jednu cestu v rozhraní stavitel, ale vypadá úplně jinak, když je aplikace spuštěna.

kdy použít kód

často je dobré použít vlastní kód pro návrh uživatelského rozhraní iOS, když máte:

• dynamické rozvržení.
• zobrazení s efekty, jako jsou zaoblené rohy, stíny atd.
• jakýkoli případ, kdy je používání hrotů a scénářů komplikované nebo neproveditelné.

pokud nepoužíváte kód

obecně lze použít kódové UIs vždy. Málokdy jsou špatný nápad, tak bych sem dal.

ačkoli hroty a storyboardy přinášejí některé výhody ke stolu, mám pocit, že neexistuje žádná rozumná nevýhoda, kterou bych dal do seznamu, abych odradil od používání kódu (s výjimkou snad lenosti).

jeden projekt, více nástrojů

storyboardy, hroty a kód jsou tři různé nástroje pro vytváření uživatelského rozhraní iOS. Máme štěstí, že je máme. Fanatici programového UIs pravděpodobně nebudou brát v úvahu další dvě možnosti: kód vám umožní dělat vše, co je technicky možné, zatímco alternativy mají svá omezení. Pro ostatní vývojáře tam, Xcode army knife poskytuje tři nástroje, které lze použít najednou, ve stejném projektu, efektivně.

jak se ptáte? Jak chcete. Zde jsou některé možné přístupy:

• seskupte všechny související obrazovky do samostatných skupin a implementujte každou skupinu s vlastním odlišným Storyboardem.
• Navrhněte opakovaně použitelné buňky stolu na místě pomocí scénáře uvnitř ovladače zobrazení tabulky.
• Navrhněte opakovaně použitelné stolní buňky v hrotech, abyste podpořili opětovné použití a vyhnuli se opakování, ale načtěte tyto hroty pomocí vlastního kódu.
• navrhujte vlastní pohledy, ovládací prvky a mezi objekty pomocí hrotů.
• použijte kód pro vysoce dynamické pohledy a obecněji pro pohledy, které nelze snadno implementovat pomocí storyboardů a hrotů, zatímco přechody zobrazení v storyboardu.

na závěr se podívejme na poslední příklad, který to všechno spojuje.

jednoduchý případ použití

Řekněme, že chceme vyvinout základní aplikaci pro zasílání zpráv s několika různými pohledy:

• seznam sledovaných přátel (s opakovaně použitelnou šablonou buněk, která udržuje uživatelské rozhraní konzistentní v budoucích seznamech).
• zobrazení podrobností profilu, složené do samostatných sekcí (včetně informací o profilu, statistik a panelu nástrojů).
• seznam zpráv odeslaných a přijatých od přítele.
• nový formulář zprávy.
• zobrazení cloud tagů, které zobrazuje různé značky používané v uživatelských zprávách, přičemž každá značka je úměrná velikosti k počtu, kolikrát byla použita.

kromě toho chceme, aby pohledy proudily následovně:

• kliknutím na položku v seznamu sledovaných přátel se zobrazí podrobnosti profilu příslušného přítele.
• podrobnosti profilu zobrazují název profilu, adresu, statistiky, krátký seznam nejnovějších zpráv a panel nástrojů.

Chcete-li implementovat tuto aplikaci pro iOS, budou všechny tři naše nástroje uživatelského rozhraní užitečné, jak můžeme použít:

• Storyboard se čtyřmi řadiči zobrazení (seznam, podrobnosti, seznam zpráv a nový formulář zprávy).
• samostatný soubor hrotu pro opakovaně použitelnou šablonu buňky seznamu profilů.
• tři samostatné soubory hrotu pro zobrazení podrobností profilu, jeden pro každou ze samostatných sekcí, které jej tvoří (podrobnosti profilu, Statistiky, poslední tři zprávy), aby byla zajištěna lepší udržovatelnost. Tyto hroty budou instantovány jako pohledy a poté přidány do ovladače zobrazení.
• vlastní kód pro zobrazení tag cloud. Tento pohled je typickým příkladem toho, který nelze navrhnout v nástroji Interface Builder, ani prostřednictvím storyboardů, ani hrotů. Místo toho je zcela implementován prostřednictvím kódu. Abychom zachovali vizuální tok storyboardu, rozhodli jsme se přidat do storyboardu prázdný řadič zobrazení, implementovat tag cloud view jako samostatný pohled a programově přidat pohled do řadiče zobrazení. Je zřejmé, že pohled může být také implementován uvnitř řadiče zobrazení spíše než jako samostatný pohled, ale udržujeme je oddělené pro lepší opětovné použití.

opravdu základní maketa může vypadat:

s tím jsme nastínili základní konstrukci přiměřeně sofistikované aplikace pro iOS, jejíž základní pohledy spojují naše tři primární přístupy k návrhu uživatelského rozhraní. Pamatujte: neexistuje žádné binární rozhodnutí, protože každý nástroj má své silné a slabé stránky.

balení

jak je zkoumáno v tomto turtorial, storyboardy přidat znatelné zjednodušení iOS UI design a vizuální tok. Eliminují také kód kotle; ale to vše přichází za cenu, zaplacená flexibilně. Hroty mezitím nabízejí větší flexibilitu zaměřením na jediný pohled, ale bez vizuálního toku. Nejflexibilnějším řešením je samozřejmě kód, který bývá spíše nepřátelský a ze své podstaty nevizuální.

pokud vás tento článek zaujal, vřele doporučuji sledovat velkou debatu od Raye Wenderlicha, 55 minut dobře strávených diskusí o hrotech, Storyboardech a kódovaných UIS.

na závěr chci zdůraznit jednu věc: nepoužívejte za každou cenu nesprávný nástroj pro návrh uživatelského rozhraní iOS. Pokud pohled není možné navrhnout pomocí scénáře, nebo pokud jej lze implementovat pomocí hrotů nebo kódu jednodušším způsobem, nepoužívejte Storyboard. Podobně, pokud pohled není určen pomocí hrotů, nepoužívejte hroty. Tato pravidla, i když jsou jednoduchá, půjdou dlouhou cestu ve vašem vzdělávání jako vývojáře.