Kuulen usein iOS-kehittäjät kysy jonkin verran samaa avainkysymystä:

Mikä on paras tapa kehittää käyttöliittymä iOS: ssä: Storyboardsin, NIB: ien tai koodin kautta?

Vastauksissa tähän kysymykseen joko nimenomaisesti tai epäsuorasti oletetaan, että on tehtävä toisistaan ​​poissulkeva valinta, joka on usein käsiteltävä etukäteen ennen kehitystä.

Olen sitä mieltä, että vastauksen pitäisi sen sijaan olla yksi tai useampi laskuri kysymyksiä.

Mikä on 'paras' auto?

Sallikaa minun selittää aiheen ulkopuolisella esimerkillä. Sano, että haluan ostaa auton, ja esitän sinulle yhden yksinkertaisen kysymyksen: 'Mikä on paras valinta?'

Voitteko todella vastata ehdottamalla mallia tai jopa a brändi ? Ei todennäköistä, ellet ehdota Ferraria. Sen sijaan vastaat todennäköisesti muutamalla muulla kysymyksellä, kuten:

• Mikä on budjettisi?
• Kuinka monta paikkaa tarvitset?
• Välitätkö polttoaineenkulutuksesta?
• Mitä mieltä olet urheiluautoista?

On selvää, että ei ole olemassa sellaista asiaa kuin hyvä tai huono auto, ellei sitä ole asetettu oikeaan asiayhteyteen - on vain hyvä tai huono auto erityistarpeiden perusteella.

Takaisin iOS-käyttöliittymäsuunnitteluun

Aivan kuten autokyselyssä, 'Mikä on paras tapa kehittää iOS-käyttöliittymä' kysymykseltä puuttuu konteksti. Ja yllättävän kyllä, vastauksen ei tarvitse olla kattava asia.

Yleisesti ottaen on olemassa kolmenlaisia ​​käyttöliittymäsuunnittelutapoja, joita voit käyttää, joista jokaisella on hyvät ja huonot puolet, fanit ja vihaajat:

• iOS Storyboards : Visuaalinen työkalu useiden sovellusnäkymien ja niiden välisten siirtymien asettamiseen.
• NIB: t (tai XIB: t) : Jokainen NIB-tiedosto vastaa yhtä näkymän elementtiä, ja se voidaan sijoittaa Interface Builderiin, mikä tekee siitä myös visuaalisen työkalun. Huomaa, että nimi “NIB” on johdettu tiedostotunnisteesta (aiemmin .nib ja nyt .xib, vaikka vanha ääntäminen on säilynyt).
• Kustomoitu koodi eli ei GUI työkalujen sijaan, vaan pikemminkin käsittelemällä kaikki mukautetut paikannukset, animaatiot jne.

Mikään näistä vaihtoehdoista ei ole universaalia paremmin kuin mikään muu (huolimatta siitä, mitä saatat kuulla).

Kuvakäsikirjoitukset ovat esimerkiksi uusin lisäys iOS-käyttöliittymän työkalupakettiin. Minulle on kerrottu, että he ovat tulevaisuus, että he korvaavat NIB: t ja mukautetun koodin käyttöliittymät. Minusta Storyboards on hyödyllinen työkalu, mutta ei niin paljon korvaus olla täydentää NIB: ille ja mukautetulle koodille. Kuvakäsikirjoitukset ovat oikea valinta joissakin, mutta eivät kaikissa tilanteissa.

Miksi sinun pitäisi staattisesti pitää kiinni yhdestä vaihtoehdosta, kun voit käyttää niitä kaikkia (samassa projektissa) ja valita mekanismi, joka parhaiten sopii käsillä olevaan ongelmaan?

Tämä on mielestäni kysymys, joka voidaan mielestäni yleistää korkeammalla tasolla ja jonka vastaus sijoittuu korkealle ohjelmistokehitysperiaatteiden luetteloon: Ei ole universaalia kieltä, kehystä tai tekniikkaa, joka olisi yleinen paras valinta jokaiselle ohjelmistokehitysongelmalle. Sama pätee iOS-käyttöliittymäsuunnitteluun.

Tässä iOS-kehityksen opetusohjelmassa aiomme tutkia kaikkia näitä menetelmiä ja esitellä käyttötapauksia, joissa niiden pitäisi ja pitäisi ei sekä tapoja, joilla ne voidaan sekoittaa yhteen.

iOS Storyboards

Klassinen aloittelijoiden virhe on luoda yksi massiivinen projektikohtainen iOS Storyboard. Minäkin tein tämän virheen, kun aloin työskennellä ensimmäisen kerran Storyboardsin kanssa (luultavasti siksi, että se on houkutteleva reitti).

Klassinen aloittelijoiden virhe on luoda yksi massiivinen projektikohtainen kuvakäsikirjoitus. Kuvakäsikirjoitus on taulu, jossa on tarina kertoa. Sitä ei pitäisi käyttää sekoittamattomien tarinoiden sekoittamiseen yhdeksi suureksi osaksi.

Kuten nimestään käy ilmi, kuvakäsikirjoitus on lauta, jolla on tarina kertoa . Sitä ei pitäisi käyttää sekoittamattomien tarinoiden sekoittamiseen yhdeksi suureksi osaksi. Kuvakäsikirjoituksen tulisi sisältää näkymän ohjaimet, jotka ovat loogisesti yhteydessä toisiinsa - mikä ei tarkoita joka näkymän ohjain.

Esimerkiksi on järkevää käyttää Storyboardsia käsiteltäessä:

• Joukko näkymiä todennusta ja rekisteröintiä varten.
• Monivaiheinen tilausten syöttövirta.
• Ohjatun toiminnan kaltainen (ts. Opetusohjelma) virta.
• Näkymien päätietosarja (esim. Profiililuettelot, profiilin tiedot).

Samaan aikaan suuria Storyboardsia tulisi välttää, mukaan lukien yksittäiset sovelluksenlaajuiset Storyboards (ellei sovellus ole suhteellisen yksinkertainen). Ennen kuin menemme syvemmälle, katsotaanpa miksi.

Suurten iOS-Storyboardsin hulluus

Suuret kuvakäsikirjoitukset, paitsi selaamisen ja ylläpitämisen vaikeuttaminen, lisäävät monimutkaisuuden tiimiympäristöön: kun useita kehittäjiä työskentelee samalla kuvakäsikirjoitustiedostolla samanaikaisesti, lähteen hallinnan konfliktit ovat väistämättömiä . Ja vaikka kuvakäsikirjoitus on sisäisesti esitetty tekstitiedostona (itse asiassa XML-tiedosto), yhdistäminen ei yleensä ole triviaalia.

Kun kehittäjät katsovat lähdekoodia, he antavat sille semanttisen merkityksen. Joten manuaalisesti yhdistämällä he pystyvät lukemaan ja ymmärtämään konfliktin molemmat puolet ja toimimaan sen mukaisesti. Kuvakäsikirjoitus on sen sijaan Xcode-tiedosto, jota hallinnoi Xcode, eikä koodirivien merkitystä ole aina helppo ymmärtää.

Otetaan hyvin yksinkertainen esimerkki: sanotaan, että kaksi erilaista kehittäjää muuttaa UILabel: n sijaintia (käyttäen automaattista asettelua), ja jälkimmäinen ajaa muutostaan ​​ja tuottaa tällaisen konfliktin (huomaa ristiriitaiset id määritteet):

id

alloc itse ei anna mitään todisteita sen todellisesta merkityksestä, joten sinulla ei ole mitään tekemistä. Ainoa mielekäs ratkaisu on valita toinen konfliktin puolista ja hylätä toinen. Onko sivuvaikutuksia? Kuka tietää? Et sinä.

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

Milloin Storyboardsia käytetään

Kuvakäsikirjoituksia voidaan parhaiten käyttää useiden toisiinsa kytkettyjen näkymien ohjainten kanssa, koska niiden merkittävä yksinkertaistaminen on siirtymässä näkymän ohjaimien välillä. Jossain määrin niitä voidaan ajatella NIB-kokoonpanoksi, jossa näkymä- ja toiminnalliset virtaukset näkymäohjaimien välillä.

Kuvakäsikirjoituksia voidaan parhaiten käyttää useiden toisiinsa kytkettyjen näkymien ohjainten kanssa, koska niiden merkittävä yksinkertaistaminen on siirtymässä näkymän ohjaimien välillä.

Navigointivirran helpottamisen lisäksi toinen selvä etu on, että ne eliminoivat kattilakoodin, jota tarvitaan näkymän ohjaimien avaamiseen, työntämiseen, esittämiseen ja hylkäämiseen. Lisäksi näkymäohjaimet jaetaan automaattisesti, joten ei tarvitse manuaalisesti init ja prepareForSegue:sender.

Lopuksi, vaikka Storyboardsia käytetään parhaiten tilanteissa, joissa on useita näkymän ohjaimia, on myös perusteltavaa käyttää Storyboardia työskenneltäessä yksittäinen taulukonäkymän ohjain kolmesta syystä:

• Kyky suunnitella pöydän solujen prototyypit paikalleen auttaa pitämään palat yhdessä.
• Ylemmän pöydänäkymän ohjaimen sisään voidaan suunnitella useita solumalleja.
• On mahdollista luoda staattisia taulukonäkymiä (kauan odotettu lisäys, joka valitettavasti on saatavana vain Storyboardsissa).

Voidaan väittää, että useita solumalleja voidaan suunnitella myös NIB: ien avulla. Todellisuudessa tämä on vain mieltymysten asia: jotkut kehittäjät haluavat pitää kaiken yhdessä paikassa, kun taas toiset eivät välitä.

Kun Ei käyttää iOS Storyboardsia

Muutama tapaus:

• Näkymä on monimutkainen tai dynaaminen, parhaiten toteutettavissa koodilla.
• Näkymä on jo toteutettu NIB: llä tai koodilla.

Tällöin voimme joko jättää näkymän Storyboardin ulkopuolelle tai upottaa sen näkymäohjaimeen. Ensin mainittu rikkoo Storyboardin visuaalisen virtauksen, mutta sillä ei ole mitään negatiivisia toiminnallisia tai kehitysvaikutuksia. Jälkimmäinen säilyttää tämän visuaalisen virran, mutta se vaatii ylimääräisiä kehittämistoimia, koska näkymää ei ole integroitu näkymäohjaimeen: se on vain upotettu komponenttina, joten näkymän ohjaimen on oltava vuorovaikutuksessa näkymän kanssa sen sijaan, että se toteutettaisiin.

Yleiset edut ja haitat

Nyt kun olemme tietoisia siitä, milloin Storyboards on hyödyllinen iOS: ssä UI-suunnittelu , ja ennen kuin siirrymme NIB: iin tässä opetusohjelmassa, käydään läpi niiden yleiset edut ja haitat.

Pro: Suorituskyky

Intuitiivisesti voit olettaa, että kun kuvakäsikirjoitus ladataan, kaikki sen näkymäohjaimet instantisoidaan välittömästi. Onneksi tämä on vain abstraktio ja ei todellinen toteutus: sen sijaan luodaan vain alkuperäinen näkymäohjain, jos sellainen on. Muut näkymänohjaimet saadaan dynaamisesti joko segmentin suorituksen yhteydessä tai manuaalisesti koodista.

Pro: Prototyypit

Kuvakäsikirjoitukset yksinkertaistavat käyttöliittymien prototyyppien tekemistä ja pilkkaamista ja virtaus. Itse asiassa täydellinen toimiva prototyyppisovellus näkymillä ja navigoinnilla voidaan helposti toteuttaa Storyboardsilla ja vain muutamalla koodirivillä.

Kanssa: Uudelleenkäytettävyys

Siirtämisen tai kopioinnin osalta iOS-Storyboards on sijoitettu huonosti. Kuvakäsikirjoitus on siirrettävä kaikkien sen riippuvien näkymien ohjainten kanssa. Toisin sanoen, yhtä näkymän ohjainta ei voida erikseen purkaa ja käyttää uudelleen muualla yhtenä itsenäisenä kokonaisuutena; se riippuu muusta kuvakäsikirjoituksesta.

Kanssa: Tietovirta

Tietoja on usein siirrettävä näkymäohjaimien välillä, kun sovellus siirtyy. Kuvakäsikirjoituksen visuaalinen virtaus on tässä tapauksessa hajonnut, koska Interface Builderissa ei ole jälkiä siitä. Kuvakäsikirjoittajat huolehtivat näkymän ohjaimien välisen virtauksen käsittelystä, mutta eivät tiedonsiirrosta. Kohdeohjain on siis määritettävä koodilla, joka ohittaa visuaalisen kokemuksen.

Kuvakäsikirjoittajat huolehtivat näkymän ohjaimien välisen virtauksen käsittelystä, mutta eivät tiedonsiirrosta.

Tällaisissa tapauksissa meidän on luotettava - (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 ... } -tyyppiseen luurankoon näin:

TTLoginView

Mielestäni tämä lähestymistapa on virhealtista ja tarpeettomasti täsmällistä.

NIB: t

NIB: t ovat vanha tapa suorittaa iOS-käyttöliittymäsuunnittelu.

Tässä tapauksessa 'vanha' ei tarkoita 'huono', 'vanhentunut' tai 'vanhentunut'. Itse asiassa on tärkeää ymmärtää, että iOS Storyboards ei ole NIB: ien yleinen korvaaja; ne vain yksinkertaistavat käyttöliittymän käyttöönottoa vuonna jonkin verran tapauksissa.

NIB: ien avulla voidaan suunnitella mikä tahansa mielivaltainen näkymä, jonka kehittäjä voi tarvittaessa liittää näkymäohjaimeen.

Jos sovellamme käyttöliittymiin olio-suuntautunutta suunnittelua, on järkevää jakaa näkymän ohjaimen näkymä erilliset moduulit , kukin toteutettu näkymänä omalla NIB-tiedostolla (tai useilla moduuleilla ryhmiteltyinä samaan tiedostoon). Tämän lähestymistavan selkeä etu on, että jokainen komponentti on helpompi kehittää, testata ja helpottaa virheenkorjausta.

NIB: t jakavat näkemämme yhdistämiskonfliktiongelmat Storyboardsin kanssa, mutta vähemmässä määrin, koska NIB-tiedostot toimivat pienemmässä mittakaavassa.

Milloin NIB: itä käytetään iOS-käyttöliittymäsuunnitteluun

Alaryhmä kaikista käyttötapauksista olisi:

• Modaaliset näkymät
• Yksinkertaiset kirjautumis- ja rekisteröintinäkymät
• asetukset
• Ponnahdusikkunat
• Uudelleenkäytettävät näkymämallit
• Uudelleenkäytettävät taulukon solumallit

Sillä välin…

Kun Ei käyttää NIB: itä

Vältä NIB: ien käyttöä:

• Näkymät dynaamisella sisällöllä, joissa asettelu muuttuu merkittävästi sisällöstä riippuen.
• Näkymät, joita luonnostaan ​​ei ole helppo suunnitella Interface Builderissa.
• Tarkastele ohjaimia monimutkaisilla siirtymillä, joita voidaan yksinkertaistaa Storyboardingilla.

Yleiset edut ja haitat

Käymme yleisemmin läpi NIB: ien käytön edut ja haitat.

Pro: Uudelleenkäytettävyys

NIB: t ovat käteviä, kun sama ulkoasu jaetaan useille luokille.

Yksinkertaisena käyttötapauksena näkymämalli, joka sisältää käyttäjätunnuksen ja salasanan tekstikentän, voitaisiin toteuttaa hypoteettisella TTSignupView ja TTLoginView molemmat voivat olla peräisin samasta NIB: stä.

olisi piilotettava salasanakenttä, ja molempien olisi määritettävä vastaavat staattiset tunnisteet (kuten ”Anna käyttäjänimesi” tai ”Kirjoita salasanasi”), mutta tarroilla olisi samat perustoiminnot ja samanlaiset asettelut.

Pro & Con: Suorituskyky

NIB: t ovat laiskasti ladattu , joten he eivät käytä muistia ennen kuin heidän on pakko. Vaikka tämä voi olla etu, laiska latausprosessi on viivästynyt, mikä tekee siitä myös haittapuolen.

iOS: n mukautettu koodi (ohjelmalliset käyttöliittymät)

Minkä tahansa iOS-käyttöliittymän suunnittelu joka voidaan tehdä Storyboardsin avulla ja NIB: t voidaan toteuttaa myös raakakoodilla (tietysti oli aika, jolloin kehittäjillä ei ollut ylellisyyttä niin rikkaista työkaluista).

Mitä ei voida tehdä NIB: ien ja Storyboardsin kanssa, voidaan aina toteuttaa koodilla.

Ehkä tärkeämpää on, että mitä ei voida tehdä NIB: ien ja Storyboardsin kanssa, voidaan aina toteuttaa koodilla - edellyttäen tietenkin, että se on teknisesti mahdollista. Toinen tapa tarkastella sitä on, että NIB: t ja Storyboards toteutetaan koodilla, joten niiden toiminnot ovat luonnollisesti osajoukkoja. Hyppäämme suoraan hyviin ja huonoihin puoliin.

Pro: Konepellin alla

Suurin etu iOS-käyttöliittymän luomisesta ohjelmallisesti: jos osaat koodata käyttöliittymän, tiedät mitä tapahtuu konepellin alla , kun taas sama ei välttämättä päde NIB: iin ja Storyboardsiin.

Vertailun tekemiseksi: laskin on hyödyllinen työkalu. Mutta ei ole huono tieto siitä, miten laskelmat tehdään manuaalisesti.

Tämä ei rajoitu iOS: ään, vaan mihin tahansa visuaaliseen RAD-työkaluun (esim. Visual Studio ja Delphi, vain muutamia mainitakseni). Visuaaliset HTML RAD -ympäristöt edustavat tyypillistä rajatapausta: niitä käytetään tuottamaan (usein huonosti kirjoitettua) koodia väittäen, että HTML-tietoa ei tarvita ja että kaikki voidaan tehdä visuaalisesti. Mikään web-kehittäjä ei kuitenkaan toteuta verkkosivua likaantumatta hänen käsiinsä: he tietävät, että käsittelemättömän HTML: n ja CSS: n käsitteleminen johtaa modulaarisempaan ja tehokkaampaan koodiin.

Joten, iOS-käyttöliittymien koodauksen hallitseminen antaa sinulle paremman hallinnan ja paremman tietämyksen siitä, miten nämä kappaleet sopivat yhteen, mikä nostaa ylempää kehittäjääsi.

Pro: Kun koodi on ainoa vaihtoehto

On myös tapauksia, joissa mukautettu iOS-koodi on ainoa vaihtoehto käyttöliittymäsuunnittelulle. Dynaamiset asettelut, joissa näkymän elementtejä siirretään ja virtaus tai asettelu mukautuu merkittävästi sisällön perusteella, ovat tyypillisiä esimerkkejä.

Pro: Yhdistä ristiriidat

Vaikka NIB: t ja Storyboards kärsivät merkittävästi sulautumisristiriidoista, koodilla ei ole samaa vikaa. Kaikilla koodeilla on semanttinen merkitys, joten konfliktien ratkaiseminen ei ole normaalia vaikeampi.

Kanssa: Prototyyppien tekeminen

On vaikea selvittää, miltä ulkoasu näyttää, ennen kuin näet sen toiminnassa. Et myöskään voi sijoittaa näkymiä ja hallintalaitteita visuaalisesti, joten asetteluiden muuntaminen konkreettiseksi näkymäksi voi viedä paljon kauemmin verrattuna NIB: iin ja Storyboardsiin, jotka antavat sinulle välittömän esikatselun siitä, miten asiat näkyvät.

Kanssa: Refactoring

Kauan sitten tai jonkun muun kirjoittaman koodin korjaaminen muuttuu myös paljon monimutkaisemmaksi: kun elementtejä sijoitetaan ja animoidaan mukautetuilla menetelmillä ja maagisilla numeroilla, virheenkorjausistunnoista voi tulla hankala.

Pro: Suorituskyky

Suorituskyvyn kannalta Storyboards ja NIB: t ovat ladattavien ja jäsentyvien kustannusten alaisia; ja lopulta ne käännetään epäsuorasti koodiksi. Tarpeetonta sanoa, että näin ei tapahdu koodilla tehdyillä käyttöliittymillä.

Pro: Uudelleenkäytettävyys

Mikä tahansa ohjelmallisesti toteutettu näkymä voidaan suunnitella uudelleenkäytettävällä tavalla. Katsotaanpa muutama käyttötapa:

• Kahdella tai useammalla näkemyksellä on yhteinen käyttäytyminen, mutta ne ovat hieman erilaisia. Perusluokka ja kaksi alaluokkaa ratkaisevat ongelman tyylikkäästi.
• Projekti on haaroitettava tavoitteena luoda yksi koodipohja, mutta luoda kaksi (tai useampaa) erilaista sovellusta, joista jokaisella on erityiset mukautukset.

Sama käyttöliittymän suunnitteluprosessi olisi paljon monimutkaisempi NIB: ien ja Storyboardsin kanssa. Mallitiedostot eivät salli perimistä, ja mahdolliset ratkaisut rajoittuvat seuraaviin:

• Kopioi NIB- ja Storyboard-tiedostot. Sen jälkeen heillä on erillinen elämä ja heillä ei ole yhteyttä alkuperäiseen tiedostoon.
• Ohita ulkoasu ja käyttäytyminen koodilla, joka voi toimia yksinkertaisissa tapauksissa, mutta voi johtaa merkittäviin komplikaatioihin muissa. Raskaat ohitukset koodilla voivat myös tehdä visuaalisen suunnittelun hyödyttömäksi ja kehittyä jatkuvaksi päänsärkylähteeksi, esimerkiksi kun tietty ohjausobjekti näkyy yhdellä tavalla Interface Builderissa, mutta näyttää täysin erilaiselta, kun sovellus on käynnissä.

Milloin koodia käytetään

Usein on hyvä kutsu käyttää mukautettua koodia iOS-käyttöliittymäsuunnittelussa, kun sinulla on:

• Dynaamiset asettelut.
• Näkymät efekteillä, kuten pyöristetyt kulmat, varjot jne.
• Kaikki tapaukset, joissa NIB: ien ja Storyboardsin käyttö on monimutkaista tai mahdotonta.

Kun Ei käyttää koodia

Yleensä koodilla tehdyt käyttöliittymät voivat aina käyttää. Ne ovat harvoin huono idea, joten laitoin tänne.

Vaikka NIB: t ja Storyboards tuovat pöydälle joitain etuja, mielestäni ei ole mitään kohtuullista haittapuolta, jonka laitan luetteloon koodin käytön estämiseksi (lukuun ottamatta ehkä laiskuutta).

Yksi projekti, useita työkaluja

Kuvakäsikirjoitukset, NIB: t ja koodi ovat kolme erilaista työkalua iOS-käyttöliittymän rakentamiseen. Olemme onnekkaita, että meillä on heitä. Ohjelmallisten käyttöliittymien fanit eivät todennäköisesti ota huomioon kahta muuta vaihtoehtoa: koodin avulla voit tehdä kaiken, mikä on teknisesti mahdollista, kun taas vaihtoehdoilla on rajoituksensa. Muille siellä oleville kehittäjille Xcode-armeijan veitsi tarjoaa kolme työkalua, joita voidaan käyttää kerralla samassa projektissa tehokkaasti.

Kuinka kysyt? Miten vain haluat. Tässä on joitain mahdollisia lähestymistapoja:

• Ryhmittele kaikki siihen liittyvät näytöt erillisiin ryhmiin ja toteuta kukin ryhmä omalla erillisellä kuvakäsikirjoituksellaan.
• Suunnittele kertakäyttöiset taulukon solut Storyboardin avulla pöydänäkymän ohjaimen sisällä.
• Suunnittele uudelleenkäytettävät taulukkosolut NIB: issä kannustamaan uudelleenkäyttöä ja välttämään toistamista, mutta lataa nämä NIB: t mukautetun koodin avulla.
• Suunnittele mukautetut näkymät, ohjausobjektit ja välissä olevat objektit NIB: ien avulla.
• Käytä koodia erittäin dynaamisiin näkymiin ja yleisemmin näkymiin, jotka eivät ole helposti toteutettavissa Storyboardsin ja NIB: ien kautta, kun taas näkymän siirtymiä Storyboardissa.

Katsotaanpa viimeinen esimerkki, joka sitoo kaiken yhteen.

Yksinkertainen käyttötapa

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

• Luettelo seuratuista ystävistä (uudelleenkäytettävällä solumallilla, jotta käyttöliittymä pysyy yhtenäisenä tulevissa luetteloissa).
• Profiilin tietonäkymä, joka koostuu erillisistä osioista (mukaan lukien profiilitiedot, tilastot ja työkalurivi).
• Luettelo kaverille lähetetyistä ja vastaanotetuista viesteistä.
• Uusi viestilomake.
• Tunnisteiden pilvipalvelunäkymä, joka näyttää eri viestit, joita käytetään käyttäjäviesteissä, kunkin tunnisteen ollessa suhteessa sen käyttökertojen määrään.

Lisäksi haluamme näkymien kulkevan seuraavasti:

• Napsauttamalla kohdetta seurattujen kaverien luettelossa näet kyseisen ystävän profiilin tiedot.
• Profiilin tiedot näyttävät profiilin nimen, osoitteen, tilastot, lyhyen luettelon uusimmista viesteistä ja työkalurivin.

Tämän iOS-sovelluksen toteuttamiseksi kaikki kolme käyttöliittymätyökalumme ovat käteviä, koska voimme käyttää:

• Kuvakäsikirjoitus, jossa on neljä näkymäohjainta (luettelo, tiedot, viestiluettelo ja uusi viestilomake).
• Erillinen NIB-tiedosto uudelleenkäytettävää profiililuettelosolumallia varten.
• Kolme erillistä NIB-tiedostoa profiilin yksityiskohdat -näkymälle, yksi kutakin erillistä osaa varten, jotka sen muodostavat (profiilin tiedot, tilastot, kolme viimeistä viestiä) paremman ylläpidettävyyden takaamiseksi. Nämä NIB: t instantisoidaan näkyminä ja lisätään sitten näkymäohjaimeen.
• Mukautettu koodi tagipilvenäkymälle. Tämä näkymä on tyypillinen esimerkki sellaisesta, jota ei voida suunnitella Interface Builderissa, ei StoryBoardsin tai NIB: ien kautta. Sen sijaan se toteutetaan kokonaan koodin avulla. Storyboardin visuaalisen kulun ylläpitämiseksi päätämme lisätä tyhjän näkymän ohjaimen kuvakäsikirjoitukseen, toteuttaa tunnisteiden pilvinäkymän erillisenä näkymänä ja lisätä näkymän ohjelmallisesti näkymän ohjaimeen. Näkymä voidaan selvästi toteuttaa myös näkymäohjaimen sisällä eikä erillisenä näkymänä, mutta pidämme ne erillään parempaan uudelleenkäyttöön.

Todella perusmalli voi näyttää:

Sen avulla olemme hahmotelleet kohtuullisen perusrakenteen hienostunut iOS-sovellus jonka ydinnäkymät yhdistävät kolme ensisijaista lähestymistapamme UI-suunnittelu . Muista: binääripäätöstä ei voida tehdä, koska jokaisella työkalulla on vahvuutensa ja heikkoutensa.

Käärimistä

Kuten tässä tapahtumassa tarkasteltiin, Storyboards lisää huomattavaa yksinkertaistusta ios Käyttöliittymän suunnittelu ja visuaalinen virtaus. Ne myös eliminoivat kattilakoodin; mutta kaikella tällä on hinta, maksetaan joustavasti. Samaan aikaan NIB: t tarjoavat enemmän joustavuutta keskittymällä yhteen näkymään, mutta ilman visuaalista virtausta. Joustavin ratkaisu on tietysti koodi, joka on yleensä melko epäystävällinen ja luonnostaan ​​ei-visuaalinen.

Jos tämä artikkeli kiehtoi sinua, suosittelen lämpimästi katsomaan suuri keskustelu Ray Wenderlichiltä, ​​55 minuuttia hyvin vietetty keskusteluun NIB: istä, Storyboardsista ja koodilla tehdystä UIS: stä.

Lopuksi haluan korostaa yhtä asiaa: Vältä väärän iOS-käyttöliittymän suunnittelutyökalun käyttöä hinnalla millä hyvänsä . Jos näkymää ei voida suunnitella Storyboardilla tai jos se voidaan toteuttaa NIB: llä tai koodilla yksinkertaisemmalla tavalla, ei käytä kuvakäsikirjoitusta. Vastaavasti, jos näkymää ei voida suunnitella NIB: ien avulla, älä käytä NIB: itä. Nämä säännöt ovat yksinkertaisia, mutta ne vievät paljon eteenpäin koulutuksessasi kehittäjänä.