Interfejsy użytkownika iOS: scenorysy a karty sieciowe a kod niestandardowy

Często słyszę, jak deweloperzy iOS zadają jakiś wariant tego samego kluczowego pytania:

Jaki jest najlepszy sposób na opracowanie interfejsu użytkownika w systemie iOS: za pomocą scenorysów, NIBów lub kodu?

Odpowiedzi na to pytanie, w sposób wyraźny lub dorozumiany, zakładają, że należy dokonać wzajemnie wykluczającego się wyboru, który często jest podejmowany z góry, przed opracowaniem.

Uważam, że odpowiedź powinna przybrać formę jednego lub więcej kontrpytań .

Jaki jest „najlepszy” samochód?

Pozwólcie, że wyjaśnię na przykładzie nie na temat. Powiedzmy, że chcę kupić samochód i zadam jedno proste pytanie: „Jaki jest najlepszy wybór?”

Czy naprawdę możesz odpowiedzieć, proponując model, a nawet markę? Mało prawdopodobne, chyba że zasugerujesz Ferrari. Zamiast tego prawdopodobnie odpowiedziałbyś kilkoma innymi pytaniami, takimi jak:

• Jaki jest twój budżet?
• Ile miejsc potrzebujesz?
• Zależy Ci na zużyciu paliwa?
• Co myślisz o samochodach sportowych?

Oczywiste jest, że nie ma czegoś takiego jak dobry lub zły samochód, o ile nie zostanie umieszczony w odpowiednim kontekście – jest po prostu dobry lub zły samochód w zależności od konkretnych potrzeb.

Powrót do projektowania interfejsu użytkownika iOS

Podobnie jak w przypadku naszego zapytania dotyczącego samochodu, pytanie „Jak najlepiej opracować interfejs użytkownika iOS” nie ma kontekstu. I, co zaskakujące, odpowiedź nie musi być ogólna.

Ogólnie rzecz biorąc, istnieją trzy rodzaje podejść do projektowania interfejsu użytkownika, które można zastosować, każde z jego zaletami i wadami, fanami i hejterami:

• Scenorysy iOS : wizualne narzędzie do układania wielu widoków aplikacji i przejść między nimi.
• NIBs (lub XIBs) : Każdy plik NIB odpowiada pojedynczemu elementowi widoku i może być ułożony w Interface Builder, co czyni go również narzędziem wizualnym. Zauważ, że nazwa „NIB” pochodzi od rozszerzenia pliku (wcześniej .nib, a teraz .xib, chociaż zachowała się stara wymowa).
• Kod niestandardowy : tj. bez narzędzi GUI, ale raczej programowo obsługujące wszystkie niestandardowe pozycjonowanie, animacje itp.

Żadna z tych opcji nie jest uniwersalnie lepsza niż jakakolwiek inna (pomimo tego, co możesz usłyszeć).

Na przykład scenorysy to najnowszy dodatek do zestawu narzędzi iOS UI. Powiedziano mi, że to przyszłość, że zastąpią NIB-y i niestandardowe interfejsy użytkownika. Widzę Storyboards jako przydatne narzędzie, ale nie tyle zamiennik , co uzupełnienie NIBów i niestandardowego kodu. Storyboardy są właściwym wyborem w niektórych, ale nie we wszystkich sytuacjach.

Co więcej, dlaczego miałbyś statycznie trzymać się jednej opcji, skoro możesz użyć ich wszystkich (w tym samym projekcie), wybierając mechanizm, który najlepiej pasuje do konkretnego problemu?

Jest to pytanie, które moim zdaniem można uogólnić na wyższym poziomie i na które odpowiedź jest wysoko oceniana na mojej liście zasad tworzenia oprogramowania: nie ma uniwersalnego języka, frameworka ani technologii, która byłaby uniwersalnym najlepszym wyborem dla każdego problem rozwoju oprogramowania. To samo dotyczy projektowania interfejsu użytkownika systemu iOS.

W tym samouczku dotyczącym programowania na iOS zamierzamy zbadać każdą z tych metod i przedstawić przypadki użycia, w których powinny i nie powinny być stosowane, a także sposoby ich łączenia.

Scenorysy na iOS

Klasycznym błędem początkującego jest stworzenie jednego ogromnego scenorysu iOS obejmującego cały projekt. Ja też popełniłem ten błąd, kiedy po raz pierwszy zacząłem pracować ze Storyboards (prawdopodobnie dlatego, że jest to kusząca trasa).

Jak sama nazwa wskazuje, Storyboard to tablica z historią do opowiedzenia . Nie należy jej używać do łączenia niepowiązanych historii w jeden duży tom. Scenorys powinien zawierać kontrolery widoku, które są ze sobą logicznie powiązane — co nie oznacza, że ​​każdy kontroler widoku.

Na przykład sensowne jest używanie scenorysów podczas obsługi:

• Zestaw widoków do uwierzytelniania i rejestracji.
• Wieloetapowy przepływ wprowadzania zamówień.
• Przepływ przypominający czarodzieja (tj. samouczek).
• Główny i szczegółowy zestaw widoków (np. listy profili, szczegóły profilu).

Tymczasem należy unikać dużych scenorysów, w tym scenorysów obejmujących całą aplikację (chyba że aplikacja jest stosunkowo prosta). Zanim wejdziemy głębiej, zobaczmy dlaczego.

Szaleństwo dużych scenorysów iOS

Duże scenorysy, poza tym, że są trudne do przeglądania i utrzymania, dodają warstwę złożoności do środowiska zespołowego: gdy wielu programistów pracuje jednocześnie nad tym samym plikiem scenorysów, konflikty kontroli źródła są nieuniknione . I chociaż scenorys 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. Dzięki temu podczas ręcznego łączenia są w stanie odczytać i zrozumieć obie strony konfliktu i odpowiednio działać. Zamiast tego scenorys jest plikiem XML zarządzanym przez Xcode, a znaczenie każdego wiersza kodu nie zawsze jest łatwe do zrozumienia.

Weźmy bardzo prosty przykład: powiedzmy, że dwóch różnych programistów zmienia pozycję etykiety UILabel (używając autoukładu), a ten drugi wprowadza swoją zmianę, tworząc konflikt taki (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 wskazuje w żaden sposób 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, zalecanym podejściem jest używanie wielu scenorysów w tym samym projekcie.

Kiedy używać scenorysów

Scenorysów najlepiej używać z wieloma połączonymi ze sobą kontrolerami widoku, ponieważ ich głównym uproszczeniem jest przechodzenie między kontrolerami widoku. Do pewnego stopnia można je traktować jako kompozycję NIBów z wizualnymi i funkcjonalnymi przepływami między kontrolerami widoku.

Oprócz ułatwienia przepływu nawigacji, kolejną wyraźną zaletą jest to, że eliminują one standardowy kod potrzebny do wyskakiwania, wypychania, prezentowania i zamykania kontrolerów widoku. Co więcej, kontrolery widoku są przydzielane automatycznie, więc nie ma potrzeby ręcznego alloc i init .

Wreszcie, chociaż scenorysy najlepiej nadają się do scenariuszy obejmujących wiele kontrolerów widoku, można również używać scenorysów podczas pracy z jednym kontrolerem widoku tabeli z trzech powodów:

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

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

Kiedy nie używać scenorysów iOS

Kilka przypadków:

• Widok ma skomplikowany lub dynamiczny układ, najlepiej zaimplementowany za pomocą kodu.
• Widok jest już zaimplementowany za pomocą NIBów lub kodu.

W takich przypadkach możemy pozostawić widok poza scenorysem lub osadzić go w kontrolerze widoku. Ten pierwszy przerywa przepływ wizualny Storyboard, ale nie ma żadnych negatywnych konsekwencji funkcjonalnych ani 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 składnik, dlatego kontroler widoku musi wchodzić w interakcje z widokiem, a nie go implementować.

Ogólne plusy i minusy

Teraz, gdy wiemy, kiedy Storyboardy są przydatne w projektowaniu interfejsu użytkownika w systemie iOS, i zanim przejdziemy do NIBów w tym samouczku, przyjrzyjmy się ich ogólnym zaletom i wadom.

Zaleta: wydajność

Intuicyjnie można założyć, że po załadowaniu scenorysu 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 taki istnieje. Inne kontrolery widoku są tworzone dynamicznie, podczas wykonywania przejścia lub ręcznie z kodu.

Zaleta: prototypy

Scenorysy upraszczają tworzenie prototypów i makiety 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ą scenorysów i zaledwie kilku linijek kodu.

Wada: Ponowne użycie

Jeśli chodzi o przenoszenie lub kopiowanie, scenorysy iOS są słabo pozycjonowane. Scenorys musi zostać przeniesiony wraz ze wszystkimi zależnymi kontrolerami widoku. Innymi słowy, pojedynczy kontroler widoku nie może być indywidualnie wyodrębniany i ponownie używany gdzie indziej jako pojedyncza niezależna jednostka; działanie zależy od reszty Storyboardu.

Wada: przepływ danych

Dane często muszą być przesyłane między kontrolerami widoku podczas przejścia aplikacji. Jednak w tym przypadku przepływ wizualny Storyboardu jest zepsuty, ponieważ nie ma śladu tego w konstruktorze interfejsów. Scenorysy zajmują się obsługą przepływu między kontrolerami widoku, ale nie przepływem danych. Tak więc kontroler docelowy musi być skonfigurowany za pomocą kodu, który ma pierwszeństwo przed wrażeniami wizualnymi.

W takich przypadkach musimy polegać na prepareForSegue:sender , ze szkieletem if/else-if takim jak ten:

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

Uważam, że takie podejście jest podatne na błędy i niepotrzebnie gadatliwe.

NIBy

NIB to starszy (starszy) sposób projektowania interfejsu iOS.

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

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

Jeśli zastosujemy projektowanie obiektowe do naszych interfejsów użytkownika, wówczas 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 testowania i łatwiejszy do debugowania.

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

Kiedy używać NIBów do projektowania interfejsu użytkownika w systemie iOS

Podzbiór wszystkich przypadków użycia to:

• Widoki modalne
• Proste widoki logowania i rejestracji
• Ustawienia
• Wyskakujące okienka
• Szablony widoków wielokrotnego użytku
• Szablony komórek tabeli wielokrotnego użytku

Tymczasem…

Kiedy nie używać NIBów

Należy unikać używania NIBów do:

• Widoki z zawartością dynamiczną, w których 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.
• Przeglądaj kontrolery ze skomplikowanymi przejściami, które można uprościć dzięki Storyboardingowi.

Ogólne plusy i minusy

Bardziej ogólnie, przyjrzyjmy się zaletom i wadom korzystania z NIBów.

Zaleta: możliwość wielokrotnego użytku

NIBy 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żna zaimplementować z hipotetycznymi TTLoginView i TTSignupView , z których oba mogą pochodzić z tego samego NIB. TTLoginView musiałby ukryć pole hasła i oba musiałyby określić odpowiednie etykiety statyczne (takie jak „Wprowadź swoją nazwę użytkownika” lub „Wprowadź swoje hasło”), ale etykiety miałyby tę samą podstawową funkcjonalność i podobny układ.

Plusy i minusy: wydajność

NIB-y są ładowane leniwie, więc nie używają pamięci, dopóki nie będą musiały. Chociaż może to być zaletą, istnieje opóźnienie w procesie leniwego ładowania, co czyni go również pewnym minusem.

Kod niestandardowy iOS (automatyczne interfejsy użytkownika)

Każdy projekt interfejsu iOS, który można wykonać za pomocą Storyboardów i NIBów, można również zaimplementować za pomocą surowego kodu (był czas, kiedy programiści nie mieli luksusu tak bogatego zestawu narzędzi).

Co być może ważniejsze, to, czego nie można zrobić za pomocą NIBów i scenorysó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 NIBy i scenorysy są implementowane za pomocą kodu, więc ich funkcjonalność będzie naturalnie podzbiorem. Przejdźmy od razu do zalet i wad.

Pro: Pod maską

Największa zaleta 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 NIBów i scenorysów.

Dla porównania: kalkulator to przydatne narzędzie. Ale nie jest źle wiedzieć, jak wykonywać obliczenia ręcznie.

Nie ogranicza się to do iOS, ale do dowolnego narzędzia Visual RAD (np. Visual Studio i Delphi, żeby wymienić tylko kilka). Wizualne środowiska HTML RAD reprezentują typowy przypadek z pogranicza: są używane do generowania (często źle napisanego) kodu, twierdząc, że nie jest potrzebna wiedza na temat HTML i że wszystko można zrobić wizualnie. Ale żaden programista nie zaimplementowałby strony internetowej bez brudzenia sobie rąk: wiedzą, że ręczna obsługa surowego kodu HTML i CSS doprowadzi do bardziej modularnego i wydajniejszego kodu.

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

Zaleta: Kiedy kod jest jedyną opcją

Istnieją również przypadki, w których niestandardowy kod iOS jest jedyną opcją projektowania interfejsu użytkownika. Typowymi przykładami są układy dynamiczne, w których elementy widoku są przesuwane, a przepływ lub układ dostosowuje się znacząco na podstawie zawartości.

Pro: Połącz konflikty

Podczas gdy NIBy i scenorysy znacznie ucierpiały z powodu konfliktów scalania, kod nie ma tej samej usterki. Cały kod ma znaczenie semantyczne, więc rozwiązywanie konfliktów nie jest trudniejsze niż zwykle.

Wada: Prototypowanie

Trudno jest wymyś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 kontrolek, więc tłumaczenie specyfikacji układu na namacalny widok może zająć znacznie więcej czasu w porównaniu z NIB-ami i scenorysami, które dają natychmiastowy podgląd tego, jak będą renderowane rzeczy.

Wada: Refaktoryzacja

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

Zaleta: wydajność

Pod względem wydajności Storyboardy i NIBy podlegają narzutowi ładowania i analizowania; a na końcu są pośrednio tłumaczone na kod. Nie trzeba dodawać, że tak się nie dzieje w przypadku interfejsów użytkownika stworzonych w kodzie.

Zaleta: możliwość wielokrotnego użytku

Każdy widok zaimplementowany programowo można zaprojektować w sposób wielokrotnego użytku. Zobaczmy kilka przypadków użycia:

• Co najmniej dwa widoki mają wspólne zachowanie, ale różnią się nieco. Klasa bazowa i dwie podklasy elegancko rozwiązują problem.
• Projekt musi zostać rozwidlony, w celu stworzenia jednej bazy kodu, ale wygenerowania dwóch (lub więcej) różnych aplikacji, z których każda ma określone dostosowania.

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

• Powiel pliki NIB i Storyboard. Potem mają oddzielne życia i nie mają żadnego 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 znacznych komplikacji w innych. Ciężkie nadpisania kodem mogą również sprawić, że projekt wizualny stanie się bezużyteczny i stanie się stałym źródłem problemów, np. gdy pewna kontrolka wyświetla się w jeden sposób w Interface Builder, 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 systemu iOS, gdy masz:

• Układy dynamiczne.
• Widoki z efektami, takimi jak zaokrąglone rogi, cienie itp.
• Każdy przypadek, w którym korzystanie z NIBów i scenorysów jest skomplikowane lub niewykonalne.

Kiedy nie używać kodu

Ogólnie rzecz biorąc, interfejsy użytkownika stworzone w kodzie mogą być zawsze używane. Rzadko są złym pomysłem, więc postawiłbym tutaj.

Chociaż NIBy i scenorysy przynoszą pewne korzyści w tabeli, uważam, że nie ma sensownych wad, które umieściłbym na liście, aby zniechęcić do używania kodu (może z wyjątkiem lenistwa).

Jeden projekt, wiele narzędzi

Scenorysy, NIBy i kod to trzy różne narzędzia do tworzenia interfejsu użytkownika iOS. Mamy szczęście, że je mamy. Fanatycy programistycznych interfejsów użytkownika prawdopodobnie nie wezmą pod uwagę dwóch pozostałych opcji: kod pozwala zrobić wszystko, co jest technicznie możliwe, podczas gdy alternatywy mają swoje ograniczenia. Pozostałym programistom scyzoryk Xcode zapewnia trzy narzędzia, z których można skutecznie korzystać jednocześnie, w tym samym projekcie.

Jak pytasz? Jednak lubisz. Oto kilka możliwych podejść:

• Pogrupuj wszystkie powiązane ekrany w osobne grupy i zaimplementuj każdą grupę z własnym, odrębnym Storyboardem.
• Projektuj komórki tabeli jednorazowego użytku na miejscu za pomocą scenorysu wewnątrz kontrolera widoku tabeli.
• Projektuj komórki tabeli wielokrotnego użytku w NIBach, aby zachęcić do ponownego użycia i uniknąć powtórzeń, ale ładuj te NIBy za pomocą niestandardowego kodu.
• Projektuj niestandardowe widoki, kontrolki i obiekty pośrednie za pomocą NIBs.
• Użyj kodu dla bardzo dynamicznych widoków, a bardziej ogólnie dla widoków, których nie można łatwo zaimplementować za pomocą scenorysów i NIBów, podczas gdy przejścia widoków są przechowywane w scenorysie.

Na zakończenie spójrzmy na ostatni przykład, który łączy to wszystko razem.

Prosty przypadek użycia

Załóżmy, że chcemy opracować 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ółów profilu, składający się z oddzielnych sekcji (w tym informacje o profilu, statystyki i pasek narzędzi).
• Lista wiadomości wysłanych i otrzymanych od znajomego.
• Nowa forma wiadomości.
• Widok chmury tagów, który wyświetla różne tagi używane w wiadomościach użytkownika, przy czym rozmiar każdego tagu jest proporcjonalny do liczby jego użycia.

Ponadto chcemy, aby widoki przebiegały w następujący sposób:

• Kliknięcie elementu na liście obserwowanych znajomych powoduje wyświetlenie szczegółów profilu odpowiedniego znajomego.
• Szczegóły profilu zawierają nazwę profilu, adres, statystyki, krótką listę najnowszych wiadomości oraz pasek narzędzi.

Aby zaimplementować tę aplikację na iOS, przydadzą się wszystkie trzy nasze narzędzia interfejsu użytkownika, ponieważ możemy użyć:

• Scenorys 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 NIB dla widoku szczegółów profilu, po jednym dla każdej z oddzielnych sekcji, które go tworzą (szczegóły profilu, statystyki, ostatnie trzy komunikaty), aby umożliwić lepszą konserwację. Te NIB-y zostaną utworzone jako widoki, a następnie dodane do kontrolera widoku.
• Kod niestandardowy dla widoku chmury tagów. Ten widok jest typowym przykładem takiego, którego nie można zaprojektować w programie Interface Builder ani za pomocą StoryBoards, ani NIBów. Zamiast tego jest całkowicie zaimplementowany za pomocą kodu. Aby zachować wizualny przepływ scenorysu, wybieramy dodanie pustego kontrolera widoku do scenorysu, zaimplementujemy widok chmury tagów jako samodzielny widok i programowo dodamy widok do kontrolera widoku. Oczywiście widok można również zaimplementować w kontrolerze widoku, a nie jako samodzielny widok, ale trzymamy je osobno, aby lepiej było je ponownie wykorzystać.

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 trzeba podejmować decyzji binarnych, ponieważ każde narzędzie ma swoje mocne i słabe strony.

Zawijanie

Jak zbadano w tym samouczku, scenorysy dodają zauważalne uproszczenie do projektowania interfejsu użytkownika i przepływu wizualnego systemu iOS. Eliminują również standardowy kod; ale wszystko to ma swoją cenę, płaconą elastycznością. Tymczasem NIBs oferują większą elastyczność, koncentrując się na jednym widoku, ale bez wizualnego przepływu. Najbardziej elastycznym rozwiązaniem jest oczywiście kod, który bywa raczej nieprzyjazny i z natury niewizualny.

Jeśli ten artykuł Cię zaintrygował, gorąco polecam obejrzenie wspaniałej debaty Raya Wenderlicha, 55-minutowej dobrze spędzonej na dyskusji o NIB-ach, scenorysach i UIS stworzonym z kodu.

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 widoku nie można zaprojektować za pomocą scenorysu lub jeśli można go zaimplementować za pomocą NIBów lub kodu w prostszy sposób, nie używaj scenorysu. Podobnie, jeśli widoku nie można zaprojektować za pomocą NIB-ów, nie używaj NIB-ów. Te zasady, choć proste, będą miały duży wpływ na twoją edukację jako programisty.