iOS 사용자 인터페이스: 스토리보드 vs. NIB vs. 커스텀 코드

나는 종종 iOS 개발자가 동일한 핵심 질문의 몇 가지 변형을 묻는 것을 듣습니다.

스토리보드, NIB 또는 코드를 통해 iOS에서 UI를 개발하는 가장 좋은 방법은 무엇입니까?

이 질문에 대한 대답은 명시적이든 암시적이든 상호 배타적인 선택이 있다고 가정하는 경향이 있습니다.

나는 대답이 하나 이상의 반대 질문의 형태를 취해야 한다고 생각합니다.

"최고의"차는 무엇입니까?

주제에서 벗어난 예를 들어 설명하겠습니다. 내가 차를 사고 싶다고 가정하고 한 가지 간단한 질문을 합니다. "가장 좋은 선택은 무엇인가요?"

모델이나 브랜드를 제안하여 정말로 대답할 수 있습니까? 페라리를 제안하지 않는 한 그럴 가능성은 없습니다. 대신 다음과 같은 몇 가지 다른 질문으로 대답할 수 있습니다.

• 당신의 예산은 얼마입니까?
• 얼마나 많은 좌석이 필요합니까?
• 당신은 연료 소비에 관심이 있습니까?
• 스포츠카에 대해 어떻게 생각하십니까?

적절한 상황에 배치되지 않는 한 좋은 자동차나 나쁜 자동차는 없다는 것이 분명합니다. 특정 요구 사항에 따라 좋은 자동차와 나쁜 자동차가 있을 뿐입니다.

iOS UI 디자인으로 돌아가기

자동차 문의와 마찬가지로 "iOS UI를 개발하는 가장 좋은 방법은 무엇입니까?"라는 질문에는 컨텍스트가 없습니다. 그리고 놀랍게도 그 대답이 모든 경우를 포괄할 필요는 없습니다.

일반적으로 사용자 인터페이스 디자인 접근 방식에는 세 가지 유형이 있으며 각각 장단점, 팬과 싫어하는 사람이 있습니다.

• iOS 스토리보드 : 여러 애플리케이션 보기와 그 사이의 전환을 배치하기 위한 시각적 도구입니다.
• NIB (또는 XIB) : 각 NIB 파일은 단일 보기 요소에 해당하며 Interface Builder에 배치하여 시각적 도구로도 사용할 수 있습니다. "NIB"라는 이름은 파일 확장자(이전의 발음은 그대로 유지되지만 이전에는 .nib에서 지금은 .xib)에서 파생되었습니다.
• 사용자 정의 코드 : 즉, GUI 도구가 아니라 모든 사용자 정의 위치, 애니메이션 등을 프로그래밍 방식으로 처리합니다.

이러한 옵션 중 어느 것도 다른 것보다 보편적으로 더 낫지 않습니다(귀하가 들을 수 있음에도 불구하고).

예를 들어 스토리보드는 iOS UI 툴킷에 가장 최근에 추가된 것입니다. 나는 그들이 NIB와 사용자 정의 코드 UI를 대체할 미래라고 들었습니다. 저는 Storyboard를 유용한 도구로 생각하지만 NIB 및 사용자 정의 코드를 보완 하기 위한 대체품 은 아닙니다. 일부 상황에서는 스토리보드가 올바른 선택이지만 모든 상황은 아닙니다.

더 나아가, 당면한 특정 문제에 가장 적합한 메커니즘을 선택하여 모두 사용할 수 있는데(동일한 프로젝트에서) 단일 옵션을 정적으로 고수해야 하는 이유는 무엇입니까?

이것은 내 생각에 더 높은 수준에서 일반화될 수 있는 질문이며, 그 대답은 내 소프트웨어 개발 원칙 목록에서 높은 순위에 있습니다. 모든 사람 에게 보편적인 최선의 선택인 보편적 언어, 프레임워크 또는 기술은 없습니다 . 소프트웨어 개발 문제. iOS UI 디자인도 마찬가지입니다.

이 iOS 개발 튜토리얼에서는 이러한 각 방법을 탐색하고 사용 사례와 사용 하지 말아야 할 사용 사례 및 함께 혼합할 수 있는 방법을 소개합니다.

iOS 스토리보드

전형적인 초보자의 실수는 하나의 방대한 프로젝트 전체 iOS 스토리보드를 만드는 것입니다. 저도 처음 스토리보드 작업을 시작할 때 이 실수를 저질렀습니다.

이름에서 알 수 있듯이 스토리보드는 이야기가 있는 보드입니다 . 관련 없는 이야기를 하나의 큰 볼륨으로 혼합하는 데 사용해서는 안 됩니다. 스토리보드에는 서로 논리적으로 관련된 뷰 컨트롤러가 포함되어야 합니다. 이것이 모든 뷰 컨트롤러를 의미하는 것은 아닙니다.

예를 들어 다음을 처리할 때 스토리보드를 사용하는 것이 좋습니다.

• 인증 및 등록을 위한 일련의 보기입니다.
• 다단계 주문 입력 흐름.
• 마법사와 같은(즉, 자습서) 흐름입니다.
• 보기의 마스터-세부 정보 세트(예: 프로필 목록, 프로필 세부 정보).

한편, 단일 앱 전체 스토리보드를 포함하여 큰 스토리보드는 피해야 합니다(앱이 비교적 단순하지 않은 경우). 더 깊이 들어가기 전에 그 이유를 살펴보겠습니다.

대형 iOS 스토리보드의 어리석음

대형 스토리보드는 탐색 및 유지 관리가 어렵다는 점 외에 팀 환경에 복잡성을 추가합니다. 여러 개발자가 동일한 스토리보드 파일에서 동시에 작업하는 경우 소스 제어 충돌이 불가피 합니다. 스토리보드는 내부적으로 텍스트 파일(실제로는 XML 파일)로 표현되지만 병합은 일반적으로 간단하지 않습니다.

개발자는 소스 코드를 볼 때 의미론적 의미를 부여합니다. 따라서 수동으로 병합할 때 충돌의 양쪽 측면을 읽고 이해하고 그에 따라 행동할 수 있습니다. 대신 스토리보드는 Xcode에서 관리하는 XML 파일이며, 각 코드 라인의 의미가 항상 이해하기 쉬운 것은 아닙니다.

매우 간단한 예를 들어보겠습니다. 두 명의 다른 개발자가 UILabel 의 위치를 ​​변경하고(autolayout 사용) 후자는 변경 사항을 푸시하여 다음과 같은 충돌을 생성한다고 가정합니다(충돌하는 id 속성 참고).

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

id 자체는 그 진정한 의미에 대한 어떠한 표시도 제공하지 않으므로 작업할 필요가 없습니다. 의미 있는 유일한 해결책은 갈등의 양면 중 하나를 선택하고 다른 하나는 버리는 것입니다. 부작용이 생길까요? 누가 알아? 너 말고.

이러한 iOS 인터페이스 디자인 문제를 완화하려면 동일한 프로젝트에서 여러 스토리보드를 사용하는 것이 좋습니다.

스토리보드를 사용하는 경우

스토리보드는 상호 연결된 여러 뷰 컨트롤러와 함께 사용하는 것이 가장 좋습니다. 주요 단순화는 뷰 컨트롤러 간 전환에 있기 때문입니다. 어느 정도까지는 뷰 컨트롤러 사이에 시각적 및 기능적 흐름이 있는 NIB의 구성으로 생각할 수 있습니다.

탐색 흐름을 용이하게 하는 것 외에도 또 다른 뚜렷한 이점은 보기 컨트롤러를 팝, 푸시, 표시 및 해제하는 데 필요한 상용구 코드를 제거한다는 것입니다. 또한 뷰 컨트롤러는 자동으로 할당되므로 수동으로 alloc 및 init 할 필요가 없습니다.

마지막으로, 스토리보드는 여러 뷰 컨트롤러와 관련된 시나리오에 가장 잘 사용되지만 다음 세 가지 이유로 단일 테이블 뷰 컨트롤러로 작업할 때 스토리보드를 사용하는 것도 방어할 수 있습니다.

• 테이블 셀 프로토타입을 제자리에 디자인하는 기능은 조각을 함께 유지하는 데 도움이 됩니다.
• 부모 테이블 뷰 컨트롤러 내에서 여러 셀 템플릿을 디자인할 수 있습니다.
• 정적 테이블 보기를 생성할 수 있습니다(불행하게도 Storyboard에서만 사용할 수 있는 오랫동안 기다려온 추가 기능).

NIB를 사용하여 여러 셀 템플릿을 설계할 수도 있다고 주장할 수 있습니다. 사실, 이것은 단지 선호도의 문제입니다. 일부 개발자는 모든 것을 한 곳에 두는 것을 선호하지만 다른 개발자는 신경 쓰지 않습니다.

iOS 스토리보드를 사용 하지 말아야 할 때

몇 가지 경우:

• 보기에는 코드로 가장 잘 구현된 복잡하거나 동적인 레이아웃이 있습니다.
• 보기는 이미 NIB 또는 코드로 구현되어 있습니다.

이러한 경우 스토리보드에서 보기를 그대로 두거나 보기 컨트롤러에 포함할 수 있습니다. 전자는 Storyboard의 시각적 흐름을 깨뜨리지만 부정적인 기능이나 개발 영향은 없습니다. 후자는 이 시각적 흐름을 유지하지만 뷰가 뷰 컨트롤러에 통합되지 않기 때문에 추가 개발 노력이 필요합니다. 구성 요소로 내장되어 있으므로 뷰 컨트롤러는 뷰를 구현하는 대신 뷰와 상호 작용해야 합니다.

일반적인 장단점

이제 스토리보드가 iOS UI 디자인에서 유용할 때를 알게 되었고 이 튜토리얼에서 NIB로 넘어가기 전에 일반적인 장점과 단점을 살펴보겠습니다.

장점: 성능

직관적으로 스토리보드가 로드되면 모든 뷰 컨트롤러가 즉시 인스턴스화된다고 가정할 수 있습니다. 다행스럽게도 이것은 추상화일 뿐 실제 구현에는 해당 되지 않습니다 . 대신 초기 뷰 컨트롤러(있는 경우)만 생성됩니다. 다른 뷰 컨트롤러는 segue가 수행되거나 코드에서 수동으로 수행될 때 동적으로 인스턴스화됩니다.

장점: 프로토타입

스토리보드는 사용자 인터페이스 및 흐름의 프로토타이핑 및 목업을 단순화합니다. 실제로 보기와 ​​탐색 기능이 있는 완전한 프로토타입 애플리케이션은 스토리보드와 몇 줄의 코드를 사용하여 쉽게 구현할 수 있습니다.

단점: 재사용성

이동 또는 복사와 관련하여 iOS 스토리보드의 위치가 좋지 않습니다. 스토리보드는 종속된 모든 뷰 컨트롤러와 함께 이동해야 합니다. 즉, 단일 뷰 컨트롤러는 개별적으로 추출되어 단일 독립 엔터티로 다른 곳에서 재사용될 수 없습니다. 작동하려면 스토리보드의 나머지 부분에 따라 다릅니다.

단점: 데이터 흐름

앱이 전환될 때 뷰 컨트롤러 간에 데이터를 전달해야 하는 경우가 많습니다. 그러나 이 경우에는 Interface Builder에서 이러한 일이 발생했다는 흔적이 없기 때문에 Storyboard의 시각적 흐름이 깨집니다. 스토리보드는 뷰 컨트롤러 간의 흐름을 처리하지만 데이터의 흐름은 처리하지 않습니다. 따라서 대상 컨트롤러는 시각적 경험을 재정의하는 코드로 구성되어야 합니다.

이러한 경우 다음과 같은 if/else-if 골격이 있는 prepareForSegue:sender 에 의존해야 합니다.

 - (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 ... }

이 접근 방식은 오류가 발생하기 쉽고 불필요하게 장황합니다.

높으신 양반

NIB는 iOS 인터페이스 디자인을 수행하는 오래된(어) 방법입니다.

이 경우 "오래된"은 "나쁜", "오래된" 또는 "사용되지 않는"을 의미하지 않습니다. 사실 iOS 스토리보드가 NIB의 보편적인 대체품이 아니라는 점을 이해하는 것이 중요합니다. 어떤 경우에는 UI 구현을 단순화합니다.

NIB를 사용하면 임의의 뷰를 설계할 수 있으며 개발자는 이를 필요에 따라 뷰 컨트롤러에 연결할 수 있습니다.

우리가 UI에 객체 지향 디자인을 적용한다면, 뷰 컨트롤러의 뷰를 별도의 모듈 로 나누는 것이 합리적입니다. 이 접근 방식의 분명한 이점은 각 구성 요소가 개발하기 쉽고 테스트하기 쉽고 디버그하기 쉽다는 것입니다.

NIB는 Storyboard에서 본 병합 충돌 문제를 공유하지만 NIB 파일이 더 작은 규모로 작동하기 때문에 그 정도는 적습니다.

iOS UI 디자인에 NIB를 사용하는 경우

모든 사용 사례의 하위 집합은 다음과 같습니다.

• 모달 뷰
• 간단한 로그인 및 등록 보기
• 설정
• 팝업 창
• 재사용 가능한 보기 템플릿
• 재사용 가능한 표 셀 템플릿

한편…

NIB를 사용 하지 않는 경우

다음과 같은 경우 NIB 사용을 피해야 합니다.

• 콘텐츠에 따라 레이아웃이 크게 변경되는 동적 콘텐츠가 포함된 보기입니다.
• 본질적으로 Interface Builder에서 쉽게 설계할 수 없는 보기입니다.
• 스토리보드로 단순화할 수 있는 복잡한 전환이 있는 보기 컨트롤러.

일반적인 장단점

보다 일반적으로 NIB 사용의 장단점을 살펴보겠습니다.

장점: 재사용성

NIB는 동일한 레이아웃이 여러 클래스에서 공유될 때 유용합니다.

간단한 사용 사례로, 사용자 이름과 암호 텍스트 필드가 포함된 보기 템플릿은 가상의 TTLoginView 및 TTSignupView 보기로 구현될 수 있으며, 둘 다 동일한 NIB에서 시작될 수 있습니다. TTLoginView 는 암호 필드를 숨겨야 하고 둘 다 해당하는 정적 레이블(예: '사용자 이름 입력' 대 '암호 입력')을 지정해야 하지만 레이블은 동일한 기본 기능과 유사한 레이아웃을 갖습니다.

장단점: 성능

NIB는 느리게 로드되므로 필요할 때까지 메모리를 사용하지 않습니다. 이것이 장점이 될 수 있지만 지연 로딩 프로세스에 지연이 있어 단점이기도 합니다.

iOS 사용자 정의 코드(프로그래매틱 UI)

스토리보드 및 NIB로 수행할 수 있는 모든 iOS 인터페이스 디자인은 원시 코드로도 구현할 수 있습니다.

아마도 더 중요한 것은 NIB와 스토리보드로 할 수 없는 일을 항상 코드로 구현할 수 있다는 점입니다. 물론 기술적으로 실현 가능하다면 말입니다. 그것을 보는 또 다른 방법은 NIB와 스토리보드가 코드로 구현되어 그들의 기능이 자연스럽게 하위 집합이 될 것이라는 점입니다. 장점과 단점으로 바로 넘어가겠습니다.

장점: 후드 아래

프로그래밍 방식으로 iOS UI를 생성할 때의 가장 큰 이점은 사용자 인터페이스를 코딩하는 방법을 알고 있으면 내부에서 어떤 일이 발생하는지 알 수 있지만 NIB 및 스토리보드의 경우 반드시 그렇지는 않다는 것입니다.

비교를 위해: 계산기는 유용한 도구입니다. 그러나 수동으로 계산을 수행하는 방법을 아는 것은 나쁜 것이 아닙니다.

이것은 iOS에 국한되지 않고 모든 시각적 RAD 도구(예: Visual Studio 및 Delphi)에 적용됩니다. Visual HTML RAD 환경은 전형적인 경계선의 경우를 나타냅니다. HTML 지식이 필요하지 않으며 모든 것이 시각적으로 수행될 수 있다고 주장하면서 (종종 제대로 작성되지 않은) 코드를 생성하는 데 사용됩니다. 그러나 어떤 웹 개발자도 손을 더럽히지 않고 웹 페이지를 구현하지 않을 것입니다. 그들은 원시 HTML과 CSS를 수동으로 처리하는 것이 더 모듈화되고 더 효율적인 코드로 이어질 것이라는 것을 알고 있습니다.

따라서 iOS 사용자 인터페이스의 코딩을 마스터하면 이러한 부분이 어떻게 서로 맞물리는지 더 잘 제어하고 더 잘 인식할 수 있으므로 개발자의 상한선이 높아집니다.

장점: 코드가 유일한 옵션일 때

사용자 정의 iOS 코드가 UI 디자인을 위한 유일한 옵션인 경우도 있습니다. 뷰 요소가 이동하고 콘텐츠에 따라 흐름이나 레이아웃이 크게 조정되는 동적 레이아웃이 대표적인 예입니다.

장점: 충돌 병합

NIB와 Storyboard는 병합 충돌로 인해 심각한 문제를 겪었지만 코드에는 동일한 오류가 없습니다. 모든 코드에는 의미론적 의미가 있으므로 충돌을 해결하는 것은 평소보다 어렵지 않습니다.

단점: 프로토타이핑

실제로 보기 전에는 레이아웃이 어떻게 보일지 파악하기 어렵습니다. 또한 보기와 컨트롤을 시각적으로 배치할 수 없으므로 레이아웃 사양을 실제 보기로 변환하는 것은 사물이 어떻게 렌더링되는지 즉시 미리 볼 수 있는 NIB 및 스토리보드와 비교할 때 훨씬 더 오래 걸릴 수 있습니다.

단점: 리팩토링

오래 전에 작성되었거나 다른 사람이 작성한 코드를 리팩토링하는 것도 훨씬 더 복잡해집니다. 요소가 배치되고 사용자 지정 메서드와 매직 넘버로 애니메이션되면 디버깅 세션이 어려울 수 있습니다.

장점: 성능

성능 면에서 스토리보드와 NIB는 로드 및 구문 분석의 오버헤드에 영향을 받습니다. 결국 간접적으로 코드로 변환됩니다. 말할 필요도 없이 이것은 코드로 만든 UI에서는 발생하지 않습니다.

장점: 재사용성

프로그래밍 방식으로 구현된 모든 보기는 재사용 가능한 방식으로 설계할 수 있습니다. 몇 가지 사용 사례를 살펴보겠습니다.

• 둘 이상의 보기는 공통 동작을 공유하지만 약간 다릅니다. 기본 클래스와 두 개의 하위 클래스는 문제를 우아하게 해결합니다.
• 프로젝트는 단일 코드 기반을 생성하는 것을 목표로 분기되어야 하지만 각각 특정 사용자 정의가 있는 두 개(또는 그 이상)의 서로 다른 애플리케이션을 생성해야 합니다.

동일한 UI 디자인 프로세스는 NIB와 스토리보드를 사용하는 경우 훨씬 더 복잡합니다. 템플릿 파일은 상속을 허용하지 않으며 가능한 솔루션은 다음으로 제한됩니다.

• NIB 및 Storyboard 파일을 복제합니다. 그 후 그들은 별도의 삶을 가지며 원본 파일과 아무런 관련이 없습니다.
• 단순한 경우에는 작동할 수 있지만 다른 경우에는 심각한 복잡성을 초래할 수 있는 코드로 모양과 동작을 재정의합니다. 코드에 대한 과도한 재정의는 또한 시각적 디자인을 쓸모없게 만들 수 있으며, 예를 들어 특정 컨트롤이 Interface Builder에서 한 방향으로 표시되지만 앱이 실행 중일 때는 완전히 다르게 보일 때 지속적인 골칫거리로 발전할 수 있습니다.

코드를 사용하는 경우

다음과 같은 경우 iOS 사용자 인터페이스 디자인에 사용자 지정 코드를 사용하는 것이 좋습니다.

• 동적 레이아웃.
• 둥근 모서리, 그림자 등과 같은 효과가 있는 보기
• NIB와 Storyboard를 사용하는 것이 복잡하거나 실행 불가능한 경우.

코드를 사용 하지 말아야 할 때

일반적으로 코드로 만든 UI는 항상 사용할 수 있습니다. 그들은 거의 나쁜 생각이 아니므로 여기.

NIB와 Storyboard가 테이블에 몇 가지 이점을 제공하지만 코드 사용을 억제하기 위해 목록에 넣는 합리적인 단점은 없다고 생각합니다(게으름을 제외하고).

하나의 프로젝트, 여러 도구

스토리보드, NIB 및 코드는 iOS 사용자 인터페이스를 구축하기 위한 세 가지 도구입니다. 우리는 그들을 가지고 운이 좋습니다. 프로그래밍 방식 UI의 광신자는 다른 두 가지 옵션을 고려하지 않을 것입니다. 코드를 사용하면 기술적으로 가능한 모든 작업을 수행할 수 있지만 대안에는 한계가 있습니다. 나머지 개발자를 위해 Xcode 군용 칼은 동일한 프로젝트에서 한 번에 모두 효과적으로 사용할 수 있는 세 가지 도구를 제공합니다.

어떻게, 당신은 물어? 그러나 당신은 좋아합니다. 다음은 몇 가지 가능한 접근 방식입니다.

• 모든 관련 화면을 별도의 그룹으로 그룹화하고 고유한 스토리보드로 각 그룹을 구현합니다.
• 테이블 뷰 컨트롤러 내에서 스토리보드를 사용하여 재사용할 수 없는 테이블 셀을 제자리에 디자인합니다.
• 재사용을 장려하고 반복을 피하기 위해 NIB에서 재사용 가능한 테이블 셀을 설계하되 사용자 정의 코드를 통해 이러한 NIB를 로드하십시오.
• NIB를 사용하여 사용자 지정 보기, 컨트롤 및 개체 사이를 디자인합니다.
• 매우 동적인 보기에 코드를 사용하고 보다 일반적으로 Storyboard 및 NIB를 통해 쉽게 구현할 수 없는 보기에 코드를 사용하는 동시에 Storyboard에 보기 전환을 수용합니다.

마지막으로 모든 것을 하나로 묶는 마지막 예를 살펴보겠습니다.

간단한 사용 사례

몇 가지 다른 보기를 가진 기본 메시징 앱을 개발하려고 한다고 가정해 보겠습니다.

• 팔로우한 친구 목록(차후 목록에서 UI 일관성을 유지하기 위해 재사용 가능한 셀 템플릿 포함).
• 별도의 섹션(프로필 정보, 통계 및 도구 모음 포함)으로 구성된 프로필 세부 정보 보기입니다.
• 친구와 주고받은 메시지 목록입니다.
• 새로운 메시지 양식입니다.
• 각 태그의 크기는 사용 횟수에 비례하여 사용자 메시지에 사용된 다양한 태그를 표시하는 태그 클라우드 보기입니다.

또한 보기가 다음과 같이 흐르기를 원합니다.

• 팔로우한 친구 목록에서 항목을 클릭하면 해당 친구의 프로필 세부 정보가 표시됩니다.
• 프로필 세부 정보에는 프로필 이름, 주소, 통계, 가장 최근 메시지의 짧은 목록 및 도구 모음이 표시됩니다.

이 iOS 앱을 구현하려면 다음과 같이 세 가지 UI 도구가 모두 유용합니다.

• 4개의 보기 컨트롤러(목록, 세부 정보, 메시지 목록 및 새 메시지 양식)가 있는 스토리보드.
• 재사용 가능한 프로필 목록 셀 템플릿에 대한 별도의 NIB 파일.
• 프로필 세부 정보 보기를 위한 3개의 개별 NIB 파일(프로필 세부 정보, 통계, 마지막 3개 메시지)을 구성하는 각 섹션에 대해 하나씩 더 나은 유지 관리를 허용합니다. 이러한 NIB는 보기로 인스턴스화된 다음 보기 컨트롤러에 추가됩니다.
• 태그 클라우드 보기에 대한 사용자 지정 코드입니다. 이 보기는 StoryBoard나 NIB를 통하지 않고 Interface Builder에서 디자인할 수 없는 전형적인 예입니다. 대신 코드를 통해 완전히 구현됩니다. 스토리보드의 시각적 흐름을 유지하기 위해 스토리보드에 빈 보기 컨트롤러를 추가하고 태그 클라우드 보기를 독립 실행형 보기로 구현하고 프로그래밍 방식으로 보기 컨트롤러에 보기를 추가하도록 선택합니다. 분명히 보기는 독립 실행형 보기가 아니라 보기 컨트롤러 내부에서 구현할 수도 있지만 더 나은 재사용을 위해 분리된 상태로 유지합니다.

정말 기본적인 목업은 다음과 같습니다.

이를 통해 UI 디자인에 대한 세 가지 기본 접근 방식을 핵심 보기로 묶는 합리적으로 정교한 iOS 앱의 기본 구성을 설명했습니다. 기억하십시오: 각 도구에는 장점과 단점이 있으므로 이진 결정을 내릴 수 없습니다.

마무리

이 튜토리얼에서 살펴본 것처럼 스토리보드는 iOS UI 디자인과 시각적 흐름에 눈에 띄는 단순화를 추가합니다. 또한 상용구 코드를 제거합니다. 그러나 이 모든 것에는 대가가 따르며 유연하게 지불됩니다. 한편 NIB는 시각적 흐름이 없는 단일 보기에 집중함으로써 더 많은 유연성을 제공합니다. 물론 가장 유연한 솔루션은 다소 비우호적이고 본질적으로 비시각적인 경향이 있는 코드입니다.

이 기사가 흥미롭다면 Ray Wenderlich의 NIB, 스토리보드 및 코드 제작 UIS에 대한 토론을 55분 동안 잘한 토론을 시청하는 것이 좋습니다.

끝으로 한 가지 강조하고 싶은 것은 부적절한 iOS UI 디자인 도구를 사용하지 않는 것입니다. 보기를 스토리보드로 디자인할 수 없거나 NIB 또는 코드로 더 간단한 방법으로 구현할 수 있는 경우 스토리보드를 사용 하지 마십시오 . 마찬가지로 NIB를 사용하여 뷰를 디자인할 수 없는 경우 NIB를 사용하지 마십시오. 이러한 규칙은 간단하지만 개발자로서의 교육에 큰 도움이 될 것입니다.