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ä.
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:
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.
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:
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.
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ä:
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.
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.
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ä:
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ä.
Muutama tapaus:
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.
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.
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.
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ä.
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.
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 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.
Alaryhmä kaikista käyttötapauksista olisi:
Sillä välin…
Vältä NIB: ien käyttöä:
Käymme yleisemmin läpi NIB: ien käytön edut ja haitat.
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ä.
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.
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.
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.
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ä.
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.
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.
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.
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ä.
Mikä tahansa ohjelmallisesti toteutettu näkymä voidaan suunnitella uudelleenkäytettävällä tavalla. Katsotaanpa muutama käyttötapa:
Sama käyttöliittymän suunnitteluprosessi olisi paljon monimutkaisempi NIB: ien ja Storyboardsin kanssa. Mallitiedostot eivät salli perimistä, ja mahdolliset ratkaisut rajoittuvat seuraaviin:
Usein on hyvä kutsu käyttää mukautettua koodia iOS-käyttöliittymäsuunnittelussa, kun sinulla on:
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).
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:
Katsotaanpa viimeinen esimerkki, joka sitoo kaiken yhteen.
Oletetaan, että haluamme kehittää perusviestisovelluksen, jossa on useita eri näkemyksiä:
Lisäksi haluamme näkymien kulkevan seuraavasti:
Tämän iOS-sovelluksen toteuttamiseksi kaikki kolme käyttöliittymätyökalumme ovat käteviä, koska voimme käyttää:
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.
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ä.