iOS användargränssnitt: Storyboards vs. NIBs vs. anpassad kod

jag hör ofta iOS-utvecklare ställa någon variant av samma nyckelfråga:

Vad är det bästa sättet att utveckla ett användargränssnitt i iOS: genom Storyboards, NIBs eller code?

svar på denna fråga, explicit eller implicit, tenderar att anta att det finns ett ömsesidigt exklusivt val att göra, en som ofta behandlas på förhand, före utveckling.

jag anser att svaret istället ska ha formen av en eller flera motfrågor.

Vad är den” bästa ” bilen?

Låt mig förklara med ett off-topic exempel. Säg att jag vill köpa en bil och jag frågar dig en enkel fråga: ”Vad är det bästa valet?”

kan du verkligen svara genom att föreslå en modell eller till och med ett varumärke? Inte troligt, om du inte föreslår en Ferrari. Istället skulle du förmodligen svara med några andra frågor, som:

• vad är din budget?
• hur många platser behöver du?
• bryr du dig om bränsleförbrukning?
• vad tycker du om sportbilar?

det är uppenbart att det inte finns något sådant som en bra eller dålig bil om den inte placeras i ett korrekt sammanhang—det finns bara en bra eller dålig bil baserad på specifika behov.

tillbaka till iOS UI Design

precis som med vår bilförfrågan saknar frågan ”Vad är det bästa sättet att utveckla en iOS UI” sammanhang. Och förvånansvärt nog, svaret behöver inte vara en catch-all case.

i stort sett finns det tre typer av användargränssnittsdesignmetoder som du kan ta, var och en med sina fördelar och nackdelar, dess fans och hatare:

• iOS Storyboards: ett visuellt verktyg för att lägga ut flera programvyer och övergångarna mellan dem.
• NIBs (eller XIBs): varje NIB-fil motsvarar ett enda visningselement och kan läggas ut i Gränssnittsbyggaren, vilket också gör det till ett visuellt verktyg. Observera att namnet ”NIB” kommer från filtillägget (tidigare .nib och nu .xib, även om det gamla uttalet har kvarstått).
• anpassad kod: dvs inga GUI-verktyg, utan snarare hantering av all Anpassad positionering,animering etc. programmässigt.

inget av dessa alternativ är universellt bättre än någon annan (trots vad du kanske hör).

Storyboards, till exempel, är det senaste tillskottet till iOS UI toolkit. Jag har fått höra att de är framtiden, att de kommer att ersätta NIBs och anpassad kod UIs. Jag ser Storyboards som ett användbart verktyg, men inte så mycket en ersättning som ett komplement till NIBs och anpassad kod. Storyboards är det rätta valet i vissa, men inte alla situationer.

vidare, varför ska du statiskt hålla fast vid ett enda alternativ när du kan använda dem alla (i samma projekt) och välja den mekanism som bäst passar det specifika problemet?

detta är en fråga som enligt min mening kan generaliseras på en högre nivå och vars svar rankas högt i min lista över mjukvaruutvecklingsprinciper: det finns inget universellt språk, ramverk eller teknik som är det universella bästa valet för varje mjukvaruutvecklingsproblem. Detsamma gäller för iOS UI design.

i denna iOS-utvecklingshandledning kommer vi att utforska var och en av dessa metoder och introducera användningsfall där de borde och inte bör användas, liksom sätt på vilka de kan blandas ihop.

iOS Storyboards

en klassisk nybörjare misstag är att skapa en massiv projektomfattande iOS Storyboard. Jag gjorde också detta misstag när jag först började arbeta med Storyboards (förmodligen för att det är en frestande väg att ta).

som namnet antyder är en Storyboard en styrelse med en historia att berätta. Det ska inte användas för att blanda orelaterade berättelser i en stor volym. En storyboard bör innehålla vykontroller som är logiskt relaterade till varandra—vilket inte betyder varje vykontrollant.

det är till exempel vettigt att använda Storyboards vid hantering:

• en uppsättning vyer för autentisering och registrering.
• ett flöde för flera steg.
• en guide-liknande (dvs handledning) flöde.
• en master-detail uppsättning vyer (t.ex. profiler listor, profiluppgifter).

samtidigt bör stora Storyboards undvikas, inklusive enstaka Appomfattande Storyboards (såvida inte appen är relativt enkel). Innan vi går djupare, låt oss se varför.

dårskapen hos stora iOS Storyboards

stora Storyboards, förutom att de är svåra att bläddra och underhålla, lägger till ett lager av komplexitet i en lagmiljö: när flera utvecklare arbetar på samma storyboard-fil samtidigt är källkontrollkonflikter oundvikliga. Och medan en storyboard är internt representerad som en textfil (en XML-fil, faktiskt), är sammanslagning vanligtvis icke-trivial.

när utvecklare visa källkod, tillskriver de det semantisk mening. Så när man sammanfogar manuellt kan de läsa och förstå båda sidor av en konflikt och agera därefter. En storyboard är istället en XML-fil som hanteras av Xcode, och betydelsen av varje kodrad är inte alltid lätt att förstå.

låt oss ta ett mycket enkelt exempel: säg att två olika utvecklare ändrar positionen för en UILabel (med autolayout), och den senare driver sin förändring och producerar en konflikt som denna (Lägg märke till de motstridiga id attributen):

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

id själv ger ingen indikation på dess sanna betydelse, så du har inget att arbeta med. Den enda meningsfulla lösningen är att välja en av konfliktens två sidor och kassera den andra. Kommer det att finnas biverkningar? Vem vet? Inte du.

för att underlätta dessa iOS-gränssnittsdesignproblem är det rekommenderat att använda flera storyboards i samma projekt.

När ska man använda Storyboards

Storyboards används bäst med flera sammankopplade vykontroller, eftersom deras stora förenkling är övergången mellan vykontroller. Till viss del kan de betraktas som en sammansättning av NIBs med visuella och funktionella flöden mellan synkontroller.

förutom att underlätta navigationsflödet är en annan tydlig fördel att de eliminerar standardkodskod som behövs för att popa, trycka, presentera och avvisa vykontroller. Dessutom tilldelas view controllers automatiskt, så det finns inget behov av att manuellt alloc och init.

slutligen, medan Storyboards bäst används för scenarier som involverar flera visningsstyrenheter, är det också försvarbart att använda en Storyboard när man arbetar med en enda tabellvykontroll av tre skäl:

• möjligheten att designa bordcellprototyper på plats hjälper till att hålla bitarna ihop.
• flera cellmallar kan utformas inuti den överordnade tabellvykontrollen.
• det är möjligt att skapa statiska tabellvyer (ett efterlängtat tillägg som tyvärr bara är tillgängligt i Storyboards).

man kan hävda att flera cellmallar också kan utformas med hjälp av NIBs. I själva verket är detta bara en fråga om preferens: vissa utvecklare föredrar att ha allt på ett ställe, medan andra inte bryr sig.

när du inte ska använda iOS Storyboards

några fall:

• vyn har en komplicerad eller dynamisk layout, bäst implementerad med kod.
• vyn är redan implementerad med NIBs eller kod.

i dessa fall kan vi antingen lämna vyn ur storyboardet eller bädda in den i en vykontroll. Den förstnämnda bryter Storyboardets visuella flöde, men har inga negativa funktionella eller utvecklingsimplikationer. Den senare behåller detta visuella flöde, men det kräver ytterligare utvecklingsinsatser eftersom vyn inte är integrerad i view controller: den är bara inbäddad som en komponent, varför view controller måste interagera med vyn snarare än att implementera den.

allmänna fördelar och nackdelar

nu när vi har en känsla för när Storyboards är användbara i iOS UI-design, och innan vi går vidare till NIBs i denna handledning, låt oss gå igenom deras allmänna fördelar och nackdelar.

Pro: prestanda

intuitivt kan du anta att när en Storyboard laddas, instansieras alla dess vykontroller omedelbart. Lyckligtvis är detta bara en abstraktion och inte sant för den faktiska implementeringen: istället skapas endast den ursprungliga visningskontrollen, om någon. De andra vykontrollerna instansieras dynamiskt, antingen när en segue utförs eller manuellt från kod.

Pro: prototyper

Storyboards förenklar prototyper och hånar användargränssnitt och flöde. Egentligen kan en komplett fungerande prototypapplikation med vyer och navigering enkelt implementeras med Storyboards och bara några rader kod.

Con: återanvändbarhet

när det gäller att flytta eller kopiera är iOS Storyboards dåligt placerade. En Storyboard måste flyttas tillsammans med alla dess beroende vykontroller. Med andra ord kan en enda vykontroll inte extraheras individuellt och återanvändas någon annanstans som en enda oberoende enhet; Det är beroende av att resten av storyboardet fungerar.

Con: dataflöde

Data måste ofta skickas mellan vykontrollerna när en app övergår. Storyboardets visuella flöde bryts dock i det här fallet eftersom det inte finns något spår av detta som händer i Gränssnittsbyggaren. Storyboards tar hand om hanteringen av flödet mellan view controllers, men inte flödet av data. Så destinationskontrollen måste konfigureras med kod och åsidosätta den visuella upplevelsen.

i sådana fall måste vi förlita oss på en prepareForSegue:sender, med ett if / else-if-skelett så här:

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

jag tycker att detta tillvägagångssätt är felaktigt benäget och onödigt verbose.

NIBs

NIBs är det gamla(er) sättet att utföra iOS-gränssnittsdesign.

i det här fallet betyder ”gammal” inte ”dålig”, ”föråldrad” eller ”föråldrad”. Det är faktiskt viktigt att förstå att iOS Storyboards inte är en universell ersättning för NIBs; de förenklar bara användargränssnittet i vissa fall.

med NIBs kan varje godtycklig vy utformas, som utvecklaren sedan kan bifoga till en vykontroll efter behov.

om vi tillämpar objektorienterad design på våra UIs, är det vettigt att bryta en vykontrollers vy ner i separata moduler, var och en implementerad som en vy med sin egen NIB-fil (eller med flera moduler grupperade i samma fil). Den tydliga fördelen med detta tillvägagångssätt är att varje komponent är lättare att utveckla, lättare att testa och lättare att felsöka.

NIBs delar de sammanslagna konfliktproblemen vi såg med Storyboards, men i mindre utsträckning, eftersom NIB-filer fungerar i mindre skala.

när du ska använda NIBs för iOS UI Design

en delmängd av alla användningsområden fall skulle vara:

• modala vyer
• enkla inloggnings-och registreringsvyer
• Inställningar
• Popup-fönster
• återanvändbara visningsmallar
• återanvändbara tabellcellmallar

under tiden…

när du inte ska använda nibs

bör du undvika att använda nibs för:

• vyer med dynamiskt innehåll, där layouten ändras väsentligt beroende på innehåll.
• visningar som av naturen inte är lätt designbara i Gränssnittsbyggaren.
• visa kontroller med komplicerade övergångar som kan förenklas med Storyboarding.

allmänna fördelar och nackdelar

mer allmänt, låt oss gå igenom fördelarna och nackdelarna med att använda NIBs.

Pro: återanvändbarhet

NIBs kommer till nytta när samma layout delas över flera klasser.

som ett enkelt användningsfall kan en vymall som innehåller ett användarnamn och ett lösenordsfält implementeras med de hypotetiska vyerna TTLoginView och TTSignupView, som båda kan komma från samma spets. TTLoginView måste dölja lösenordsfältet, och båda måste ange motsvarande statiska etiketter (till exempel ’ange ditt användarnamn’ vs ’ange ditt lösenord’), men etiketterna skulle ha samma grundläggande funktionalitet och liknande layouter.

Pro & Con: prestanda

NIBs laddas lätt, så de använder inte minne förrän de måste. Även om detta kan vara en fördel, finns det latens för den lata laddningsprocessen, vilket gör det också till en nackdel.

iOS anpassad kod (programmatisk UIs)

alla iOS-gränssnittsdesign som kan göras med Storyboards och NIBs kan också implementeras med raw-kod (det var naturligtvis en tid då utvecklare inte hade lyxen med en så rik uppsättning verktyg).

kanske ännu viktigare, vad som inte kan göras med NIBs och Storyboards kan alltid implementeras med kod—givetvis att det är tekniskt genomförbart. Ett annat sätt att se på det är att NIBs och Storyboards implementeras med kod, så deras funktionalitet kommer naturligtvis att vara en delmängd. Låt oss hoppa rakt in i för-och nackdelar.

Pro: Under huven

den största fördelen med att skapa ett iOS-användargränssnitt programmatiskt: om du vet hur man kodar ett användargränssnitt, vet du vad som händer under huven, medan detsamma inte nödvändigtvis gäller NIBs och Storyboards.

för att göra en jämförelse: en räknare är ett användbart verktyg. Men det är inte dåligt att veta hur man utför beräkningar manuellt.

Detta är inte begränsat till iOS, men till något visuellt RADVERKTYG (t.ex. Visual Studio och Delphi, bara för att nämna några). Visuella HTML-RADMILJÖER representerar ett typiskt gränsfall: de används för att generera (ofta dåligt skriven) kod och hävdar att ingen HTML-kunskap behövs och att allt kan göras visuellt. Men ingen webbutvecklare skulle implementera en webbsida utan att få sina händer smutsiga: de vet att manuell hantering av raw HTML och CSS kommer att leda till mer modulär och effektivare kod.

så att behärska kodningen av iOS-användargränssnitt ger dig mer kontroll över och större medvetenhet om hur dessa bitar passar ihop, vilket ökar din övre gräns som utvecklare.

Pro: när kod är det enda alternativet

det finns också fall där Anpassad iOS-kod är det enda alternativet för UI-design. Dynamiska layouter, där visningselement flyttas runt och flödet eller layouten justeras väsentligt baserat på innehåll, är typiska exempel.

Pro: Sammanfoga konflikter

medan NIBs och Storyboards drabbades avsevärt av sammanslagningskonflikter, har kod inte samma fel. All kod har semantisk mening, så att lösa konflikter är inte svårare än vanligt.

Con: Prototyping

det är svårt att ta reda på hur en layout kommer att se ut tills du såg den i aktion. Vidare kan du inte visuellt placera vyer och kontroller, så att översätta layoutspecifikationer till en konkret vy kan ta mycket längre tid jämfört med NIBs och Storyboards som ger dig en omedelbar förhandsgranskning av hur saker kommer att göra.

med: Refactoring

refactoring-kod som skrevs för länge sedan eller av någon annan blir också mycket mer komplicerad: när element placeras och animeras med anpassade metoder och magiska nummer kan felsökningssessioner bli svåra.

Pro: prestanda

när det gäller prestanda, Storyboards och NIBs är föremål för overhead av lastning och tolkning; och i slutändan, de är indirekt översatt till kod. Det behöver inte sägas att detta inte händer med kodgjorda UIs.

Pro: Återanvändbarhet

alla vyer som implementeras programmatiskt kan utformas på ett återanvändbart sätt. Låt oss se några användningsfall:

• två eller flera vyer delar ett gemensamt beteende, men de är något annorlunda. En basklass och två underklasser löser problemet elegant.
• ett projekt måste gafflas, i syfte att skapa en enda kodbas, men generera två (eller flera) olika applikationer, var och en med specifika anpassningar.

samma UI-designprocess skulle vara mycket mer komplicerad med NIBs och Storyboards. Mallfiler tillåter inte arv, och de möjliga lösningarna är begränsade till följande:

• duplicera NIB och Storyboard filer. Därefter har de separata liv och inget förhållande till originalfilen.
• åsidosätta utseende och beteende med kod, som kan fungera i enkla fall, men kan leda till betydande komplikationer i andra. Tunga åsidosättningar med kod kan också göra visuell design värdelös och utvecklas till en konstant källa till huvudvärk, t. ex., när en viss kontroll visar ett sätt i Gränssnittsbyggaren, men ser helt annorlunda ut när appen körs.

När ska man använda kod

det är ofta ett bra samtal att använda Använd anpassad kod för iOS-användargränssnittsdesign när du har:

• dynamiska layouter.
• vyer med effekter, såsom rundade hörn, skuggor, etc.
• alla fall där användning av NIBs och Storyboards är komplicerat eller omöjligt.

när man inte ska använda kod

i allmänhet kan kodgjorda UIs alltid användas. De är sällan en dålig ide, så jag skulle lägga en här.

även om NIBs och Storyboards ger några fördelar till bordet, känner jag att det inte finns någon rimlig nackdel som jag skulle lägga i en lista för att motverka kodanvändning (förutom kanske latskap).

ett projekt, flera verktyg

Storyboards, NIBs och code är tre olika verktyg för att bygga iOS-användargränssnitt. Vi har tur som har dem. Fanatiker av programmatiska UIs kommer förmodligen inte att ta hänsyn till de andra två alternativen: kod låter dig göra allt som är tekniskt möjligt, medan alternativen har sina begränsningar. För resten av utvecklarna där ute, Xcode army knife ger tre verktyg som kan användas på en gång, i samma projekt, effektivt.

hur frågar du? Hur du vill. Här är några möjliga tillvägagångssätt:

• gruppera alla relaterade skärmar i separata grupper och implementera varje grupp med sin egen distinkta Storyboard.
• designa icke-återanvändbara tabellceller på plats med en Storyboard, inuti tabellvyn.
• designa återanvändbara tabellceller i NIBs för att uppmuntra återanvändning och undvika upprepning, men ladda dessa NIBs genom anpassad kod.
• designa anpassade vyer, kontroller och mellan objekt med hjälp av NIBs.
• Använd kod för mycket dynamiska vyer, och mer generellt för vyer som inte är lätt implementerbara via Storyboards och NIBs, medan bostadsvyövergångar i en Storyboard.

för att stänga, låt oss titta på ett sista exempel som knyter samman allt.

ett enkelt användningsfall

säg att vi vill utveckla en grundläggande meddelandeapp med flera olika vyer:

• en lista med följda vänner (med en återanvändbar cellmall för att hålla användargränssnittet konsekvent över framtida listor).
• en profildetaljvy, sammansatt i separata avsnitt (inklusive profilinformation, statistik och ett verktygsfält).
• en lista med meddelanden som skickas till och tas emot från en vän.
• ett nytt meddelandeformulär.
• en taggmolnvy som visar de olika taggarna som används i användarmeddelanden, med varje tagg proportionell i storlek till antalet gånger den har använts.

dessutom vill vi att vyerna ska flöda enligt följande:

• om du klickar på ett objekt i listan med följda vänner visas relevant väns profilinformation.
• profilinformationen visar profilnamn, adress, statistik, en kort lista över de senaste meddelandena och ett verktygsfält.

för att implementera denna iOS-app kommer alla tre av våra UI-verktyg att vara till nytta, som vi kan använda:

• en Storyboard med fyra vykontroller (listan, detaljer, lista över meddelanden och nytt meddelandeformulär).
• en separat NIB-fil för den återanvändbara profillistan cellmall.
• tre separata NIB-filer för vyn profilinformation, en för var och en av de separata sektionerna som komponerar den (profilinformation, statistik, tre senaste meddelanden), för att möjliggöra bättre underhåll. Dessa NIBs kommer att instansieras som vyer och sedan läggas till i vykontrollen.
• anpassad kod för taggmolnvyn. Denna vy är ett typiskt exempel på en som inte kan utformas i Gränssnittsbyggaren, varken genom StoryBoards eller NIBs. Istället är det helt implementerat genom kod. För att upprätthålla Storyboards visuella flöde väljer vi att lägga till en tom vykontroll till Storyboard, implementera taggmolnvyn som en fristående vy och programmatiskt lägga till vyn i vykontrollen. Det är uppenbart att vyn också kan implementeras i view controller snarare än som en fristående vy, men vi håller dem åtskilda för bättre återanvändning.

en riktigt grundläggande mock-up kan se ut:

med det har vi skisserat den grundläggande konstruktionen av en rimligt sofistikerad iOS-app vars kärnvyer knyter samman våra tre primära tillvägagångssätt för UI-design. Kom ihåg: det finns inget binärt beslut att fatta, eftersom varje verktyg har sina styrkor och svagheter.

inslagning upp

som undersökts i denna turtorial, Storyboards lägga till en märkbar förenkling till iOS UI design och visuellt flöde. De eliminerar också standardtext kod; men allt detta kommer till ett pris, betalas i flexibilitet. NIBs erbjuder under tiden mer flexibilitet genom att fokusera på en enda vy, men utan visuellt flöde. Den mest flexibla lösningen är naturligtvis kod, som tenderar att vara ganska ovänlig och i sig icke-visuell.

om den här artikeln fascinerade dig rekommenderar jag starkt att du tittar på den stora debatten från Ray Wenderlich, 55-minuter som spenderas på en diskussion om NIBs, Storyboards och kodgjorda UIS.

avslutningsvis vill jag betona en sak: Undvik att använda det felaktiga iOS UI-designverktyget till varje pris. Om en vy inte kan designeras med en Storyboard, eller om den kan implementeras med NIBs eller kod på ett enklare sätt, Använd inte en Storyboard. På samma sätt, om en vy inte kan designeras med NIBs, använd inte NIBs. Dessa regler, medan enkla, kommer att gå långt i din utbildning som utvecklare.