iOS 프로그래밍에서 xib 파일 대신 스토리 보드를 사용하면 어떤 이점이 있습니까?

iOS 프로그래밍에서 xib 파일 대신 스토리 보드를 사용하면 어떤 이점이 있습니까?

---

스토리 보드와 xib 파일 사용 의 주요 차이점 은 무엇입니까?

구체적 으로 스토리 보드 사용의 장단점 은 무엇입니까?

안타깝게도 꽤 많은 조사를했지만 스토리 보드에서 찾을 수있는 것은 스토리 보드가 무엇인지 설명하는 구체적인 정보 대신 스토리 보드를 설정하는 방법을 보여주는 간단한 자습서뿐입니다.

---

스토리 보드는 다음과 같습니다.

• 모든 장면에 대한 컨테이너 (View Controllers, Nav Controllers, TabBar Controllers 등)
• 이러한 장면 간의 연결 및 전환 관리자 (이를 Segues라고 함)
• 서로 다른 컨트롤러가 서로 대화하는 방식을 관리하는 좋은 방법
• 스토리 보드는 떠 다니는 개별 nib 파일에서 절대 얻을 수없는 애플리케이션의 흐름을 완벽하게 보여줍니다.
• 각각 고유 한 nib 파일이있는 여러 컨트롤러가있을 때 발생하는 모든 "혼잡함"을 줄입니다.

저는 한동안 스토리 보드를 사용해 왔으며 유일한 단점은 iOS 4 이하를 타겟팅 할 수 없다는 것입니다. 스토리 보드는 iOS 5 이상을 실행하는 장치에서만 작동합니다. 그 외에는 이점이 많고 단점은 존재하지 않는 IMO입니다.

내가 본 최고의 튜토리얼은 Ray Wenderlich의

또한 Apple Developer 프로그램의 회원이라면 지난 몇 년간 Storyboards (iTunesU)에서 WWDC 세션을 확인하십시오.

또 다른 훌륭한 프로그램 (iTunesU에서도 가능)은 최신 Stanford iOS 애플리케이션 프로그래밍 과정입니다.

---

스토리 보딩의 장점뿐만 아니라 단점도 있습니다. 입력을 요청했기 때문입니다.

• 한 번에 한 명의 참가자 만 SB에서 작업 할 수 있기 때문에 팀에서 SB로 작업하기가 쉽지 않습니다 (파일 하나이기 때문에).

-다음은 사실이 아닙니다 : -SB가 제공하지 않는 작업을 수행해야하는 경우 SB를 프로그래밍 방식으로 생성 된 뷰와 혼합하는 것은 쉽지 않습니다 (글쎄요, 가능합니다).

경험의 법칙은 프로젝트가 더 복잡해질수록 SB를 선택하지 않는 것이 좋습니다.

편집 :-SB의 또 다른 단점 : SB와 관련된 XCode의 모든 성가신 버그를 해결하는 것입니다. 예 : 몇 가지 불일치로 인해 DerivedData 폴더를 자주 플러시해야합니다. 때때로 스토리 보드 파일이나 그에 대한 링크가 손상됩니다. 그러면 문제를 찾는 기쁨을 누릴 수 있습니다. 아이디어를 얻으려면 이 스레드를 살펴보십시오.

편집 2 (2013 년 3 월) : 한편 스토리 보드와 Xcode는 훨씬 더 잘 작동하며 문서와 모범 사례가 널리 퍼져 있습니다. 여전히 약간의 결함이 있더라도 대부분의 프로젝트에서 스토리 보드 작업을 권장 할 수 있다고 생각합니다.

편집 3 (2013 년 9 월) : 이제 SB 코드를 훨씬 쉽게 병합 할 수있는 것처럼 보이기 때문에 SB 팀에서 작업하는 새로운 Xcode 5 형식이 훨씬 더 좋아질 수 있습니다.

또 다른 편집 : 글쎄요, 시간이 있다면 편히 앉아 긴장을 풀고이 주제를 논의하는 이들의 이야기를 들어보세요 (Ray Wenderlich & Co)

2016.1 편집 : 오랫동안 스토리 보드 옹호자로 활동 한 후 지난 몇 달 동안 너무 번거로워서 가능한 한 스토리 보드를 포기하기로 결정했습니다. 그 이유는 애플이 멍청한 기능을 추가하지만 버그와 결함에 대해서는 신경 쓰지 않기 때문입니다. 많은 자동 레이아웃 제약이있는 성능은 (디자인 시간 동안) 정말 나쁘고 오류 발생 가능성이 커졌습니다. 예 : 훨씬 덜 복잡한 스토리 보드는 Xcode에서 프로젝트를 연 직후에 '더티 모드'가되는 경향이 있습니다 (git 상태 참조). 팁 : 초보자는 빠르게 프로토 타입을 만들고 많은 코드 없이도 실행할 수 있으므로 Storyboard를 좋아할 것입니다. 중간 상태에 들어가면 프로젝트에 더 많은 GUI 코드를 추가하게됩니다. 이제 코드와 SB 사이를 오가며 일이 더 나 빠지기 시작합니다.

---

요약

Nibs / .xib 파일과 Storyboard는 모두 Xcode에서 iOS 및 Mac 응용 프로그램 용 사용자 인터페이스를 시각적으로 생성하는 데 사용되는 Interface Builder 파일입니다 (이 질문은 iOS에 태그가 지정되어 있지만 Mac 프로그래밍에도 적용되므로 클래스에 대해 iOS 용어를 사용하겠습니다) .

차이점

펜촉은 단일 UIView. 또한 UIViewControllerFile 's Owner의 클래스를 임의의 하위 클래스로 UIViewController설정하고 뷰 아웃렛을 연결하여 하위 클래스에 연결할 수 있습니다 (Xcode의 맨 오른쪽 창에있는 Connections Inspector를 사용하여 연결하려면 드래그).

스토리 보드는 하나 이상의 사용자 인터페이스를 포함하기위한 것 UIViewController입니다. 단일 스토리 보드에서 전체 사용자 인터페이스를 구축하거나 더 작은 부분으로 분리 할 수 ​​있습니다.

장점

스토리 보드는 항상 .xib 파일 / Nibs (보기 컨트롤러 용) 대신 사용해야합니다. 스토리 보드에는 더 많은 기능이 있으며 Apple에서 적극적으로 개발하고 있습니다.

Nibs를 선호하는 모든 주장은 스토리 보드에 많은 장면이 포함되어있는 동안 개별적으로 사용했다는 사실에 의존합니다. UIViewControllerNibs를 사용하는 것처럼 쉽게 각각에 대해 단일 스토리 보드를 사용할 수 있습니다 (아래 코드 샘플 참조). 자세한 설명과 코드 예제는 계속 읽으십시오.

상세한

Storboard가 Nibs보다 우수한 이유는 무엇입니까?

대답은 기본적으로 Apple이 스토리 보드 사용을 장려하고 더 많은 개발 노력을 기울이는 데 있습니다.

1. 스토리 보드에는 펜촉에없는 확대 / 축소 기능이 있습니다. 진지하게, 작은 노트북에서 더 큰 화면을 위해 디자인 할 때 짜증나는 Nibs에서는 전혀 확대 할 수 없습니다.
2. 펜촉에는 다음과 같은 주요 기능이 없습니다.
   • 에 대한 프로토 타입 및 동적 셀 UITableView( 추가 정보 )
   • 상단 레이아웃 가이드 자산 (주석 참조)
   • 이 목록에 추가 할 내용이 있으면 수정하거나 댓글을 달아주세요.
3. 파일 소유자의 클래스 설정을 망칠 필요가 없습니다.

스토리 보드에 대한 기본 주장은 모든 뷰 컨트롤러를 한곳에두면 병합 충돌, 느린 Xcode, 느린 빌드 시간 및 유지 관리에 대한 일반적인 고통을 초래한다는 것입니다. 따라서 일반적인 조언은 각각에 대해 펜촉을 사용하는 것 UIViewController입니다.

하지만 ... 각각에 대해 스토리 보드를 만들 수 있습니다 UIViewController. 일반적인 관행은 (적어도) 클래스 메서드에서 모든 UIViewController 초기화를 숨기는 것입니다 (다른 클래스는 컨트롤러의 Nib / Storyboard가있는 파일의 이름을 알 필요가 없기 때문입니다). 이러한 메서드를 만드는 데 사용할 수있는 관련 코드 조각을 비교해 보겠습니다. 한 줄의 코드는 둘 사이의 전체적인 차이입니다.

목표 -C

스토리 보드

+ (ViewController *)create
{
    UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"ViewController" bundle:nil];
    return [storyboard instantiateInitialViewController];
}

부리

+ (ViewController *)create
{
    return [super initWithNibName:@"ViewController" bundle:nil];
}

용법

- (void)showMyViewController
{
    ViewController *vc = [ViewController create];
    [self presentViewController:vc animated:YES completion:nil];
}

빠른

스토리 보드

static func create() -> ViewController {
    let storyboard = UIStoryboard(name: "ViewController", bundle: NSBundle.mainBundle())
    return storyboard.instantiateInitialViewController() as! ViewController
}

부리

static func create() -> ViewController {
    return ViewController(nibName: "ViewController", bundle: nil)
}

용법

func showMyViewController() {
    let vc = ViewController.create()
    self.presentViewController(vc, animated: true, completion: nil)
}

인수

Nibs에 대한 모든 일반적인 주장을 다룰 것입니다. 앞서 언급했듯이 대부분은 스토리 보드에 대한 Nibs 인수가 아닌 단일 파일을 선호합니다.

1. 팀 및 병합

인수 : 여러 사람이 변경하는 팀에서 작업하는 경우 뷰 컨트롤러가 많은 스토리 보드가 있으면 병합 충돌이 발생합니다.

응답 : 단일 스토리 보드는 단일 Nib보다 더 이상 병합 충돌을 일으키지 않습니다.

2. 복잡성

인수 : 매우 복잡한 앱은 스토리 보드에 많은 장면이있어로드하는 데 시간이 오래 걸리고 크기 때문에 거의 이해할 수없는 거대한 스토리 보드로 이어집니다.

응답 : 이것은 좋은 점이지만 스토리 보드를 쉽게 작은 부분으로 나눌 수 있습니다. 스토리 보드 참조 는 스토리 보드를 함께 연결하는 데 사용할 수있는 훌륭한 기능처럼 보이지만 Xcode 7 / iOS 9+에서만 사용할 수 있습니다. 또한 스토리 보드보다 개별 펜촉을 선택해야하는 이유도 아닙니다.

3. 재사용 성

인수 : 각 UIViewController하위 클래스 에 대해 Nib을 생성하면 코드를 재사용 할 수 있으므로 스토리 보드의 각 장면에 대한 모든 제약 조건과 출구를 설정할 필요가 없습니다.

응답 : 다시 말하지만, 개별 스토리 보드 대신 개별 펜촉을 선택하는 이유가 아닙니다.

---

몇 달 전 LiDG 회의에서 Storyboard 에 대한 멋진 프레젠테이션 이있었습니다 .

개인적으로 새로운 앱을 사용하는 길이라고 말하고 싶습니다. 특히 매우 복잡한 앱의 경우 약간의 차이가 있지만 대부분의 경우 프로가 단점을 능가합니다.

---

스토리 보드의 추가 이점 :

• 스토리 보드는 테이블보기를 더 잘 지원합니다. 즉, "동적"및 "프로토 타입"셀을 사용할 수 있습니다.
• 스토리 보드를 사용하여 뷰 컨트롤러를 인스턴스화하는 것이 더 쉽습니다. 다음과 같은 작업을 수행 할 수 있습니다. [se lf.storyboard instantiateViewControllerWithIdentifer :]
• 스토리 보드는 뷰 컨트롤러 컨테이너를 지원하므로 자식 뷰 컨트롤러를 그래픽으로 배치 할 수 있습니다.

단점은 다음과 같습니다.

• Storyboards are slow to render in XCode when they contain lots of view controllers

• Autolayout can not be enabled for one view controller in the storyboard.

---

Be careful, if you use Storyboards your app is not backwards compatible with older OS installations.

---

A storyboard is basically a device to make your job as a developer easier. It is complied into a series of nib files, so the performance is pretty much equivalent, but it's great as a developer to be able to look at a quick overview of your entire application flow.

I'm starting to transition to using storyboards on new projects, providing I can convince the client to accept iOS 5 as a minimum version. This is purely because I prefer to do it this way, and it takes me less time to accomplish the same tasks.

---

Your attitude toward Auto Layout may also affect whether you want to use Storyboards. Using xibs you can enabled or disable Auto Layout is on a per .xib basis, allowing for a mix within your application, while Storyboards apply your choice to ALL views they contain.

---

You see the big picture in one second. Having many NIB files, well, you don't see the big picture. Easier to maintain your programs. Easier to understand others programs... among others.

---

Advantages:

1) It's very nice to design interfaces

2) You can use StoryBoard Segues to identify navigation/modal relationships in a cool manner.

3) If your app supports multiple devices, it's a good way to organize different views.

4) Prototyping is another added advantage.

5) Prototype UITableViewCell can save time and it reduce the amount of the code too.

6) you can see all the screens of the app at one place by using StoryBoard.

7) You can easily view the relationship among them

8) if you are working on someone's code you can get the better understanding of the flow of the app.

9) You can setup the user interface for iPhone 4 and iPhone 5 by applying the retina form factor from storyboard, without running the app again and again.

10) Clients can see the prototype of the app before start developing it, here storyboard helps you a lot.

Disadvantages:

1) It is only available in iOS 5+

2) StoryBoardSegues are kind of rigid and you may make use of prepareForSegue many times.

4) Like IB, not very friendly with other display engines and toolkits.

4) Makes it hard to share designs for a single view or set of views - you have to send all or nothing.

5) For storyboard you will need a big screen specially in case of iPad.

6) Difficulty while copying views from other apps to storyboard.

7) Problems in storyboard when multiple developers work on the same project by using git repository

copied from some resource

---

Storyboards have many more problems than benefits. Here's is a list of their problems, copied from iraycd:

• Storyboards fail at runtime, not at compile time: You have a typo in a segue name or connected it wrong in your storyboard? It will blow up at runtime. You use a custom UIViewController subclass that doesn't exist anymore in your storyboard? It will blow up at runtime. If you do such things in code, you will catch them early on, during compile time. Update: My new tool StoryboardLint mostly solves this problem.

• Storyboards get confusing fast: As your project grows, your storyboard gets increasingly more difficult to navigate. Also, if multiple view controllers have multiple segues to multiple other view controllers, your storyboard quickly starts to look like a bowl of spaghetti and you'll find yourself zooming in and out and scrolling all over the place to find the view controller you are looking for and to find out what segue points where. Update: This problem can mostly be solved by splitting your Storyboard up into multiple Storyboards, as described in this article by Pilky and this article by Robert Brown.

• Storyboards make working in a team harder: Because you usually only have one huge storyboard file for your project, having multiple developers regularly making changes to that one file can be a headache: Changes need to be merged and conflicts resolved. When a conflict occurs, it is hard to tell how to resolve it: Xcode generates the storyboard XML file and it was not really designed with the goal in mind that a human would have to read, let alone edit it.

• Storyboards make code reviews hard or nearly impossible: Peer code reviews are a great thing to do on your team. However, when you make changes to a storyboard, it is almost impossible to review these changes with a different developer. All you can pull up is a diff of a huge XML file. Deciphering what really changed and if those changes are correct or if they broke something is really hard.

• Storyboards hinder code reuse: In my iOS projects, I usually create a class that contains all the colors and fonts and margins and insets that I use throughout the app to give it a consistent look and feel: It's a one line change if I have to adjust any of those values for the whole app. If you set such values in the storyboard, you duplicate them and will need to find every single occurrence when you want to change them. Chances are high that you miss one, because there's no search and replace in storyboards.

• Storyboards make you do everything twice: Are you building a universal app that runs both on iPad and on iPhone? When you use storyboards, you will usually have one storyboard for the iPad version and one for the iPhone version. Keeping both in sync requires you to do every UI or app-workflow change in two places. Yay. Update: In iOS 8 and Xcode 6, you can use a single Storyboard for iPhone and iPad.

• Storyboards require constant context switches: I find myself working and navigating much faster in code than in storyboards. When your app uses storyboards, you constantly switch your context: "Oh, I want a tap on this table view cell to load a different view controller. I now have to open up the storyboard, find the right view controller, create a new segue to the other view controller (that I also have to find), give the segue a name, remember that name (I can't use constants or variables in storyboards), switch back to code and hope I don't mistype the name of that segue for my prepareForSegue method. How I wish I could just type those 3 lines of code right here where I am!" No, it's not fun. Switching between code and storyboard (and between keyboard and mouse) gets old fast and slows you down.

• Storyboards are hard to refactor: When you refactor your code, you have to make sure it still matches what your storyboard expects. When you move things around in your storyboard, you will only find out at runtime if it still works with your code. It feels to me as if I have to keep two worlds in sync. It feels brittle and discourages change in my humble opinion.

• Storyboards are not searchable: A project-wide search in Xcode is not really a project-wide search when you use storyboards. They are not included in the search. So when you remove a custom class from your code or rename it, you will have to manually go through the storyboard or look at its raw XML to make sure it is on par with your code changes. No sir, I don't like it. Update: Storyboards are searchable in Xcode 6.

• Storyboards are less flexible: In code, you can basically do anything you want! With storyboards you are limited to a subset of what you can do in code. Especially when you want to do some advanced things with animations and transitions you will find yourself "fighting the storyboard" to get it to work.

• Storyboards don't let you change the type of special view controllers: You want to change a UITableViewController into a UICollectionViewController? Or into a plain UIViewController? Not possible in a Storyboard. You have to delete the old view controller and create a new one and re-connect all the segues. It's much easier to do such a change in code.

• Storyboards add two extra liabilities to your project: (1) The Storyboard Editor tool that generates the storyboard XML and (2) the runtime component that parses the XML and creates UI and controller objects from it. Both parts can have bugs that you can't fix.

• Storyboards don't allow you to add a subview to a UIImageView: Who knows why.

• Storyboards don't allow you to enable Auto Layout for individual View(-Controller)s: By checking/unchecking the Auto Layout option in a Storyboard, the change is applied to ALL controllers in the Storyboard. (Thanks to Sava Mazăre for this point!)

• Storyboards have a higher risk of breaking backwards compatibility: Xcode sometimes changes the Storyboard file format and doesn't guarantee in any way that you will be able to open Storyboard files that you create today a few years or even months from now. (Thanks to thoughtadvances for this point. See the original comment)

• It's McDonald's: To say it in Steve Jobs' words about Microsoft: It's McDonald's (video)!

---

Prior to iOS 7, Storyboards were kind of neat but not a must have. They introduced as many problems as they solved. iOS 7 tilted the balance towards Storyboards.

With iOS 8 and 9 this is not a question anymore: Use storyboards!

The main downside of storyboard is that you're completely dependent on XCode, and you might end up spending hours spinning your wheels on XCode bugs. But XCode has gotten a lot better, and the advantages with Storyboards are now too numerous to ignore. Table view cell prototypes, Size classes, auto layout support and so on.

Some Tips:

• Think of each Storyboard as a container for view controllers that belong together. Don't think of it as a grand layout of your entire application.
• You might need more than one Storyboard
• Segues are really only useful for the most trivial use cases - they're great for that. But in a real world app many transitions will happen from within code. And that's OK.
• Write a category to programmatically instantiate view controllers from the storyboard(s) so all you have to do is let vc=SomeViewController.create(), where the method handles all the details (pull story board, pull view controller out of story board etc).

참고URL : https://stackoverflow.com/questions/9083759/what-are-the-benefits-of-using-storyboards-instead-of-xib-files-in-ios-programmi