스토리 보드와 기존 XIB 방식
저는 iOS를 처음 접했고 어떤 것이 가장 배우기 좋은지 궁금했습니다. 나는 여기에서 몇 가지 답변을 읽었지만 어떤 사람들은 Storyboard를 사용하면 다른 사람들은 XIB를 먼저 배우게 될 것이라고 말합니다. XIB를 배우는 데 실질적인 이점이 있습니까? XIB는 이해하기 쉽고 스토리 보드에 도움이 될까요?
펜촉으로는 할 수없는 스토리 보드로 할 수있는 일이 있습니다. 스토리 보드를 사용하면 뷰 컨트롤러간에 세그먼트를 만들 수 있으며 테이블 뷰 셀을 제자리에서 디자인 할 수 있습니다.
스토리 보드로는 할 수없는 펜촉으로 할 수있는 일이 있습니다. 펜촉에서 파일의 소유자 자리 표시 자에 대한 참조를 만들 수 있습니다. 여러 개의 최상위보기를 작성하고 편집하고 이들 간의 연결을 작성할 수 있습니다. 왜 그렇게하고 싶은지에 대한 예는 이 답변 을 참조하십시오 . 외부 개체 자리 표시자를 추가 할 수 있습니다 (거의 사용되지 않는 기능).
스토리 보드에는 느슨하게 관련된 여러 개체를 하나의 큰 파일로 수집한다는 단점이 있습니다. 여러 개발자와 함께 프로젝트를 진행하는 경우 xib 파일을 사용하는 경우보다 스토리 보드를 사용하는 경우 병합 충돌이 발생할 가능성이 훨씬 더 높습니다.
어떤 시점에서 펜촉에 대해 확실히 배워야합니다. 그들과 함께 시작하든 스토리 보드로 시작하든 그다지 중요하지 않을 것입니다. 좋아하는 튜토리얼을 찾아서 그들이 사용하는 파일 유형 (nib 또는 스토리 보드)으로 작업하십시오.
두 가지 접근 방식을 모두 배우면 이점이 있습니다.
xib 접근 방식의 역사적 가치 외에도 xib는 모듈성을 제공합니다. 코드 라이브러리가 있거나 만든 유용한 위젯을 공유하고 싶을 수 있습니다. xib 접근 방식을 취하면 공유 및 재사용이 용이 해집니다.
xib 접근 방식은 또한 자신의 코드 측면에서 더 큰 유연성을 제공합니다. 예를 들어, iOS 5에는 달리 문서화 되었음에도 불구하고 반환 UITableView
될 수있는 접근성 / VoiceOver 지원 버그가 포함되어 있습니다 (자세한 내용은 이 블로그 게시물 참조). xib에서 테이블 뷰 셀을 동적으로로드하기 위해 버그를 해결할 수있는 기능이 제공되었습니다.-dequeueReusableCellWithIdentifier:
nil
Storyboards의 테이블 및 테이블 셀 지원은 훌륭하고 대부분의 사람들이 테이블에서 수행해야하는 작업을 지원하지만, 때로는 선 외부에 색상을 지정해야하고, 많은 다른 셀이 필요할 수 있으며, xib에서 동적으로로드 할 수 있습니다. 귀하의 솔루션.
Storyboard의 큰 장점 중 하나는 전체 애플리케이션의 GUI 흐름을 볼 수 있다는 것입니다. 축소하면 모든 것이 어떻게 상호 연결되고 흐르는 지 볼 수 있습니다. xibs를 사용하면 모듈성이 좋지만 모든 것이 어떻게 연결되고 함께 흐르는 지 상상하기가 더 어렵습니다. 이것은 자신에게 유용한 기능이 될 수도 있고 공유 할 더 큰 팀이있는 경우 다른 사람들이 앱의 흐름을 볼 수 있도록하는 데 유용 할 수 있습니다.
두 가지 접근 방식 모두에 가치가 있으며 두 가지를 모두 아는 것이 좋으므로 당면한 작업에 가장 적합한 도구를 선택할 수 있습니다.
업데이트 2014-10-06- 위의 글을 쓴 이후로 더 많은 프로젝트에 참여했습니다. 일부는 xib를 사용하고 일부는 스토리 보드를 사용할 수 있습니다.
스토리 보드는 상당히 성숙 해졌고 (지금은 Xcode 6에 있습니다) 정말 멋진 스토리 보드가 많이 있습니다. xib 접근 방식에서 조금 더 복잡한 스토리 보드 내에서 훨씬 더 많은 작업을 수행 할 수 있다는 점이 정말 마음에 듭니다. 몇 가지 예 :
하나는 스토리 보드에서 직접 프로토 타입 셀로 작업 할 때 UITableView
또는 UICollectionView
얼마나 많이 작업 할 수 있는지입니다. 멋지고 쉬운 설정이 많고, 대부분의 무거운 작업은 코드가 적은 스토리 보드에있을 수 있습니다. 꽤 좋습니다. xib 접근 방식에서 이것을 시도하는 것은 확실히 가능하지만이를 실현하기위한 더 많은 작업이 있습니다.
또 하나는 UIViewController
일반 segues로 전환 한 다음 unwind segues로 되돌아 갈 수있는 방법입니다. 최소한의 코드로 스토리 보드에 있습니다. 너무 편리합니다.
하지만 여전히 스토리 보드를 죽이는 한 가지는 협업 환경에서 사용하려는 것입니다. 잘 병합되지 않을 것입니다. 그리고 어떤면에서는 1 명 이상의 팀에서 일하는 경우에도 마찬가지입니다. 버전 제어를 활용하고 자신의 개인 워크 플로우를 위해 좋은 분기 및 병합 모델을 사용하는 경우 다른 분기로 가져와야하는 일부 분기에서 일부 변경을 수행해야 할 때가 올 수 있습니다. 오 고통. 나에게 이것은 스토리 보드를 죽이는 것입니다.
시간과 작업이 발전함에 따라 제가 찾은 것은 스토리 보드가 프로토 타이핑에 적합하다는 것입니다. 빠르게 진행할 수있는 능력은 스토리 보드의 큰 이점입니다. 그것들을 사용하는 데 많은 속도가 있습니다. 그러나 속도는 비용이 듭니다. 일부 프로젝트에 대한 "실제"코드를 작성할 때 xibs를 고수 할 것입니다. 더 많은 작업이 될 수 있지만 더 큰 팀이나 시간이 지남에 따라 더 잘 작동하는 더 유연한 경로이기 때문입니다.
업데이트 2015-04-07 또 다른 업데이트는 지난 몇 달 간의 프로젝트로 인해 더 많은 통찰력을 제공하는 스토리 보드를 사용해야했기 때문입니다.
첫째, 어떤 것들은 하나 또는 다른 접근법을 요구할 것입니다. 예를 들어, 스토리 보드에서 동일한 작업을 수행하는 존재하지 않는 xibs의 크기 클래스로 작업 할 때 일부 엣지 케이스 버그가 있었던 것 같습니다. 따라서 버그에 의해 영향을 받으면 손을 한 방향 또는 다른 방향으로 강요 할 수 있습니다. 또 하나는 스토리 보드가 일반적으로 UIViewController
레벨에서 작동한다는 점을 기억하는 것입니다. 따라서 로드 할 a UIView
또는 a 와 같은 작업을 수행해야하는 경우 UICollectionViewCell
xib에서 제공하는 것이 더 나을 것입니다.
둘째, 처음에는 왜 이런 일이 발생하지 않았는지 모르겠지만 전체 프로젝트에 대해 단일 스토리 보드를 사용해야하는 것은 없습니다 ! 스토리 보드의 특성상 사람들이 그런 식으로 끌릴 수 있다고 생각하지만, (제가 알고있는) 그 어떤 의무도 기억할 필요가 없습니다.
내가 잘 찾은 것은 일반적으로 스토리 보드별로 각 "보기 그룹화"에 접근하는 것입니다. 즉, 종종 ViewController가 격리되어 스토리 보드 (또는 xib) 당 1 개가되는 경향이 있습니다. 그러나 밀접하게 관련된 두 개의 ViewController가있는 상황이있을 수 있으며,이를 동일한 스토리 보드에 넣는 것이 합리적 일 수 있습니다. 특히 segue와 같이 둘 사이에 쉽게 연결할 수 있기 때문입니다.
여러 스토리 보드의 주요 이점은 무엇입니까? 팀으로 작업합니다. 이런 식으로 Fred는 자신의 스토리 보드에서 작업 할 수 있고 Wilma는 자신의 스토리 보드에서 작업 할 수 있으며 병합 문제 나 작업 코디 나티 논에 대한 강한 걱정이 없습니다! 여러 스토리 보드 (일반적으로 스토리 보드 당 1 개의 ViewController)를 사용하는 것은 여러 사람이 참여하는 개발 팀에서 스토리 보드를 사용하는 데 큰 도움이되었습니다.
애플이 우리가 스토리 보드를 선호하기를 원한다는 것은 꽤 분명하며, 요즘에는 더 많이 수용하고 있습니다. 여러 스토리 보드를 사용하지만 필요할 때 여전히 xib를 사용하는 것이 현재 상당히 잘 작동합니다.
업데이트 2015-09-21 이제 Apple이 Xcode 7을 출시 했으므로 Apple이 단점을 극복하기 위해 노력함에 따라 스토리 보드를 채택 할 이유가 더 많습니다.
가장 중요한 개선 사항은 스토리 보드 참조로 , 한 스토리 보드에서 다른 스토리 보드에 대한 참조를 만들 수 있습니다. 만드는 것은 매우 간단하며 이제 교차 스토리 보드 세그 (입구 및 퇴장)를 가질 수 있습니다. 나는 이미 새로운 프로젝트에서 이것을 몇 번 사용했고 그것은 단지 기쁨입니다.
또 다른 개선 사항은 UIView
스토리 보드 내에서 독립 실행 형 클래스를 만들 수 있다는 것 입니다. 그러나이 글을 쓰는 시점에서 나는 그것과 혼합 된 결과를 얻었다. 간단한 경우는 괜찮지 만 "복잡한"경우는 그렇지 않았습니다. 예를 들어, 내가 가지고 UIViewController
A를을 UITableView
그 안에. 5 개의 정적 셀이있는 간단한 테이블이기 때문에 UITableViewCell
스토리 보드에서 ViewController의 일부로 5s를 인스턴스화했습니다 . 작동하는 것처럼 보였지만 런타임에 실제로로드되고 표시되는 것은 없습니다. 이동UITableViewCell
xib에 들어가고 모두 작동했습니다. 내가 뭔가 잘못하고 있는지 또는 그것이 무엇인지 확실하지 않으므로 YMMV. 그러나 여전히 몇 가지 단점이 있더라도 시간이 지나면 애플이이를 해결하고 스토리 보드에 대한 또 다른 장벽이 무너질 것이라고 확신합니다. 그러한 지원이 필요하면 시도해보고 어떻게 진행되는지 확인해야한다고 말하고 싶습니다. 큰 약속이 있습니다.
점점 더 훌륭한 스토리 보드가 형성되고 있습니다.
참조 URL : https://stackoverflow.com/questions/13834999/storyboards-vs-the-old-xib-way
'IT TIP' 카테고리의 다른 글
신속하게 이번 달의 첫 번째와 마지막 날 (0) | 2020.12.31 |
---|---|
Ruby on Rails의 '뒤로'브라우저 작업 (0) | 2020.12.31 |
Python에서 초를 hh : mm : ss로 변환 (0) | 2020.12.31 |
내부 예외를 확인하는 가장 좋은 방법은 무엇입니까? (0) | 2020.12.31 |
sqldatetime.minvalue를 datetime으로 변환하는 방법은 무엇입니까? (0) | 2020.12.31 |