interfețe utilizator iOS: Storyboards vs. penițe vs. cod personalizat

am auzit de multe ori dezvoltatorii iOS cere o variantă a aceleiași întrebări cheie:

care este cel mai bun mod de a dezvolta o interfață de utilizator în iOS: prin Storyboards, penițe sau cod?

răspunsurile la această întrebare, Explicit sau implicit, tind să presupună că există o alegere care se exclude reciproc, una care este adesea abordată în avans, înainte de dezvoltare.

sunt de părere că răspunsul ar trebui să ia forma uneia sau mai multor întrebări contrare.

care este” cea mai bună ” mașină?

permiteți-mi să explic cu un exemplu off-topic. Spuneți că vreau să cumpăr o mașină și vă pun o întrebare simplă: „care este cea mai bună alegere?”

puteți răspunde cu adevărat sugerând un model sau chiar un brand? Nu probabil, dacă nu sugerezi un Ferrari. În schimb, probabil că ați răspunde cu alte câteva întrebări, cum ar fi:

• care este bugetul tău?
• de Câte locuri ai nevoie?
• îți pasă de consumul de combustibil?
• ce părere aveți despre mașinile sport?

este evident că nu există o mașină bună sau rea decât dacă este plasată într—un context adecvat-există doar o mașină bună sau rea bazată pe nevoi specifice.

înapoi la iOS UI Design

la fel ca în cazul anchetei noastre auto, întrebarea „Care este cel mai bun mod de a dezvolta o interfață iOS” nu are context. Și destul de surprinzător, răspunsul nu trebuie să fie un caz de captură.

în linii mari, există trei tipuri de abordări de proiectare a interfeței cu utilizatorul pe care le puteți lua, fiecare cu avantajele și dezavantajele sale, fanii și urâții săi:

• Storyboards iOS: un instrument vizual pentru stabilirea mai multor vizualizări ale aplicației și a tranzițiilor dintre ele.
• penițe (sau XIBs): fiecare fișier peniță corespunde unui singur element de vizualizare și poate fi așezat în constructorul de interfețe, făcându-l și un instrument vizual. Rețineți că numele „peniță” este derivat din extensia de fișier (anterior .peniță și acum .xib, deși vechea pronunție a persistat).
• cod personalizat: adică, nu există instrumente GUI, ci mai degrabă, de manipulare toate poziționare personalizate, animație, etc. programatic.

niciuna dintre aceste opțiuni nu este universal mai bună decât oricare alta (în ciuda a ceea ce ați putea auzi).

storyboard-urile, de exemplu, sunt cea mai recentă adăugare la setul de instrumente iOS UI. Mi sa spus că ei sunt viitorul, că acestea vor înlocui penițe și cod personalizat UIs. Văd Storyboards ca un instrument util, dar nu atât de mult un înlocuitor ca un complement pentru penițe și cod personalizat. Storyboard-urile sunt alegerea potrivită în unele, dar nu în toate situațiile.

mai mult, de ce ar trebui să rămânem static la o singură opțiune atunci când le puteți utiliza pe toate (în același proiect), alegerea mecanismului care se potrivește cel mai bine problema specifică la îndemână?

aceasta este o întrebare care poate fi, în opinia mea, generalizată la un nivel superior și al cărei răspuns este clasat foarte mult în lista mea de principii de dezvoltare software: nu există un limbaj universal, un cadru sau o tehnologie care să fie cea mai bună alegere universală pentru fiecare problemă de dezvoltare software. Același lucru este valabil și pentru iOS UI design.

în acest tutorial de dezvoltare iOS, vom explora fiecare dintre aceste metode și vom introduce cazuri de utilizare în care ar trebui și nu ar trebui să fie utilizate, precum și moduri în care pot fi amestecate împreună.

storyboard-uri iOS

greșeala unui începător clasic este de a crea un Storyboard masiv iOS la nivel de proiect. Și eu am făcut această greșeală când am început să lucrez cu storyboard-uri (probabil pentru că este un traseu tentant de urmat).

după cum sugerează și numele, un Storyboard este un consiliu cu o poveste de spus. Nu ar trebui să fie folosit pentru a amesteca povești fără legătură într-un volum mare. Un storyboard ar trebui să conțină controlere de vizualizare care sunt logic legate între ele-ceea ce nu înseamnă fiecare controler de vizualizare.

de exemplu, este logic să folosiți storyboard-uri atunci când manipulați:

• un set de vizualizări pentru autentificare și înregistrare.
• un flux de intrare pentru mai multe etape.
• un flux de tip vrăjitor (adică tutorial).
• un set de vizualizări master-detail (de exemplu, liste de profiluri, detalii despre profil).

între timp, ar trebui evitate storyboard-urile mari, inclusiv storyboard-urile unice la nivel de aplicație (cu excepția cazului în care aplicația este relativ simplă). Înainte de a merge mai adânc, să vedem de ce.

nebunia Storyboard-urilor mari iOS

storyboard-uri mari, altele decât cele dificil de navigat și întreținut, adaugă un strat de complexitate unui mediu de echipă: atunci când mai mulți dezvoltatori lucrează la același fișier storyboard în același timp, conflictele de control al sursei sunt inevitabile. Și în timp ce un storyboard este reprezentat intern ca un fișier text (un fișier XML, de fapt), fuzionarea este de obicei non-banală.

când dezvoltatorii vizualiza codul sursă, ei atribuie o semnificație semantică. Deci, atunci când fuzionează manual, sunt capabili să citească și să înțeleagă ambele părți ale unui conflict și să acționeze în consecință. Un storyboard, în schimb, este un fișier XML gestionat de Xcode, iar semnificația fiecărei linii de cod nu este întotdeauna ușor de înțeles.

să luăm un exemplu foarte simplu: spuneți că doi dezvoltatori diferiți schimbă poziția unui UILabel(folosind autolayout), iar acesta din urmă își împinge schimbarea, producând un conflict ca acesta (observați atributele conflictuale id ):

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

id în sine nu oferă nici un fel de indicație cu privire la adevărata sa semnificație, deci nu ai nimic de a lucra cu. Singura soluție semnificativă este alegerea uneia dintre cele două părți ale conflictului și aruncarea celeilalte. Vor exista efecte secundare? Cine știe? Nu tu.

pentru a ușura aceste probleme de proiectare a interfeței iOS, utilizarea mai multor storyboard-uri în același proiect este abordarea recomandată.

când se utilizează storyboard-uri

storyboard-urile sunt cel mai bine utilizate cu mai multe controlere de vizualizare interconectate, deoarece simplificarea lor majoră constă în tranziția între controlerele de vizualizare. Într-o anumită măsură, ele pot fi gândite ca o compoziție de penițe cu fluxuri vizuale și funcționale între controlerele de vizualizare.

pe lângă facilitarea fluxului de navigație, un alt avantaj distinct este că elimină codul de placă de cazan necesar pentru a deschide, împinge, prezenta și respinge controlerele de vizualizare. Mai mult, controlerele de vizualizare sunt alocate automat, deci nu este nevoie să faceți manual alloc și init.

în cele din urmă, în timp ce storyboard-urile sunt cel mai bine utilizate pentru scenarii care implică mai multe controlere de vizualizare, este, de asemenea, apărabil să folosiți un Storyboard atunci când lucrați cu un singur controler de vizualizare a tabelului din trei motive:

• capacitatea de a proiecta prototipuri de celule de masă în loc ajută la menținerea pieselor împreună.
• șabloane de celule Multiple pot fi proiectate în interiorul controlerului de vizualizare tabel părinte.
• este posibil să creați vizualizări statice ale tabelelor (un plus mult așteptat, care, din păcate, este disponibil doar în storyboard-uri).

s-ar putea argumenta că mai multe șabloane de celule pot fi, de asemenea, proiectate folosind penițe. Într-adevăr, aceasta este doar o chestiune de preferință: unii dezvoltatori preferă să aibă totul într-un singur loc, în timp ce altora nu le pasă.

când să nu folosiți storyboard-uri iOS

câteva cazuri:

• vizualizarea are un aspect complicat sau dinamic, cel mai bine implementat cu cod.
• vizualizarea este deja implementată cu penițe sau cod.

în aceste cazuri, putem fie să lăsăm vizualizarea în afara Storyboard-ului, fie să o încorporăm într-un controler de vizualizare. Primul sparge fluxul vizual al Storyboard-ului, dar nu are implicații funcționale sau de dezvoltare negative. Acesta din urmă păstrează acest flux vizual, dar necesită eforturi suplimentare de dezvoltare, deoarece vizualizarea nu este integrată în controlerul de vizualizare: este doar încorporată ca o componentă, prin urmare controlerul de vizualizare trebuie să interacționeze cu vizualizarea, mai degrabă decât să o implementeze.

argumente pro și contra generale

acum, că avem un sens pentru când storyboard-urile sunt utile în designul UI iOS și înainte de a trece la penițe în acest tutorial, să trecem prin avantajele și dezavantajele lor generale.

Pro: performanță

intuitiv, puteți presupune că atunci când un Storyboard este încărcat, toate controlerele sale de vizualizare sunt instantiate imediat. Din fericire, aceasta este doar o abstractizare și nu este adevărată pentru implementarea efectivă: în schimb, este creat doar controlerul de vizualizare inițial, dacă există. Celelalte controlere de vizualizare sunt instanțiate dinamic, fie atunci când se efectuează o segue, fie manual din cod.

Pro: prototipuri

Storyboard simplifică prototiparea și batjocorirea interfețelor de utilizator și a fluxului. De fapt, o aplicație completă de prototip de lucru cu vizualizări și navigare poate fi implementată cu ușurință folosind storyboard-uri și doar câteva linii de cod.

Con: reutilizare

când vine vorba de mutare sau copiere, storyboard-urile iOS sunt slab poziționate. Un Storyboard trebuie mutat împreună cu toate controlerele de vizualizare dependente. Cu alte cuvinte, un singur controler de vizualizare nu poate fi extras și reutilizat individual în altă parte ca o singură entitate independentă; depinde de restul Storyboard-ului să funcționeze.

Con: fluxul de date

datele trebuie adesea transmise între controlerele de vizualizare atunci când o aplicație trece. Cu toate acestea, fluxul vizual Storyboard este rupt în acest caz, deoarece nu există nici o urmă de acest lucru se întâmplă în constructor de interfață. Storyboard-urile au grijă să gestioneze fluxul dintre controlerele de vizualizare, dar nu și fluxul de date. Deci, controlerul de destinație trebuie să fie configurat cu cod, depășind experiența vizuală.

în astfel de cazuri, trebuie să ne bazăm pe un prepareForSegue:sender, cu un schelet if/else-if ca acesta:

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

consider că această abordare este predispusă la erori și verbose inutil.

penițe

penițe sunt vechiul(er) mod de a efectua proiectarea interfeței iOS.

în acest caz, „vechi” nu înseamnă „rău”, „învechit” sau „depreciat”. De fapt, este important să înțelegem că storyboard-urile iOS nu sunt un înlocuitor universal pentru penițe; ele simplifică doar implementarea UI în unele cazuri.

cu penițe, orice vizualizare arbitrară poate fi proiectată, pe care dezvoltatorul o poate atașa apoi la un controler de vizualizare după cum este necesar.

dacă aplicăm design orientat pe obiecte la UIs-urile noastre, atunci are sens Să împărțim vizualizarea unui controler de vizualizare în module separate, fiecare implementat ca vizualizare cu propriul fișier peniță (sau cu mai multe module grupate în același fișier). Avantajul clar al acestei abordări este că fiecare componentă este mai ușor de dezvoltat, mai ușor de testat și mai ușor de depanat.

NIBs împărtășesc problemele de conflict de îmbinare pe care le-am văzut cu storyboard-urile, dar într-o măsură mai mică, deoarece fișierele NIB funcționează la o scară mai mică.

când să utilizați penițe pentru iOS UI Design

un subset al tuturor cazurilor de utilizare ar fi:

• vizualizări modale
• vizualizări simple de conectare și înregistrare
• Setări
• ferestre pop-up
• șabloane de vizualizare reutilizabile
• șabloane de celule de masă reutilizabile

între timp…

când nu utilizați penițe

ar trebui să evitați utilizarea penițelor pentru:

• vizualizări cu conținut dinamic, unde aspectul se modifică semnificativ în funcție de conținut.
• vizualizări care, prin natura lor, nu sunt ușor de proiectat în constructorul de interfețe.
• vezi controlere cu tranziții complicate, care ar putea fi simplificate cu Storyboarding.

argumente pro și contra generale

mai general, să trecem prin avantajele și dezavantajele utilizării Penițelor.

Pro: reutilizare

penițe veni la îndemână atunci când același aspect este partajat în mai multe clase.

ca un caz simplu de utilizare, un șablon de vizualizare care conține un nume de utilizator și un câmp de text pentru parolă ar putea fi implementat cu vizualizările ipotetice TTLoginView și TTSignupView, ambele putând proveni din aceeași peniță. TTLoginView ar trebui să ascundă câmpul de parolă și ambele ar trebui să specifice etichetele statice corespunzătoare (cum ar fi ‘introduceți numele de utilizator’ vs ‘introduceți parola’), dar etichetele ar avea aceeași funcționalitate de bază și machete similare.

Pro& Con: performanță

Penițele sunt încărcate leneș, deci nu folosesc memoria până nu trebuie. Deși acest lucru poate fi un avantaj, există o latență a procesului de încărcare leneș, ceea ce îl face și un dezavantaj.

cod personalizat iOS (UIs programatic)

orice design de interfață iOS care poate fi realizat cu storyboard-uri și penițe poate fi implementat și cu cod raw (a existat o perioadă, desigur, când dezvoltatorii nu aveau luxul unui set atât de bogat de instrumente).

poate mai important, ceea ce nu se poate face cu penițe și storyboard—uri poate fi întotdeauna implementat cu cod-cu condiția, desigur, că este fezabil din punct de vedere tehnic. Un alt mod de a privi este că Penițele și storyboard-urile sunt implementate cu cod, astfel încât funcționalitatea lor va fi în mod natural un subset. Să sărim direct în argumente pro și contra.

Pro: sub capota

cel mai mare avantaj de a crea un iOS UI programatic: dacă știi cum să Cod o interfață de utilizator, atunci știi ce se întâmplă sub capota, întrucât același lucru nu este neapărat adevărat de penițe și Storyboards.

pentru a face o comparație: un calculator este un instrument util. Dar nu este un lucru rău să știi cum să faci calcule manual.

acest lucru nu se limitează la iOS, ci la orice instrument rad vizual (de exemplu, Visual Studio și Delphi, doar pentru a numi câteva). Mediile vizuale HTML rad reprezintă un caz tipic limită: sunt folosite pentru a genera cod (adesea prost scris), susținând că nu sunt necesare cunoștințe HTML și că totul se poate face vizual. Dar niciun dezvoltator web nu ar implementa o pagină web fără să-și murdărească mâinile: știu că manipularea manuală a codului html și CSS brut va duce la un cod mai modular și mai eficient.

deci, stăpânirea codării interfețelor de utilizator iOS vă oferă mai mult control și o mai mare conștientizare a modului în care aceste piese se potrivesc împreună, ceea ce vă ridică limita superioară ca dezvoltator.

Pro: când codul este singura opțiune

există, de asemenea, cazuri în care codul iOS personalizat este singura opțiune pentru designul UI. Aspectele dinamice, în care elementele de vizualizare sunt deplasate și fluxul sau aspectul se ajustează semnificativ pe baza conținutului, sunt exemple tipice.

Pro: Merge conflicte

în timp ce penițe și Storyboards a suferit în mod semnificativ de conflicte de îmbinare, codul nu are aceeași eroare. Tot codul are semnificație semantică, astfel încât rezolvarea conflictelor nu este mai dificilă decât de obicei.

Con: Prototyping

este dificil să dau seama cum un aspect va arăta până când ați văzut-o în acțiune. Mai mult, nu puteți poziționa vizual vizualizările și comenzile, astfel încât traducerea specificațiilor de aspect într-o vizualizare tangibilă poate dura mult mai mult, în comparație cu Penițele și storyboard-urile care vă oferă o previzualizare imediată a modului în care vor fi redate lucrurile.

Con: Refactorizarea

codul de refactorizare care a fost scris cu mult timp în urmă sau de altcineva devine, de asemenea, mult mai complicat: atunci când elementele sunt poziționate și animate cu metode personalizate și numere magice, sesiunile de depanare pot deveni dificile.

Pro: performanță

în termeni de performanță, Storyboards și penițe sunt supuse aeriene de încărcare și parsare; și în cele din urmă, ele sunt traduse indirect în cod. Inutil să spun că acest lucru nu se întâmplă cu UIs-urile create de cod.

Pro: Reutilizarea

orice vizualizare implementată programatic poate fi proiectată într-un mod reutilizabil. Să vedem câteva cazuri de utilizare:

• două sau mai multe opinii împărtășesc un comportament comun, dar sunt ușor diferite. O clasă de bază și două subclase rezolvă problema elegant.
• un proiect trebuie bifurcat, cu scopul de a crea o singură bază de cod, dar generând două (sau mai multe) aplicații diferite, fiecare cu personalizări specifice.

același proces de proiectare UI ar fi mult mai complicat cu penițe și Storyboards. Fișierele șablon nu permit moștenirea, iar soluțiile posibile sunt limitate la următoarele:

• duplicați fișierele peniță și Storyboard. După aceea, au vieți separate și nu au nicio relație cu fișierul original.
• suprascrie aspectul și comportamentul cu codul, care poate funcționa în cazuri simple, dar poate duce la complicații semnificative în altele. Suprascrierile grele cu cod pot face, de asemenea, designul vizual inutil și pot evolua într-o sursă constantă de dureri de cap, de ex., când un anumit control afișează o cale în constructorul de interfețe, dar arată complet diferit atunci când aplicația rulează.

când să utilizați codul

este adesea un apel bun pentru a utiliza utilizați codul personalizat pentru proiectarea interfeței cu utilizatorul iOS atunci când aveți:

• machete dinamice.
• vizualizări cu efecte, cum ar fi colțuri rotunjite, umbre etc.
• orice caz în care utilizarea penițe și Storyboards este complicată sau imposibil.

când nu se utilizează codul

în general, pot fi utilizate întotdeauna iu-uri create de cod. Rareori sunt o idee proastă, așa că aș pune-o aici.

deși penițe și Storyboards aduce unele avantaje la masa, mă simt nu există nici un dezavantaj rezonabil, care mi-ar pune într-o listă pentru a descuraja utilizarea de cod (cu excepția, poate, Lene).

un proiect, mai multe instrumente

storyboard-uri, penițe și cod sunt trei instrumente diferite pentru construirea interfeței cu utilizatorul iOS. Suntem norocoși să le avem. Fanaticii UI-urilor programatice probabil nu vor lua în considerare celelalte două opțiuni: Codul vă permite să faceți tot ce este posibil din punct de vedere tehnic, în timp ce alternativele au limitările lor. Pentru restul dezvoltatorilor de acolo, Xcode army knife oferă trei instrumente care pot fi utilizate simultan, în același proiect, în mod eficient.

cum, întrebi? Cum vrei tu. Iată câteva abordări posibile:

• grupați toate ecranele conexe în grupuri separate și implementați fiecare grup cu propriul Storyboard distinct.
• proiectați celule de masă care nu pot fi refolosibile la locul lor cu un Storyboard, în interiorul controlerului de vizualizare a tabelului.
• proiectați celule de tabel reutilizabile în penițe pentru a încuraja reutilizarea și a evita repetarea, dar încărcați aceste penițe prin cod personalizat.
• proiectați vizualizări personalizate, comenzi și obiecte intermediare folosind penițe.
• utilizați codul pentru vizualizări extrem de dinamice și, în general, pentru vizualizări care nu sunt ușor de implementat prin storyboard-uri și penițe, în timp ce găzduiți tranziții de vizualizare într-un Storyboard.

pentru a încheia, să ne uităm la un ultim exemplu care leagă totul împreună.

un caz de utilizare simplă

să spunem că vrem să dezvoltăm o aplicație de mesagerie de bază cu mai multe vizualizări diferite:

• o listă de prieteni urmat (cu un șablon de celule reutilizabile pentru a menține UI consecventă în listele viitoare).
• o vizualizare detaliată a profilului, compusă în secțiuni separate (inclusiv informații despre profil, statistici și o bară de instrumente).
• o listă de mesaje trimise și primite de la un prieten.
• un nou formular de mesaj.
• o vizualizare în cloud a etichetelor care afișează diferitele etichete utilizate în mesajele utilizatorilor, fiecare etichetă având o dimensiune proporțională cu numărul de utilizări.

în plus, dorim ca punctele de vedere să curgă după cum urmează:

• dacă faceți clic pe un element din lista de prieteni urmăriți, se afișează detaliile profilului prietenului relevant.
• detaliile profilului afișează numele profilului, adresa, Statisticile, o listă scurtă cu cele mai recente mesaje și o bară de instrumente.

pentru a implementa această aplicație iOS, toate cele trei instrumente UI vor fi utile, deoarece putem folosi:

• un Storyboard cu patru controlere de vizualizare (lista, Detalii, lista de mesaje, și noul formular de mesaj).
• un fișier peniță separat pentru șablonul de celule listă profil reutilizabile.
• trei fișiere peniță separate pentru vizualizarea detaliilor profilului, câte unul pentru fiecare dintre secțiunile separate care o compun (Detalii profil, statistici, ultimele trei mesaje), pentru a permite o mai bună mentenabilitate. Aceste penițe vor fi instanțiate ca vizualizări și apoi adăugate la controlerul de vizualizare.
• cod personalizat pentru vizualizarea norului de etichete. Această vizualizare este un exemplu tipic al unuia care nu poate fi proiectat în constructorul de interfețe, nici prin storyboard-uri, nici prin Nib-uri. În schimb, este complet implementat prin cod. Pentru a menține fluxul vizual al Storyboard – ului, alegem să adăugăm un controler de vizualizare gol la Storyboard, să implementăm vizualizarea cloud tag ca vizualizare independentă și să adăugăm programatic vizualizarea la controlerul de vizualizare. În mod clar, vizualizarea ar putea fi implementată și în interiorul controlerului de vizualizare, mai degrabă decât ca o vizualizare independentă, dar le păstrăm separate pentru o reutilizare mai bună.

o machetă cu adevărat de bază ar putea arăta:

cu aceasta, am subliniat construcția de bază a unei aplicații iOS destul de sofisticate, ale cărei vederi de bază leagă cele trei abordări principale ale designului UI. Amintiți-vă: nu există nicio decizie binară care să fie luată, deoarece fiecare instrument are punctele sale forte și punctele slabe.

înfășurarea

după cum sa examinat în acest turtorial, storyboard-urile adaugă o simplificare vizibilă designului UI iOS și fluxului vizual. Ei elimina, de asemenea, codul boilerplate; dar toate acestea vine la un preț, plătit în flexibilitate. Penițele, între timp, oferă mai multă flexibilitate concentrându-se pe o singură vizualizare, dar fără flux vizual. Cea mai flexibilă soluție, desigur, este codul, care tinde să fie destul de neprietenos și inerent non-vizual.

dacă acest articol v-a intrigat, vă recomand să urmăriți marea dezbatere de la Ray Wenderlich, 55 de minute bine cheltuite pentru o discuție despre penițe, storyboard-uri și UIS-uri create de cod.

în încheiere, vreau să subliniez un lucru: evitați cu orice preț utilizarea instrumentului de proiectare iOS UI necorespunzător. Dacă o vizualizare nu poate fi proiectată cu un Storyboard sau dacă poate fi implementată cu penițe sau cod într-un mod mai simplu, nu utilizați un Storyboard. În mod similar, dacă o vizualizare nu poate fi proiectată folosind penițe, nu utilizați penițe. Aceste reguli, deși simple, vor merge mult în educația dvs. ca dezvoltator.