[Ios] Storyboard 사용시기 및 XIB 사용시기


Answers

2016 년 1 월 12 일 업데이트 : 2016 년이고 Storyboards가 아닌 코드로 UI를 배치하는 편이 더 좋습니다. 즉, 스토리 보드는 먼 길을왔다. 이 게시물에서 2016 년 단순히 더 이상 적용하지 않는 모든 요점을 제거했습니다.

업데이트 4/24/2015 : 흥미롭게도 Apple은 피터 슈타인 버거 ( "Interface Builder"소제목) 가 알게 된 대로 최근 오픈 소스 연구 키트에서 스토리 보드를 사용하지 않습니다.

2014 년 6 월 10 일 업데이트 : 예상대로 Apple은 스토리 보드 및 Xcode를 계속 개선합니다. iOS 7 이하 버전에 적용된 요점 중 일부는 더 이상 iOS 8에 적용되지 않습니다. 그래서 Storyboards에는 본질적으로 결함이 있지만, 필자는 조언을 선별 적으로 사용 하지 않는 것으로 부터 수정합니다.

이제 iOS 9이 출시되었지만, 반대 스토리 보드 사용 여부를 결정할 때주의해야합니다. 내 이유는 다음과 같습니다.

  • 스토리 보드는 컴파일 타임이 아니라 런타임에 실패합니다. 스토리 보드 에 세그 이름에 오타가 있거나 잘못 연결되어 있습니까? 그것은 런타임에 날아갈 것이다. 스토리 보드에 더 이상 존재하지 않는 사용자 정의 UIViewController 하위 클래스를 사용합니까? 그것은 런타임에 날아갈 것이다. 코드에서 이러한 작업을 수행하는 경우 컴파일 타임에 일찍 잡을 것입니다. 업데이트 : 내 새로운 도구 StoryboardLint 대부분이 문제를 해결합니다.

  • 스토리 보드의 혼란은 빨라집니다 : 프로젝트가 성장함에 따라 스토리 보드의 탐색이 점점 더 어려워집니다. 또한 여러 개의보기 컨트롤러가 여러 개의 다른보기 컨트롤러에 대해 여러 개의보기를 가지고있는 경우 스토리 보드가 빠르게 스파게티 한 그릇처럼 보이기 시작하고 사용자가 직접 화면을 확대 및 축소하고 스크롤하면 찾고있는보기 컨트롤러를 찾을 수 있습니다 segue가 어떤 점을 가리키고 있는지 찾아야합니다. 업데이트 :이 문제는 주로 Pilky 의이 기사Robert Brown의 기사 에서 설명한대로 스토리 보드를 여러 개의 스토리 보드로 분할하여 해결할 수 있습니다.

  • 스토리 보드를 사용하면 팀 작업이 더 어려워집니다 . 일반적으로 프로젝트에 하나의 커다란 스토리 보드 파일 만 있기 때문에 여러 개발자가 정기적으로 해당 파일을 변경하면 두통이 생길 수 있습니다. 변경 내용을 병합하고 충돌을 해결해야합니다. 충돌이 발생하면 해결 방법을 밝히기가 어렵습니다. Xcode는 스토리 보드 XML 파일을 생성하며 인간이 읽을 필요가 있다는 것을 염두에두고 실제로 편집하지 않았습니다.

  • 스토리 보드는 코드 검토를 어렵거나 거의 불가능하게 만듭니다 . 동료 코드 검토는 팀에서 할 수있는 가장 좋은 방법입니다. 그러나 스토리 보드를 변경하면 다른 개발자와 함께 이러한 변경 사항을 검토하는 것은 거의 불가능합니다. 끌어 올 수있는 것은 거대한 XML 파일의 차이입니다. 정말 바뀐 것을 해독하고 그 변화가 맞는지 또는 무엇인가를 깨뜨린 경우 정말 어렵습니다.

  • 스토리 보드는 코드 재사용을 방해합니다 . iOS 프로젝트에서는 대개 앱 전체에서 일관된 모양과 느낌을주기 위해 사용하는 모든 색상과 글꼴, 여백 및 인세 트를 포함하는 클래스를 만듭니다. 앱 전체에 해당하는 값을 조정하십시오. 스토리 보드에 이러한 값을 설정하면 해당 값을 복제하므로 변경하려는 경우 모든 단일 어커런스를 찾아야합니다. 스토리 보드에서는 검색 및 교체가 없으므로 놓칠 확률이 높습니다.

  • 스토리 보드에는 상수 컨텍스트 스위치가 필요합니다 . 스토리 보드보다 코드 작업이 훨씬 빨라지고 탐색 속도가 빨라졌습니다. 앱에서 스토리 보드를 사용하면 컨텍스트가 끊임없이 전환됩니다. "아,이 테이블 뷰 셀의 탭으로 다른 뷰 컨트롤러를로드하고 싶습니다. 이제 스토리 보드를 열고 올바른보기 컨트롤러를 찾고 새로운 세그먼트를 만들어야합니다. 다른보기 컨트롤러 (나는 또한 찾아야한다), segue에게 이름을주고, 그 이름을 기억한다. (나는 스토리 보드에서 상수 나 변수를 사용할 수 없다) 코드로 다시 전환하고 이름을 잘못 입력하지 않기를 바란다. 내 prepareForSegue 메서드에 대한 그 segue. 어떻게 내가 여기에 바로 3 줄의 코드를 입력 할 수 있으면 좋겠어! " 아니, 재미 없어. 코드와 스토리 보드 간 전환 (키보드와 마우스 간 전환)이 오래 걸리고 속도가 느려집니다.

  • 스토리 보드는 리팩터링하기가 어렵습니다 . 코드를 리팩터링 할 때 스토리 보드가 기대하는 것과 일치하는지 확인해야합니다. 스토리 보드에서 물건을 움직이면 코드에서 작동하는지 여부 만 런타임에 알 수 있습니다. 마치 두 세계를 동기화 시켜야만하는 것처럼 느껴집니다. 그것은 겸손한 생각으로 부서지기 쉬우 며 변화를 저지합니다.

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

  • 스토리 보드는 특수 뷰 컨트롤러의 유형을 변경할 수 없습니다 . UITableViewControllerUICollectionViewController 로 변경하고 UICollectionViewController 습니까? 아니면 일반 UIViewController ? 스토리 보드에서는 불가능합니다. 이전보기 컨트롤러를 삭제하고 새로운보기 컨트롤러를 만들고 모든 세그먼트를 다시 연결해야합니다. 코드에서 이러한 변경을 수행하는 것이 훨씬 쉽습니다.

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

  • 스토리 보드는 UIImageView 하위 뷰를 추가하는 것을 허용하지 않습니다 . 누가 그 이유를 알고 있습니다.

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

  • 스토리 보드는 이전 버전과의 호환성을 상실 할 위험이 더 큽니다 . Xcode는 스토리 보드 파일 형식을 변경하는 경우가 있으며, 지금부터 몇 년 또는 몇 달 후에 작성한 스토리 보드 파일을 어떤 방식 으로든 열 수는 없습니다. (이 점에 대한 사려 깊음에 감사드립니다. 원래의 코멘트를보십시오 )

  • 스토리 보드는 코드를 더욱 복잡하게 만들 수 있습니다. 코드로 뷰 컨트롤러를 만들 때 사용자 정의 init 메소드 (예 initWithCustomer: 를 생성 할 수 있습니다. 그렇게하면 뷰 컨트롤러 내부의 customer 변경하지 못하게 할 수 있으며이 뷰 컨트롤러를 customer 개체없이 만들 수 없습니다. 스토리 보드를 사용할 때는 불가능합니다. prepareForSegue:sender: 메서드가 호출 될 때까지 기다린 다음 뷰 컨트롤러에서 customer 속성을 설정해야합니다. 즉,이 속성을 변경할 수있게해야한다는 것을 의미합니다. 그러면 뷰 컨트롤러를 허용해야합니다. customer 오브젝트없이 작성할 수 있습니다. 제 경험상이 코드는 코드를 복잡하게 만들 수 있으며 앱의 흐름을 추론하기가 더 어려워집니다. 업데이트 9/9/16 : Chris Dzombak 이이 문제에 대한 훌륭한 기사를 작성했습니다.

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

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

코드에서 UI 및 응용 프로그램 흐름을 만들 때 진행중인 작업을 훨씬 더 많이 제어 할 수 있으며 디버깅하기 쉽고 실수를 일찍 찾아내는 것이 쉬우 며 다른 개발자에게 내 변경 사항을 설명하는 것이 더 쉽습니다. iPhone 및 iPad를 지원하는 것이 더 쉽습니다.

그러나 모든 UI 를 코드로 배치하는 것이 모든 프로젝트에 맞는 솔루션이 될 수는 없다는 것에 동의합니다. iPad UI가 특정 장소에서 iPhone UI와 크게 다른 경우 해당 지역에 대한 XIB를 만드는 것이 좋습니다.

위에 설명 된 많은 문제는 Apple에 의해 수정 될 수 있으며, 그것이 그들이 할 일이기를 희망합니다.

그냥 내 두 센트.

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

Question

iOS 프로젝트에서 스토리 보드를 사용할시기와 XIB를 사용할시기에 대한 가이드 라인이 있습니까? 각자의 장점과 단점은 무엇이며, 어떤 상황에서 어떤 상황에 처하게됩니까?

근처에보기 컨트롤러가 동적 UI 요소 (지도 핀처럼)로 푸시 될 때 스토리 보드 단편을 사용하는 것이 깔끔하지 않다고 말할 수 있습니다.




스토리 보드를 사용해야 하는 이유 간단 합니다 . 특히 제품 소유자, 제품 관리자, UX 디자이너 등으로 구성된 팀에서 작업해야하는 생산적인 환경에서 특히 그렇습니다.

  1. 애플은 스토리 보드 작업을 대폭 개선했다. 그리고 그들은 당신이 그들과 함께 일하도록 권장합니다. 즉, 기존 프로젝트를 업데이트 하지 않고 스토리 보드가 최신 XCode / iOS 버전의 미래를 보장한다는 것을 의미합니다.
  2. 생성 단계에서조차도 제품 소유자 및 관리자가 더 짧은 시간더 많은 가시적 인 결과를 얻을 수 있습니다 . 스토리 보드 자체를 스크린 플로우 다이어그램으로 사용하고 회의에서 토론 할 수도 있습니다.
  3. 응용 프로그램이 완료된 후에도 (그리고 일반적으로 수명주기가 시작되는 곳) - 앞으로는 작은 조정을 적용하는 것이 더 빠르고 쉽습니다 . 그리고 이것들은 WYSIWYG 방식으로보기를 원하는 레이아웃의 여러 측면을 동시에 바꿀 수 있습니다. 대안은 코드에서 UI 변경 사항을 직접 작성하고 IDE와 시뮬레이터간에 앞뒤로 전환하여 컴파일 및 빌드를 기다릴 때마다이를 테스트하는 것입니다.
  4. 개발자가 아닌 사람들 은 스토리 보드에 레이아웃을 설정하고 개발자에게 필요한 훅을 만드는 배울 수 있습니다 (IBOutlets 및 IBActions). 이것은 devs가 로직에 초점을 맞추고 UX 디자이너가 코드를 전혀 작성하지 않고 시각적으로 변경 사항을 적용 할 수 있기 때문에 매우 큰 장점입니다.

요하네스가 이미 모든 답변을 나열했기 때문에 나는 단점을 적어 두지 않을 것입니다. 그리고 그들 중 대부분은 확실히 실행 가능하지 않습니다. 특히 XCode6의 주요 개선점은 아닙니다.




저는 합리적인 규모의 프로젝트 (스토리 보드에서 20 개 이상의 장면)를 작업 해 왔으며 많은 한계를 경험했으며 작업을 수행하기 위해 문서 및 Google 검색에 반복적으로 가야했습니다.

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

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

  3. IDE는 축소 된 상태로 컨트롤을 선택할 수 없습니다. 따라서 대규모 프로젝트에서 축소는 대부분 상위 수준의 뷰를 얻는 것뿐입니다.

팀 규모가 작은 소규모 애플리케이션에 스토리 보드를 사용하고 중간 규모의 팀 / 프로젝트에 XIB 방식을 사용합니다.




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

Δ 이점 :

UIView 의 복잡한 종류의 UI 나 전환 애니메이션을 만들 수 있습니다.

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

√ * 귀하의 응용 프로그램은 코드 내에서 모든 iPhone / iPod / iPad 장치를 지원합니다.

√ 항상 작동 할 코드를 아는대로 항상 업데이트됩니다.

√ * (새로운) 장치가 작동 할 때 작동합니다 - 코드를 변경할 필요가 없습니다.

√ 모든 것이 당신에게 달려 있습니다. 특정 장소에서 뭔가를 변경하고 싶을 때 - 스토리 보드 나 xib를 들여다 볼 필요가 없습니다. 특정 클래스에서 검색하십시오.

마지막으로 목록은 아니지만 - 프로그래밍 방식으로 모든 것을 관리하는 방법을 잊지 못할 것입니다. 이것은 당신이 아주 깊은 곳에서 통제를 아는 한 최고의 것입니다.

SB 또는 XIBs를 사용하지 않아서 문제가 발생하지 않았습니다.

* 화면 크기에 따라 UIKit의 대상 프레임을 설정 한 경우

추신 :이 일을 아직 끝내지 않았다면 어려움에 직면 할 수도 있지만 지루할 수도 있습니다. 일단 익숙해지면 정말 사탕을 먹을 수 있습니다.