2009-10-27 5 views
4

저는 MacOSX 용 코코아를 처음 접했지만 끊임없이 인터페이스 빌더와 싸우고 있습니다.Interface Builder가 방해가되는 이유는 무엇입니까?

현재 사용자 정의 컨트롤과 뷰가있는 앱을 만들고 있습니다. 처음에는 인터페이스 빌더에서 응용 프로그램을 작성하기 시작했습니다. 처음에는 물건을 드래그하여 올바른 색상과 정확한 자동 크기 조정 규칙을 사용하여 올바른 지점으로 가져 오기가 쉽기 때문입니다. 그러나 IBPlugin을 구축하지 않고 인터페이스 빌더에서 표현할 수없는 사용자 정의 컨트롤과 뷰를 빌드 할 때가 왔습니다. 필자가 알고있는 유일한 다른 옵션은 클래스 만 변경된 곳에서 여러 개의 "사용자 정의보기"를 포함하는 인터페이스 빌더 문서를 갖는 것입니다. 갑자기 IB에 귀찮게하는 것조차도 무의미한 것처럼 보입니다. 특히 이러한 컨트롤과 뷰는 IB 문서에있는 다른 뷰와 컨트롤처럼 설정해야 할 색상과 같은 속성을 갖게됩니다. 이제는 두 개의 연결이 끊긴 장소에 시각화 속성이 설정되어있어 IB의 잠재적 인 장점 중 하나를 상쇄하는 것으로 보입니다. IB의 잠재적 인 이점은 코드를 파고 들지 않으면 서 앱의 UI를 비교적 쉽게 조정할 수 있다는 것입니다.

데이터 나 현재 선택에 따라 몇 가지 컨트롤 (예 : 색상)이 변경되는 경우도 있습니다. 이제 인터페이스 빌더에 지정된 컨트롤의 초기 기본 색상이 있지만 코드에서 데이터 기반 색상을 지정해야합니까? 다시 Interface Builder는 세계와 코드 사이에서 일부 프리젠 테이션 설정을 분할해야하는 것처럼 보입니다. 내 데이터 나 상태에 대해 알고있는 복잡한 플러그인으로이 문제를 다소 해결할 수 있다고 생각하지만 인터페이스 빌더의 경험이 "옳다"라는 지원 코드를 maintaing하는 것처럼 보입니다.

내가 자주 언급 한 내용 중 일부는 IB가 구성 요소 간의 바인딩을 얼마나 쉽게 정의 할 수 있는지 보여줍니다. "코드를 쓰지 않고도 할 수 있습니다!" 다시 말하지만, 나는 뭔가를 놓친 것일 수 있지만, 한 속성을 다른 속성에 바인딩하는 것은 내가 말할 수있는 한 줄의 코드입니다. IB의 상자에있는 몇 가지 속성을 코드의 한 줄만 쓰는 것보다 낫게 설정하고 있습니까? 그리고 프리젠 테이션 레이어의 사양에 애플리케이션 로직에 필요한 것을 넣는 것이 더 나은 이유는 무엇입니까?

개방형에서 말했듯이이 코코아 소재에 익숙하지는 않지만 Interface Builder를 사용하는 방법에 대해 매우 중요한 것이 있거나 기본으로 제공되는 사소한 데모 응용 프로그램을 주로 사용하고 있습니다. 높은 "와우"요소.

+0

UI가 어떻게 보이는지 보겠습니다. –

+1

아래 답변은 이미 작성한 모든 내용을 다룹니다. 따라서이 말은 단지 주석 일뿐입니다. 당신은 혼자가 아닙니다! 나는 다른 개발자와 함께 커다란 코코아 프로젝트의 마지막 단계에서 일하고있다. 우리는 IB를 사용하기 시작했지만, UI가 매우 커스터마이징 되었기 때문에 우리는 완전히 그만 두었습니다. 제 생각에 IB는 Cocoa 앱 개발의 기초를 배우고, Apple의 UI 표준을 완벽하게 준수하는 소규모 프로젝트에 적합합니다. 대부분의 맞춤식 또는 복잡한 앱은 코드에서 상황을 파악하는 것이 좋습니다. –

+1

문제에 대한 좀 더 좋은 토론을 위해 : http://stackoverflow.com/questions/1056079/is-there-a-way-to-programmatically-determine-the-proper-sizes-for-apples-built-i –

답변

7

인터페이스 빌더가 앱의 일반 레이아웃을 얻는 데 우수하다는 것을 알았습니다. 바인딩 (Mac)에서도 유용합니다. 그러나 Interface Builder를 사용하여 Delicious Library를 만들 방법은 없습니다. 인터페이스가 복잡할수록 더 많은 코드를 작성해야합니다.

1

제 첫 번째 iPhone 프로그램과 개발중인 두 번째 iPhone 프로그램은 Interface Builder를 사용하지 않습니다. 나는 코드에서 모든 것을 가지고있는 것을 좋아해서 무슨 일이 일어나고 있는지 이해할 수 있고 모든 버전을 추적하기 위해 버전 추적을 사용할 수 있습니다.

지금까지 내가 아는 한, 우선 순위에 달려있다. 두 가지 스타일 (IB와 IB 없음)을 사용하는 코코아 서적이 있습니다.

+0

iPhone에서도 마찬가지였습니다. iPhone 개발을 시작했을 때 IB는 어쨌든 거의 지원하지 않아서 사용하지 않았기 때문입니다. 그러나 OSX 세계는 내가 실행 한 것을 중심으로 매우 IB 중심으로 보입니다. 그래서 간단하게 "어떻게 완료되었는지"보였습니다. 나는 그 인식이 실제로 진실인지 아닌지 알아 내려고 노력 중이다. 이 두 가지 방법을 사용하는 책이 있다는 것을 나타내므로, 방금 메뉴 바를 관리하기 위해 IB를 사용하고 다른 모든 것을 코드에 남겨 두었다면 중요한 것을 잃지 않을 것이라고 확신합니다. – Sean

2

Jeff LaMarche (iPhone 개발 명성)는 an excellent article에 IB를 사용하는 것이 좋은 선택 인 이유에 대해 썼습니다. 기본 자습서를 지나면 올바른 경로로 보이지 않더라도 말입니다. 나는 당신과 비슷한 이유로 IB를 포기했으나이 기사는 계속 작업에 영감을 불어 넣었습니다. 너무 괴상한 추상화를 허용하지 않는 괴짜 경향에 맞서도 실제로는 올바른 해결책이되었습니다.

+1

그 기사는 대부분 "내가 굉장하다고 말하기 때문에 그것을 사용하십시오." 실제로 코드가 생성되지 않았기 때문에 디버깅 할 코드가 적어서 실제로 나열된 단 하나의 인수 (주목)가있었습니다. 좋게 들리지만, 전 그걸 전적으로 사는지 모르겠습니다. 커플 바인딩을 설정하거나 프레임 사각형을 설정하면 IB에서의 클릭 및 타이핑 또는 Objective-C에서의 몇 줄이 소요됩니다. 이 코드 줄이 갑자기 나중에 바뀔 것이고 버그가 마술처럼 나타날 것입니다. – Sean

6

인터페이스 빌더는 약간 익숙해 질 수 있습니다.그러나 이전에 언급했듯이 사용할수록 더 좋습니다. 물론 사용자 정의보기는 코드에서 수행 할 수 있지만 IB는 이유의 표준입니다. Mac 응용 프로그램은 다른 플랫폼의 UI 표준보다 훨씬 높은 커뮤니티의 특정 UI 품질 표준을 유지합니다. IB는 시각적 인 참고없이 코드에서 모든 것을하는 것보다 이러한 표준을 따르는 것이 훨씬 쉽습니다.

버전 관리에서 UI를 사용하려면 코드에서 모든 작업을 수행 할 필요가 없습니다. 모든 Cocoa 프로젝트는 nib/xib 파일이 포함 된 git 저장소에 있습니다.

IB에게 기회를주십시오. 더 많이 사용할수록 더 쉽게 얻을 수 있습니다.

+0

IB 사용이 그리 어렵지 않습니다. 이 문제는 IB가 할 수 있기 때문에 IB에서, 일부 코드에서, 데이터 기반으로, 등 다양한 방식으로 설정된 여러 가지 속성을 갖는 것 (적어도이 프로젝트의 경우)이 겉으로보기에는 겉으로보기에는 결과가 될지 여부입니다. 플러그인 및 여러 지원 코드를 작성하지 않고 내 사용자 정의보기 및 사물을 지원하지 않습니다. : / – Sean

관련 문제