Kiedy używać Storyboard i kiedy korzystać z XIB

Czy istnieją jakieś wytyczne dotyczące tego, kiedy używać scenorysów w projekcie iOS, a kiedy używać XIB? jakie są zalety i wady każdej z nich oraz w jakich sytuacjach one odpowiadają?

Prawie, jak mogę powiedzieć, nie jest tak łatwe w użyciu sekwencje scenariuszy, gdy kontrolery widoku są wypychane przez dynamiczne elementy interfejsu użytkownika (jak szpilki mapy).

Szeroko korzystałem z XIB i ukończyłem dwa projekty przy użyciu Storyboardów. Moje nauki to:

• Scenorysy są dobre dla aplikacji z małą lub średnią liczbą ekranów i stosunkowo prostą nawigacją między widokami.
• Jeśli masz wiele widoków i wiele nawigacji między nimi, widok Storyboard staje się mylący i zbyt wiele pracy, aby zachować czystość.
• W przypadku dużego projektu z wieloma programistami nie używałbym Storyboard, ponieważ masz jeden plik dla interfejsu użytkownika i nie możesz łatwo pracować równolegle.
• Duże aplikacje mogą być podzielone na wiele plików scenariuszy, ale nie próbowałem tego. Ta odpowiedź pokazuje, jak robić sekwencje między scenopisami.
• Nadal potrzebujesz XIB: W obu moich projektach Storyboard musiałem używać XIB do niestandardowych komórek tabeli.

Myślę, że Storyboardy są krokiem we właściwym kierunku dla implementacji interfejsu użytkownika i mam nadzieję, że Apple rozszerzy je w przyszłych wersjach iOS. Muszą jednak rozwiązać problem „pojedynczego pliku”, w przeciwnym razie nie będą atrakcyjne dla większych projektów.

Jeśli uruchomię małą aplikację i mogę pozwolić sobie na zgodność tylko z iOS5, użyłbym Storyboard. We wszystkich innych przypadkach trzymam się XIB.

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

Scenorysy zostały utworzone, aby pomóc programistom w wizualizacji ich aplikacji i przepływu aplikacji. To tak, jakby mieć kilka xib, ale w jednym pliku.

Pytanie podobne do tego. Jaka jest różnica między plikiem .xib a .storyboard? .

Możesz także tworzyć niestandardowe przejścia za pomocą kodu, który w razie potrzeby będzie się dynamicznie zmieniał, podobnie jak w przypadku plików .xib.

Plusy:

• Możesz naśladować przepływ aplikacji, nie pisząc dużo, jeśli w ogóle kodu.
• Znacznie łatwiej zobaczyć przejścia między ekranami i przepływ aplikacji.
• W razie potrzeby można także używać .xibs w scenorysach.

CONS:

• Działa tylko z iOS 5+. Nie działa z iOS4.
• Może być łatwo zagracony, jeśli masz bardzo intensywną aplikację.

Naprawdę nie ma dobrego / złego momentu, gdy chcesz użyć jednego lub drugiego, jest to tylko kwestia preferencji i tego, które wersje iOS chcesz używać.

Podam tylko 4 proste powody, dla których powinieneś używać scenorysów, szczególnie w produktywnym środowisku, w którym musisz pracować w zespole właścicieli produktów, menedżerów produktu, projektantów UX itp.

1. Apple znacznie poprawiło pracę z Storyboard. I zachęcają cię do współpracy z nimi. Co oznacza, że nie zepsują istniejących projektów aktualizacjami, zapewnią, że scenorysy będą w przyszłości odporne na nowsze wersje XCode / iOS.
2. Bardziej widoczne wyniki w krótszym czasie dla właścicieli produktów i menedżerów, nawet w fazie tworzenia. Możesz nawet użyć samej scenorysu jako diagramu przepływu ekranu i omawiać go na spotkaniach.
3. Nawet po zakończeniu aplikacji (i to na ogół tam, gdzie zaczyna się jej cykl życia) - w przyszłości będzie można szybciej i łatwiej wprowadzać niewielkie poprawki . I mogą bardzo dobrze zmienić wiele aspektów twojego układu w tym samym czasie, co prawdopodobnie chcesz zobaczyć w sposób WYSIWYG. Alternatywą byłoby ręczne pisanie zmian w interfejsie użytkownika i przełączanie się między IDE a symulatorem w celu przetestowania go, za każdym razem czekając na kompilację i kompilację.
4. Nie-programistów można nauczyć, jak konfigurować układy scenariuszy i tworzyć niezbędne haki dla programistów (IBOutlety i IBAction). To bardzo duży plus, ponieważ pozwala deweloperom skupić się na logice, a projektanci UX stosują zmiany w sposób wizualny, bez konieczności pisania kodu.

Nie będę pisać żadnych CONS, ponieważ Johannes wymienił już prawdopodobnie wszystkie realne w swojej odpowiedzi. I większość z nich na pewno nie jest wykonalna, szczególnie nie z ważnymi ulepszeniami XCode6.

Nie sądzę, aby na twoje pytanie była odpowiednia odpowiedź, to tylko kwestia osobistego doświadczenia i tego, z czym czujesz się bardziej komfortowo.

Moim zdaniem Storyboardy to świetna rzecz. To prawda, naprawdę trudno jest ustalić, dlaczego aplikacja w tajemniczy sposób ulega awarii w czasie wykonywania, ale po pewnym czasie i doświadczeniu zdasz sobie sprawę, że zawsze wiąże się to z brakiem jakiegoś IBOutleta i możesz łatwo to naprawić.

Jedynym prawdziwym problemem jest praca w zespole pod kontrolą wersji za pomocą scenariuszy, na wczesnych etapach rozwoju może to być prawdziwy bałagan. Ale po tym pierwszym etapie aktualizacje interfejsu użytkownika, które całkowicie zmieniają scenorys, są bardzo rzadkie, aw większości przypadków kończą się konflikty w ostatnich częściach pliku XML, które są oddzielnymi odniesieniami, które zwykle same się ustalają po ponownym otwarciu scenorysu . W pracy zespołowej woleliśmy sobie z tym poradzić zamiast ciężkich kontrolerów widoku z mnóstwem kodu widoku.

Przeczytałem wiele komentarzy dotyczących automatycznego układu. Z XCode5 został naprawdę ulepszony, jest naprawdę dobry nawet do autorotacji układów. W niektórych przypadkach będziesz musiał zrobić coś w kodzie, ale możesz po prostu usunąć ograniczenie, które musisz edytować, i w tym momencie zrobić to, czego potrzebujesz w kodzie. Nawet ożyw ich.

Myślę też, że większość osób, które nie lubią scenorysów, nie starały się w pełni zrozumieć mocy niestandardowego ręcznego sortowania, w którym można całkowicie dostosować (w jednym pliku) sposób przejścia z jednej drogi do drugiej, a także (z niektóre sztuczki), a nawet ponownie użyj wcześniej załadowanego kontrolera widoku, po prostu aktualizując jego zawartość widoku zamiast całkowicie ładować całość. Na koniec możesz naprawdę robić te same rzeczy, co w kodzie, ale myślę, że masz lepszy rozdział problemów z storyboardami, ale zgadzam się, że pod wieloma względami nie mają funkcji (czcionki, obraz jako kolorowe tło, itd.) ).

Nie używam StoryBoard ani XIB w żadnej z aplikacji .. ale tworzę wszystko programowo.

∆ Korzyści:

√ Możesz tworzyć wszelkiego rodzaju złożone interfejsy użytkownika lub animacje przejścia dla UIView.

√ Obsługuje wszystkie wersje iOS. Nie musisz się martwić o <iOS 5.

√ * Twoja aplikacja będzie obsługiwać wszystkie urządzenia iPhone / iPod / iPad w Twoim kodzie.

√ Jesteś zawsze na bieżąco, ponieważ znasz kod, który zawsze będzie działał.

√ * Działa na każdym uruchomionym (nowym) urządzeniu - nie trzeba zmieniać kodu.

√ Wszystko zależy od ciebie. W pewnym miejscu chcesz coś zmienić - nie musisz zaglądać do scenorysu lub Xib. Poszukaj go w konkretnej klasie.

√ Ostatnia, ale nie lista - nigdy tego nie zapomnisz, jak zarządzać wszystkim programowo. To najlepsza rzecz, ponieważ znasz kontrolę bardzo głęboko niż ktokolwiek inny.

_{Nigdy nie znalazłem problemu, ponieważ nie korzystałem z SB ani XIB, ponieważ jestem w tym dobry.}

_{* jeśli ustawiłeś ramki obiektów UIKit zgodnie z rozmiarem ekranu.}

_{PS Jeśli jeszcze tego nie zrobiłeś - możesz napotkać trudności (lub nudę), ale kiedy się z tym zapoznasz - to naprawdę Candy.}

Jeśli masz zamiar dbać o wydajność Storyboard, obejrzyj sesję 407 WWDC 2015

Czas budowy

Gdy konstruktor interfejsów kompiluje scenorys, najpierw robi dwie rzeczy, stara się zmaksymalizować wydajność aplikacji, a po drugie minimalizuje liczbę utworzonych plików końcówek.

Jeśli mam kontroler widoku z widokiem i kilka widoków podrzędnych, konstruktora interfejsu, czas kompilacji utworzy plik stalówki dla kontrolera widoku i plik stalówki dla widoku.

Dzięki osobnym plikom stalówki dla kontrolera widoku i widoku, hierarchia widoków może być ładowana na żądanie.

Czas pracy

Podczas przydzielania wystąpienia scenorysu za pomocą interfejsu użytkownika scenariusza interfejsu API, początkowo jedyną alokacją pamięci jest sama instancja scenorysu interfejsu użytkownika.

Brak kontrolerów widoków. Brak widoków.

Kiedy utworzysz instancję początkowego kontrolera widoku, załaduje on końcówkę dla tego początkowego kontrolera widoku, ale ponownie, nie załadowano jeszcze hierarchii widoków, dopóki ktoś o to nie poprosi.

Pracowałem nad projektem o rozsądnej wielkości (> 20 scen w języku scenariuszy), natknąłem się na wiele ograniczeń i musiałem wielokrotnie przeglądać dokumentację i wyszukiwać w wyszukiwarkach Google.

1. Interfejs użytkownika znajduje się w jednym pliku. Nawet jeśli utworzysz wiele scenariuszy, nadal masz wiele scen / ekranów w każdej scenorysie. Jest to problem w średnich i dużych zespołach.

2. Po drugie, nie działają dobrze z niestandardowymi kontrolerami kontenerów, które osadzają inne kontrolery kontenerów itp. Używamy MFSlideMenu w aplikacji Tabbed, a scena ma tabelę. Jest to prawie niemożliwe w przypadku scenorysu. Spędziłem dni, uciekłem się do XIB, gdzie jest pełna kontrola.

3. IDE nie pozwala wybierać elementów sterujących w stanie pomniejszonym. Tak więc w dużym projekcie pomniejszenie służy głównie do uzyskania widoku na wysokim poziomie i nic więcej.

Używałbym scenariuszy do mniejszych aplikacji o małych rozmiarach zespołów i stosuję podejście XIB do średnich / dużych zespołów / projektów.

Jeśli chcesz ponownie użyć interfejsu użytkownika w wielu kontrolerach widoku, powinieneś użyć XIB