iOS – käyttöliittymät: Storyboards vs. NIBs vs. Custom Code

kuulen usein iOS-kehittäjien kysyvän saman avainkysymyksen muunnelmaa:

mikä on paras tapa kehittää UI iOS: ssä: Storyboards, NIBs, tai koodi?

vastaukset tähän kysymykseen, eksplisiittisesti tai implisiittisesti, ovat taipuvaisia olettamaan, että on tehtävä toisensa poissulkeva valinta, joka usein käsitellään etukäteen, ennen kehitystä.

olen sitä mieltä, että vastauksen pitäisi sen sijaan olla yhden tai useamman vastakysymyksen muodossa.

mikä on” paras ” auto?

selitän aiheen ulkopuolisella esimerkillä. Sano, että haluan ostaa auton ja kysyn sinulta yhden yksinkertaisen kysymyksen: ”Mikä on paras valinta?”

Osaatko oikeasti vastata ehdottamalla mallia tai edes brändiä? Tuskin, ellei ehdoteta Ferraria. Sen sijaan vastaisit varmaan muutamaan kysymykseen, kuten:

• mikä on budjettisi?
• montako paikkaa tarvitset?
• välitätkö polttoaineen kulutuksesta?
• mitä mieltä olet urheiluautoista?

on selvää, ettei hyvää tai huonoa autoa ole olemassa, ellei sitä aseteta oikeaan kontekstiin—on vain hyvä tai huono auto, joka perustuu erityistarpeisiin.

Back to iOS UI Design

aivan kuten autokyselyssämme, ”mikä on paras tapa kehittää iOS UI” – kysymys puuttuu kontekstista. Ja yllättävää kyllä, vastauksen ei tarvitse olla kaiken kattava tapaus.

yleisesti ottaen on olemassa kolmenlaisia käyttöliittymäsuunnittelun lähestymistapoja, joita voit ottaa, joista jokaisella on hyvät ja huonot puolensa, faninsa ja vihaajansa:

• iOS Storyboards: visuaalinen työkalu, jolla luodaan useita sovellusnäkymiä ja niiden välisiä siirtymiä.
• NIBs (tai XIBs): jokainen NIB-tiedosto vastaa yhtä näkymäelementtiä ja se voidaan asettaa rajapinnan rakentajalle, mikä tekee siitä myös visuaalisen työkalun. Huomaa, että nimi ”NIB” on johdettu tiedostopääte (ENT .nib ja nyt .xib, vaikka vanha ääntämys on säilynyt).
• mukautettu koodi: ei GUI-työkaluja, vaan käsittelee kaikkea mukautettua paikannusta, animaatiota jne. ohjelmallisesti.

mikään näistä vaihtoehdoista ei ole yleisesti parempi kuin mikään muu (huolimatta siitä, mitä saatat kuulla).

Storyboards on esimerkiksi uusin lisäys iOS: n KÄYTTÖLIITTYMÄTYÖKALUPAKKIIN. Minulle on kerrottu, että ne ovat tulevaisuutta, että ne korvaavat NIBs: n ja custom code UIs: n. Näen kuvakäsikirjoituksia hyödyllisenä työkaluna, mutta ei niinkään korvaavana vaan NIBs: n ja mukautetun koodin täydentäjänä. Kuvakäsikirjoitukset ovat oikea valinta joissakin, mutta eivät kaikissa tilanteissa.

edelleen, miksi sinun pitäisi staattisesti kiinni yksi vaihtoehto, kun voit käyttää niitä kaikkia (samassa projektissa), poiminta mekanismi, joka parhaiten sopii tiettyyn ongelmaan käsillä?

tämä on kysymys, joka voidaan mielestäni yleistää korkeammalla tasolla, ja jonka vastaus sijoittuu korkealle listassani ohjelmistokehityksen periaatteista: ei ole olemassa universaalia kieltä, kehystä tai teknologiaa, joka olisi universaali paras valinta jokaiseen ohjelmistokehityksen ongelmaan. Sama pätee iOS: n käyttöliittymäsuunnitteluun.

tässä iOS development tutoriaalissa aiomme tutkia jokaista näistä menetelmistä ja esitellä käyttötapauksia, joissa niitä pitäisi ja ei pitäisi käyttää, sekä tapoja, joilla ne voidaan sekoittaa yhteen.

iOS Storyboards

klassinen aloittelijan virhe on luoda yksi massiivinen projektin laajuinen iOS-kuvakäsikirjoitus. Minäkin tein tämän virheen, kun aloin työskennellä Kuvakäsikirjoitusten kanssa (luultavasti siksi, että se on houkutteleva reitti).

nimensä mukaisesti kuvakäsikirjoitus on taulu, jossa on tarina kerrottavana. Sitä ei pitäisi käyttää sekoittamaan toisiinsa liittymättömiä tarinoita yhdeksi isoksi volyymiksi. Kuvakäsikirjoituksen pitäisi sisältää näkymäohjaimet, jotka liittyvät loogisesti toisiinsa-mikä ei tarkoita jokaista näkymäohjainta.

esimerkiksi kuvakäsikirjoituksia on järkevää käyttää käsiteltäessä:

• joukko näkymiä todentamista ja rekisteröintiä varten.
• monivaiheinen tilaussyöttövirta.
• velhomainen (eli tutoriaali) flow.
• yleisyksityiskohtainen katselukokonaisuus (esim.profiililistat, profiilitiedot).

sillä välin tulisi välttää suuria kuvakäsikirjoituksia, mukaan lukien yhden sovelluksen laajuisia kuvakäsikirjoituksia (ellei sovellus ole suhteellisen yksinkertainen). Ennen kuin menemme syvemmälle, katsotaan miksi.

suurten iOS-Kuvakäsikirjoitusten hulluus

suuret Kuvakäsikirjoitukset, muut kuin vaikeat selata ja ylläpitää, lisäävät monimutkaisuuden kerroksen tiimiympäristöön: kun useat kehittäjät työskentelevät samalla kuvakäsikirjoitustiedostolla samaan aikaan, lähdekoodiohjauksen ristiriidat ovat väistämättömiä. Ja vaikka kuvakäsikirjoitus on sisäisesti edustettuna tekstitiedostona (XML-tiedosto, itse asiassa), yhdistäminen on yleensä ei-triviaalia.

kun Kehittäjät tarkastelevat lähdekoodia, he liittävät sen semanttiseen merkitykseen. Kun he sulautuvat manuaalisesti, he pystyvät lukemaan ja ymmärtämään konfliktin molempia osapuolia ja toimimaan sen mukaisesti. Kuvakäsikirjoitus sen sijaan on XML-tiedosto, jota hallinnoi Xcode, eikä jokaisen koodirivin merkitystä ole aina helppo ymmärtää.

otetaan hyvin yksinkertainen esimerkki: sano, että kaksi eri kehittäjää muuttaa UILabel: n asemaa (käyttäen autolayoutia), ja jälkimmäinen työntää muutostaan tuottaen näin ristiriidan (huomaa ristiriitaiset id attribuutit):

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

id ei itsessään anna mitään viitteitä sen todellisesta merkityksestä, joten sinulla ei ole mitään työstettävää. Ainoa mielekäs ratkaisu on valita jompikumpi konfliktin osapuolista ja hylätä toinen. Tuleeko sivuvaikutuksia? Kuka tietää? Et sinä.

näiden iOS-käyttöliittymäsuunnitteluongelmien helpottamiseksi on suositeltavaa käyttää useita kuvakäsikirjoituksia samassa projektissa.

milloin käyttää kuvakäsikirjoituksia

kuvakäsikirjoituksia käytetään parhaiten useiden toisiinsa yhdistettyjen näkymäohjainten kanssa, koska niiden suurin yksinkertaistus on näkymäohjainten välisessä siirtymisessä. Jossain määrin ne voidaan ajatella NIBs: n koostumuksena, jossa on visuaalisia ja toiminnallisia virtauksia näkymäohjaimien välillä.

navigointivirtauksen helpottamisen lisäksi toinen selvä etu on se, että ne poistavat boilerplate-koodin, jota tarvitaan näkymäohjaimien poksauttamiseen, työntämiseen, esittämiseen ja hylkäämiseen. Lisäksi näkymäohjaimet varataan automaattisesti, joten ei tarvitse manuaalisesti alloc ja init.

lopuksi, vaikka kuvakäsikirjoituksia käytetään parhaiten skenaarioissa, joissa on useita näkymäohjaimia, on myös puolustettavissa käyttää kuvakäsikirjoitusta työskenneltäessä yhden taulukon näkymäohjaimen kanssa kolmesta syystä:

• kyky suunnitella pöytäkenno prototyyppejä paikallaan auttaa pitämään palaset yhdessä.
• Kantataulun näkymäohjaimen sisälle voidaan suunnitella useita solumalleja.
• on mahdollista luoda staattisia taulunäkymiä (kauan odotettu lisäys, joka on valitettavasti saatavilla vain Kuvakäsikirjoituksissa).

voidaan väittää, että myös useita solupohjia voidaan suunnitella NIBs: n avulla. Todellisuudessa tämä on vain mieltymyskysymys: jotkut kehittäjät haluavat kaiken yhteen paikkaan, kun taas toiset eivät välitä.

kun ei käytetä iOS Storyboards

muutamia tapauksia:

• näkymä on monimutkainen tai dynaaminen ulkoasu, parhaiten toteutettu koodilla.
• näkymä on jo toteutettu NIBs: llä tai koodilla.

näissä tapauksissa voimme joko jättää näkymän pois kuvakäsikirjoituksesta tai upottaa sen näkymäohjaimeen. Entinen rikkoo kuvakäsikirjoituksen visuaalinen virtaus, mutta ei ole mitään negatiivisia toiminnallisia tai kehityksen vaikutuksia. Jälkimmäinen säilyttää tämän visuaalisen virtauksen, mutta se vaatii lisää kehitystyötä, koska näkymää ei ole integroitu näkymäohjaimeen: se on vain upotettu komponenttina, joten näkymäohjaimen on oltava vuorovaikutuksessa näkymän kanssa sen toteuttamisen sijaan.

yleiset hyvät ja huonot puolet

nyt kun meillä on tunne siitä, milloin Kuvakäsikirjoitukset ovat hyödyllisiä iOS: n käyttöliittymäsuunnittelussa, ja ennen kuin siirrymme NIBs: ään tässä opetusohjelmassa, käydään läpi niiden yleiset edut ja haitat.

Pro: suorituskyky

intuitiivisesti voi olettaa, että kun kuvakäsikirjoitus Ladataan, kaikki sen katseluohjaimet instantioidaan välittömästi. Onneksi tämä on vain abstraktio eikä pidä paikkaansa varsinaisessa toteutuksessa:sen sijaan luodaan vain alkuperäinen näkymäohjain, jos sellainen on. Muut näkymäohjaimet instantioidaan dynaamisesti, joko kun segue suoritetaan tai manuaalisesti koodista.

Pro: prototyypit

Kuvakäsikirjoitukset yksinkertaistavat käyttöliittymien ja flow ’ n prototyyppejä ja pilkkaamista. Itse asiassa täydellinen toimiva prototyyppisovellus, jossa on näkymät ja navigointi, voidaan helposti toteuttaa käyttämällä kuvakäsikirjoituksia ja vain muutamia koodirivejä.

Con: uudelleenkäytettävyys

kun kyse on liikkumisesta tai kopioinnista, iOS: n Kuvakäsikirjoitukset ovat huonosti sijoitettuja. Kuvakäsikirjoituksen on siirrettävä yhdessä kaikkien sen riippuvainen näkymä ohjaimet. Toisin sanoen, yhden näkymän ohjainta ei voida erikseen purkaa ja käyttää uudelleen muualla yhtenä itsenäisenä kokonaisuutena; se on riippuvainen muusta kuvakäsikirjoituksesta toimiakseen.

con: datavirta

tiedot on usein siirrettävä näkymäohjaimien välillä sovelluksen siirtyessä. Kuitenkin, kuvakäsikirjoituksen visuaalinen virtaus on rikki tässä tapauksessa, koska ei ole jälkeäkään tästä tapahtuu käyttöliittymän rakentaja. Kuvakäsikirjoitukset huolehtivat näkymäohjaimien välisen virtauksen käsittelystä, mutta eivät tiedonkulusta. Niin, kohdeohjain on konfiguroitava koodi, ohittaen visuaalinen kokemus.

tällaisissa tapauksissa on turvauduttava prepareForSegue:sender, jossa on tällainen if / else-if-luuranko:

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

mielestäni tämä lähestymistapa on virhealtis ja tarpeettoman monisanainen.

NIBs

NIBs on vanha(er) tapa suorittaa iOS-käyttöliittymäsuunnittelu.

tässä tapauksessa ”vanha ”ei tarkoita” huonoa”,” vanhentunutta ”tai”vanhentunutta”. Itse asiassa, on tärkeää ymmärtää, että iOS kuvakäsikirjoituksia eivät ole universaali korvaava NIBs; ne vain yksinkertaistaa käyttöliittymän täytäntöönpanoa joissakin tapauksissa.

NIBs: llä voidaan suunnitella mikä tahansa mielivaltainen näkymä, jonka kehittäjä voi sitten tarvittaessa liittää näkymäohjaimeen.

jos sovellamme olio-orientoitunutta suunnittelua UIs: ään, on järkevää jakaa näkymäohjaimen näkymä erillisiin moduuleihin, joista jokainen toteutetaan näkymänä omalla NIB-tiedostollaan (tai useammalla moduulilla, jotka on ryhmitelty samaan tiedostoon). Selkeä etu tässä lähestymistavassa on, että jokainen komponentti on helpompi kehittää, helpompi testata ja helpompi debug.

NIBs jakaa näkemämme yhdistymisristiriidat tarinoiden kanssa, mutta vähäisemmässä määrin, sillä NIB-tiedostot toimivat pienemmässä mittakaavassa.

milloin NIBs: ää käytetään iOS: n käyttöliittymäsuunnittelussa

kaikkien käyttötapausten osajoukko olisi:

• Modaalinäkymät
• yksinkertaiset kirjautuminen-ja rekisteröintinäkymät
• Asetukset
• ponnahdusikkunat
• uudelleenkäytettävät katselupohjat
• uudelleenkäytettävät taulukkopohjapohjat

sillä välin…

kun nibs: ää ei saa käyttää

sinun tulee välttää nibs: n käyttöä:

• näkymät dynaamisella sisällöllä, jossa ulkoasu muuttuu merkittävästi sisällöstä riippuen.
• näkemyksiä, jotka eivät luonnostaan ole helposti muotoiltavissa rajapinnan rakentajassa.
• View-ohjaimet, joilla on monimutkaisia siirtymiä, joita voitaisiin yksinkertaistaa Storyboardingilla.

yleiset hyvät ja huonot puolet

yleisemmin, kävellään läpi NIBs: n käytön hyvät ja huonot puolet.

Pro: uudelleenkäytettävyys

Nibsit ovat käteviä, kun sama asettelu on jaettu useammalle luokalle.

yksinkertaisena käyttötapauksena voidaan toteuttaa käyttäjätunnuksen ja salasanatekstikentän sisältävä näkymämalli hypoteettisilla TTLoginView ja TTSignupView näkymillä, jotka molemmat voisivat olla peräisin samasta NIB: stä. TTLoginView olisi piilotettava salasanakenttä, ja molempien olisi määriteltävä vastaavat staattiset tarrat (kuten ”Enter your username” vs ”Enter your password”), mutta tarroissa olisi sama perustoiminto ja samanlaiset asettelut.

Pro & con: suorituskyky

Nibit ovat laiskasti ladattuja, joten ne eivät käytä muistia ennen kuin on pakko. Vaikka tämä voi olla etu, on latenssi laiska lastaus prosessi, joten se jotain haittapuoli samoin.

iOS Custom Code (Programmatic UIs)

mikä tahansa iOS-käyttöliittymäsuunnittelu, joka voidaan tehdä Kuvakäsikirjoituksilla ja NIBs: llä, voidaan toteuttaa myös raw-koodilla (oli tietenkin aika, jolloin kehittäjillä ei ollut ylellisyyttä niin runsaaseen työkalusarjaan).

ehkä vielä tärkeämpää on, että se, mitä ei voi tehdä Nibsillä ja Kuvakäsikirjoituksilla, voidaan aina toteuttaa koodilla—edellyttäen tietysti, että se on teknisesti mahdollista. Toinen tapa tarkastella sitä on, että NIBs ja kuvakäsikirjoituksia toteutetaan koodilla, joten niiden toiminnallisuus on luonnollisesti osajoukko. Hypätään suoraan plussiin ja miinuksiin.

Pro: Konepellin Alla

iOS-käyttöliittymän ohjelmallisen luomisen suurin etu: jos osaat koodata käyttöliittymää, tiedät mitä konepellin alla tapahtuu, kun taas sama ei välttämättä päde Nibsiin ja Storyboardeihin.

vertailun tekemiseksi: Laskin on hyödyllinen työkalu. Mutta se ei ole huono asia tietää, miten suorittaa laskelmia manuaalisesti.

tämä ei rajoitu iOS: ään, vaan mihin tahansa visual RAD-työkaluun (esim.Visual Studio ja Delphi, vain muutamia mainitakseni). Visuaalinen HTML RAD ympäristöt edustavat tyypillinen rajatapaus: niitä käytetään tuottamaan (usein huonosti kirjoitettu) koodia, väittäen, että ei HTML tietoa tarvitaan, ja että kaikki voidaan tehdä visuaalisesti. Mutta yksikään web-kehittäjä ei toteuttaisi web-sivua saamatta käsiään likaiseksi: he tietävät, että raa ’ an HTML: n ja CSS: n käsitteleminen manuaalisesti johtaa modulaarisempaan, tehokkaampaan koodiin.

joten iOS-käyttöliittymien koodauksen hallitseminen antaa sinulle enemmän kontrollia ja suuremman tietoisuuden siitä, miten nämä palaset sopivat yhteen, mikä nostaa yläviistoon kehittäjänä.

Pro: Kun koodi on ainoa vaihtoehto

on myös tapauksia, joissa mukautettu iOS-koodi on ainoa vaihtoehto KÄYTTÖLIITTYMÄSUUNNITTELULLE. Tyypillisiä esimerkkejä ovat dynaamiset asettelut, joissa näkymäelementtejä liikutellaan ja virtaus tai asettelu mukautuu merkittävästi sisällön perusteella.

Pro: Yhdistämisriidat

vaikka NIBs ja Storyboards kärsivät merkittävästi yhdistämisriidoista, koodissa ei ole samaa vikaa. Kaikilla koodeilla on semanttinen merkitys, Joten ristiriitojen ratkaiseminen ei ole tavallista vaikeampaa.

Con: Prototyping

on vaikea hahmottaa, miltä ulkoasu näyttää ennen kuin sen näkee toiminnassa. Lisäksi, et voi visuaalisesti sijainti näkymiä ja valvontaa, joten kääntäminen layout specs konkreettinen näkymä voi kestää paljon kauemmin, verrattuna NIBs ja kuvakäsikirjoituksia, jotka antavat sinulle välittömän esikatselun siitä, miten asiat tekevät.

Con: Refaktorointi

Refaktorointikoodi, joka on kirjoitettu kauan sitten tai jonkun muun toimesta, muuttuu myös paljon monimutkaisemmaksi: kun elementtejä asetellaan ja animoidaan mukautetuilla menetelmillä ja taikanumeroilla, virheenkorjaus sessioista voi tulla vaivalloisia.

Pro: Performance

performance, Storyboards and NIBs are subject to the overhead of loading and parsing; and in end, they ’ re epäsuorasti translated in code. Sanomattakin on selvää, että tämä ei tapahdu koodatuilla UIs-laitteilla.

Pro: Uudelleenkäytettävyys

mikä tahansa ohjelmallisesti toteutettu näkymä voidaan suunnitella uudelleen. Katsotaan muutama käyttötapaus:

• kahdella tai useammalla näkemyksellä on yhteinen käytös, mutta ne ovat hieman erilaisia. Perusluokka ja kaksi alaluokkaa ratkaisevat ongelman tyylikkäästi.
• projekti on haarukoitava siten, että tavoitteena on luoda yksi koodikanta, mutta tuottaa kaksi (tai useampia) erilaista sovellusta, joista jokaisella on omat räätälöintinsä.

sama KÄYTTÖLIITTYMÄSUUNNITTELUPROSESSI olisi paljon monimutkaisempi NIBs-ja Storyboardien kanssa. Mallitiedostot eivät salli perintöä, ja mahdolliset ratkaisut rajoittuvat seuraaviin:

• Kopioi NIB ja kuvakäsikirjoituksen tiedostoja. Sen jälkeen heillä on erilliset elämät eikä mitään suhdetta alkuperäiseen tiedostoon.
• korvaa katse ja käyttäytyminen koodilla, joka voi toimia yksinkertaisissa tapauksissa, mutta voi johtaa merkittäviin komplikaatioihin toisissa. Raskaat ohitukset koodilla voivat myös tehdä visuaalisesta suunnittelusta hyödytöntä ja kehittyä jatkuvaksi päänsäryn aiheuttajaksi esim., kun tietty ohjaus näyttää yhteen suuntaan käyttöliittymän rakentaja, mutta näyttää täysin erilainen, kun sovellus on käynnissä.

kun käyttää koodia

on usein hyvä käyttää mukautettua koodia iOS: n käyttöliittymäsuunnittelussa, kun sinulla on:

• dynaamiset asettelut.
• efekteillä varustetut näkymät, kuten pyöristetyt kulmat, varjot jne.
• kaikki tapaukset, joissa Kuvakäsikirjoitusten ja Kuvakäsikirjoitusten käyttö on monimutkaista tai mahdotonta.

kun koodia

ei yleensä käytetä, voidaan aina käyttää koodattuja UIs-tunnisteita. Ne ovat harvoin huono idea,joten laittaisin tähän.

vaikka NIBs ja Storyboards tuo joitakin etuja pöytään, mielestäni ei ole mitään järkevää varjopuolia, jotka laittaisin luetteloon estämään koodin käyttöä (paitsi ehkä laiskuus).

yksi projekti, useita työkaluja

Storyboards, NIBs ja code ovat kolme erilaista työkalua iOS-käyttöliittymän rakentamiseen. Onneksi meillä on niitä. Ohjelmallisen UIs: n fanaatikot eivät luultavasti ota kahta muuta vaihtoehtoa huomioon: koodin avulla voit tehdä kaiken, mikä on teknisesti mahdollista, kun taas vaihtoehdoilla on rajoituksensa. Muille kehittäjille Xcode army knife tarjoaa kolme työkalua, joita voidaan käyttää yhtä aikaa, samassa projektissa, tehokkaasti.

miten, kysyt? Miten vain haluat. Tässä muutamia mahdollisia lähestymistapoja:

• Ryhmä kaikki liittyvät näytöt erillisiin ryhmiin, ja toteuttaa kunkin ryhmän oma erillinen kuvakäsikirjoituksen.
• Suunnittele uudelleenkäytettävät pöytäsolut paikoilleen Kuvakäsikirjoituksella, pöydän näkymäohjaimen sisälle.
• Suunnittele uudelleenkäytettävät pöytäsolut NIBs: ään uudelleenkäytön kannustamiseksi ja toistojen välttämiseksi, mutta lataa ne mukautetun koodin avulla.
• suunnittele omia näkymiä, hallintalaitteita ja niiden välissä olevia kohteita käyttäen Nibsejä.
• Käytä koodia erittäin dynaamisille näkymille ja yleisemmin näkymille, jotka eivät ole helposti toteutettavissa kuvakäsikirjoituksen ja kuvakäsikirjoituksen kautta, kun taas asuntonäkymän siirtymät kuvakäsikirjoituksessa.

lopuksi katsotaan vielä yksi esimerkki, joka sitoo kaiken yhteen.

yksinkertainen Käyttötapaus

sano, että haluamme kehittää perusviestisovelluksen, jossa on useita eri näkemyksiä:

• luettelo seuratuista ystävistä (uudelleenkäytettävällä solumallilla, joka pitää käyttöliittymän yhdenmukaisena tulevissa luetteloissa).
• Profiilin yksityiskohtanäkymä, joka on koottu erillisiin osioihin (mukaan lukien profiilitiedot, tilastot ja työkalupalkki).
• luettelo ystävälle lähetetyistä ja vastaanotetuista viesteistä.
• Uusi viestilomake.
• tag cloud-näkymä, joka näyttää käyttäjän viesteissä käytetyt eri tagit, ja kunkin tagin koko on verrannollinen siihen, kuinka monta kertaa sitä on käytetty.

lisäksi näkymien halutaan virtaavan seuraavasti:

• kun napsautat kohdetta seurattujen ystävien luettelossa, näet kyseisen ystävän profiilitiedot.
• profiilitiedoissa näkyvät profiilin nimi, osoite, tilastot, lyhyt luettelo viimeisimmistä viesteistä ja työkalupalkki.

tämän iOS-sovelluksen toteuttamiseksi kaikki kolme KÄYTTÖLIITTYMÄTYÖKALUAMME ovat käteviä, koska voimme käyttää:

• kuvakäsikirjoitus, jossa on neljä näkymäohjainta (luettelo, yksityiskohdat, luettelo viesteistä ja uusi viestilomake).
• erillinen NIB-tiedosto uudelleenkäytettävää profiililuettelon solumallia varten.
• kolme erillistä NIB-tiedostoa profiilitiedot-näkymää varten, yksi kutakin erillistä osiota varten, jotka muodostavat sen (profiilitiedot, tilastot, kolme viimeistä viestiä) paremman ylläpidettävyyden mahdollistamiseksi. Nämä näyt instantioidaan näkymiksi ja lisätään sitten näkymäohjaimeen.
• oma koodi tagin pilvinäkymälle. Tämä näkymä on tyypillinen esimerkki sellaisesta, jota ei voi suunnitella käyttöliittymän rakentajassa, Ei Kuvakäsikirjoitusten eikä NIBs: n kautta. Sen sijaan se toteutetaan kokonaan koodilla. Säilyttääksemme kuvakäsikirjoituksen visuaalisen virtauksen, valitsemme lisätä tyhjän näkymäohjaimen kuvakäsikirjoitukseen, toteuttaa tag cloud-näkymän itsenäisenä näkymänä ja lisätä ohjelmallisesti näkymän näkymäohjaimeen. On selvää, että näkymä voidaan toteuttaa myös näkymäohjaimen sisällä eikä erillisenä näkymänä, mutta pidämme ne erillään paremman uudelleenkäytön vuoksi.

todella perusmalli saattaa näyttää:

sen avulla olemme hahmotelleet kohtuullisen hienostuneen iOS-sovelluksen perusrakenteen, jonka ydinnäkymät yhdistävät kolme ensisijaista lähestymistapaamme käyttöliittymäsuunnitteluun. Muista: binääripäätöstä ei tehdä, sillä jokaisella työkalulla on omat vahvuutensa ja heikkoutensa.

kääre

kuten tässä turtorialissa tarkastellaan, Kuvakäsikirjoitukset lisäävät iOS: n käyttöliittymäsuunnitteluun ja visuaaliseen flow ’ hun havaittavaa yksinkertaistusta. He myös poistavat boilerplate-koodin, mutta kaikella tällä on hintansa, joka maksetaan joustavasti. NIBs puolestaan tarjoaa enemmän joustavuutta keskittymällä yhteen näkymään, mutta ilman visuaalista virtausta. Joustavin ratkaisu on tietenkin koodi, joka on yleensä melko epäystävällinen ja luonnostaan ei-visuaalinen.

jos tämä artikkeli kiehtoi sinua, suosittelen lämpimästi katsomaan Ray Wenderlichin suurta väittelyä, 55-minuuttista hyvin käytettyä keskustelua Nibsistä, Storyboardeista ja koodilla tehdyistä UIS: ista.

lopuksi haluan korostaa yhtä asiaa: Vältä virheellisen iOS UI-suunnittelutyökalun käyttöä hinnalla millä hyvänsä. Jos näkymää ei voi suunnitella Kuvakäsikirjoituksella tai jos se voidaan toteuttaa NIBs: llä tai koodilla yksinkertaisemmalla tavalla, älä käytä kuvakäsikirjoitusta. Samoin, jos näkymää ei voi suunnitella käyttämällä NIBs, älä käytä NIBs. Nämä säännöt, vaikka yksinkertainen, menee pitkälle koulutuksen Kehittäjä.