스토리 보드 사용시기 및 XIB 사용시기

iOS 프로젝트에서 스토리 보드를 사용하는시기와 XIB를 사용하는시기에 대한 지침이 있습니까? 각각의 장단점은 무엇이며 각각의 상황은 무엇입니까?

내가 말할 수 있듯이 동적 UI 요소 (맵 핀과 같은)에 의해 뷰 컨트롤러를 푸시 할 때 스토리 보드 segue를 사용하는 것이 깨끗하지 않다는 것을 알 수 있습니다.

XIB를 광범위하게 사용했으며 스토리 보드를 사용하여 두 개의 프로젝트를 완료했습니다. 내 학습은 다음과 같습니다

• 스토리 보드는 화면 수가 적거나 중간 정도이고보기 간 비교적 간단한 탐색 기능이있는 앱에 적합합니다.
• 그 사이에 많은 뷰와 교차 탐색이있는 경우 스토리 보드 뷰는 혼란스럽고 너무 많은 작업을 수행하여 깨끗하게 유지할 수 없습니다.
• 여러 개발자가있는 대규모 프로젝트의 경우 UI 용 단일 파일이 있고 쉽게 병렬로 작업 할 수 없으므로 스토리 보드를 사용하지 않습니다.
• 큰 앱이 여러 스토리 보드 파일로 분할되는 것이 가치가 있지만 시도하지는 않았습니다. 이 답변 은 스토리 보드간에 segue를 수행하는 방법을 보여줍니다.
• 여전히 XIB가 필요합니다. 두 스토리 보드 프로젝트 모두에서 사용자 정의 테이블 셀에 XIB를 사용해야했습니다.

스토리 보드는 UI 구현에 올바른 방향으로 나아가는 단계라고 생각하며 Apple이 향후 iOS 버전으로 확장 할 수 있기를 바랍니다. 그러나 "단일 파일"문제를 해결해야합니다. 그렇지 않으면 대규모 프로젝트에는 적합하지 않습니다.

작은 크기의 앱을 시작하고 iOS5 전용 호환성을 제공 할 수 있다면 스토리 보드를 사용합니다. 다른 모든 경우에는 XIB를 고수합니다.

2016 년 1 월 2 일 업데이트 : 2016 년이며 스토리 보드가 아닌 코드로 UI를 배치하는 것을 선호합니다. 그러나 스토리 보드는 먼 길을 왔습니다. 이 게시물에서 2016 년에 더 이상 적용되지 않는 모든 포인트를 제거했습니다.

2015 년 4 월 24 일 업데이트 : 흥미롭게도 Peter Steinberger ( "인터페이스 빌더"라는 제목 아래)에서 알 수 있듯이 Apple은 최근 오픈 소스 ResearchKit에서 스토리 보드를 사용하지 않습니다 .

2014 년 6 월 10 일 업데이트 : Apple은 예상대로 스토리 보드 및 Xcode를 지속적으로 개선하고 있습니다. iOS 7 이하에 적용된 일부 포인트는 더 이상 iOS 8에는 적용되지 않으며 이제는 그렇게 표시됩니다. 따라서 스토리 보드에는 여전히 결함이 있지만, 조언을 사용하지 않는 곳 에서 선택적으로 사용하는 것이 좋습니다 .

이제 iOS 9가 출시되었으므로 조언 할 것입니다. 에 맞서스토리 보드 사용 여부를 결정할 때주의해야합니다. 내 이유는 다음과 같습니다.

• 스토리 보드는 컴파일 타임이 아닌 런타임에 실패 합니다. segue 이름에 오타가 있거나 스토리 보드에 잘못 연결되어 있습니까? 런타임에 폭파됩니다. 스토리 보드에 더 이상 존재하지 않는 사용자 정의 UIViewController 서브 클래스를 사용하십니까? 런타임에 폭파됩니다. 코드에서 이러한 작업을 수행하면 컴파일 타임에 조기에 잡을 수 있습니다. 업데이트 : 내 새 도구 StoryboardLint가 대부분이 문제를 해결합니다.

• 스토리 보드가 빠르게 혼동됩니다 . 프로젝트가 성장함에 따라 스토리 보드를 탐색하기가 점점 더 어려워집니다. 또한 여러 개의 뷰 컨트롤러에 여러 개의 다른 뷰 컨트롤러에 대한 여러 개의 segue가있는 경우 스토리 보드가 빠르게 스파게티 한 그릇처럼 보이기 시작하고, 확대 / 축소 및 스크롤하여 원하는 뷰 컨트롤러를 찾을 수 있습니다. segue가 어디를 가리키는 지 알아 내야합니다. 업데이트 :이 문제는 Pilky 의이 기사 와 Robert Brown의이 기사에 설명 된대로 스토리 보드를 여러 스토리 보드로 분할하여 해결할 수 있습니다 .

• 스토리 보드는 팀 작업을 어렵게 만듭니다 . 일반적으로 프로젝트에는 하나의 거대한 스토리 보드 파일 만 있기 때문에 여러 개발자가 해당 파일을 정기적으로 변경하면 두통이 될 수 있습니다. 변경 사항을 병합하고 충돌을 해결해야합니다. 충돌이 발생하면이를 해결하는 방법을 말하기가 어렵습니다. Xcode는 스토리 보드 XML 파일을 생성하며 실제로 편집하지 않고 사람이 읽어야한다는 목표를 염두에두고 설계되지 않았습니다.

• 스토리 보드는 코드 검토를 어렵게하거나 거의 불가능하게 만듭니다 . 동료 코드 검토는 팀에서해야 할 큰 일입니다. 그러나 스토리 보드를 변경하면 다른 개발자와 이러한 변경 사항을 검토하는 것이 거의 불가능합니다. 풀 수있는 것은 거대한 XML 파일이다. 실제로 변경된 내용을 해독하고 해당 변경 사항이 올바른지 또는 변경 사항을 파기했는지 여부는 매우 어렵습니다.

• 스토리 보드는 코드 재사용을 방해합니다 : iOS 프로젝트에서 일반적으로 앱 전체에서 일관된 모양과 느낌을주기 위해 사용하는 모든 색상과 글꼴 및 여백 및 삽입물이 포함 된 클래스를 만듭니다. 전체 앱에 대해 해당 값을 조정하십시오. 스토리 보드에서 이러한 값을 설정하면 해당 값을 복제하므로 값을 변경할 때마다 발생하는 모든 항목을 찾아야합니다. 스토리 보드에는 검색 및 교체가 없기 때문에 놓칠 가능성이 높습니다.

• 스토리 보드에는 지속적인 컨텍스트 전환이 필요합니다 . 스토리 보드보다 코드에서 작업하고 탐색하는 것이 훨씬 빠릅니다. 앱에서 스토리 보드를 사용하는 경우 컨텍스트를 지속적으로 전환해야합니다. "오,이 테이블 뷰 셀을 탭하여 다른 뷰 컨트롤러를로드하고 싶습니다. 이제 스토리 보드를 열고 올바른 뷰 컨트롤러를 찾고 새로운 segue를 만들어야합니다. 다른 뷰 컨트롤러 (내가 찾은 것)에 segue의 이름을 지정하고 그 이름을 기억하고 (스토리 보드에서 상수 또는 변수를 사용할 수 없음) 코드로 다시 전환하고 이름을 잘못 입력하지 않기를 바랍니다. "제 3 단계 코드를 여기에 입력하면 좋겠다!" 아니, 재미 없어 코드와 스토리 보드 간 (및 키보드와 마우스 간) 전환이 오래되고 속도가 느려집니다.

• 스토리 보드는 리팩토링하기 어렵습니다 . 코드를 리팩터링 할 때 스토리 보드가 기대하는 것과 여전히 일치하는지 확인해야합니다. 스토리 보드에서 물건을 움직일 때 여전히 코드와 함께 작동하는 경우에만 런타임에 알 수 있습니다. 마치 두 세계를 동기화시켜야하는 것처럼 느껴집니다. 나는 겸손한 의견으로 부서지기를 느끼고 변화를 좌절시킵니다.

• 스토리 보드는 유연성이 떨어집니다 . 코드에서 기본적으로 원하는 모든 것을 할 수 있습니다! 스토리 보드를 사용하면 코드에서 수행 할 수있는 작업의 하위 집합으로 제한됩니다. 특히 애니메이션과 전환으로 일부 고급 작업을 수행하려는 경우 "스토리 보드와 싸우기"를 통해 작업을 수행 할 수 있습니다.

• 스토리 보드는 특수 뷰 컨트롤러의 유형을 변경하지 않는 : 당신은 변경할 UITableViewController에 UICollectionViewController? 아니면 평원으로 UIViewController? 스토리 보드에서는 불가능합니다. 이전 뷰 컨트롤러를 삭제하고 새 컨트롤러를 생성하고 모든 segue를 다시 연결해야합니다. 코드를 변경하는 것이 훨씬 쉽습니다.

• 스토리 보드는 프로젝트에 두 가지 추가 책임을 추가합니다 . (1) 스토리 보드 XML을 생성하는 스토리 보드 편집기 도구 및 (2) XML을 구문 분석하고 UI 및 컨트롤러 개체를 생성하는 런타임 구성 요소. 두 부분 모두 수정할 수없는 버그가있을 수 있습니다.

• 스토리 보드에서는 서브 뷰를 다음에 추가 할 수 없습니다UIImageView . 이유를 아는 사람.

• 스토리 보드에서는 개별보기 (- 컨트롤러)에 대해 자동 레이아웃을 사용할 수 없습니다. 스토리 보드에서 자동 레이아웃 옵션을 선택 / 선택 취소하면 스토리 보드의 모든 컨트롤러에 변경 사항이 적용됩니다. (이 시점에서 Sava Mazăre에게 감사합니다!)

• 스토리 보드는 이전 버전과의 호환성을 깨뜨릴 위험이 더 높습니다 . Xcode는 때때로 스토리 보드 파일 형식을 변경하고 현재 몇 년 또는 몇 달 후에 생성 한 스토리 보드 파일을 열 수 있다고 보장하지 않습니다. (이 시점에서 발전해 왔습니다. 원래 의견보기 )

• 스토리 보드를 사용 하면 코드를 더 복잡하게 만들 수 있습니다. 코드 에서 뷰 컨트롤러를 만들 때와 같이 사용자 지정 init메서드를 만들 수 있습니다 initWithCustomer:. 이렇게하면 customer뷰 컨트롤러 내부를 변경할 수 없으며 customer객체 없이이 뷰 컨트롤러를 만들 수 없도록 할 수 있습니다 . 스토리 보드를 사용할 때는 불가능합니다. prepareForSegue:sender:메서드가 호출 될 때까지 기다려야하고 customer뷰 컨트롤러 에서 속성 을 설정해야 합니다. 즉,이 속성을 변경 가능하게해야하고 customer개체 없이 뷰 컨트롤러를 만들 수 있어야 합니다. . 내 경험상 이것은 코드를 크게 복잡하게 만들고 앱 흐름에 대해 추론하기 어렵게 만듭니다. 9/9/16 업데이트: Chris Dzombak는 이 문제에 대한 훌륭한 기사를 썼습니다 .

• McDonald 's : Microsoft에 대한 Steve Jobs의 말로 말하면 McDonald (비디오)입니다 .

이것이 내가 스토리 보드 작업을 정말로 좋아하지 않는 이유입니다. 이러한 이유 중 일부는 XIB에도 적용됩니다. 내가 작업했던 스토리 보드 기반 프로젝트에서, 그들은 저축 한 것보다 훨씬 많은 시간을 소비했으며 일을 더 쉽게하는 대신 더 복잡하게 만들었습니다.

코드에서 UI 및 응용 프로그램 흐름을 만들면 진행 상황을 훨씬 더 많이 제어하고 디버깅하기 쉽고 실수를 쉽게 발견 할 수 있으며 변경 사항을 다른 개발자에게 설명하는 것이 더 쉽습니다. iPhone 및 iPad를 지원하기가 더 쉽습니다.

그러나 모든 UI 를 코드로 배치하는 것이 모든 프로젝트에 맞는 단일 솔루션은 아닐 수도 있습니다. 특정 장소에서 iPad UI가 iPhone UI와 크게 다른 경우 해당 영역에 대한 XIB를 만드는 것이 좋습니다.

위에서 설명한 많은 문제가 Apple에 의해 해결 될 수 있으며 이것이 그들이 할 수 있기를 바랍니다.

내 두 센트.

업데이트 : Xcode 5에서 Apple은 스토리 보드없이 프로젝트를 만들 수있는 옵션을 제거했습니다. Xcode 4의 템플릿 (Storyboard-opt-out 옵션 포함)을 Xcode 5로 이식하는 작은 스크립트를 작성했습니다. https://github.com/jfahrenkrug/Xcode4templates

스토리 보드는 개발자가 응용 프로그램과 응용 프로그램의 흐름을 시각화 할 수 있도록 만들어졌습니다. 그것은 많은 xib를 가지고 있지만 하나의 파일에있는 것처럼 많이 있습니다.

이 위치와 비슷한 질문이 있습니다 . .xib 파일과 .storyboard의 차이점은 무엇입니까? .

.xibs와 마찬가지로 필요한 경우 동적으로 변경되는 코드를 통해 사용자 지정 전환을 만들 수도 있습니다.

장점 :

• 코드를 많이 쓰지 않고도 응용 프로그램의 흐름을 조롱 할 수 있습니다.
• 화면과 응용 프로그램 흐름 간의 전환을 훨씬 쉽게 볼 수 있습니다.
• 스토리 보드와 함께 필요한 경우 .xibs를 사용할 수도 있습니다.

단점 :

• iOS 5 이상에서만 작동합니다. iOS4에서는 작동하지 않습니다.
• 보기 집약적 인 응용 프로그램을 사용하면 쉽게 어수선해질 수 있습니다.

하나 또는 다른 것을 사용할 때 실제로 옳고 그른 것은 아닙니다. 환경 설정과 사용하려는 iOS 버전의 문제 일뿐입니다.

스토리 보드 를 사용해야 하는 4 가지 간단한 이유 , 특히 제품 소유자, 제품 관리자, UX 디자이너 등의 팀에서 작업해야하는 생산적인 환경에서 설명 하겠습니다 .

1. 애플은 스토리 보드 작업을 대폭 개선했습니다. 그리고 그들은 당신이 그들과 함께 일하도록 격려합니다. 즉, 기존 프로젝트를 업데이트 해도 중단 되지 않으므로 스토리 보드가 최신 XCode / iOS 버전에 대한 향후 증거가 될 것입니다.
2. 생성 단계에서도 제품 소유자와 관리자가 더 눈에 잘 띄는 결과 를 얻습니다 . 스토리 보드 자체를 화면 흐름도로 사용하여 회의에서 토론 할 수도 있습니다.
3. 심지어 응용 프로그램이 완료된 후 (및 라이프 사이클이 시작되는 곳이 일반적이다) - 미래가 될 것입니다 빠르고 쉽게 작은 조정을 적용합니다 . 그리고 이것들은 레이아웃의 여러 측면을 동시에 매우 잘 바꿀 수 있습니다. 아마도 WYSIWYG 방식으로보고 싶을 것입니다. 대안은 코드에서 UI 변경 사항을 직접 작성하고 IDE와 시뮬레이터 사이를 전환하여 테스트 및 컴파일을 기다릴 때마다 테스트 및 테스트를 전환하는 것입니다.
4. 비 개발자에게는 스토리 보드에서 레이아웃을 설정하고 개발자 (IBOutlets 및 IBActions)에 필요한 후크를 만드는 방법을 배울 수 있습니다 . 이는 개발자가 논리에 집중할 수있게하고 UX 디자이너는 코드를 전혀 작성하지 않고도 변경 사항을 시각적으로 적용 할 수 있기 때문에 매우 큰 장점입니다.

Johannes가 이미 그의 대답에 가능한 모든 것을 나열했기 때문에 CONS를 작성하지 않을 것입니다. 그리고 대부분 XCode6의 주요 개선 사항으로는 불가능합니다.

나는 당신의 질문에 대한 정답이 없다고 생각합니다. 그것은 단지 개인적인 경험과 당신이 더 편한 느낌의 문제입니다.

제 생각에는 스토리 보드는 대단합니다. 사실, 왜 앱이 런타임에 끔찍하게 충돌하는지 알아내는 것은 정말 어렵지만 시간과 경험이 있더라도 항상 어딘가에 누락 된 일부 IBOutlet과 관련이 있으며 쉽게 해결할 수 있습니다.

유일한 진짜 문제는 스토리 보드를 사용하여 버전 관리하에 팀에서 일하는 것입니다. 개발 초기 단계에서는 문제가 될 수 있습니다. 그러나 첫 번째 단계 후에 스토리 보드를 완전히 변경하는 UI 업데이트는 매우 드물며 대부분 스토리 보드를 다시 열 때 자동으로 수정되는 segue 참조 인 xml의 마지막 부분에서 충돌이 발생합니다. . 우리 팀 작업에서 우리는 많은 뷰 코드를 가진 무거운 뷰 컨트롤러 대신이 문제를 처리하는 것을 선호했습니다.

많은 의견을 자동으로 읽었습니다. XCode5를 사용하면 실제로 향상되었으며 레이아웃을 자동 회전하는 경우에도 좋습니다. 어떤 경우에는 코드에서 무언가를 수행해야하지만, 편집해야하는 제약 조건을 간단히 종료하고 그 시점에서 코드에서 필요한 것을 수행 할 수 있습니다. 심지어 그들을 애니메이션.

또한 스토리 보드를 싫어하는 대부분의 사람들은 사용자 정의 매뉴얼 세그의 힘을 완전히 이해하려고 시도하지 않았다고 생각합니다. 여기서 한 파일에서 다른 방식으로 전환하는 방식을 완전히 사용자 정의 할 수 있습니다. 일부 트릭)은 전체를 완전히 다시로드하는 대신보기 내용을 업데이트하여 이전에로드 된보기 컨트롤러를 재사용합니다. 결국 코드에서와 똑같은 일을 할 수는 있지만 스토리 보드와 관련된 문제를 더 잘 분리한다고 생각하지만 많은면에서 기능 (글꼴, 색상 배경 ​​이미지, 이미지 등)이 부족하다는 데 동의합니다. ).

내 응용 프로그램에서 StoryBoard 또는 XIB를 사용하지 않고 프로그래밍 방식으로 모든 것을 만듭니다.

∆ 장점 :

√ 복잡한 UI 또는 전환 애니메이션을 만들 수 있습니다. UIView .

√ 모든 iOS 버전을 지원하십시오. <iOS 5에 대해 걱정할 필요가 없습니다.

√ * 앱은 코드 내의 모든 iPhone / iPod / iPad 장치를 지원합니다.

√ 항상 작동하는 코드를 알고 있으면 항상 업데이트됩니다.

√ * 시작된 (새로운) 장치에서 작동합니다 – 코드를 변경할 필요가 없습니다.

√ 모든 것이 당신에게 달려 있습니다. 어떤 곳에서는 무언가를 바꾸고 싶어합니다 – 스토리 보드 나 xib를 볼 필요가 없습니다. 특정 클래스에서 검색하십시오.

√ 마지막이지만 목록은 아님 – 모든 것을 프로그래밍 방식으로 관리하는 방법을 잊지 마십시오. 컨트롤을 누구보다 깊게 알고 있으므로 이것이 가장 좋습니다.

_{SB 또는 XIB를 사용하지 않아서 문제를 찾지 못했습니다.}

_{* 화면 크기에 따라 UIKit의 객체 프레임을 설정 한 경우.}

_{추신. 만약 당신이 여전히이 일을하지 않았다면 – 당신은 어려움에 직면 할 수 있습니다 (또는 지루함을 느낄 수 있습니다). 그러나 일단 당신이 이것에 익숙해지면 – 그것은 당신을위한 사탕입니다.}

스토리 보드 성능에 관심이 있다면 WWDC 2015 Session 407을보십시오.

건설 시간

인터페이스 빌더가 스토리 보드를 컴파일 할 때 먼저 두 가지 작업을 수행하며, 응용 프로그램의 성능을 최대화하려고 시도하며, 두 번째로 생성 된 펜촉 파일의 수를 최소화합니다.

뷰와 많은 하위 뷰, 인터페이스 빌더가있는 뷰 컨트롤러가있는 경우 빌드 시간은 뷰 컨트롤러의 펜촉 파일을 만들고 뷰의 펜촉 파일을 만듭니다.

뷰 컨트롤러와 뷰 모두에 대해 별도의 nib 파일이 있으므로 필요에 따라 뷰 계층 구조를로드 할 수 있습니다.

런타임

UI 스토리 보드 API를 사용하여 스토리 보드 인스턴스를 할당 할 때 처음에는 메모리를 할당하는 모든 것이 UI 스토리 보드 인스턴스 자체입니다.

뷰 컨트롤러가 아직 없습니다.

초기 뷰 컨트롤러를 인스턴스화하면 해당 초기 뷰 컨트롤러에 대한 펜촉이로드되지만 다시 누군가가 실제로 요청할 때까지 뷰 계층 구조가로드되지 않았습니다.

나는 합리적인 크기의 프로젝트 (스토리 보드 용어에서 20 장면 이상)를 작업하고 있으며 많은 한계를 극복했으며 문서 작업과 Google 검색을 반복하여 수행해야합니다.

1. UI는 모두 하나의 파일에 있습니다. 스토리 보드를 여러 개 만들더라도 각 스토리 보드에는 여전히 많은 장면 / 화면이 있습니다. 이것은 중규모 팀의 문제입니다.

2. 둘째, 다른 컨테이너 컨트롤러 등을 포함하는 사용자 지정 컨테이너 컨트롤러와 잘 작동하지 않습니다. 우리는 탭 응용 프로그램에서 MFSlideMenu를 사용하고 있으며 장면에는 테이블이 있습니다. 스토리 보드와는 거의 불가능합니다. 며칠을 보낸 후, 나는 완전한 통제가 가능한 XIB 방식을 사용했습니다.

3. IDE에서는 축소 상태의 컨트롤을 선택할 수 없습니다. 따라서 대규모 프로젝트에서 축소는 주로 높은 수준의 시야를 확보하는 것입니다.

팀 규모가 작은 소규모 응용 프로그램에는 스토리 보드를 사용하고 중간 규모의 팀 / 프로젝트에는 XIB 접근 방식을 사용합니다.

다중 뷰 컨트롤러에서 일부 UI를 재사용하려면 XIB를 사용해야합니다