iOS Brukergrensesnitt: Storyboards vs NIBs vs Custom Code

jeg hører ofte iOS-utviklere spør noen variant av det samme nøkkelspørsmålet:

Hva er den beste måten å utvikle ET BRUKERGRENSESNITT på i iOS: Gjennom Storyboards, NIBs eller kode?

Svar på dette spørsmålet, eksplisitt eller implisitt, har en tendens til å anta at det er et gjensidig utelukkende valg som skal gjøres, en som ofte adresseres på forhånd, før utvikling.

jeg er av den oppfatning at svaret i stedet skal ta form av ett eller flere motspørsmål.

Hva er den «beste» bilen?

La meg forklare med et off-topic eksempel. Si at jeg vil kjøpe en bil, og jeg spør deg et enkelt spørsmål: «Hva er det beste valget?»

kan du virkelig svare ved å foreslå en modell, eller til og med et merke? Ikke sannsynlig, med mindre du foreslår En Ferrari. I stedet vil du sannsynligvis svare med noen andre spørsmål, som:

• hva er budsjettet ditt?
• hvor mange seter trenger du?
• bryr du deg om drivstofforbruket?
• hva synes du om sportsbiler?

det er åpenbart at det ikke er noe som en god eller dårlig bil med mindre den er plassert i en riktig sammenheng—det er bare en god eller dårlig bil basert på spesifikke behov.

Tilbake til iOS UI Design

akkurat som med vår bilforespørsel, mangler spørsmålet «Hva er den beste måten å utvikle et iOS UI» kontekst. Og overraskende nok, svaret trenger ikke være en catch-all sak.

Stort sett er det tre typer brukergrensesnitt design tilnærminger som du kan ta, hver med sine fordeler og ulemper, sine fans og haters:

• iOS Storyboards: et visuelt verktøy for å legge ut flere applikasjonsvisninger og overgangene mellom dem.
• NIBs (Eller XIBs): Hver NIB-fil tilsvarer et enkelt visningselement og kan legges ut i Grensesnittbyggeren, noe som gjør Det til et visuelt verktøy også. Merk at navnet «NIB» er avledet fra filtypen (tidligere .nib og nå .xib, selv om den gamle uttalen har vedvart).
• Tilpasset Kode: dvs. ingen GUI-verktøy, men heller, håndtering av all tilpasset posisjonering, animasjon, etc. programmatisk.

Ingen av disse alternativene er universelt bedre enn noen andre(til tross for hva du kanskje hører).

Storyboards, for eksempel, er det nyeste tilskuddet til iOS UI toolkit. Jeg har blitt fortalt at de er fremtiden, at de vil erstatte NIBs og tilpasset kode UIs. Jeg ser Storyboards som et nyttig verktøy, men ikke så mye en erstatning som et supplement Til NIBs og tilpasset kode. Storyboards er det riktige valget i noen, men ikke alle situasjoner.

Videre, Hvorfor skal du statisk holde deg til et enkelt alternativ når du kan bruke dem alle (i samme prosjekt), og velge den mekanismen som passer best til det spesifikke problemet ved hånden?

Dette er et spørsmål som etter min mening kan generaliseres på et høyere nivå, og hvis svar er rangert høyt i min liste over programvareutviklingsprinsipper: Det er ikke universelt språk, rammeverk eller teknologi som er det universelle beste valget for hvert programvareutviklingsproblem. Det samme gjelder for iOS UI design.

i denne iOS-utviklingsopplæringen skal vi utforske hver av disse metodene og introdusere brukssaker der de skal og ikke skal brukes, samt måter de kan blandes sammen på.

iOS Storyboards

en klassisk nybegynners feil er å skape et massivt prosjektomfattende iOS Storyboard. Jeg gjorde også denne feilen da jeg først begynte å jobbe Med Storyboards (sannsynligvis fordi det er en fristende rute å ta).

som navnet tilsier, Er Et Storyboard et brett med en historie å fortelle. Det bør ikke brukes til å blande urelaterte historier i ett stort volum. Et storyboard skal inneholde visningskontrollere som er logisk relatert til hverandre-noe som ikke betyr alle visningskontrollere.

for eksempel er det fornuftig å bruke Storyboards når du håndterer:

• et sett med visninger for godkjenning og registrering.
• en flertrinns bestillingsflyt.
• en veiviser-lignende (dvs. opplæring) flyt.
• et hoveddetaljsett med visninger(f. eks. profillister, profildetaljer).

I Mellomtiden bør store Storyboards unngås, inkludert single app-wide Storyboards (med mindre appen er relativt enkel). Før vi går dypere, la oss se hvorfor.

Dårskapen Til Store iOS-Storyboards

Store Storyboards, annet enn å være vanskelig å bla gjennom og vedlikeholde, legger til et lag av kompleksitet i et lagmiljø: når flere utviklere jobber på samme storyboard-fil samtidig, er kildekontrollkonflikter uunngåelige. Og mens et storyboard er internt representert som en tekstfil (EN XML-fil, faktisk), er sammenslåing vanligvis ikke-trivial.

når utviklere vise kildekoden, tilskriver de det semantisk betydning. Så når de slås sammen manuelt, kan de lese og forstå begge sider av en konflikt og handle deretter. Et storyboard er i stedet EN XML-fil administrert Av Xcode, og betydningen av hver kodelinje er ikke alltid lett å forstå.

La oss ta et veldig enkelt eksempel: si at to forskjellige utviklere endrer posisjonen til en UILabel (ved hjelp av autolayout), og sistnevnte skyver sin endring, og produserer en konflikt som dette (legg merke til de motstridende id attributter):

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

id selv gir ingen indikasjon på dens sanne betydning, så du har ingenting å jobbe med. Den eneste meningsfulle løsningen er å velge en av de to sidene av konflikten og kaste bort den andre. Vil det være bivirkninger? Hvem vet? Ikke du.

for å lette disse iOS-grensesnittdesignproblemene, er det anbefalt å bruke flere storyboards i samme prosjekt.

Når Du Skal Bruke Storyboards

Storyboards brukes best med flere sammenkoblede visningskontrollere, da deres store forenkling er i overgang mellom visningskontrollere. Til en viss grad kan de betraktes som en sammensetning Av Nib med visuelle og funksjonelle strømmer mellom visningsregulatorer.

I Tillegg til å lette navigasjonsflyten, er en annen klar fordel at de eliminerer standardtekstkode som trengs for å pop, skyve, presentere og avvise visningskontrollere. Videre tildeles visningskontrollere automatisk, så det er ikke nødvendig å manuelt alloc og init.

Til Slutt, Mens Storyboards er best brukt til scenarier som involverer flere visningskontrollere, er det også forsvarlig å bruke Et Storyboard når du arbeider med en enkelt tabellvisningskontroller av tre grunner:

• evnen til å designe bordcelleprototyper på plass bidrar til å holde brikkene sammen.
• Flere cellemaler kan utformes inne i overordnet tabellvisning kontrolleren.
• Det er mulig å lage statiske tabellvisninger (et etterlengtet tillegg som dessverre bare er tilgjengelig i Storyboards).

man kan hevde at flere cellemaler også kan utformes ved Hjelp Av NIBs. I sannhet er dette bare et spørsmål om preferanse: noen utviklere foretrekker å ha alt på ett sted, mens andre ikke bryr seg.

når du Ikke Skal Bruke iOS Storyboards

Noen tilfeller:

• visningen har en komplisert eller dynamisk layout, best implementert med kode.
• visningen er allerede implementert Med NIBs eller kode.

i slike tilfeller kan vi enten legge visningen ut Av Storyboardet eller legge den inn i en visningskontroller. Den tidligere bryter Storyboardet visuelle flyt, men har ingen negative funksjonelle eller utviklingsmessige implikasjoner. Sistnevnte beholder denne visuelle flyten, men det krever ytterligere utviklingsarbeid da visningen ikke er integrert i visningskontrolleren: den er bare innebygd som en komponent, derfor må visningskontrolleren samhandle med visningen i stedet for å implementere den.

Generelle Fordeler Og Ulemper

Nå som vi har en følelse av Når Storyboards er nyttige i iOS UI-design, og før vi går videre Til NIBs i denne opplæringen, la oss gå gjennom deres generelle fordeler og ulemper.

Pro: Ytelse

Intuitivt kan Du anta at når Et Storyboard er lastet, blir alle visningskontrollene påbegynt umiddelbart. Heldigvis er dette bare en abstraksjon og ikke sant for den faktiske implementeringen: i stedet er bare den første visningskontrolleren, hvis noen, opprettet. De andre visningskontrollene startes dynamisk, enten når en segue utføres eller manuelt fra kode.

Pro: Prototyper

Storyboards forenkle prototyping og tentamen opp av brukergrensesnitt og flyt. Faktisk kan en komplett fungerende prototype applikasjon med visninger og navigasjon enkelt implementeres ved Hjelp Av Storyboards og bare noen få linjer med kode.

Con: Gjenbruk

når det gjelder flytting eller kopiering, er iOS Storyboards dårlig plassert. Et Storyboard må flyttes sammen med alle sine avhengige visningskontrollere. Med andre ord, en enkelt visningskontroller kan ikke individuelt trekkes ut og gjenbrukes andre steder som en enkelt uavhengig enhet; det er avhengig av resten Av Storyboardet for å fungere.

Con: dataflyt

Data må ofte sendes mellom visningskontrollere når en app overgår. Imidlertid Er Storyboardet visuelle flyt brutt i dette tilfellet, da det ikke er spor av dette som skjer i Grensesnittbyggeren. Storyboards tar seg av å håndtere strømmen mellom visningskontrollere, men ikke strømmen av data. Så, målkontrolleren må konfigureres med kode, som overstyrer den visuelle opplevelsen.

i slike tilfeller må vi stole på en prepareForSegue:sender, med et if/else-if skjelett som dette:

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

jeg finner denne tilnærmingen å være feil utsatt og unødvendig verbose.

NIBs

NIBs er den gamle måten å utføre iOS-grensesnittdesign på.

i dette tilfellet betyr «gammel» ikke «dårlig», «utdatert» eller «utdatert». Faktisk er det viktig å forstå at iOS Storyboards ikke er en universell erstatning for NIBs; de forenkler BARE UI-implementeringen i noen tilfeller.

med NIBs kan enhver vilkårlig visning utformes, som utvikleren deretter kan legge til en visningskontroller etter behov.

hvis vi bruker objektorientert design til Våre UIs, er det fornuftig å bryte en visningskontrollerens visning ned i separate moduler, hver implementert som en visning med sin EGEN NIB-fil (eller med flere moduler gruppert i samme fil). Den klare fordelen med denne tilnærmingen er at hver komponent er lettere å utvikle, lettere å teste og lettere å feilsøke.

NIBs deler fusjonskonfliktproblemene vi så Med Storyboards, men i mindre grad, da NIB-filer opererer i mindre skala.

Når Du Skal Bruke NIBs for iOS UI Design

Et delsett av alle bruksområder ville være:

• Modale visninger
• enkel pålogging og registrering visninger
• Innstillinger
• Popup-vinduer
• gjenbrukbare visningsmaler
• Gjenbrukbare tabellcellemaler

I Mellomtiden…

når du ikke skal bruke nibs

du bør unngå å bruke nibs for:

• Visninger med dynamisk innhold, der oppsettet endres vesentlig avhengig av innhold.
• Visninger som av natur ikke lett kan utformes i Grensesnittbyggeren.
• Vis kontrollere med kompliserte overganger som kan forenkles med Storyboarding.

Generelle Fordeler Og Ulemper

Mer generelt, la oss gå gjennom fordeler og ulemper ved Å bruke NIBs.

Pro: Gjenbrukbarhet

Nib er nyttig når samme layout deles på tvers av flere klasser.

som en enkel brukstilfelle kan en visningsmal som inneholder et brukernavn og et passord tekstfelt implementeres med de hypotetiske TTLoginView og TTSignupView visningene, som begge kan stamme fra samme SPISS. TTLoginView må skjule passordfeltet, og begge må spesifisere tilsvarende statiske etiketter (for eksempel ‘Skriv inn brukernavn’ vs ‘Skriv inn passordet ditt’), men etikettene vil ha samme grunnleggende funksjonalitet og lignende oppsett.

Pro & Con: Ytelse

Nib er lazily lastet, slik at de ikke bruker minne før de må. Selv om dette kan være en fordel, er det latens til lat lasting prosessen, noe som gjør det noe av en ulempe også.

iOS Tilpasset Kode (Programmatisk UIs)

enhver iOS-grensesnittdesign som kan gjøres Med Storyboards og NIBs, kan også implementeres med raw-kode (det var selvfølgelig en tid da utviklere ikke hadde luksusen til et så rikt sett med verktøy).

kanskje enda viktigere, hva som ikke kan gjøres Med NIBs og Storyboards kan alltid implementeres med kode-forutsatt at det selvfølgelig er teknisk mulig. En annen måte å se på det er At NIBs og Storyboards er implementert med kode, så deres funksjonalitet vil selvsagt være en delmengde. La oss hoppe rett inn i fordeler og ulemper.

Pro: Under Panseret

den største fordelen med å lage en iOS UI programmatisk: hvis du vet hvordan å kode et brukergrensesnitt, så vet du hva som skjer under panseret, mens det samme er ikke nødvendigvis sant For NIBs og Storyboards.

for å sammenligne: en kalkulator er et nyttig verktøy. Men det er ikke dårlig å vite hvordan man utfører beregninger manuelt.

Dette er ikke begrenset til iOS, men til noe visuelt RADVERKTØY (F.eks. Visual HTML RAD miljøer representerer en typisk borderline sak: de brukes til å generere (ofte dårlig skrevet) kode, hevder at INGEN HTML kunnskap er nødvendig, og at alt kan gjøres visuelt. Men ingen webutvikler ville implementere en nettside uten å få hendene skitne: de vet at manuell håndtering av rå HTML og CSS vil føre til mer modulær, mer effektiv kode.

så, mestre koding av iOS brukergrensesnitt gir deg mer kontroll over og større bevissthet om hvordan disse brikkene passer sammen, som hever øvre bundet som utvikler.

Pro: Når Kode Er Det Eneste Alternativet

er det også tilfeller der tilpasset iOS-kode er det eneste alternativet for UI-design. Dynamiske layouter, der visningselementer flyttes rundt og flyten eller oppsettet justeres betydelig basert på innhold, er typiske eksempler.

Pro: Flett Konflikter

Mens NIBs og Storyboards led betydelig fra flettekonflikter, har koden ikke den samme feilen. All kode har semantisk betydning, så det er ikke vanskeligere å løse konflikter enn vanlig.

Con:Prototyping

det er vanskelig å finne ut hvordan en layout vil se ut før du sett den i aksjon. Videre kan du ikke visuelt plassere visninger og kontroller, så det kan ta mye lengre tid å oversette layoutspesifikasjoner til en konkret visning, sammenlignet med NIBs og Storyboards som gir deg en umiddelbar forhåndsvisning av hvordan ting vil gjengi.

Med: Refactoring

Refactoring kode som ble skrevet for lenge siden eller av noen andre blir også mye mer komplisert: når elementer blir plassert og animert med tilpassede metoder og magiske tall, debugging økter kan bli krevende.

Pro: Ytelse

Når det gjelder ytelse, Er Storyboards og NIBs underlagt overhead for lasting og parsing; og til slutt blir de indirekte oversatt til kode. Unødvendig å si, dette skjer ikke med kode-laget UIs.

Pro: Gjenbruk

enhver visning implementert programmatisk kan utformes på en gjenbrukbar måte. La oss se noen brukstilfeller:

• To eller flere visninger deler en felles oppførsel, men de er litt forskjellige. En grunnklasse og to underklasser løser problemet elegant.
• et prosjekt må deles, med sikte på å skape en enkelt kodebase, men generere to (eller flere) forskjellige applikasjoner, hver med spesifikke tilpasninger.

den samme UI designprosessen ville være mye mer komplisert Med NIBs og Storyboards. Malfiler tillater ikke arv, og de mulige løsningene er begrenset til følgende:

• Dupliser NIB-og Storyboard-filene. Deretter har de separate liv og ikke noe forhold til den opprinnelige filen.
• Overstyr utseendet og virkemåten med kode, som kan fungere i enkle tilfeller, men kan føre til betydelig komplikasjon i andre. Tunge overstyringer med kode kan også gjøre visuell design ubrukelig og utvikle seg til en konstant kilde til hodepine, f. eks., når en viss kontroll viser en vei i Grensesnittbyggeren, men ser helt annerledes ut når appen kjører.

Når Du Skal Bruke Kode

det er ofte en god samtale å bruke bruk tilpasset kode for iOS brukergrensesnitt design når du har:

• Dynamiske oppsett.
• Visninger med effekter, for eksempel avrundede hjørner, skygger, etc.
• Alle tilfeller der Bruk Av NIBs og Storyboards er komplisert eller umulig.

når Du Ikke Skal Bruke Kode

generelt kan kodelagde Uier alltid brukes. De er sjelden en dårlig ide, så jeg vil sette en her.

Selv Om NIBs og Storyboards gir noen fordeler til bordet, føler jeg at det ikke er noen rimelig ulempe at jeg ville sette inn en liste for å motvirke kodebruk(unntatt kanskje latskap).

Ett Prosjekt, Flere Verktøy

Storyboards, NIBs og kode er tre forskjellige verktøy for å bygge iOS brukergrensesnitt. Vi er heldige som har dem. Fanatikere av programmatiske UIs vil nok ikke ta hensyn til de to andre alternativene: kode lar deg gjøre alt som er teknisk mulig, mens alternativene har sine begrensninger. For resten Av utviklerne der ute, Gir Xcode army knife tre verktøy som kan brukes på en gang, i samme prosjekt, effektivt.

hvordan spør du? Men du vil. Her er noen mulige tilnærminger:

• Gruppere alle relaterte skjermer i separate grupper, og implementere hver gruppe med sin egen distinkte Storyboard.
• Design ikke-gjenbrukbare tabellceller på plass med Et Storyboard, inne i tabellvisningskontrolleren.
• Design gjenbrukbare tabellceller i Nib for å oppmuntre til gjenbruk og unngå repetisjon, men last Disse Nibene gjennom tilpasset kode.
• Utform egendefinerte visninger, kontroller og mellom objekter ved Hjelp Av NIBs.
• Bruk kode for svært dynamiske visninger, og mer generelt for visninger som ikke er lett implementerbare via Storyboards og NIBs, mens boliger viser overganger i Et Storyboard.

for å lukke, la oss se på et siste eksempel som knytter alt sammen.

En Enkel Use Case

Si At Vi ønsker å utvikle en grunnleggende meldingsapp med flere forskjellige visninger:

• en liste over fulgte venner(med en gjenbrukbar cellemal for å holde BRUKERGRENSESNITTET konsistent på tvers av fremtidige lister).
• en profildetaljvisning, sammensatt i separate seksjoner(inkludert profilinformasjon, statistikk og en verktøylinje).
• en liste over meldinger sendt til og mottatt fra en venn.
• Et nytt meldingsskjema.
• en tag cloud-visning som viser de forskjellige kodene som brukes i brukermeldinger, med hver kode proporsjonal i størrelse til antall ganger den er brukt.

i tillegg vil vi at visningene skal flyte som følger:

• Hvis Du Klikker på et element i listen over fulgte venner, vises den relevante vennens profildetaljer.
• profildetaljene viser profilnavn, adresse, statistikk, en kort liste over de nyeste meldingene og en verktøylinje.

å implementere denne iOS app, alle tre AV VÅRE UI verktøy vil komme godt med, som vi kan bruke:

• Et Storyboard med fire visningskontrollere(listen, detaljer, liste over meldinger og nytt meldingsskjema).
• en egen NIB-fil for cellemalen for gjenbrukbar profilliste.
• Tre separate NIB-filer for profildetaljer-visningen, en for hver av de separate delene som komponerer den (profildetaljer, statistikk, siste tre meldinger), for å gi bedre vedlikehold. Disse NIBs vil bli instantiated som visninger og deretter lagt til vis kontrolleren.
• Tilpasset kode for tag cloud-visningen. Denne visningen er et typisk eksempel på en som ikke kan utformes i Grensesnittbyggeren, verken Gjennom StoryBoards eller NIBs. I stedet er det helt implementert gjennom kode. For å opprettholde Storyboardet visuelle flyt, velger vi å legge til en tom visningskontroller Til Storyboardet, implementere tag cloud view som en frittstående visning, og programmatisk legge visningen til visningskontrolleren. Klart kan visningen også implementeres inne i visningskontrolleren i stedet for som en frittstående visning, men vi holder dem skilt for bedre gjenbruk.

en virkelig grunnleggende mock-up kan se ut:

Med det har vi skissert den grunnleggende konstruksjonen av en rimelig sofistikert iOS-app hvis kjernevisninger knytter sammen våre tre primære tilnærminger til UI-design. Husk: det er ingen binær beslutning å bli gjort, da hvert verktøy har sine styrker og svakheter.

Innpakning

Som undersøkt i denne turtorial, Storyboards legge en merkbar forenkling til iOS UI design og visuell flyt. De eliminerer også standardtekstkode; men alt dette kommer til en pris, betalt i fleksibilitet. NIBs tilbyr i mellomtiden mer fleksibilitet ved å fokusere på en enkelt visning, men uten visuell flyt. Den mest fleksible løsningen er selvfølgelig kode, som har en tendens til å være ganske uvennlig og iboende ikke-visuell.

hvis denne artikkelen fascinerte deg, anbefaler jeg på det sterkeste å se den store debatten Fra Ray Wenderlich, 55 minutter godt brukt på en diskusjon Av NIBs, Storyboards og kode-laget UIS.

avslutningsvis vil jeg understreke en ting: Unngå å bruke feil iOS UI designverktøy for enhver pris. Hvis en visning ikke kan utformes Med Et Storyboard, eller hvis det kan implementeres Med NIBs eller kode på en enklere måte, ikke bruk Et Storyboard. På samme måte, hvis en visning ikke kan utformes ved Hjelp Av NIBs, ikke bruk NIBs. Disse reglene, mens enkle, vil gå langt i utdanningen din som utvikler.