iOS felhasználói felületek: Storyboards vs. NIBs vs. Custom Code

gyakran hallom, hogy az iOS Fejlesztők ugyanazon kulcskérdés néhány változatát kérdezik:

mi a legjobb módja annak, hogy dolgozzon ki egy UI iOS: keresztül Storyboards, tollhegy, vagy kódot?

az erre a kérdésre adott válaszok, explicit vagy implicit módon, hajlamosak azt feltételezni, hogy van egy kölcsönösen kizáró választás, amelyet gyakran előre, a fejlesztés előtt kezelnek.

azon a véleményen vagyok, hogy a válasz helyett egy vagy több ellenkérdés formáját kell öltenie.

mi a “legjobb” autó?

hadd magyarázzam el egy témán kívüli példával. Tegyük fel, hogy autót szeretnék vásárolni, és felteszek egy egyszerű kérdést: “Mi a legjobb választás?”

valóban válaszolhat-e egy modell vagy akár egy márka javaslatával? Nem valószínű, hacsak nem javasolsz egy Ferrarit. Helyette, valószínűleg néhány más kérdéssel válaszolna, mint:

• mi a költségvetése?
• hány ülőhelyre van szüksége?
• érdekli az üzemanyag-fogyasztás?
• hogyan érzi magát a sportautókkal kapcsolatban?

nyilvánvaló, hogy nincs olyan, hogy jó vagy rossz autó, hacsak nem megfelelő kontextusba helyezzük—csak egy jó vagy rossz autó van, amely speciális igényeken alapul.

vissza az iOS UI Design-hoz

csakúgy, mint az autókérdésünknél, a “mi a legjobb módja az iOS UI fejlesztésének” kérdés hiányzik a kontextusból. És meglepő módon, a válasz nem kell egy catch-all eset.

Általánosságban elmondható, hogy háromféle felhasználói felület-tervezési megközelítés létezik, amelyek mindegyike előnye és hátránya, rajongói és gyűlölői:

• iOS Storyboards: vizuális eszköz több alkalmazásnézet és a köztük lévő átmenetek elrendezéséhez.
• NIBs (vagy XIBs): minden NIB fájl egyetlen nézet elemnek felel meg, és az Interface Builderben lefektethető, így vizuális eszköz is. Vegye figyelembe, hogy a “NIB” név a fájlkiterjesztésből származik (korábban .nib és most .xib, bár a régi kiejtés fennmaradt).
• egyéni kód: azaz nincs GUI eszköz, hanem az összes egyedi pozícionálás, animáció stb. programszerűen.

ezen opciók egyike sem általánosan jobb, mint bármely más (Annak ellenére, amit hallhat).

a Storyboards például az iOS UI eszközkészlet legújabb kiegészítése. Azt mondták nekem, hogy ők a jövő, hogy felváltják a Tollhegyeket és az egyedi kódú UI-ket. Látom Storyboards, mint egy hasznos eszköz, de nem annyira a csere, mint kiegészítője a tollhegy és az egyéni kódot. A Storyboards a megfelelő választás néhány, de nem minden helyzetben.

továbbá, miért kellene statikusan ragaszkodnia egyetlen opcióhoz, ha mindegyiket használhatja (ugyanabban a projektben), kiválasztva azt a mechanizmust, amely a legjobban megfelel az adott problémának?

ez egy olyan kérdés, amely véleményem szerint magasabb szinten általánosítható, és amelynek válaszát a szoftverfejlesztési alapelvek listáján magasan rangsorolják: nincs olyan univerzális nyelv, keretrendszer vagy technológia, amely minden szoftverfejlesztési problémára az egyetemes legjobb választás. Ugyanez igaz az iOS felhasználói felület tervezésére is.

ebben az iOS fejlesztési oktatóanyagban megvizsgáljuk ezeket a módszereket, és bemutatjuk azokat a használati eseteket, amelyekben alkalmazni kell őket, és nem szabad őket alkalmazni, valamint azokat a módszereket, amelyekkel össze lehet keverni őket.

iOS Storyboards

a klasszikus kezdő hiba az, hogy hozzon létre egy hatalmas projekt-szintű iOS Storyboard. Én is elkövettem ezt a hibát, amikor először elkezdtem dolgozni a forgatókönyvekkel (valószínűleg azért, mert ez egy csábító útvonal).

ahogy a neve is mutatja, a Storyboard egy tábla egy történetet mondani. Nem szabad arra használni, hogy a nem kapcsolódó történeteket egyetlen nagy kötetbe keverje. A storyboard tartalmaznia kell nézet vezérlők, amelyek logikusan kapcsolódnak egymáshoz—ami nem jelenti azt, minden nézet vezérlő.

például érdemes használni a storyboardokat a kezelés során:

• a hitelesítés és a regisztráció nézeteinek halmaza.
• többlépcsős rendelésbeviteli folyamat.
• varázsló-szerű (azaz bemutató) folyamat.
• a mester-részletes készlet nézetek (pl. profilok listák, profil adatait).

eközben kerülni kell a nagy storyboardokat, beleértve az egyetlen alkalmazásszintű storyboardot is (kivéve, ha az alkalmazás viszonylag egyszerű). Mielőtt mélyebbre mennénk, lássuk, miért.

a nagy iOS Storyboards

nagy Storyboards, kivéve, hogy nehéz böngészni és fenntartani, adjunk hozzá egy réteg komplexitás egy csapat környezetben: ha több fejlesztő dolgozik ugyanazon storyboard fájl ugyanabban az időben, forrás ellenőrzési konfliktusok elkerülhetetlenek. És míg a storyboard belsőleg szöveges fájlként jelenik meg (valójában XML fájl), az egyesítés általában nem triviális.

amikor a fejlesztők megtekintik a forráskódot, szemantikai jelentést tulajdonítanak neki. Tehát amikor manuálisan egyesülnek, képesek olvasni és megérteni a konfliktus mindkét oldalát, és ennek megfelelően cselekedni. A storyboard ehelyett egy Xcode által kezelt XML fájl, és az egyes kódsorok jelentése nem mindig könnyű megérteni.

Vegyünk egy nagyon egyszerű példát: tegyük fel, hogy két különböző Fejlesztő megváltoztatja a UILabel pozícióját (autolayout használatával), ez utóbbi pedig megnyomja a változtatását, így konfliktust hoz létre (figyelje meg az ütköző id attribútumokat):

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

a id önmagában nem ad semmilyen jelzést a valódi jelentőségéről, így nincs mit dolgozni. Az egyetlen értelmes megoldás az, ha a konfliktus két oldala közül az egyiket választjuk, a másikat pedig elvetjük. Lesznek mellékhatások? Ki tudja? Nem te.

az iOS interfész tervezési problémáinak megkönnyítése érdekében az ajánlott megközelítés több storyboard használata ugyanabban a projektben.

mikor kell használni a storyboardokat

a storyboardokat leginkább több összekapcsolt nézetvezérlővel lehet használni, mivel jelentős egyszerűsítésük a nézetvezérlők közötti átmenet. Bizonyos fokig úgy is felfoghatók, mint a tollhegyek összetétele, vizuális és funkcionális áramlásokkal a nézetvezérlők között.

a navigációs folyamat megkönnyítése mellett egy másik egyértelmű előnye, hogy kiküszöbölik a nézetvezérlők pop, push, present és elvetéséhez szükséges boilerplate kódot. Ezenkívül a nézetvezérlők automatikusan kiosztásra kerülnek, így nincs szükség manuálisan alloc és init.

végül, míg a storyboardokat leginkább a több nézetvezérlőt érintő forgatókönyvekhez használják, az is védhető, hogy egy storyboardot használjon, ha egyetlen táblázatnézet-vezérlővel dolgozik három okból:

• az asztali cellás prototípusok helyben történő tervezésének képessége segít a darabok összetartásában.
• több cellasablon is kialakítható a szülő tábla nézet vezérlő belsejében.
• lehetőség van statikus táblázatnézetek létrehozására (egy régóta várt kiegészítés, amely sajnos csak a forgatókönyvekben érhető el).

azt lehet állítani, hogy több cellasablon is megtervezhető a tollhegy használatával. Valójában ez csak preferencia kérdése: egyes fejlesztők inkább mindent egy helyen tartanak, míg mások nem érdekelnek.

ha nem használja iOS Storyboards

néhány esetben:

• a nézet bonyolult vagy dinamikus elrendezésű, legjobban kóddal valósítható meg.
• a nézet már implementálva van Nib-ekkel vagy kóddal.

ezekben az esetekben vagy elhagyhatjuk a nézetet a forgatókönyvből, vagy beágyazhatjuk egy nézetvezérlőbe. Az előbbi megtöri a Storyboard vizuális áramlását, de nincs negatív funkcionális vagy fejlesztési következménye. Ez utóbbi megtartja ezt a vizuális folyamatot, de további fejlesztési erőfeszítéseket igényel, mivel a nézet nincs integrálva a nézetvezérlőbe: csak komponensként van beágyazva, ezért a nézetvezérlőnek interakcióba kell lépnie a nézettel, ahelyett, hogy megvalósítaná.

Általános érvek és ellenérvek

most, hogy van értelme, ha Storyboards hasznosak iOS UI design, és mielőtt lépni a tollhegy ez a bemutató, menjünk át az általános előnyei és hátrányai.

Pro: Performance

intuitív módon feltételezheti, hogy amikor egy Storyboard betöltődik, az összes nézetvezérlője azonnal megjelenik. Szerencsére ez csak egy absztrakció, és nem igaz a tényleges megvalósításra: ehelyett csak a kezdeti nézetvezérlő jön létre, ha van ilyen. A többi nézetvezérlő dinamikusan példányosul, akár egy szakasz végrehajtásakor, akár manuálisan a kódból.

Pro: prototípusok

Storyboards egyszerűsíti a prototípus és gúnyos fel a felhasználói felületek és az áramlás. Valójában egy teljes működő prototípus alkalmazás nézetekkel és navigációval könnyen megvalósítható a Storyboards és csak néhány sornyi kód segítségével.

Con: újrafelhasználhatóság

amikor a mozgó vagy másolás, iOS Storyboards rosszul elhelyezett. A Storyboard kell mozgatni együtt az összes függő nézet vezérlők. Más szavakkal, egyetlen nézetvezérlőt nem lehet külön-külön kivonni és újra felhasználni máshol egyetlen független entitásként;a Storyboard többi részétől függ.

Con: adatáramlás

az adatokat gyakran át kell adni a nézetvezérlők között, amikor egy alkalmazás átmegy. Azonban a Storyboard vizuális áramlása ebben az esetben megszakad, mivel nincs nyoma ennek az Interfészkészítőben. A Storyboards gondoskodik a nézetvezérlők közötti áramlás kezeléséről, de nem az adatáramlásról. Tehát a célvezérlőt kóddal kell konfigurálni, felülírva a vizuális élményt.

ilyen esetekben egy prepareForSegue:sender-re kell támaszkodnunk, egy ilyen if/else-if csontvázzal:

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

úgy vélem, hogy ez a megközelítés hibákra hajlamos és szükségtelenül bőbeszédű.

tollhegy

tollhegy a régi(er) módja annak, hogy végre iOS interfész.

ebben az esetben a “régi” nem azt jelenti, hogy “rossz”, “elavult” vagy “elavult”. Valójában fontos megérteni, hogy az iOS Storyboards nem univerzális helyettesítője a hüvelyeknek; egyes esetekben csak egyszerűsítik a felhasználói felület megvalósítását.

a Tollhegyekkel bármilyen tetszőleges nézet megtervezhető, amelyet a fejlesztő szükség szerint csatolhat egy nézetvezérlőhöz.

ha objektum-orientált tervezést alkalmazunk az UI-kre, akkor van értelme a nézetvezérlő nézetét külön modulokra bontani, amelyek mindegyike saját NIB fájllal (vagy több, ugyanabba a fájlba csoportosított modullal) nézetként valósul meg. Ennek a megközelítésnek az egyértelmű előnye, hogy minden komponens könnyebben fejleszthető, könnyebben tesztelhető és könnyebben hibakereshető.

a tollhegyek megosztják az egyesítési konfliktus problémáit, amelyeket a forgatókönyvekkel láttunk, de kisebb mértékben, mivel a tollhegy fájlok kisebb léptékben működnek.

mikor kell használni NIBs iOS UI Design

egy részhalmaza minden felhasználási esetben lenne:

• modális nézetek
• egyszerű bejelentkezési és regisztrációs nézetek
• Beállítások
• felugró ablakok
• újrafelhasználható nézet sablonok
• újrafelhasználható táblázat cellasablonok

közben…

ha nem használja a tollhegy

kerülje a tollhegy használatát:

• dinamikus tartalommal rendelkező nézetek, ahol az elrendezés a tartalomtól függően jelentősen megváltozik.
• olyan nézetek, amelyek természetüknél fogva nem könnyen tervezhetők az interfész-készítőben.
• tekintse meg a vezérlőket bonyolult átmenetekkel, amelyek egyszerűsíthetők a Storyboardozással.

Általános érvek és ellenérvek

általánosabban nézzük végig a tollhegy használatának előnyeit és hátrányait.

Pro: újrafelhasználhatóság

a tollhegyek jól jönnek, ha ugyanazt az elrendezést több osztály osztja meg.

egyszerű használati esetként egy felhasználónevet és egy jelszó szövegmezőt tartalmazó nézetsablon implementálható a hipotetikus TTLoginView és TTSignupView nézetekkel, amelyek mindkettő ugyanabból a NIB-ből származhat. A TTLoginView – nek el kell rejtenie a jelszó mezőt, és mindkettőnek meg kell adnia a megfelelő statikus címkéket (például ‘Enter your username’ vs ‘Enter your password’), de a címkék ugyanolyan alapvető funkciókkal és hasonló elrendezéssel rendelkeznek.

Pro & Con: Performance

a hüvelyek lustán vannak betöltve, így nem használják a memóriát, amíg nem kell. Bár ez előnyt jelenthet, a lusta betöltési folyamat késése van, ami szintén hátrányt jelent.

iOS Custom Code (Programmatic UIs)

bármely iOS felület, amelyet Storyboardokkal és Tollhegyekkel lehet elvégezni, raw kóddal is megvalósítható (természetesen volt idő, amikor a fejlesztőknek nem volt ilyen gazdag eszközkészletük).

talán még ennél is fontosabb, hogy amit nem lehet megtenni a tollakkal és a forgatókönyvekkel, mindig kóddal lehet végrehajtani-természetesen, hogy technikailag megvalósítható. Egy másik módja annak, hogy megnézzük, hogy a tollak és a forgatókönyvek kóddal vannak megvalósítva, így funkcionalitásuk természetesen részhalmaz lesz. Ugorjunk egyenesen az érvek és ellenérvek közé.

Pro: A motorháztető alatt

az iOS felhasználói felület programozásának legnagyobb előnye: ha tudja, hogyan kell kódolni a felhasználói felületet, akkor tudja, mi történik a motorháztető alatt, míg ugyanez nem feltétlenül igaz a hüvelyekre és a forgatókönyvekre.

összehasonlításhoz: a számológép hasznos eszköz. De nem rossz dolog tudni, hogyan kell manuálisan elvégezni a számításokat.

ez nem korlátozódik az iOS-re, hanem bármely visual Rad eszközre (például a Visual Studio és a Delphi, csak hogy néhányat említsünk). A vizuális HTML RAD környezetek tipikus határesetet jelentenek: (gyakran rosszul megírt) kód generálására használják, azt állítva, hogy nincs szükség HTML ismeretekre, és hogy minden vizuálisan elvégezhető. De egyetlen webfejlesztő sem valósítana meg egy weboldalt anélkül, hogy bepiszkolná a kezét: tudják, hogy a nyers HTML és CSS kézi kezelése modulárisabb, hatékonyabb kódot eredményez.

tehát az iOS felhasználói felületek kódolásának elsajátítása nagyobb ellenőrzést és nagyobb tudatosságot ad arra, hogy ezek a darabok hogyan illeszkednek egymáshoz, ami növeli a felső határt fejlesztőként.

Pro: Ha a kód az egyetlen lehetőség

vannak olyan esetek is, amikor az egyéni iOS kód az egyetlen lehetőség a felhasználói felület tervezéséhez. Tipikus példák a dinamikus elrendezések, ahol a nézetelemeket mozgatják, és az áramlás vagy az elrendezés jelentősen módosul a tartalom alapján.

Pro: Merge Conflicts

míg a NIBs és a Storyboards jelentősen szenvedett az egyesítési konfliktusoktól, a kódnak nincs ugyanaz a hibája. Minden kódnak szemantikai jelentése van, így a konfliktusok megoldása nem nehezebb, mint a szokásos.

Con: prototípuskészítés

nehéz kitalálni, hogyan fog kinézni egy elrendezés, amíg meg nem látta működés közben. Továbbá nem lehet vizuálisan elhelyezni a nézeteket és a vezérlőket, így az elrendezési SPECIFIKÁCIÓK kézzelfogható nézetbe történő fordítása sokkal hosszabb időt vehet igénybe, mint a tollak és a forgatókönyvek, amelyek azonnali áttekintést nyújtanak arról, hogy a dolgok hogyan fognak megjelenni.

Con:

a régen vagy valaki más által írt kód Refaktorálása szintén sokkal bonyolultabbá válik: amikor az elemeket egyedi módszerekkel és mágikus számokkal helyezik el és animálják, a hibakeresési munkamenetek fáradságosak lehetnek.

Pro: Performance

a teljesítmény szempontjából a Storyboards és a NIBs a betöltés és az elemzés fölött van; és végül közvetetten lefordítják a kódot. Mondanom sem kell, hogy ez nem történik meg a kóddal készített UI-kkal.

Pro: Újrafelhasználhatóság

bármely, programozottan megvalósított nézet újrafelhasználható módon tervezhető. Nézzünk meg néhány felhasználási esetet:

• két vagy több nézet közös viselkedést mutat, de kissé eltérnek egymástól. Egy alaposztály és két alosztály elegánsan oldja meg a problémát.
• a projektet el kell villázni, azzal a céllal, hogy egyetlen kódbázist hozzon létre, de két (vagy több) különböző alkalmazást generáljon, mindegyik egyedi testreszabással.

ugyanaz a felhasználói felület tervezési folyamata sokkal bonyolultabb lenne a tollakkal és a forgatókönyvekkel. A sablonfájlok nem engedélyezik az öröklést, és a lehetséges megoldások a következőkre korlátozódnak:

• másolja a NIB és a Storyboard fájlokat. Ezután külön életük van, és nincs kapcsolatuk az eredeti fájllal.
• felülírja a kinézetet és a viselkedést kóddal, ami egyszerű esetekben működhet, de másokban jelentős komplikációkhoz vezethet. A kóddal való nehéz felülbírálások a vizuális tervezést is használhatatlanná tehetik, és állandó fejfájásforrássá válhatnak, pl., amikor egy bizonyos vezérlő egyféleképpen jelenik meg az interfész-készítőben, de teljesen másképp néz ki, amikor az alkalmazás fut.

mikor kell használni a kódot

gyakran jó hívás az egyéni kód használata az iOS felhasználói felület tervezéséhez, ha van:

• dinamikus elrendezések.
• effektekkel ellátott nézetek, például lekerekített sarkok, árnyékok stb.
• minden esetben, amikor a tollhegy és Storyboards bonyolult vagy kivitelezhetetlen.

ha nem használja a kódot

általában a kód által készített UI-k mindig használhatók. Ritkán rossz ötlet, ezért ide tenném.

bár a tollak és a forgatókönyvek bizonyos előnyöket hoznak az asztalra, úgy érzem, nincs ésszerű hátránya, hogy felsorolnám a kódhasználatot (kivéve talán a lustaságot).

egy projekt, több eszköz

a Storyboards, a NIBs és a code három különböző eszköz az iOS felhasználói felület létrehozásához. Szerencsések vagyunk, hogy vannak. A programozott UI-k fanatikusai valószínűleg nem veszik figyelembe a másik két lehetőséget: a kód lehetővé teszi, hogy mindent megtegyen, ami technikailag lehetséges, míg az alternatíváknak megvannak a korlátai. A többi fejlesztő számára, az Xcode army knife három eszközt kínál, amelyek egyszerre használhatók, ugyanabban a projektben, hatékonyan.

hogyan, kérdezed? Ahogy akarod. Íme néhány lehetséges megközelítés:

• csoportosítsa az összes kapcsolódó képernyőt külön csoportokba, és hajtsa végre az egyes csoportokat saját különálló Storyboarddal.
• tervezze meg a nem újrafelhasználható asztali cellákat a helyén egy Storyboarddal, az asztal nézetvezérlőjén belül.
• tervezzen újrafelhasználható táblacellákat a Tollhegyekben, hogy ösztönözze az újrafelhasználást és elkerülje az ismétlést, de ezeket a Tollhegyeket egyedi kóddal töltse be.
• Egyedi nézetek, vezérlők és köztes objektumok tervezése Tollhegyekkel.
• használja a kódot a rendkívül dinamikus nézetekhez, és általánosabban olyan nézetekhez, amelyek nem könnyen megvalósíthatók a Storyboards és a NIBs segítségével, míg a ház nézetátmenetek egy Storyboardban.

a bezáráshoz nézzünk meg egy utolsó példát, amely összekapcsolja az egészet.

egy egyszerű használati eset

mondjuk szeretnénk fejleszteni egy alapvető üzenetküldő alkalmazás több különböző nézetek:

• a követett barátok listája (újrafelhasználható cellasablonnal, hogy a felhasználói felület konzisztens maradjon a jövőbeli listákon).
• profil részletes nézet, amely külön szakaszokba (profilinformációkba, statisztikákba és egy eszköztárba) van összeállítva.
• egy barátnak küldött és attól kapott üzenetek listája.
• új üzenet űrlap.
• címkefelhő-nézet, amely megjeleníti a felhasználói üzenetekben használt különböző címkéket, mindegyik címke mérete arányos a használatuk számával.

ezenkívül azt akarjuk, hogy a nézetek az alábbiak szerint folyjanak:

• ha rákattint egy elemre a követett barátok listájában, megjelenik az adott barát profiljának adatai.
• a Profil adatai a profil nevét, címét, statisztikáit, a legutóbbi üzenetek rövid listáját és egy eszköztárat mutatják.

ennek az iOS alkalmazásnak a megvalósításához mind a három felhasználói felület eszközünk hasznos lesz, mivel használhatjuk:

• a Storyboard négy nézet vezérlők (a lista, részletek, üzenetek listáját, és az új üzenet formájában).
• külön NIB fájl az újrafelhasználható profillista cellasablonhoz.
• három különálló NIB fájl a profil részletei nézethez, egy-egy az azt alkotó különálló szakaszokhoz (profiladatok, statisztikák, utolsó három üzenet) a jobb karbantarthatóság érdekében. Ezeket a Tollhegyeket nézetekként példányosítják, majd hozzáadják a nézetvezérlőhöz.
• egyéni kód a címkefelhő nézethez. Ez a nézet egy tipikus példa arra, amelyet nem lehet megtervezni az interfész-készítőben, sem a StoryBoards, sem a NIBs segítségével. Ehelyett teljesen kódon keresztül valósul meg. A Storyboard vizuális áramlásának fenntartása érdekében úgy döntünk, hogy egy üres nézetvezérlőt adunk a Storyboardhoz, a címkefelhő nézetet önálló nézetként valósítjuk meg, és programszerűen hozzáadjuk a nézetet a nézetvezérlőhöz. Nyilvánvaló, hogy a nézetet a nézetvezérlőn belül is megvalósíthatjuk, nem pedig önálló nézetként, de a jobb újrafelhasználás érdekében elválasztjuk őket.

egy igazán alapvető makett úgy nézhet ki, mint:

ezzel felvázoltuk egy ésszerűen kifinomult iOS alkalmazás alapvető felépítését, amelynek alapvető nézetei összekapcsolják a felhasználói felület tervezésének három elsődleges megközelítését. Ne feledje: nincs bináris döntés, mivel minden eszköznek megvannak a maga erősségei és gyengeségei.

csomagolás

amint azt ebben a turtorialban megvizsgáltuk, a Storyboards észrevehető egyszerűsítést ad az iOS felhasználói felületének tervezéséhez és a vizuális áramláshoz. Azt is megszünteti boilerplate kód; de mindez ára van, fizetett rugalmasság. A hüvelyek eközben nagyobb rugalmasságot kínálnak, ha egyetlen nézetre összpontosítanak, de vizuális áramlás nélkül. A legrugalmasabb megoldás természetesen a kód, amely általában meglehetősen barátságtalan és természeténél fogva nem vizuális.

ha ez a cikk felkeltette Önt, nagyon ajánlom a Ray Wenderlich nagy vitáját, 55 percet, amelyet jól töltöttek a tollak, a forgatókönyvek és a kódolt UI-k megvitatására.

zárásként egy dolgot szeretnék hangsúlyozni: kerülje a nem megfelelő iOS felhasználói felület tervező eszköz használatát minden áron. Ha egy nézet nem tervezhető egy Storyboarddal, vagy ha egyszerűbb módon valósítható meg a tollal vagy a kóddal, ne használjon storyboardot. Hasonlóképpen, ha egy nézet nem tervezhető Tollhegyekkel, ne használjon Tollhegyeket. Ezek a szabályok, bár egyszerűek, hosszú utat fognak megtenni az oktatásban, mint Fejlesztő.