Jeg hører ofte iOS-utviklere still en variant av det samme nøkkelspørsmålet:

Hva er den beste måten å utvikle et brukergrensesnitt i iOS: gjennom Storyboards, NIB-er eller kode?

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

Jeg er av den oppfatning at svaret i stedet bør ta form av en eller flere disk spørsmål.

Hva er den 'beste' bilen?

La meg forklare med et utenfor-emneeksempel. Si at jeg vil kjøpe en bil, og jeg stiller deg ett enkelt spørsmål: 'Hva er det beste valget?'

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

• Hva er budsjettet ditt?
• Hvor mange seter trenger du?
• Bryr du deg om drivstofforbruk?
• Hvordan har du det med sportsbiler?

Det er åpenbart at det ikke er noe som heter a god eller dårlig bil med mindre den er plassert i 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, 'Hva er den beste måten å utvikle et iOS-brukergrensesnitt' spørsmål mangler sammenheng. Og overraskende nok trenger ikke svaret å være en sak.

I det store og hele er det tre typer tilnærminger for brukergrensesnittdesign du kan ta, hver med sine fordeler og ulemper, fans og hatere:

• iOS Storyboards : Et visuelt verktøy for å legge ut flere applikasjonsvisninger og overgangene mellom dem.
• NIB (eller XIB) : Hver NIB-fil tilsvarer et enkelt visningselement og kan legges ut i Interface Builder, noe som også gjør det til et visuelt verktøy. Merk at navnet “NIB” er avledet fra filtypen (tidligere .nib og nå .xib, selv om den gamle uttalen har vedvaret).
• Egendefinert kode : dvs. nei GUI verktøy, men heller å håndtere all tilpasset posisjonering, animasjon osv. programmatisk.

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

Storyboards , for eksempel, er det siste tilskuddet til iOS UI-verktøysettet. Jeg har blitt fortalt at de er fremtiden, at de vil erstatte NIB-er og tilpassede kode-brukergrensesnitt. Jeg ser Storyboards som et nyttig verktøy, men ikke så mye a erstatning ha en komplement for NIB-er og tilpasset kode. Storyboards er det riktige valget i noen, men ikke i 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 som er tilgjengelig?

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 listen over programvareutviklingsprinsipper: Det er ikke noe universelt språk, rammeverk eller teknologi som er det universelle beste valget for ethvert programvareutviklingsproblem. Det samme gjelder for iOS UI-design.

I denne iOS-utviklingsveiledningen skal vi utforske hver av disse metodene og introdusere brukstilfeller der de burde og burde ikke ansatt, samt måter de kan blandes sammen.

iOS Storyboards

En klassisk nybegynnerfeil er å lage et stort prosjektomfattende iOS Storyboard. Jeg gjorde også denne feilen da jeg først begynte å jobbe med Storyboards (sannsynligvis fordi det er en fristende vei å ta).

En klassisk nybegynnerfeil er å lage et massivt prosjektomfattende Storyboard. Et storyboard er et brett med en historie å fortelle. Den skal ikke brukes til å blande ubeslektede historier i ett stort volum.

Som navnet antyder, er et Storyboard et brett med en historie å fortelle . Den skal ikke brukes til å blande ubeslektede historier i ett stort volum. Et storyboard bør inneholde visningskontrollere som er logisk relatert til hverandre - noe som ikke betyr hver se kontrolleren.

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

• Et sett med visninger for autentisering og registrering.
• En inngangsflyt i flere trinn.
• En veiviselignende (dvs. veiledning) flyt.
• Et mester-detalj sett med visninger (f.eks. Profillister, profildetaljer).

I mellomtiden bør store Storyboards unngås, inkludert Storyboards med én app (med mindre appen er relativt enkel). La oss se hvorfor før vi går dypere.

The Folly of Large iOS Storyboards

Store storyboards, annet enn å være vanskelige å bla gjennom og vedlikeholde, legger til et lag med kompleksitet i et teammiljø: når flere utviklere jobber med samme storyboard-fil samtidig, konflikter med kildekontroll er uunngåelig . Og mens et storyboard internt er representert som en tekstfil (faktisk en XML-fil), er sammenslåing vanligvis ikke trivielt.

Når utviklere ser kildekoden, tilskriver de den semantiske betydning. Så når de slås sammen manuelt, er de i stand til å lese og forstå begge sider av en konflikt og handle deretter. Et storyboard er i stedet en XML-fil som administreres 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 (bruker autolayout), og sistnevnte skyver endringen sin, og produserer en konflikt som denne (legg merke til de motstridende attributtene id):

id

alloc i seg selv gir ingen indikasjoner på dens virkelige betydning, så du har ingenting å jobbe med. Den eneste meningsfylte løsningen er å velge en av de to sidene av konflikten og kaste den andre. Vil det være bivirkninger? Hvem vet? Ikke deg.

For å lette disse designproblemene i iOS-grensesnittet, er det anbefalt å bruke flere storyboards i samme prosjekt.

Når skal du bruke storyboards

Storyboards brukes best med flere sammenkoblede visningskontrollere, da deres største forenkling er å bytte mellom visningskontrollere. I noen grad kan de betraktes som en sammensetning av NIB-er med visuelle og funksjonelle strømmer mellom visningskontrollere.

Storyboards brukes best med flere sammenkoblede visningskontrollere, da deres største forenkling er å bytte mellom visningskontrollere.

Foruten å lette navigasjonsflyten, er en annen distinkt fordel at de eliminerer kjelekoden som trengs for å pope, skyve, presentere og avvise visningskontrollere. Videre tildeles visningskontrollere automatisk, så det er ikke nødvendig å manuelt init og prepareForSegue:sender.

Til slutt, mens Storyboards best brukes 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 prototyper på bordceller hjelper med å holde brikkene sammen.
• Flere cellemaler kan utformes inne i den overordnede tabellvisningskontrolleren.
• Det er mulig å lage statiske tabellvisninger (et etterlengtet tillegg som dessverre bare er tilgjengelig på Storyboards).

Man kan hevde at flere cellemaler også kan utformes ved hjelp av NIBer. 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 Ikke å bruke iOS Storyboards

Noen få tilfeller:

• Visningen har et komplisert eller dynamisk oppsett, best implementert med kode.
• Visningen er allerede implementert med NIB-er eller kode.

I slike tilfeller kan vi enten la utsikten ligge utenfor Storyboard eller legge den inn i en visningskontroller. Førstnevnte bryter Storyboard's visuelle flyt, men har ingen negative funksjonelle eller utviklingsmessige implikasjoner. Sistnevnte beholder denne visuelle strømmen, 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 sans for når Storyboards er nyttige i iOS UI-design , og før vi går videre til NIB i denne veiledningen, 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 øyeblikkelig instantiert. Heldigvis er dette bare en abstraksjon og ikke sant for den faktiske implementeringen: i stedet opprettes bare den opprinnelige visningskontrolleren. De andre visningskontrollene instanseres dynamisk, enten når et segment utføres eller manuelt fra kode.

Pro: Prototyper

Storyboards forenkler prototyping og spott av brukergrensesnitt og strømme. Egentlig kan en komplett fungerende prototypeapplikasjon med visninger og navigering enkelt implementeres ved hjelp av Storyboards og bare noen få linjer med kode.

Med: Gjenbrukbarhet

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 kan en enkelt visningskontroller ikke ekstraheres individuelt og gjenbrukes andre steder som en enkelt uavhengig enhet; det er avhengig av at resten av Storyboard fungerer.

Med: Dataflyt

Data må ofte sendes mellom visningskontrollere når en app overgår. Storyboardets visuelle flyt er imidlertid brutt i dette tilfellet, da det ikke er spor av dette som skjer i Interface Builder. Storyboards tar seg av håndteringen av flyten mellom visningskontrollere, men ikke datastrømmen. Så må destinasjonskontrolleren konfigureres med kode, og overstyrer den visuelle opplevelsen.

Storyboards tar seg av håndteringen av flyten mellom visningskontrollere, men ikke datastrømmen.

I slike tilfeller må vi stole på et - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier [email protected] 'segue_name_1']) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier [email protected] 'segue_name_2']) { ... } else if ... } , med et if / else-if skjelett som dette:

TTLoginView

Jeg synes denne tilnærmingen er utsatt for feil og unødvendig utførlig.

NIBer

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

I dette tilfellet betyr ikke 'gammel' ikke 'dårlig', 'utdatert' eller 'utdatert'. Det er faktisk viktig å forstå at iOS Storyboards ikke er en universell erstatning for NIB-er; de forenkler bare UI-implementeringen i noen saker.

Med NIB-er kan ethvert vilkårlig syn utformes, som utvikleren deretter kan feste til en visningskontroller etter behov.

Hvis vi bruker objektorientert design på brukergrensesnittene våre, er det fornuftig å bryte en visningskontrollers syn 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.

NIB-er deler konfliktproblemene vi så med Storyboards, men i mindre grad, ettersom NIB-filer fungerer i mindre skala.

Når skal du bruke NIB-er for iOS UI-design

En delmengde av alle bruksområder vil være:

• Modal visninger
• Enkel påloggings- og registreringsvisning
• Innstillinger
• Popup-vinduer
• Gjenbrukbare visningsmaler
• Gjenbrukbare tabellcellemaler

I mellomtiden…

Når Ikke å bruke NIBer

Du bør unngå å bruke NIBer til:

• Visninger med dynamisk innhold, der oppsettet endres betydelig avhengig av innholdet.
• Visninger som av natur ikke er lett designbare i Interface Builder.
• Se kontrollere med kompliserte overganger som kan forenkles med Storyboarding.

Generelle fordeler og ulemper

Mer generelt, la oss gå gjennom fordeler og ulemper ved å bruke NIB-er.

Pro: Gjenbrukbarhet

NIB-er kommer til nytte når samme layout deles på tvers av flere klasser.

Som en enkel brukstilfelle kan en visningsmal som inneholder et brukernavn og et passordtekstfelt implementeres med det hypotetiske TTSignupView og TTLoginView synspunkter, som begge kan stamme fra samme NIB.

måtte skjule passordfeltet, og begge måtte spesifisere korresponderende statiske etiketter (for eksempel ‘Skriv inn brukernavnet ditt’ mot ‘Angi passordet ditt’), men etikettene ville ha samme grunnleggende funksjonalitet og lignende oppsett.

Pro & Con: Ytelse

NIB er lat lastet , slik at de ikke bruker minne før de må. Selv om dette kan være en fordel, er det latens for den dovne lasteprosessen, noe som også gjør det til en ulempe.

iOS-tilpasset kode (programmatiske brukergrensesnitt)

Noen iOS-grensesnittdesign som kan gjøres med Storyboards og NIB-er kan også implementeres med rå kode (det var selvfølgelig en tid da utviklere ikke hadde den luksusen å ha et så rikt sett med verktøy).

Det som ikke kan gjøres med NIBer og Storyboards, kan alltid implementeres med kode.

Enda viktigere, det som ikke kan gjøres med NIBer og Storyboards kan alltid implementeres med kode - forutsatt, selvfølgelig, at det er teknisk mulig. En annen måte å se på det er at NIBer og Storyboards implementeres med kode, så funksjonaliteten deres vil naturligvis være en delmengde. La oss hoppe rett inn i fordeler og ulemper.

Pro: Under hetten

Den største fordelen med å lage et iOS-brukergrensesnitt programmatisk: hvis du vet hvordan du skal kode et brukergrensesnitt, så vet du hva som skjer under panseret , mens det samme ikke nødvendigvis gjelder NIB og Storyboards.

For å gjøre en sammenligning: 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 ethvert visuelt RAD-verktøy (f.eks. Visual Studio og Delphi, for bare å nevne noen). Visuelle HTML RAD-miljøer representerer en typisk borderline-sak: de brukes til å generere (ofte dårlig skrevet) kode, og hevder at ingen HTML-kunnskap er nødvendig, og at alt kan gjøres visuelt. Men ingen webutvikler ville implementere en webside uten å gjøre hendene skitne: De vet at manuell håndtering av rå HTML og CSS vil føre til mer modulær og mer effektiv kode.

Så å mestre kodingen av iOS-brukergrensesnitt gir deg mer kontroll over og større bevissthet om hvordan disse delene passer sammen, noe som øker din øvre grense som utvikler.

Pro: Når kode er det eneste alternativet

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

Pro: Slå sammen konflikter

Mens NIB-er og Storyboards led betydelig av sammenslåingskonflikter, har ikke kode den samme feilen. All kode har semantisk betydning, så å løse konflikter er ikke vanskeligere enn vanlig.

Med: Prototyping

Det er vanskelig å finne ut hvordan en layout vil se ut før du ser den i aksjon. Videre kan du ikke visuelt posisjonere visninger og kontroller, så å oversette layoutspesifikasjoner til en håndgripelig visning kan ta mye lengre tid, sammenlignet med NIBer og Storyboards som gir deg en umiddelbar forhåndsvisning av hvordan ting vil gjengis.

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 egendefinerte metoder og magiske tall, kan feilsøkingsøkter bli vanskelige.

Pro: Ytelse

Når det gjelder ytelse, er Storyboards og NIB-er underlagt belastning og parsing; og til slutt blir de indirekte oversatt til kode. Det er unødvendig å si at dette ikke skjer med kodelagde brukergrensesnitt.

Pro: Gjenbrukbarhet

Enhver visning implementert programmatisk kan utformes på en gjenbrukbar måte. La oss se noen få bruksområder:

• To eller flere visninger deler en felles oppførsel, men de er litt forskjellige. En basisklasse og to underklasser løser problemet elegant.
• Et prosjekt må gaffles, med sikte på å lage 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 NIBer og Storyboards. Malfiler tillater ikke arv, og de mulige løsningene er begrenset til følgende:

• Dupliser NIB- og Storyboard-filene. Etter det har de separate liv og ikke noe forhold til originalfilen.
• Overstyr utseendet og oppførselen med kode, som kan fungere i enkle tilfeller, men kan føre til betydelig komplikasjon hos andre. Tunge overstyringer med kode kan også gjøre visuell design ubrukelig og utvikle seg til en konstant kilde til hodepine, for eksempel når en bestemt kontroll vises på en måte i Interface Builder, men ser helt annerledes ut når appen kjører.

Når skal du bruke kode

Det er ofte en god oppfordring å bruke bruk av tilpasset kode for iOS-brukergrensesnittdesign når du har:

• Dynamiske oppsett.
• Visninger med effekter, for eksempel avrundede hjørner, skygger osv.
• Ethvert tilfelle der bruk av NIBer og Storyboards er komplisert eller gjennomførbart.

Når Ikke å bruke kode

Generelt kan kodelagde brukergrensesnitt alltid bli brukt. De er sjelden en dårlig idé, så jeg vil sette en her.

Selv om NIB-er og Storyboards gir noen fordeler med tabellen, føler jeg at det ikke er noen rimelig ulempe at jeg vil legge inn en liste for å motvirke kodebruk (bortsett fra latskap).

Ett prosjekt, flere verktøy

Storyboards, NIB-er og kode er tre forskjellige verktøy for å bygge iOS-brukergrensesnitt. Vi er heldige som har dem. Fanatikere av programmatiske brukergrensesnitt tar sannsynligvis ikke 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 hærkniven tre verktøy som kan brukes samtidig, i samme prosjekt, effektivt.

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

• Gruppere alle relaterte skjermer i separate grupper, og implementer hver gruppe med sitt eget distinkte Storyboard.
• Design ikke-gjenbrukbare bordceller på plass med et Storyboard, inne i tabellvisningskontrolleren.
• Design gjenbrukbare bordceller i NIBer for å oppmuntre til gjenbruk og unngå repetisjon, men last disse NIB-ene gjennom tilpasset kode.
• Design tilpassede visninger, kontroller og mellomliggende objekter ved hjelp av NIBer.
• Bruk kode for svært dynamiske visninger, og mer generelt for visninger som ikke er lett implementerbare via Storyboards og NIB, mens huset viser overganger i et Storyboard.

For å lukke, la oss se på et siste eksempel som binder det hele sammen.

En enkel brukstilfelle

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 meldeskjema.
• En skyskyvisning som viser de forskjellige kodene som brukes i brukermeldinger, med hver tag som er proporsjonal i størrelse med antall ganger den er brukt.

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

• Ved å klikke på et element i listen over venner som følges, vises profilene til den aktuelle vennen.
• Profildetaljene viser profilnavnet, adressen, statistikken, en kort liste over de siste meldingene og en verktøylinje.

For å implementere denne iOS-appen, vil alle tre UI-verktøyene våre være nyttige, slik vi kan bruke:

• Et Storyboard med fire visningskontrollere (listen, detaljer, liste over meldinger og nytt meldingsskjema).
• En egen NIB-fil for den gjenbrukbare profillistecellemalen.
• Tre separate NIB-filer for profildetaljvisningen, en for hver av de separate seksjonene som komponerer den (profildetaljer, statistikk, de siste tre meldingene), for å gi bedre vedlikeholdsevne. Disse NIB-ene blir instansert som visninger og deretter lagt til visningskontrolleren.
• Tilpasset kode for tag sky view. Denne visningen er et typisk eksempel på en som ikke kan utformes i Interface Builder, verken gjennom StoryBoards eller NIB. I stedet er den fullstendig implementert gjennom kode. For å opprettholde Storyboard's visuelle flyt, velger vi å legge til en tom visningskontroller i Storyboardet, implementere tag skyvisningen som en frittstående visning og programmatisk legge til visningen til visningskontrolleren. Visningen kan tydeligvis også implementeres i visningskontrolleren i stedet for som et frittstående syn, men vi holder dem skilt for bedre gjenbruk.

En veldig grunnleggende mock-up kan se ut:

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

Innpakning

Som undersøkt i denne tårnet, legger Storyboards en merkbar forenkling til ios UI design og visuell flyt. De eliminerer også kjeleplatekoden; men alt dette har en pris, betalt i fleksibilitet. I mellomtiden tilbyr NIBer 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 brukt godt på en diskusjon av NIB, Storyboards og kodelaget UIS.

Til slutt vil jeg understreke en ting: Unngå å bruke det upassende designverktøyet for iOS UI for enhver pris . Hvis en visning ikke kan designes med et Storyboard, eller hvis den kan implementeres med NIB-er eller kode på en enklere måte, ikke gjør det bruk et Storyboard. På samme måte, hvis en visning ikke kan designes ved hjelp av NIB-er, må du ikke bruke NIB-er. Selv om disse reglene er enkle, kommer de langt i utdannelsen din som utvikler.