BLOG ARTICLE Nib | 2 ARTICLE FOUND

  1. 2008.09.01 nib 파일 둘러보기 (7)
  2. 2008.02.25 적당히 참견하는 Xcode (4)

기타 2008.09.01 13:21
1. nib 파일이란?
Nib는 코코아 어플리케이션에서 사용하는 파일로 인터페이스빌더에서 생성한 윈도우, 메뉴, 컨트롤과 사용자가 만든 오브젝트들의 레이아웃과 속성등의 정보와 오브젝트간의 연결과 바인딩등의 정보를 포함하고 있는 파일입니다.

윈도우즈의 rc 파일과 개념이 비슷하지만 소스코드에서 처리하던 메시지 처리함수 연결과 바인딩등의 더 포괄적인 정보를 가지고 있습니다.

Xcode 3.1에서는 개발과정에선 nib 대신 xib란 XML 포멧의 파일을 사용합니다. (개발이 완료되고 릴리즈된 후에 nib의 역활은 이전과 동일합니다.) 3.1 이전의 자료에서는 Xcode에서 nib를 더블클릭하여 관련된 nib를 인터페이스 빌더로 실행하는 것으로 나와 있지만, 현 3.1 버젼에서는 xib를 더블클릭하여 실행합니다.


2. MainMenu.nib
사용자 삽입 이미지
MainMenu.nib는 어플리케이션에서 사용하는 메뉴, 메인윈도우, Application등 기본적인 오브젝트를 포함하고 있습니다. MainMenu.nib의 File's Owner는 NSApplication이며 또는 사용자가 생성한 NSApplication의 서브클래스를 지정할 수 있습니다. 그렇기 때문에 MainMenu.nib는 NSApplication에 의해 실행 초기(이벤트 루프에 들어 가기 전)에 자동으로 로딩됩니다.

그러므로 가능하면 다른 오브젝트나 컨트롤, 윈도우등은 모듈별로 각각의 nib를 만들어 작게 유지하며, 해당 모듈의 실행 시에만 메모리에 올라 오도록 하는 것이 좋습니다. MainMenu.nib가 많은 오브젝트나 리소를 가지고 있으면, 초기 런칭 속도가 느려지며 처음부터 많은 메모리를 사용하게 됩니다. 

MainMenu 외에 사용자가 직접 nib를 로딩해야 할 경우에는 NSBundle을 사용하여 아래와 같이 호출합니다.

[NSBundle loadNibNamed:@"[nib file name]" owner:self];


3. nib 파일 로딩
nib 파일은 로딩 시에 아래와 같은 순서로 처리됩니다.

1) 메모리 로딩
해당 Nib에 등록된 오브젝트, 관련된 리소스(이미지, 사운드 파일등)를 메모리 또는 캐쉬로 불러 옵니다.

2) 오브젝트 Unarchive
nib에 냉동포장 되어있던 오브젝트들을 해동합니다. 인터페이스 빌더의 오브젝트들에게는 initWithCoder 메시지를 발송하며, NSView의 서브클래스들에게는 initWithFrame, 그외 오브젝트들에게는 init 메시지를 발송합니다. 그리고 인터페이스 빌더에서 설정한 정보에 따라 오브젝트들간의 연결(actions, outlet)과 바인딩을 설정합니다.

3) awakeFromNib
nib내의 모든 오브젝트들에게 awakeFromNib 메시지를 발송하여, 오브젝트가 생성이 완료되었음을 알립니다. nib내의 오브젝트들은 이 메시지를 이용하여 초기화와 관련된 처리를 할 수 있습니다.

사용자 삽입 이미지
그리고 nib내의 윈도우중에 인터페이스 빌더의 Window/Behavior내의 'Visible at Launch' 속성이 체크되어 있는 윈도우를 오픈합니다.



4. 로컬라이징
nib 파일의 로컬라이징은 매우 쉽습니다. Xcode 내에서 해당 xib를 마우스 우클릭하여 나온 메뉴중에 'Get Info'를 클릭하여 정보창을 오픈합니다.
사용자 삽입 이미지
하단의 Add Localization 버튼을 클릭하여 해당언어를 추가합니다.

사용자 삽입 이미지
XCode에서 좌측과 같이 Korean이 추가되어 있는 것을 확인할 수 있습니다. 프로젝트 디렉토리내에는 Korean.lproj 디렉토리가 추가되고 그 안에 한국어 버젼의 MainMenu.xib이 위치합니다. 각 nib마다 컨트롤의 타이틀과 텍스트를 해당언어로 변경하면 됩니다.

어플리케이션이 실행되면 시스템에 설정된 현재언어를 우선으로 해당 nib가 존재할 경우에는 그 언어의 nib 파일이 로드됩니다.

nib에 대해 자세한 사항은 ADCResource Programming Guide 문서를 참조하시기 바랍니다.

'기타' 카테고리의 다른 글

아이팟 터치 2세대  (8) 2008.10.10
OS X 루트계정 활성화  (6) 2008.10.08
nib 파일 둘러보기  (7) 2008.09.01
OS X의 번들(Bundle) 둘러보기  (2) 2008.08.28
맥 OS X에서 CHM 파일 보기  (4) 2008.08.19
ClassDumper - 응용프로그램 Class Viewer  (0) 2008.08.07

Xcode를 많이 사용해 보지도 않았고, 간단한 샘플 몇가지만 만들어 본 초보 사용자라 아직 Xcode가 어떻다는 평가를 하기는 어렵습니다. 하지만 주관적인 취향이지만 Xcode 코코아의 GUI 개발 방식이 저에게는 편하게 느껴집니다.

저는 위자드에서 소스코드를 생성해 주는 방식을 선호하지 않습니다. 당장의 편리함과 속도면에서는 손해를 볼 수도 있지만 내가 사용하는 변수와 함수를 직접 타이핑함으로써 존재와 용도를 확실히 인지하고 있는 것이 소스를 이해하고 관리해 나가는데 더 많이 도움이 되기 때문입니다.

그런면에서 Xcode는 최소한의 코드를 생성해 내고 인터페이스빌더에서는 소스코드 자체에는 영향을 주지 않는 것(class 파일을 생성해 주는 일은 합니다)이 좋습니다. 이에 반해 MS의 VC++에서는 Xcode의 코코아에서 보다 훨씬 많은 파일과 코드를 자동으로 생성합니다.

또한 다이얼로그 ID, 컨트롤-변수 연결 정보, 메시지-함수 연결 정보등이 헤더나 소스파일에 기록됩니다. (MS의 개발툴중 VC만 이에 해당되는 것 같습니다) 하지만 Xcode에서는 IBAction, IBOutlet으로 변수와 함수들이 Nib의 객체들과 관련이 있는 것만 나타냅니다.

이는 OS X의 Nib 파일이 리소스, 사용자 인터페이스와 더불어 class, instance, 바인딩과 같은 객체와 연결에 대한 다양한 정보를 가지고 있지만 VC의 .rc파일에서는 객체와 연결정보 등을 가지고 있지 않고 이에 관련된 부분을 소스코드에서 관리하기 때문인 것 같습니다.

또한 코코아에서 생성하는 실행파일은 많은 부분을 컴파일하는 시점 보다 실행될 때 연결되는 동적 바인딩을 사용하고 있기 때문에 소스파일에 존재하여 같이 컴파일 되지 않아도 되기 때문인 것 같습니다.

반대로 VC++에선 rc에 있는 UI, 기타 리소스에 대한 정보와 코드의 연관관계를 소스에서 명확하게 확인할 수 있어 좋습니다. Xcode에서는 그런 정보들이 Nib파일에 들어 가고 인터페이스 빌더에서 관리하기 때문에 소스코드만 보아서는 어떤 객체와 어떻게 연결되었는지 정확히 알 수 없습니다. (하지만 잘된 명명규칙을 따랐다면 쉽게 짐작할 수는 있을 것입니다)

이전 포스팅에서 Xcode에서 소스코드에 아무런 변경없이 간단한 GUI 어플리케이션을 만드는 작업을 해보았습니다. VC++였으면 모든 연관 관계의 작업이 코드에 추가되었을 것입니다. 소스코드는 복잡해 지지만 소스코드만 보면 어떻게 연관되어 있는지 어떤 동작을 하는지 짐작할 수 있을 것 입니다. Xcode에서는 인터페이스 빌더에서 확인해야만 명확하게 알 수 있습니다. 대신 소스코드는 매우 간결합니다.

저는 소스코드가 간단하고 툴이 많은 부분 소스에 관여하는 것 보다는 소스코드가 제 취향과 입맛대로 직접 입력한 내용으로 구성되어 있다는 면에서 Xcode의 방식이 더 편하게 느껴집니다. 이 부분이 Xcode의  본래 설계의도인지 애플이 인력이 부족해 아직 신경을 쓰지 못하는지는 모르겠습니다.

실용주의 프로그래머란 책에선 '자신이 이해하지 못하는, 마법사가 만들어 준 코드는 사용하지 말라'고 합니다. 이유에 있어서 많은 부분 동의 하지만 VC++ 6.0의 클래스 위자드를 사용하지 않거나 기타 다른 툴에서 위자드나 속성창을 이용하지 않고 타이핑에 의한 코딩만 해야 한다면 그리 좋은 방법 같지는 않습니다. 일단 위자드로 생성해 놓고 올바른 위치로 재배열 하는 것이 좋지 않나 생각됩니다. 책에서도 이해하고 사용해라 정도의 의미인 것 같습니다.

툴 자체로만 놓고 본다면 VC++이 분명히 Xcode보다 편리성과 다양한 기능을 가진 더 잘 만들어진 툴입니다. 하지만 꼭 다양한 기능을 가지고 많은 부분을 자동화 해주는 툴이 모든 사람들이 개발하기에 좋다고는 할 수 없을 것 같습니다.

만약 툴이 배려하지 않은 작업을 해야 할 때나 자동으로 처리되는 부분에 있어 변경이 필요할 시에는 더 복잡한 작업을 해야하며 쓸데 없는 내용을 알아야 할 때가 있기 때문입니다. 또한 아무리 도움을 준대도 툴이 지나치게 참견하는 것을 싫어하고 제 손으로 해야만 직성이 풀리는 저같이 깝깝하게 막힌 사람도 있으니까요.

인터페이스 빌더에서 마우스로 드래그 하여 오브젝트들을 연결하는 모습과 오브젝트와 정보들을 Nib란 파일에 순간 냉동포장하여 저장하는 방식은 상당히 재밌습니다. 아마 일반적인 GUI 개발툴에서 자주 보던 방법이 아닌 다소 독특한 Xcode의 개발방법이 익숙치 않고 신선하기 때문에 단점을 묻어 두고 좋은 평가를 내리는지도 모르겠습니다. 익숙해지면 또 어떤 생각이 들지 모르겠네요.

'개발 툴' 카테고리의 다른 글

실버라이트2 둘러보기  (10) 2008.12.16
프로젝트 관리 도구 OpenProj  (2) 2008.03.21
적당히 참견하는 Xcode  (4) 2008.02.25
OS X의 파이썬  (0) 2008.02.20
Java 교육용 프로그램 Greenfoot  (0) 2007.12.23
Xcode에서 Flex - Hello World 작성  (0) 2007.12.12