iOS: Storyboard, NIB(xib), Code 비교

by http://angelking.org/ios-storyboard-nibxib-code/

iOS: Storyboard, NIB(xib), Code 비교

Storyboard, NIB(xib), Code는 각각의 장단점이 있습니다.

이 글을 번역한 내용 정리입니다.

틈틈히 시간을 내어 번역, 정리 하며 작성하다 보니 중간 중간 글의 느낌이 변하지만 내용 파악엔 그닥 지장이 없을 것 입니다.

글이 너무 길어서 중간에 그냥 지워버릴 까 울컥울컥(…) 을 몇 번 했는지.

도움이 되시길.

Storyboard

---

Storybaord를 아주 큰 한 덩어리로 만들지 말자.

– 기능/주제/메뉴 등등의 분류대로 분리된 여러 개의 스토리보드로 구현.

– 여러 사람이 작업할 경우 conflict 발생 소지가 아주 높고, merge가 쉽지 않음.

 

Storyboard를 사용할 때

– 뷰컨트롤러들 사이에서의 이동을 주된 목적으로 하는 다수의 서로 연결된 뷰컨트롤러들의 경우.

– 네비게이션 흐름(pop, push, present, dismiss 등)을 쉽게 해줌.

– 뷰컨트롤러가 자동으로 생성되므로 alloc이나 init을 해줄 필요 없음.

– 테이블뷰 컨트롤러 이점

셀을 함께 디자인해서 테이블뷰와 함께 둘 수 있음.

여러 형태의 셀 템플릿을 디자인할 수 있음.

Static cell 사용 가능(스토리보드에서만 가능).

 

Storyboard를 사용하지 않을 때

– 복잡한 다이나믹 레이아웃을 가진 뷰일 경우 – 코드 추천

– 뷰가 이미 xib이나 코드로 개발되어 있을 때

 

Storyboard의 장점

– 퍼포먼스: 최초 뷰컨트롤러 하나만 초기화된 후 나머지는 세구에가 동작할 때 동적으로 객체화 됨.

– 프로토타입: 스토리보드+코드 몇 줄로 빠른 목업 프로토타이핑이 가능.

 

Storyboard의 단점

– 재사용성: 스토리보드는 의존하는 모든 뷰 컨트롤러들과 함께 복사 혹은 이동해야 함.

스토리보드의 나머지 기능에 의존적이기 때문에 뷰컨트롤러 하나만 뽑아내 재사용하기가 성가심.

– 데이터 흐름: 스토리보드는 뷰컨트롤러들 사이의 흐름을 다루지만 데이터의 흐름은 관여하지 않음.

 

NIB

---

Storyboard가 NIB의 대체품은 아님.

더욱 구체적인 UI의 구현이 가능함.

객체지향 관점에서 뷰를 여러 분리된 모듈로 쪼개서 개발, 테스트, 디버그를 더 쉽게 해줌.

merge conflict 문제를 갖고 있으나 규모가 스토리보드에 비해 규모가 작음.

 

NIB을 사용할 때

– 모달뷰

– 간단한 로그인, 회원가입 뷰

– 설정

– 팝업윈도우

– 재사용 가능한 뷰

– 재사용 가능한 테이블 셀

 

NIB을 사용하지 않을 때

– 내용에 따라 변화무쌍한 레이아웃을 가진 뷰들

– 애초에 인터페이스 빌더에서 쉽게 디자인할 수 없는 뷰들

– 스토리보드에서는 단순하게 처리할 수 있는 복잡한 화면전환을 가진 뷰컨트롤러들

 

NIB의 장점: 재사용성

여러 클래스에서 동일한 레이아웃을 공유할 경우 좋음.

예) 로그인 뷰와 회원가입 뷰는 패스워드 필드 하나를 감추는 형태로 비슷한 기능과 레이아웃을 공유할 수 있다.

 

NIB의 장점이자 단점: 성능

NIB은 필요할 때 로드됨. 필요할 때 외에는 메모리를 사용하지 않으나, 로드 시 지연이 있을 수 있음.

 

Code

---

Storyboard와 NIB 으로 할 수 있는 어떤 것도 코드로도 가능하다.

Storyboard와 NIB으로 할 수 없는 것들은 언제나 코드로 구현할 수 있다( 당연히 ).

장점: 동작방식

UI를 코드로 작성하는 법을 알면 그 이면에 어떤 일이 일어나는지 알 수 있다.

(계산기는 유용하다. 하지만 계산을 어떻게 수행하는지 아는 것이 나쁜 건 아니다.)

UI를 코드로 작성하면 더 많은 제어와 이해를 할 수 있고 이런 것들을 통해 당신은 더 뛰어난 개발자가 될 수 있다.

장점: 코드만이 방법일 때

코드만이 UI 디자인에 있어 유일한 방법인 경우가 있다. 전형적인 예로, 뷰가 이리 저리 움직이는 다이나믹 레이아웃이나 내용물에 기반을 두고 변화하는 레이아웃 등이 있다.

장점: 머지 충돌(Merge Conflicts)

NIB이나 Storyboard가 머지 충돌로 고통스러울 수 있는 반면, 코드는 분명한 문법적 의미를 갖고 있기 때문에 충돌을 해결하는 것이 그리 어렵지 않다.

단점: 프로토타입 제작(Prototyping)

레이아웃이 화면에 어떻게 보여지고 작동하는지 보여주기 위해 작업해야 하는 시간이 NIB과 Storyboard에 비해 오래 걸린다.

단점: 리펙토링

누군가 오래 전에 작성한 코드를 리펙토링 하는것이 훨씬 복잡해진다. 구성요소들이 커스텀 메서드나 특정한 숫자들을 이용해 위치와 에니메이션을 결정하면 디버깅에 고통이 수반된다.

장점: 성능

성능 관점에서 storyboard와 NIB은 로드와 파싱에 오버헤드를 거치고 최종에서야 간접적으로 코드로 변환된다. 코드로 만든 UI는 이런게 필요 없다.

장점: 재사용성

코드로 작성하는 뷰는 재사용 가능한 디자인으로 구현할 수 있다. 예를 들어:

– 두개(이상)의 뷰가 비슷한 동작을 하지만, 살짝 다른 부분이 있다. 베이스 클래스와 두개(이상)의 서브클래스로 해결할 수 있다.

– 싱글 코드 베이스지만 두개 (이상)으로 커스텀된 다른 앱을 생성하려할 때  프로젝트가 두개로 분기(fork)되어야 한다.

동일한 UI 디자인 과정정은 NIB과 storyboard에서 더 복잡할 것이다. 템플릿 파일들은 상속이 불가하고, 가능한 해결책은 다음으로 제한된다:

– NIB과 storyboard 파일을 복사한다. 그 후엔 원본 파일과 관계가 없이 생명주기가 분리된다.

– 화면과 동작을 코드로 덮어 쓴다. 간단한 경우엔 작동할 것이지만, 다른 부분에 있어서는 현저한 복잡성을 가질 수 있다. 많은 부분을 코드로 오버라이드 할 경우 시각적인 디자인을 쓸모 없도록 할 것이고 이는 지속적으로 골치아프게 할 것이다. 예를 들면, 인터페이스 빌더에서 보이는 특정 컨트롤이 앱 실행 중에는 완전히 다르게 보이는 경우가 있다.

Code를 사용할 때

아래와 같은 인터페이스 디자인을 위해서는 좋은 선택이 된다:

– 다이나믹(변화가 크거나 빈번한) 레이아웃

– 둥근 모서리나 그림자 등의 효과를 갖는 뷰

– NIB과 storyboard를 사용하는 것이 복잡하거나 불가능한 경우.

 

Code를 사용하지 않을 때

보통 코드로 만든 UI는 언제나 사용되며, 좋지 않은 경우는 드믈다.

NIB과 storyboard가 테이블에 몇 가지 장점이 있지만, 코드 사용을 만류할 만한 목록에 넣을만한 합당한 단점이 없는 것 같다(아마도 게으름을 제외하면(except, perhaps, laziness)).

 

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

UI 구성에 세 개의 툴이 있다는건 행운이다. Xcode는 같은 프로젝트 내에서 동시에 “효율적”으로 사용할 수있는 이 모든 툴을 제공한다.

어떻게? 다음과 같은 몇 가지 가능한 접근방법들이 있다:

– 연관있는 화면을 별도의 그룹으로 모으고, 각각의 그룹을 분리된 storyboard로 구현한다.

– Storyboard의 테이블뷰 컨트롤러 내에 재사용할 수 없는 테이블 셀을 디자인한다.

– NIB에 재사용 가능한 테이블 셀을 디자인한다. 이 NIB은 코드로 불러들인다.

– 커스텀 뷰, 컨트롤과 그 것들 사이의 것들을 NIB으로 디자인한다.

– 다이나믹 뷰, 일반적으로 storyboard와 NIB으로 쉽게 구현할 수 없는 뷰를 코드로 구현한다.

 

간단한 Use Case

몇 가지 다른 뷰를 가진 기본적인 메시징 앱을 개발하고 싶다 치면:

– 친구목록( 재사용 가능한 셀 )

– 프로필 상세 뷰 – 몇 개의 섹션으로 구성된

– 보내고 받은 메시지 목록( 채팅방 )

– 메시지 작성 폼

– 사용된 빈도에 따라 크기가 다른 태그 클라우드

추가로, 뷰가 다음의 동작을 하길 바란다:

– 친구 목록에서 친구를 클릭하면 프로필 상세를 보여준다.

– 프로필 상세는 이름, 주소, 상태, 최근 메시지 목록, 툴바를 보여준다.

이 앱을 구현하기 위해, 세 개의 UI 툴을 사용할 수 있다:

– 네 개의 뷰 컨트롤러를 가진 storyboard (친구목록, 프로필상세, 메시지 목록, 메시지 작성 폼)

– 재사용 가능한 프로필 리스트 셀 템플릿을 위한 별도의 NIB 파일

– NIB 파일 3개 – 프로필 상세 뷰를 위한 상세, 상태, 최근 메시지. 세 NIB들은 뷰로 구성되고 뷰 컨트롤러에 올라갈 것이다.

– 태그 클라우드를 위한 커스텀 코드. Storyboard 나 NIB으로 구현 불가. 완전히 코드로 구현된다. 스토리보드의 시각적인 흐름을 관리하기 위해, 스토리보드에 빈 뷰컨트롤러를 추가한 다음, 독립적인 뷰를 태그 클라우드 뷰로 구현하고, 뷰 컨트롤러에 code를 이용해 삽입한다. 확실히, 뷰는 독립적인 뷰로써가 아니라 뷰 컨트롤러 안에 구현할 수도 있으나, 더 나은 재사용을 위해 분리된 상태로 유지한다.

아주 기본적인 목업은 이렇게 보일거다:

이렇게게 합리적으로 세련된 기본 구조를 구상했다. 각각의 툴이 장점과 단점을 갖고 있기 때문에 정해진 법칙은 없음을 잊지 말자.

 

마무리

튜토리얼에서처럼, 스토리보드는 UI 디자인과 시각적 흐름의 구현을 매우 단순하게 해주고 상투적으로 사용되는 코드들을 걷어내주지만, 그 유연성에 댓가가 다른다. 한편 NIB은 하나의 뷰에 초점을 맞춰 더 큰 유연함을 제공하지만 시각적 흐름이 없다. 가장 유연한 방법은 당연히 코드지만 덜 친숙하고 본질적으로 시각적이지 않다.

더 흥미가 생긴다면, Ray Wenderlish에 있는 the great debate 를 볼 것을 강추한다.

마치며, 하나 강조하고 싶다: 모든 측면에서, 적절치 않은 iOS UI 디자인 툴의 사용을 피하자(Avoid using the improper iOS UI design tool at all costs). 뷰가 스토리보드에서 디자인이 불가하다면, 또는 NIB이나 코드로 더 간단히 구현 가능하다면, 스토리보드를 사용하지 말자. 비슷하게, 뷰가 NIB으로 디자인 불가하다면 NIB을 사용하지 말자. 이 간단한 법칙이 개발자로서의 배움에 오래토록 함께 할 것이다.