Aktualizacja 1/12/2016 : Jest rok 2016 i nadal wolę układać moje interfejsy w kodzie, a nie w Storyboardach. To powiedziawszy, Storyboardy przeszły długą drogę. Usunąłem wszystkie punkty z tego postu, które po prostu już nie obowiązują w 2016 roku.
Aktualizacja 24.04.2015 : Co ciekawe, Apple nawet nie używa Storyboardów w swoim niedawno otwartym pakiecie ResearchKit, jak zauważył Peter Steinberger (pod podtytułem „Konstruktor interfejsów”).
Aktualizacja 6/10/2014 : Zgodnie z oczekiwaniami Apple stale ulepsza Storyboardy i Xcode. Niektóre punkty, które dotyczyły iOS 7 i niższych, nie dotyczą już iOS 8 (i są teraz oznaczone jako takie). Tak więc, chociaż Storyboardy z natury wciąż mają wady, zmieniam moją radę od nie używaj do selektywnego używania tam, gdzie ma to sens .
Nawet teraz, gdy iOS 9 jest niedostępny, radziłbym przeciwkozachować ostrożność przy podejmowaniu decyzji, czy używać Storyboardów. Oto moje powody:
Scenorysy kończą się niepowodzeniem w czasie wykonywania, a nie w czasie kompilacji : literówka w nazwie segue lub źle połączona w storyboardzie? Wybuchnie podczas działania. Używasz niestandardowej podklasy UIViewController, która już nie istnieje w twojej serii ujęć? Wybuchnie podczas działania. Jeśli robisz takie rzeczy w kodzie, złapiesz je wcześnie, podczas kompilacji. Aktualizacja : Moje nowe narzędzie StoryboardLint głównie rozwiązuje ten problem.
Scenorysy szybko się mylą : w miarę rozwoju projektu nawigacja staje się coraz trudniejsza. Ponadto, jeśli wiele kontrolerów widoku ma wiele sekwencji do wielu innych kontrolerów widoku, twoja plansza szybko zaczyna wyglądać jak miska spaghetti, a zobaczysz, że powiększasz i pomniejszasz i przewijasz w dowolnym miejscu, aby znaleźć kontroler widoku, którego szukasz i dowiedzieć się, gdzie segue punktów. Aktualizacja : Ten problem można w większości rozwiązać, dzieląc Storyboard na wiele Storyboard, jak opisano w tym artykule Pilky i tym artykule Roberta Browna .
Scenorysy utrudniają pracę w zespole : ponieważ zazwyczaj masz tylko jeden ogromny plik scenariuszy dla swojego projektu, wielu programistów regularnie wprowadzających zmiany w tym jednym pliku może być uciążliwe: zmiany muszą zostać scalone, a konflikty rozwiązane. Kiedy pojawia się konflikt, trudno jest powiedzieć, jak go rozwiązać: Xcode generuje plik XML scenorysu i nie został tak naprawdę zaprojektowany z myślą o tym, że człowiek musiałby czytać, a co dopiero edytować.
Scenorysy utrudniają lub wręcz uniemożliwiają recenzowanie kodu: recenzowanie kodu równorzędnego to świetna rzecz dla twojego zespołu. Jednak po wprowadzeniu zmian w serii ujęć przeglądanie tych zmian z innym programistą jest prawie niemożliwe. Wszystko, co możesz wyciągnąć, to plik różnicowy dużego pliku XML. Rozszyfrowanie, co naprawdę się zmieniło i czy te zmiany są poprawne lub jeśli coś zepsuło, jest naprawdę trudne.
Scenorysy utrudniają ponowne użycie kodu : w moich projektach na iOS zwykle tworzę klasę, która zawiera wszystkie kolory i czcionki oraz marginesy i wypustki, których używam w aplikacji, aby nadać jej spójny wygląd: To zmiana jednej linii, jeśli muszę dostosuj dowolne z tych wartości dla całej aplikacji. Jeśli ustawisz takie wartości w serii ujęć, powiel je i będziesz musiał znaleźć każde wystąpienie, gdy chcesz je zmienić. Szanse są duże, że przegapisz jedną, ponieważ nie ma wyszukiwania i zamiany w scenorysach.
Scenorysy wymagają ciągłego przełączania kontekstu : pracuję i nawiguję znacznie szybciej w kodzie niż w scenorysach. Kiedy Twoja aplikacja używa scenariuszy, ciągle zmieniasz kontekst: „Och, chcę dotknąć tej komórki widoku tabeli, aby załadować inny kontroler widoku. Teraz muszę otworzyć scenorys, znaleźć odpowiedni kontroler widoku, utworzyć nowy segue do drugiego kontrolera widoku (który również muszę znaleźć), nadaj segue nazwę, pamiętaj tę nazwę (nie mogę używać stałych lub zmiennych w scenorysach), przełącz się z powrotem na kod i mam nadzieję, że nie pomylę nazwy ten segment dla mojej metody preparForSegue. Chciałbym po prostu wpisać te 3 wiersze kodu tutaj, gdzie jestem! ” Nie, to nie jest zabawne. Przełączanie między kodem a scenorysem (oraz klawiaturą i myszą) szybko się starzeje i spowalnia.
Scenorysy są trudne do refaktoryzacji : Kiedy refaktoryzujesz kod, musisz upewnić się, że nadal odpowiada on oczekiwaniom twojego scenorysu. Gdy poruszasz się po swoim scenariuszu, dowiesz się w czasie wykonywania tylko wtedy, gdy nadal działa z twoim kodem. Wydaje mi się, że muszę zsynchronizować dwa światy. To kruche i zniechęca do zmiany mojej skromnej opinii.
Scenorysy są mniej elastyczne : w kodzie możesz w zasadzie robić wszystko, co chcesz! W przypadku scenariuszy jesteś ograniczony do części tego, co możesz zrobić w kodzie. Zwłaszcza, gdy chcesz robić zaawansowane rzeczy z animacjami i przejściami, „walczysz z scenariuszem”, aby go uruchomić.
Scenorysy nie pozwalają na zmianę rodzaju specjalnych kontrolerów widoku : Chcesz zmienić a UITableViewControllerna UICollectionViewController? A może na równinę UIViewController? Niemożliwe w serii ujęć. Musisz usunąć stary kontroler widoku, utworzyć nowy i połączyć ponownie wszystkie sekwensy. O wiele łatwiej jest dokonać takiej zmiany kodu.
Storyboardy dodają dwa dodatkowe zobowiązania do twojego projektu : (1) Narzędzie Storyboard Editor, które generuje XML scenorysu i (2) składnik środowiska wykonawczego, który analizuje XML i tworzy z niego obiekty interfejsu użytkownika i kontrolera. Obie części mogą zawierać błędy, których nie można naprawić.
Scenorysy nie pozwalają dodawać podview doUIImageView : Kto wie, dlaczego.
Scenorysy nie pozwalają na włączenie automatycznego układu dla poszczególnych widoków (-Kontrolera) : Zaznaczenie / odznaczenie opcji automatycznego układu w serii ujęć powoduje zmianę wszystkich WSZYSTKICH kontrolerów w serii ujęć. (Podziękowania dla Sava Mazăre za ten punkt!)
Scenorysy mają większe ryzyko zerwania z kompatybilnością wsteczną : Xcode czasami zmienia format pliku Storyboard i nie gwarantuje w żaden sposób, że będziesz w stanie otworzyć pliki Storyboard, które utworzysz dzisiaj za kilka lat, a nawet miesięcy. (Dziękujemy za przemyślenia na ten temat. Zobacz oryginalny komentarz )
Scenorysy mogą sprawić, że kod stanie się bardziej złożony : Kiedy tworzysz kontrolery widoku w kodzie, możesz initna przykład tworzyć niestandardowe metody initWithCustomer:. W ten sposób możesz sprawić, że customerwnętrze kontrolera widoku pozostanie niezmienne i upewnij się, że nie można utworzyć tego kontrolera widoku bez customerobiektu. Nie jest to możliwe podczas korzystania z Storyboardów. Musisz poczekać na prepareForSegue:sender:wywołanie metody, a następnie ustawić customerwłaściwość na kontrolerze widoku, co oznacza, że musisz zmienić tę właściwość na zmienną i musisz zezwolić na utworzenie kontrolera widoku bez customerobiektu . Z mojego doświadczenia wynika, że może to znacznie skomplikować kod i utrudnić rozumowanie przepływu aplikacji. Zaktualizuj 9/9/16: Chris Dzombak napisał świetny artykuł na temat tego problemu .
To McDonald's : Powiedzieć to słowami Steve'a Jobsa o Microsoft: To McDonald's (wideo) !
To są moje powody, dla których naprawdę nie lubię pracować z storyboardami. Niektóre z tych powodów dotyczą również XIB. Przy projektach opartych na scenorysach, nad którymi pracowałem, kosztowały mnie znacznie więcej czasu niż zaoszczędziły i sprawiły, że sprawy stały się bardziej skomplikowane, a nie łatwiejsze.
Kiedy tworzę interfejs użytkownika i przepływ aplikacji w kodzie, mam większą kontrolę nad tym, co się dzieje, łatwiej jest debugować, łatwiej jest wcześnie wykryć błędy, łatwiej jest wyjaśnić moje zmiany innym programistom i to łatwiej jest obsługiwać iPhone'a i iPada.
Zgadzam się jednak, że umieszczenie całego interfejsu użytkownika w kodzie może nie być uniwersalnym rozwiązaniem dla każdego projektu. Jeśli interfejs iPada różni się znacznie od interfejsu iPhone w niektórych miejscach, warto utworzyć XIB tylko dla tych obszarów.
Wiele z opisanych powyżej problemów może rozwiązać Apple i mam nadzieję, że tak właśnie zrobią.
Tylko moje dwa centy.
Aktualizacja : w Xcode 5 Apple usunęło opcję stworzenia projektu bez Storyboard. Napisałem mały skrypt, który przenosi szablony Xcode 4 (z opcją rezygnacji z Storyboard) do Xcode 5: https://github.com/jfahrenkrug/Xcode4templates
