interfejsy użytkownika iOS: Storyboards vs. NIBs vs. custom Code

często słyszę, jak Programiści iOS zadają kilka wariantów tego samego kluczowego pytania:

jaki jest najlepszy sposób na stworzenie interfejsu użytkownika w systemie iOS: poprzez storyboardy, Stalówki lub kod?

odpowiedzi na to pytanie, wyraźnie lub pośrednio, zwykle zakładają, że istnieje wzajemnie wykluczający się wybór, który jest często podejmowany z góry, przed rozwojem.

jestem zdania, że odpowiedź powinna mieć formę jednego lub więcej pytań przeciwnych.

jaki” najlepszy ” samochód?

pozwól, że wyjaśnię za pomocą przykładu off-topic. Powiedz, że chcę kupić samochód i zadam ci jedno proste pytanie: „Jaki jest najlepszy wybór?”

czy naprawdę możesz odpowiedzieć sugerując model, a nawet markę? Raczej nie, chyba że zaproponujesz Ferrari. Zamiast tego prawdopodobnie odpowiesz kilkoma innymi pytaniami, takimi jak:

• jaki masz budżet?
• ile potrzebujesz miejsc?
• zależy ci na zużyciu paliwa?
• co sądzisz o samochodach sportowych?

to oczywiste, że nie ma czegoś takiego jak dobry lub zły samochód, chyba że jest umieszczony w odpowiednim kontekście—jest po prostu dobry lub zły samochód oparty na konkretnych potrzebach.

wróć do projektowania interfejsu iOS

podobnie jak w przypadku naszego zapytania o samochód, pytanie „jaki jest najlepszy sposób na opracowanie interfejsu iOS” nie ma kontekstu. Co zaskakujące, odpowiedź nie musi być przypadkowa.

Ogólnie rzecz biorąc, istnieją trzy rodzaje podejść do projektowania interfejsu użytkownika, z których każdy ma swoje plusy i minusy, fanów i nienawistników:

• storyboardy iOS: wizualne narzędzie do układania wielu widoków aplikacji i przejść między nimi.
• Stalówki (lub XIBs): każdy plik stalówki odpowiada pojedynczemu elementowi widoku i może być rozplanowany w Konstruktorze interfejsu, co czyni go również narzędziem wizualnym. Zauważ, że nazwa „NIB” pochodzi od rozszerzenia pliku (poprzednio .stalówka i teraz .xib, choć stara wymowa przetrwała).
• kod niestandardowy: tj. brak narzędzi GUI, ale raczej Obsługa wszystkich niestandardowych pozycjonowań, animacji itp. programowo.

żadna z tych opcji nie jest ogólnie lepsza niż jakakolwiek inna (pomimo tego, co możesz usłyszeć).Na przykład

storyboardy są najnowszym dodatkiem do zestawu narzędzi interfejsu iOS. Powiedziano mi, że są przyszłością, że zastąpią Stalówki i niestandardowy kod Ui. Widzę storyboardy jako przydatne narzędzie, ale nie tyle zamiennik, co uzupełnienie stalówek i niestandardowego kodu. Storyboardy są właściwym wyborem w niektórych, ale nie we wszystkich sytuacjach.

ponadto, dlaczego należy statycznie trzymać się jednej opcji, gdy można użyć ich wszystkich (w tym samym projekcie), wybierając mechanizm, który najlepiej pasuje do konkretnego problemu pod ręką?

jest to pytanie, które moim zdaniem może być uogólnione na wyższym poziomie, a którego odpowiedź jest wysoko na mojej liście zasad tworzenia oprogramowania: nie ma uniwersalnego języka, struktury lub technologii, która byłaby uniwersalnym najlepszym wyborem dla każdego problemu tworzenia oprogramowania. To samo dotyczy projektowania interfejsu użytkownika iOS.

w tym samouczku dotyczącym rozwoju systemu iOS omówimy każdą z tych metod i przedstawimy przypadki użycia, w których powinny, a nie powinny być stosowane, jak również sposoby ich łączenia.

iOS Storyboards

klasycznym błędem początkującego jest stworzenie jednego ogromnego projektu-całego storyboardu iOS. Ja też popełniłem ten błąd, kiedy po raz pierwszy zacząłem pracować z Storyboardami (prawdopodobnie dlatego, że jest to kusząca trasa).

jak sama nazwa wskazuje, Storyboard to tablica z historią do opowiedzenia. Nie powinien być używany do mieszania niepowiązanych historii w jeden duży Tom. Storyboard powinien zawierać Kontrolery widoków, które są logicznie ze sobą powiązane—co nie oznacza każdego kontrolera widoku.

na przykład warto używać Storyboardów podczas obsługi:

• zestaw widoków do uwierzytelniania i rejestracji.
• wieloetapowy przepływ wprowadzania zamówień.
• przepływ podobny do Kreatora (np. samouczka).
• zestaw widoków typu master-detail (np. listy profili, szczegóły profilu).

tymczasem należy unikać dużych Storyboardów, w tym pojedynczych Storyboardów w całej aplikacji (chyba że aplikacja jest stosunkowo prosta). Zanim wejdziemy głębiej, zobaczmy dlaczego.

szaleństwo dużych Storyboardów iOS

Duże storyboardy, inne niż trudne do przeglądania i utrzymywania, dodają warstwę złożoności do środowiska zespołowego: gdy wielu programistów pracuje nad tym samym plikiem scenorysu w tym samym czasie, konflikty kontroli źródła są nieuniknione. I podczas gdy storyboard jest wewnętrznie reprezentowany jako plik tekstowy (w rzeczywistości plik XML), scalanie jest zwykle nietrywialne.

kiedy Programiści przeglądają kod źródłowy, przypisują mu znaczenie semantyczne. Tak więc podczas ręcznego łączenia są w stanie odczytać i zrozumieć obie strony konfliktu i odpowiednio działać. Storyboard to zamiast tego plik XML zarządzany przez Xcode, a znaczenie każdej linii kodu nie zawsze jest łatwe do zrozumienia.

weźmy bardzo prosty przykład: powiedzmy, że dwóch różnych programistów zmienia pozycję UILabel (używając autolayout), a ten drugi popycha swoją zmianę, tworząc konflikt w ten sposób (zwróć uwagę na sprzeczne atrybuty id ):

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

Sam id nie daje żadnych wskazówek co do jego prawdziwego znaczenia, więc nie masz z czym pracować. Jedynym sensownym rozwiązaniem jest wybranie jednej z dwóch stron konfliktu i odrzucenie drugiej. Czy będą skutki uboczne? Kto wie? Nie ty.

aby złagodzić te problemy z projektowaniem interfejsu iOS, zalecane jest użycie wielu scenorysów w tym samym projekcie.

kiedy używać Storyboardów

storyboardy są najlepiej używane z wieloma połączonymi ze sobą kontrolerami widoków, ponieważ ich głównym uproszczeniem jest przejście między kontrolerami widoków. Do pewnego stopnia można je traktować jako kompozycję stalówek z przepływami wizualnymi i funkcjonalnymi między kontrolerami widoku.

oprócz ułatwienia przepływu nawigacji, inną wyraźną zaletą jest to, że eliminują one kod boilerplate potrzebny do pop, push, present I disclose kontrolerów widoków. Ponadto Kontrolery widoku są przydzielane automatycznie, więc nie ma potrzeby ręcznego alloci init.

wreszcie, podczas gdy storyboardy są najlepiej używane w scenariuszach obejmujących wiele kontrolerów widoków, można również bronić się przed używaniem storyboardu podczas pracy z pojedynczym kontrolerem widoku tabeli z trzech powodów:

• możliwość projektowania prototypów komórek tabeli na miejscu pomaga utrzymać elementy razem.
• wiele szablonów komórek można zaprojektować wewnątrz kontrolera widoku tabeli nadrzędnej.
• możliwe jest tworzenie statycznych widoków tabeli (długo oczekiwany dodatek, który jest niestety dostępny tylko w Storyboardach).

można argumentować, że wiele szablonów komórek można również zaprojektować za pomocą stalówek. W rzeczywistości jest to tylko kwestia preferencji: niektórzy deweloperzy wolą mieć wszystko w jednym miejscu, podczas gdy inni nie dbają o to.

kiedy nie używać Storyboardów iOS

kilka przypadków:

• Widok ma skomplikowany lub dynamiczny układ, najlepiej zaimplementowany za pomocą kodu.
• widok jest już zaimplementowany z NIBs lub kodem.

w takich przypadkach możemy pozostawić widok poza Scenorysem lub osadzić go w kontrolerze widoku. Ten pierwszy przerywa wizualny przepływ scenorysu, ale nie ma żadnych negatywnych konsekwencji funkcjonalnych lub rozwojowych. Ten ostatni zachowuje ten przepływ wizualny, ale wymaga dodatkowych wysiłków programistycznych, ponieważ widok nie jest zintegrowany z kontrolerem widoku: jest po prostu osadzony jako komponent, dlatego kontroler widoku musi współdziałać z widokiem, a nie go implementować.

ogólne plusy i minusy

teraz, gdy mamy poczucie, kiedy storyboardy są przydatne w projektowaniu interfejsu użytkownika iOS, a zanim przejdziemy do stalówek w tym samouczku, przejdźmy przez ich ogólne zalety i wady.

Pro: wydajność

intuicyjnie można założyć, że po załadowaniu storyboardu wszystkie jego Kontrolery widoku są natychmiast tworzone. Na szczęście jest to tylko abstrakcja i nie dotyczy rzeczywistej implementacji: zamiast tego tworzony jest tylko początkowy kontroler widoku, jeśli w ogóle istnieje. Pozostałe Kontrolery widoków są tworzone dynamicznie, zarówno podczas wykonywania segue, jak i ręcznie z kodu.

Pro: prototypy

storyboardy upraszczają prototypowanie i szydzenie z interfejsów użytkownika i przepływu. W rzeczywistości kompletną działającą aplikację prototypową z widokami i nawigacją można łatwo zaimplementować za pomocą Storyboardów i zaledwie kilku linii kodu.

Con: możliwość ponownego użycia

jeśli chodzi o przenoszenie lub kopiowanie, storyboardy na iOS są słabo ustawione. Storyboard musi zostać przesunięty wraz ze wszystkimi zależnymi kontrolerami widoku. Innymi słowy, pojedynczy kontroler widoku nie może być indywidualnie wyodrębniony i ponownie użyty w innym miejscu jako pojedyncza niezależna jednostka; jest zależny od pozostałej części storyboardu do działania.

Con: przepływ danych

dane często muszą być przekazywane między kontrolerami widoku podczas przejścia aplikacji. Jednak przepływ wizualny storyboardu jest w tym przypadku zepsuty, ponieważ nie ma śladu tego w Konstruktorze interfejsu. Storyboardy zajmują się obsługą przepływu między kontrolerami widoku, ale nie przepływem danych. Tak więc kontroler docelowy musi być skonfigurowany z kodem, nadpisując wrażenia wizualne.

w takich przypadkach musimy polegać na prepareForSegue:sender, Z if/else-jeśli szkielet taki jak ten:

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

uważam to podejście za podatne na błędy i niepotrzebnie gadatliwe.

Stalówki

Stalówki to stary(er) sposób na projektowanie interfejsu iOS.

w tym przypadku „stary” nie oznacza „zły”, „przestarzały” lub „przestarzały”. W rzeczywistości ważne jest, aby zrozumieć, że storyboardy iOS nie są uniwersalnym zamiennikiem stalówek; po prostu upraszczają implementację interfejsu użytkownika w niektórych przypadkach.

za pomocą stalówek można zaprojektować dowolny dowolny widok, który programista może następnie dołączyć do kontrolera widoku w razie potrzeby.

jeśli zastosujemy projektowanie obiektowe do naszego interfejsu użytkownika, sensowne jest rozbicie widoku kontrolera widoku na oddzielne moduły, z których każdy jest zaimplementowany jako widok z własnym plikiem NIB (lub z wieloma modułami zgrupowanymi w tym samym pliku). Wyraźną zaletą tego podejścia jest to, że każdy komponent jest łatwiejszy do opracowania, łatwiejszy do przetestowania i łatwiejszy do debugowania.

Stalówki dzielą problemy z konfliktami scalania, które widzieliśmy w Storyboardach, ale w mniejszym stopniu, ponieważ pliki NIB działają na mniejszą skalę.

kiedy używać stalówek do projektowania interfejsu iOS

podzbiór wszystkich przypadków użycia byłby następujący:

• widoki Modalne
• proste widoki logowania i rejestracji
• Ustawienia
• okna wyskakujące
• Szablony widoku wielokrotnego użytku
• Szablony komórek tabeli wielokrotnego użytku

tymczasem…

kiedy nie używać stalówek

należy unikać używania stalówek dla:

• widoki z zawartością dynamiczną, gdzie układ zmienia się znacząco w zależności od zawartości.
• widoki, które z natury nie są łatwe do zaprojektowania w Konstruktorze interfejsów.
• Kontrolery widoku ze skomplikowanymi przejściami, które można uprościć za pomocą Storyboardingu.

ogólne plusy i minusy

Ogólnie rzecz biorąc, przejdźmy przez plusy i minusy używania stalówek.

Pro: możliwość ponownego użycia

Stalówki przydają się, gdy ten sam układ jest współdzielony przez wiele klas.

w prostym przypadku użycia szablon widoku zawierający nazwę użytkownika i pole tekstowe hasła może być zaimplementowany z hipotetycznymi widokami TTLoginView i TTSignupView, z których oba mogą pochodzić z tej samej końcówki. TTLoginView musiałoby ukryć pole hasła, a oba muszą określać odpowiednie statyczne etykiety (takie jak „wprowadź nazwę użytkownika” lub „Wprowadź hasło”), ale etykiety miałyby tę samą podstawową funkcjonalność i podobny układ.

Pro & Con: wydajność

Stalówki są leniwie ładowane, więc nie używają pamięci, dopóki nie będą musiały. Chociaż może to być zaletą, proces leniwego ładowania jest opóźniony, co czyni go również pewnym minusem.

kod niestandardowy iOS (Programmatic UIs)

każdy projekt interfejsu iOS, który można wykonać za pomocą Storyboardów i stalówek, może być również zaimplementowany za pomocą surowego kodu (oczywiście był czas, gdy programiści nie mieli luksusu tak bogatego zestawu narzędzi).

co ważniejsze, to, czego nie można zrobić za pomocą stalówek i storyboardów, zawsze można zaimplementować za pomocą kodu-oczywiście pod warunkiem, że jest to technicznie wykonalne. Innym sposobem patrzenia na to jest to, że Stalówki i storyboardy są implementowane z kodem, więc ich funkcjonalność będzie naturalnie podzbiorem. Przejdźmy od razu do zalet i wad.

Pro: pod maską

największą zaletą programowego tworzenia interfejsu użytkownika iOS: jeśli wiesz, jak kodować interfejs użytkownika, wiesz, co dzieje się pod maską, podczas gdy to samo niekoniecznie dotyczy stalówek i storyboardów.

aby dokonać porównania: Kalkulator jest przydatnym narzędziem. Ale nie jest źle, aby wiedzieć, jak wykonywać obliczenia ręcznie.

to nie jest ograniczone do iOS, ale do dowolnego narzędzia visual RAD (np. Visual Studio i Delphi, by wymienić tylko kilka). Wizualne środowiska rad HTML reprezentują typowy przypadek graniczny: są używane do generowania (często źle napisanego) kodu, twierdząc, że nie jest potrzebna wiedza HTML i że wszystko można zrobić wizualnie. Ale żaden programista nie wdrożyłby strony internetowej bez zabrudzenia sobie rąk: wiedzą, że ręczna obsługa surowego HTML i CSS doprowadzi do bardziej modułowego, bardziej wydajnego kodu.

tak więc opanowanie kodowania interfejsów użytkownika iOS daje większą kontrolę i większą świadomość tego, jak te elementy pasują do siebie, co podnosi twoją górną granicę jako programisty.

Pro: gdy kod jest jedyną opcją

istnieją również przypadki, w których niestandardowy kod iOS jest jedyną opcją dla projektowania interfejsu użytkownika. Typowymi przykładami są układy dynamiczne, w których elementy widoku są przesuwane, a przepływ lub układ znacznie dostosowuje się w zależności od zawartości.

Pro: Konflikty scalania

podczas gdy Stalówki i storyboardy znacznie ucierpiały z powodu konfliktów scalania, kod nie ma tego samego błędu. Cały kod ma znaczenie semantyczne, więc rozwiązywanie konfliktów nie jest trudniejsze niż zwykle.

Con: Prototypowanie

trudno jest określić, jak będzie wyglądał układ, dopóki nie zobaczysz go w akcji. Co więcej, nie można wizualnie pozycjonować widoków i formantów, więc tłumaczenie specyfikacji układu na namacalny Widok może trwać znacznie dłużej, w porównaniu do stalówek i storyboardów, które dają natychmiastowy podgląd tego, jak rzeczy będą renderowane.

Con: Refaktoryzacja

refaktoryzacja kodu napisanego dawno temu lub przez kogoś innego również staje się znacznie bardziej skomplikowana: gdy elementy są pozycjonowane i animowane za pomocą niestandardowych metod i magicznych liczb, sesje debugowania mogą stać się uciążliwe.

Pro: wydajność

pod względem wydajności storyboardy i Stalówki podlegają narzutowi ładowania i parsowania, a ostatecznie są pośrednio tłumaczone na kod. Nie trzeba dodawać, że nie dzieje się tak z kodowymi interfejsami użytkownika.

Pro: Możliwość wielokrotnego użytku

każdy widok zaimplementowany programowo może być zaprojektowany w sposób wielokrotnego użytku. Zobaczmy kilka przypadków użycia:

• dwa lub więcej poglądów mają wspólne zachowanie, ale są nieco inne. Klasa podstawowa i dwie podklasy rozwiązują problem elegancko.
• projekt musi zostać rozwidlony, w celu stworzenia pojedynczej bazy kodu, ale wygenerowania dwóch (lub więcej) różnych aplikacji, każda z określonymi dostosowaniami.

ten sam proces projektowania interfejsu użytkownika byłby znacznie bardziej skomplikowany w przypadku stalówek i storyboardów. Pliki szablonów nie pozwalają na dziedziczenie, a możliwe rozwiązania są ograniczone do następujących:

• Zduplikuj pliki Stalówki i storyboardu. Po tym mają oddzielne życie i nie mają związku z oryginalnym plikiem.
• Zastąp wygląd i zachowanie kodem, co może działać w prostych przypadkach, ale może prowadzić do poważnych komplikacji w innych. Ciężkie przesłonięcia z kodem mogą również sprawić, że projekt wizualny stanie się bezużyteczny i przekształci się w stałe źródło bólu głowy, np., gdy pewna kontrola wyświetla się w jedną stronę w Konstruktorze interfejsu, ale wygląda zupełnie inaczej, gdy aplikacja jest uruchomiona.

kiedy używać kodu

często dobrym pomysłem jest użycie niestandardowego kodu do projektowania interfejsu użytkownika iOS, gdy masz:

• dynamiczne układy.
• widoki z efektami, takimi jak zaokrąglone rogi, cienie itp.
• każdy przypadek, w którym używanie stalówek i storyboardów jest skomplikowane lub niewykonalne.

kiedy nie należy używać kodu

Ogólnie rzecz biorąc, można zawsze użyć interfejsu użytkownika wykonanego kodem. Rzadko są złym pomysłem, więc umieściłbym tutaj.

chociaż NIBs i storyboardy przynoszą pewne korzyści do stołu, czuję, że nie ma rozsądnego minusa, który umieściłbym na liście, aby zniechęcić do korzystania z kodu (z wyjątkiem, być może, lenistwa).

jeden projekt, Wiele narzędzi

storyboardy, Stalówki i Kod to trzy różne narzędzia do budowania interfejsu użytkownika iOS. Mamy szczęście, że je mamy. Fanatycy programmatic UIs prawdopodobnie nie wezmą pod uwagę pozostałych dwóch opcji: kod pozwala robić wszystko, co jest technicznie możliwe, podczas gdy alternatywy mają swoje ograniczenia. Dla reszty programistów, Xcode Army knife zapewnia trzy narzędzia, które mogą być używane jednocześnie, w tym samym projekcie, skutecznie.

jak, pytasz? Jak chcesz. Oto kilka możliwych podejść:

• pogrupuj wszystkie powiązane ekrany w osobne grupy i zaimplementuj każdą grupę z odrębnym Storyboardem.
• projektuj komórki tabeli, które nie nadają się do wielokrotnego użytku, na miejscu za pomocą storyboardu, wewnątrz kontrolera widoku tabeli.
• Zaprojektuj komórki tabeli wielokrotnego użytku w Stalówkach, aby zachęcić do ponownego użycia i uniknąć powtarzania, ale załaduj te Stalówki za pomocą niestandardowego kodu.
• projektuj własne widoki, kontrolki i Obiekty między obiektami za pomocą stalówek.
• Użyj kodu dla bardzo dynamicznych widoków, a bardziej ogólnie dla widoków, które nie są łatwe do implementacji za pomocą Storyboardów i stalówek, podczas gdy przejścia widoku w Scenopisie.

aby zamknąć, spójrzmy na ostatni przykład, który łączy to wszystko razem.

prosty przypadek użycia

powiedzmy, że chcemy stworzyć podstawową aplikację do przesyłania wiadomości z kilkoma różnymi widokami:

• Lista obserwowanych znajomych (z szablonem komórki wielokrotnego użytku, aby zachować spójność interfejsu użytkownika na przyszłych listach).
• widok szczegółowy profilu, podzielony na osobne sekcje (w tym informacje o Profilu, statystyki i pasek narzędzi).
• lista wiadomości wysłanych i otrzymanych od znajomego.
• nowy formularz wiadomości.
• widok chmury znaczników, który wyświetla różne tagi używane w wiadomościach użytkownika, z każdym znacznikiem proporcjonalnym do liczby razy został użyty.

ponadto chcemy, aby widoki płynęły w następujący sposób:

• kliknięcie elementu na liście obserwowanych znajomych powoduje wyświetlenie szczegółów profilu danego znajomego.
• szczegóły profilu pokazują nazwę profilu, adres, statystyki, krótką listę najnowszych wiadomości i pasek narzędzi.

aby zaimplementować tę aplikację na iOS, wszystkie trzy nasze narzędzia UI przydadzą się, ponieważ możemy z nich korzystać:

• Storyboard z czterema kontrolerami widoku (lista, szczegóły, lista wiadomości i formularz nowej wiadomości).
• oddzielny plik NIB dla szablonu komórki listy profili wielokrotnego użytku.
• trzy oddzielne pliki stalówki dla widoku szczegółów profilu, po jednym dla każdej z osobnych sekcji, które go tworzą (szczegóły profilu, statystyki, ostatnie trzy wiadomości), aby umożliwić lepszą konserwację. Te Stalówki będą tworzone jako widoki, a następnie dodawane do kontrolera widoku.
• kod niestandardowy dla widoku chmury tagów. Ten widok jest typowym przykładem takiego, którego nie można zaprojektować w Konstruktorze interfejsu, ani za pomocą Storyboardów, ani stalówek. Zamiast tego jest całkowicie zaimplementowany za pomocą kodu. Aby utrzymać przepływ wizualny scenorysu, dodajemy pusty kontroler widoku do scenorysu, implementujemy widok chmury tagów jako samodzielny widok i programowo dodajemy widok do kontrolera widoku. Oczywiście Widok może być również zaimplementowany wewnątrz kontrolera widoku, a nie jako samodzielny widok, ale trzymamy je osobno dla lepszego ponownego użycia.

naprawdę podstawowa makieta może wyglądać tak:

w ten sposób nakreśliliśmy podstawową konstrukcję dość wyrafinowanej aplikacji na iOS, której podstawowe widoki łączą nasze trzy podstawowe podejścia do projektowania interfejsu użytkownika. Pamiętaj: nie ma binarnej decyzji do podjęcia, ponieważ każde narzędzie ma swoje mocne i słabe strony.

zakończenie

jak zbadano w tym turtorialu, storyboardy dodają zauważalne uproszczenie do projektu interfejsu iOS i przepływu wizualnego. Eliminują również kod boilerplate; ale wszystko to ma cenę, płaconą w elastyczności. Stalówki oferują natomiast większą elastyczność, skupiając się na jednym widoku, ale bez przepływu obrazu. Najbardziej elastycznym rozwiązaniem jest oczywiście kod, który jest raczej nieprzyjazny i z natury niewizualny.

Jeśli ten artykuł Cię zaintrygował, Gorąco polecam obejrzenie wspaniałej debaty Raya Wenderlicha, 55-minutowej dobrze poświęconej dyskusji o Stalówkach, Storyboardach i kodowych interfejsach użytkownika.

na zakończenie chcę podkreślić jedną rzecz: za wszelką cenę Unikaj używania niewłaściwego narzędzia do projektowania interfejsu użytkownika iOS. Jeśli widok nie można zaprojektować za pomocą storyboardu lub jeśli można go zaimplementować za pomocą stalówek lub kodu w prostszy sposób, nie używaj storyboardu. Podobnie, jeśli widok nie jest możliwy do zaprojektowania przy użyciu stalówek, nie używaj stalówek. Te zasady, choć proste, będzie przejść długą drogę w edukacji jako deweloper.