Khi nào nên sử dụng Storyboard và khi nào nên sử dụng XIB

Có hướng dẫn nào về thời điểm sử dụng bảng phân cảnh trong dự án iOS và khi nào nên sử dụng XIB không? những ưu và nhược điểm của mỗi loại và những tình huống nào mà mỗi bộ đồ phù hợp?

Gần như tôi có thể nói rằng sẽ không sạch khi sử dụng các phân đoạn bảng phân cảnh khi bạn có các bộ điều khiển xem được đẩy bởi các thành phần UI động (Giống như các chân bản đồ).

Tôi đã sử dụng XIB rộng rãi và hoàn thành hai dự án bằng Storyboards. Bài học của tôi là:

• Bảng phân cảnh rất phù hợp cho các ứng dụng có số lượng màn hình từ nhỏ đến trung bình và điều hướng tương đối đơn giản giữa các chế độ xem.
• Nếu bạn có nhiều chế độ xem và nhiều điều hướng chéo giữa chúng, chế độ xem Storyboard sẽ gây nhầm lẫn và quá nhiều công việc để giữ sạch sẽ.
• Đối với một dự án lớn có nhiều nhà phát triển, tôi sẽ không sử dụng Storyboards vì bạn có một tệp duy nhất cho UI của mình và không thể dễ dàng hoạt động song song.
• Có thể đáng để các ứng dụng lớn chia thành nhiều tệp bảng phân cảnh nhưng tôi chưa thử. Câu trả lời này cho thấy làm thế nào để phân biệt giữa các bảng phân cảnh.
• Bạn vẫn cần XIB: Trong cả hai dự án Storyboard của tôi, tôi đã phải sử dụng XIB cho các ô bảng tùy chỉnh.

Tôi nghĩ Storyboards là một bước đi đúng hướng để triển khai UI và hy vọng Apple sẽ mở rộng chúng trong các phiên bản iOS trong tương lai. Tuy nhiên, họ cần giải quyết vấn đề "một tập tin", nếu không họ sẽ không hấp dẫn đối với các dự án lớn hơn.

Nếu tôi bắt đầu một ứng dụng kích thước nhỏ và chỉ có khả năng tương thích với iOS5, tôi sẽ sử dụng Storyboards. Đối với tất cả các trường hợp khác, tôi dính vào XIBs.

Cập nhật 1/12/2016 : Đó là năm 2016 và tôi vẫn thích đặt UI của mình bằng mã chứ không phải trong Storyboards. Điều đó đang được nói, Storyboards đã đi một chặng đường dài. Tôi đã xóa tất cả các điểm khỏi bài đăng này mà đơn giản là không áp dụng nữa vào năm 2016.

Cập nhật 24/24/2015 : Điều thú vị là Apple thậm chí không sử dụng Storyboards trong ResearchKit có nguồn mở gần đây của họ như Peter Steinberger đã nhận thấy (dưới tiêu đề "Trình tạo giao diện").

Cập nhật 6/10/2014 : Theo dự kiến, Apple tiếp tục cải thiện Storyboards và Xcode. Một số điểm áp dụng cho iOS 7 trở xuống không áp dụng cho iOS 8 nữa (và hiện được đánh dấu như vậy). Vì vậy, trong khi Storyboards vốn vẫn còn thiếu sót, tôi sửa lại lời khuyên của mình từ không sử dụng sang sử dụng có chọn lọc ở nơi có ý nghĩa .

Ngay cả khi iOS 9 không hoạt động, tôi sẽ khuyên bạn chống lạithận trọng khi quyết định có nên sử dụng Storyboards không. Đây là lý do của tôi:

• Bảng phân cảnh thất bại trong thời gian chạy, không phải lúc biên dịch : Bạn có một lỗi đánh máy trong một tên riêng biệt hoặc kết nối nó sai trong bảng phân cảnh của bạn? Nó sẽ nổ tung khi chạy. Bạn sử dụng một lớp con UIViewControll tùy chỉnh không còn tồn tại trong bảng phân cảnh của bạn? Nó sẽ nổ tung khi chạy. Nếu bạn làm những điều như vậy trong mã, bạn sẽ bắt chúng sớm, trong thời gian biên dịch. Cập nhật : Công cụ mới StoryboardLint của tôi chủ yếu giải quyết vấn đề này.

• Bảng phân cảnh trở nên khó hiểu nhanh : Khi dự án của bạn phát triển, bảng phân cảnh của bạn ngày càng khó điều hướng hơn. Ngoài ra, nếu nhiều bộ điều khiển chế độ xem có nhiều phân biệt cho nhiều bộ điều khiển chế độ xem khác, bảng phân cảnh của bạn sẽ nhanh chóng trông giống như một bát mì spaghetti và bạn sẽ thấy mình phóng to và thu nhỏ và cuộn khắp nơi để tìm bộ điều khiển chế độ xem mà bạn đang tìm kiếm cho và để tìm ra những điểm segue ở đâu. Cập nhật : Vấn đề này chủ yếu có thể được giải quyết bằng cách chia Bảng phân cảnh của bạn thành nhiều Bảng phân cảnh, như được mô tả trong bài viết này của Pilky và bài viết này của Robert Brown .

• Bảng phân cảnh làm việc trong một nhóm khó hơn : Bởi vì bạn thường chỉ có một tệp bảng phân cảnh lớn cho dự án của mình, việc nhiều nhà phát triển thường xuyên thay đổi một tệp đó có thể là vấn đề đau đầu: Các thay đổi cần được hợp nhất và giải quyết xung đột. Khi xảy ra xung đột, thật khó để nói cách giải quyết: Xcode tạo tệp XML bảng phân cảnh và nó không thực sự được thiết kế với mục tiêu là con người sẽ phải đọc, chứ đừng nói đến việc chỉnh sửa nó.

• Bảng phân cảnh làm cho các đánh giá mã khó hoặc gần như không thể : Đánh giá mã ngang hàng là một điều tuyệt vời để làm cho nhóm của bạn. Tuy nhiên, khi bạn thực hiện thay đổi cho bảng phân cảnh, gần như không thể xem lại những thay đổi này với một nhà phát triển khác. Tất cả những gì bạn có thể kéo lên là một khác biệt của một tệp XML lớn. Giải mã những gì thực sự thay đổi và nếu những thay đổi đó là chính xác hoặc nếu chúng phá vỡ một cái gì đó thực sự khó khăn.

• Bảng phân cảnh cản trở việc tái sử dụng mã : Trong các dự án iOS của tôi, tôi thường tạo một lớp chứa tất cả các màu và phông chữ và lề và các phần tử mà tôi sử dụng trong suốt ứng dụng để mang lại cho nó một giao diện nhất quán: Tôi phải thay đổi một dòng điều chỉnh bất kỳ giá trị nào cho toàn bộ ứng dụng. Nếu bạn đặt các giá trị như vậy trong bảng phân cảnh, bạn sẽ nhân đôi chúng và sẽ cần tìm mọi lần xuất hiện khi bạn muốn thay đổi chúng. Rất có thể là bạn bỏ lỡ một thứ, bởi vì không có tìm kiếm và thay thế trong bảng phân cảnh.

• Bảng phân cảnh yêu cầu chuyển đổi ngữ cảnh liên tục : Tôi thấy mình làm việc và điều hướng mã nhanh hơn nhiều so với bảng phân cảnh. Khi ứng dụng của bạn sử dụng bảng phân cảnh, bạn liên tục chuyển ngữ cảnh: "Ồ, tôi muốn nhấn vào ô xem bảng này để tải trình điều khiển chế độ xem khác. Bây giờ tôi phải mở bảng phân cảnh, tìm trình điều khiển chế độ xem phù hợp, tạo một phân đoạn mới đến bộ điều khiển khung nhìn khác (mà tôi cũng phải tìm), đặt tên riêng cho tên đó, hãy nhớ tên đó (tôi không thể sử dụng hằng hoặc biến trong bảng phân cảnh), chuyển lại mã và hy vọng tôi không gõ nhầm tên của sự khác biệt đó đối với phương thức chuẩn bị của tôi. Tôi ước gì tôi có thể gõ 3 dòng mã này ngay tại nơi tôi đang ở! " Không, nó không vui. Chuyển đổi giữa mã và bảng phân cảnh (và giữa bàn phím và chuột) sẽ nhanh cũ và làm bạn chậm lại.

• Bảng phân cảnh rất khó để cấu trúc lại : Khi bạn cấu trúc lại mã của mình, bạn phải chắc chắn rằng nó vẫn khớp với những gì bảng phân cảnh của bạn mong đợi. Khi bạn di chuyển mọi thứ xung quanh trong bảng phân cảnh của mình, bạn sẽ chỉ phát hiện ra trong thời gian chạy nếu nó vẫn hoạt động với mã của bạn. Tôi cảm thấy như thể tôi phải giữ hai thế giới đồng bộ. Nó cảm thấy dễ vỡ và không khuyến khích sự thay đổi trong quan điểm khiêm tốn của tôi.

• Bảng phân cảnh kém linh hoạt : Về mã, về cơ bản bạn có thể làm bất cứ điều gì bạn muốn! Với bảng phân cảnh, bạn bị giới hạn trong một tập hợp con những gì bạn có thể làm trong mã. Đặc biệt là khi bạn muốn thực hiện một số điều tiên tiến với hình ảnh động và chuyển tiếp, bạn sẽ thấy mình "chiến đấu với bảng phân cảnh" để làm cho nó hoạt động.

• Bảng phân cảnh không cho phép bạn thay đổi loại bộ điều khiển chế độ xem đặc biệt : Bạn muốn thay đổi UITableViewControllerthành một UICollectionViewController? Hay vào một đồng bằng UIViewController? Không thể có trong Storyboard. Bạn phải xóa bộ điều khiển xem cũ và tạo một bộ điều khiển mới và kết nối lại tất cả các phân biệt. Việc thay đổi mã như vậy dễ dàng hơn nhiều.

• Bảng phân cảnh bổ sung thêm hai khoản nợ cho dự án của bạn : (1) Công cụ Trình biên tập Storyboard tạo ra bảng phân cảnh XML và (2) thành phần thời gian chạy phân tích cú pháp XML và tạo các đối tượng UI và trình điều khiển từ nó. Cả hai phần có thể có lỗi mà bạn không thể sửa.

• Bảng phân cảnh không cho phép bạn thêm một khung nhìn vàoUIImageView : Ai biết tại sao.

• Bảng phân cảnh không cho phép bạn bật Bố cục tự động cho từng Chế độ xem (-Contoder) riêng lẻ : Bằng cách kiểm tra / bỏ chọn tùy chọn Bố cục tự động trong Bảng phân cảnh, thay đổi được áp dụng cho TẤT CẢ các bộ điều khiển trong Bảng phân cảnh. (Cảm ơn Sava Mazăre về điểm này!)

• Bảng phân cảnh có nguy cơ phá vỡ tính tương thích ngược cao hơn : Đôi khi Xcode thay đổi định dạng tệp Storyboard và không đảm bảo theo bất kỳ cách nào bạn có thể mở các tệp Storyboard mà bạn tạo ngày hôm nay vài năm hoặc thậm chí vài tháng kể từ bây giờ. (Cảm ơn những suy nghĩ cho điểm này. Xem nhận xét ban đầu )

• Bảng phân cảnh có thể làm cho mã của bạn phức tạp hơn : initVí dụ : khi bạn tạo bộ điều khiển xem của mình bằng mã, bạn có thể tạo các phương thức tùy chỉnh initWithCustomer:. Bằng cách đó, bạn có thể làm cho customerbên trong bộ điều khiển khung nhìn của bạn không thay đổi và đảm bảo rằng bộ điều khiển khung nhìn này không thể được tạo mà không có customerđối tượng. Điều này là không thể khi sử dụng Storyboards. Bạn sẽ phải đợi prepareForSegue:sender:phương thức được gọi và sau đó bạn sẽ phải đặt thuộc customertính trên trình điều khiển chế độ xem của mình, điều đó có nghĩa là bạn phải làm cho thuộc tính này có thể thay đổi và bạn sẽ phải cho phép trình điều khiển xem được tạo mà không có customerđối tượng . Theo kinh nghiệm của tôi, điều này có thể làm phức tạp mã của bạn rất nhiều và khiến cho việc suy luận về dòng chảy của ứng dụng trở nên khó khăn hơn. Cập nhật ngày 16/9/2016: Chris Dzombak đã viết một bài viết tuyệt vời về vấn đề này .

• Đó là McDonald : Nói theo lời của Steve Jobs về Microsoft: Đó là McDonald (video) !

Đây là những lý do của tôi tại sao tôi thực sự không thích làm việc với bảng phân cảnh. Một số trong những lý do này cũng áp dụng cho XIB. Trong các dự án dựa trên bảng phân cảnh mà tôi đã làm việc, chúng đã tiêu tốn của tôi nhiều thời gian hơn so với chúng đã tiết kiệm và chúng khiến mọi thứ trở nên phức tạp hơn thay vì dễ dàng hơn.

Khi tôi tạo giao diện người dùng và ứng dụng trong mã, tôi sẽ kiểm soát nhiều hơn những gì đang diễn ra, dễ gỡ lỗi hơn, dễ dàng phát hiện ra lỗi sớm hơn, dễ dàng giải thích các thay đổi của tôi cho các nhà phát triển khác và nó dễ dàng hơn hỗ trợ iPhone và iPad dễ dàng hơn.

Tuy nhiên, tôi đồng ý rằng việc đưa ra tất cả UI của bạn trong mã có thể không phải là giải pháp một kích cỡ phù hợp cho tất cả các dự án. Nếu giao diện người dùng iPad của bạn khác rất nhiều so với giao diện người dùng iPhone của bạn ở một số nơi nhất định, có thể có ý nghĩa khi tạo XIB cho chỉ những khu vực đó.

Rất nhiều vấn đề được nêu ở trên có thể được Apple khắc phục và tôi hy vọng đó là những gì họ sẽ làm.

Chỉ hai xu của tôi.

Cập nhật : Trong Xcode 5, Apple đã loại bỏ tùy chọn tạo dự án mà không cần Storyboard. Tôi đã viết một tập lệnh nhỏ chuyển các mẫu của Xcode 4 (với tùy chọn từ chối Storyboard) sang Xcode 5: https://github.com/jfahrenkrug/Xcode4tem mẫu

Bảng phân cảnh được tạo ra để giúp các nhà phát triển hình dung ứng dụng của họ và dòng chảy của ứng dụng. Nó rất giống như có một loạt xib nhưng trong một tệp duy nhất.

Có một câu hỏi tương tự như thế này Sự khác biệt giữa tệp .xib và .storyboard là gì? .

Bạn cũng có thể tạo các chuyển tiếp tùy chỉnh thông qua mã sẽ thay đổi linh hoạt nếu cần, giống như bạn có thể làm với .xibs.

PROS:

• Bạn có thể mô phỏng dòng ứng dụng mà không cần viết nhiều, nếu có mã.
• Dễ dàng hơn nhiều để xem chuyển tiếp giữa các màn hình và luồng ứng dụng của bạn.
• Cũng có thể sử dụng .xibs nếu cần với bảng phân cảnh.

Nhược điểm:

• Chỉ hoạt động với iOS 5+. Không hoạt động với iOS4.
• Có thể bị lộn xộn một cách dễ dàng nếu bạn có một ứng dụng rất chuyên sâu.

Thực sự không có đúng / sai khi sử dụng cái này hay cái kia, đó chỉ là vấn đề ưu tiên và phiên bản iOS nào bạn muốn sử dụng.

Tôi sẽ chỉ nêu 4 lý do đơn giản tại sao bạn nên sử dụng bảng phân cảnh, đặc biệt là trong môi trường năng suất, nơi bạn phải làm việc trong một nhóm chủ sở hữu sản phẩm, quản lý sản phẩm, nhà thiết kế UX, v.v.

1. Apple đã cải thiện TUYỆT VỜI khi làm việc với Storyboards. Và họ khuyến khích bạn làm việc với họ. Điều đó có nghĩa là họ sẽ không phá vỡ các dự án hiện tại của bạn bằng các bản cập nhật, họ sẽ đảm bảo rằng bảng phân cảnh là bằng chứng trong tương lai cho các phiên bản XCode / iOS mới hơn.
2. Kết quả rõ ràng hơn trong thời gian ít hơn cho chủ sở hữu và người quản lý sản phẩm, ngay cả trong giai đoạn tạo. Bạn thậm chí có thể sử dụng chính bảng phân cảnh như một sơ đồ dòng màn hình và thảo luận về nó trong các cuộc họp.
3. Ngay cả sau khi một ứng dụng được hoàn thành (và đó thường là nơi vòng đời của nó bắt đầu) - trong tương lai, nó sẽ nhanh hơn và dễ dàng hơn để áp dụng các điều chỉnh nhỏ . Và những điều này rất có thể thay đổi nhiều khía cạnh của bố cục của bạn cùng một lúc, mà bạn có thể muốn thấy theo cách WYSIWYG. Giải pháp thay thế sẽ là viết tay thay đổi giao diện người dùng trong mã và chuyển đổi qua lại giữa IDE và trình giả lập để kiểm tra, mỗi lần chờ biên dịch & xây dựng.
4. Những người không phải là nhà phát triển có thể được dạy để thiết lập bố cục trong bảng phân cảnh và tạo các móc nối cần thiết cho nhà phát triển (IBOutlets và IBActions). Đó là một điểm cộng rất lớn bởi vì nó cho phép các nhà phát triển tập trung vào logic và các nhà thiết kế UX áp dụng các thay đổi của họ theo cách trực quan, mà không phải viết bất kỳ mã nào cả.

Tôi sẽ không viết lên bất kỳ TIÊU DÙNG nào, vì Julian đã liệt kê tất cả những câu hỏi khả thi trong câu trả lời của anh ấy. Và hầu hết trong số chúng chắc chắn là không khả thi, đặc biệt là với các cải tiến lớn của XCode6.

Tôi không nghĩ rằng có một câu trả lời đúng cho câu hỏi của bạn, đó chỉ là vấn đề kinh nghiệm cá nhân và những gì bạn cảm thấy khó hiểu hơn.

Theo tôi, Storyboards là một điều tuyệt vời. Đó là sự thật, thật khó để tìm ra lý do tại sao ứng dụng của bạn bị lỗi nghiêm trọng khi chạy, nhưng sau một thời gian và trải nghiệm bạn sẽ nhận ra nó luôn liên quan đến một số IBOutlet bị thiếu ở đâu đó và bạn sẽ dễ dàng khắc phục nó.

Vấn đề thực sự duy nhất là làm việc trong nhóm dưới sự kiểm soát phiên bản với bảng phân cảnh, trong giai đoạn đầu phát triển, nó có thể là một mớ hỗn độn thực sự. Nhưng sau giai đoạn đầu tiên đó, các cập nhật giao diện người dùng thay đổi hoàn toàn bảng phân cảnh là rất hiếm và trong hầu hết các trường hợp, bạn kết thúc bằng xung đột ở phần cuối của xml, là các tham chiếu riêng biệt thường tự động kết hợp khi bạn mở lại bảng phân cảnh . Trong công việc nhóm của chúng tôi, chúng tôi thích giải quyết vấn đề này thay vì các bộ điều khiển chế độ xem nặng với hàng tấn mã xem.

Tôi đã đọc nhiều bình luận tự động bố trí. Với XCode5, nó đã thực sự được cải thiện, nó thực sự tốt ngay cả đối với bố cục tự động. Trong một số trường hợp, bạn sẽ phải làm một cái gì đó bằng mã, nhưng bạn có thể chỉ cần đưa ra các ràng buộc bạn cần chỉnh sửa và tại thời điểm đó, hãy làm những gì bạn cần trong mã của mình. Thậm chí làm động chúng.

Tôi cũng nghĩ rằng hầu hết những người không thích bảng phân cảnh đã không hoàn toàn cố gắng hiểu sức mạnh của một phân biệt thủ công tùy chỉnh, nơi bạn hoàn toàn có thể tùy chỉnh (trong một tệp) theo cách bạn chuyển từ cách này sang cách khác và cả (với một số thủ thuật) thậm chí sử dụng lại bộ điều khiển xem được tải trước đó bằng cách cập nhật nội dung xem thay vì tải lại toàn bộ nội dung. Cuối cùng, bạn thực sự có thể làm những điều tương tự như trong mã, nhưng tôi nghĩ rằng bạn có sự phân tách mối quan tâm tốt hơn với bảng phân cảnh, nhưng tôi đồng ý rằng trong nhiều thứ họ thiếu các tính năng (phông chữ, hình ảnh làm nền màu, ecc ... ).

Tôi không sử dụng StoryBoard hoặc XIB trong bất kỳ ứng dụng nào của mình .. nhưng tạo mọi thứ theo chương trình.

Lợi ích:

Bạn có thể tạo bất kỳ loại UI hoặc hình động chuyển tiếp phức tạp nào cho UIView.

Hỗ trợ tất cả các phiên bản iOS. Không cần phải lo lắng về <iOS 5.

* Ứng dụng của bạn sẽ hỗ trợ tất cả các thiết bị iPhone / iPod / iPad trong mã của bạn.

Bạn luôn được cập nhật khi bạn biết mã sẽ luôn hoạt động.

* Sẽ hoạt động trên mọi thiết bị (mới) được khởi chạy - Không cần thay đổi mã.

Mọi thứ tùy thuộc vào bạn. Tại một số nơi bạn muốn thay đổi một cái gì đó - Không cần phải nhìn vào bảng phân cảnh hoặc xib. Chỉ cần tìm kiếm nó trong lớp học cụ thể.

Cuối cùng nhưng không phải là danh sách - Bạn sẽ không bao giờ quên điều đó, làm thế nào để quản lý mọi thứ theo chương trình. Đây là điều tốt nhất khi bạn biết một điều khiển rất sâu sắc sau đó bất cứ ai.

_{Tôi chưa bao giờ tìm thấy vấn đề bằng cách không sử dụng SB hoặc XIB vì tôi tốt với điều này.}

_{* nếu bạn đã đặt khung đối tượng của UIKit theo kích thước màn hình.}

_{Tái bút Nếu bạn vẫn chưa làm điều này - bạn có thể gặp khó khăn (hoặc có thể cảm thấy nhàm chán) nhưng một khi bạn đã quen với điều này - nó thực sự là một viên kẹo dành cho bạn.}

Nếu bạn chuẩn bị quan tâm đến hiệu suất của Storyboard, hãy xem WWDC 2015 Phiên 407

Xây dựng thời gian

Khi trình xây dựng giao diện đang biên dịch bảng phân cảnh, nó sẽ thực hiện hai việc trước tiên, nó sẽ cố gắng tối đa hóa hiệu suất của ứng dụng của bạn và thứ hai là nó cũng giảm thiểu số lượng tệp nib được tạo.

Nếu tôi có trình điều khiển chế độ xem với chế độ xem và một loạt các chế độ xem phụ, trình tạo giao diện, thời gian xây dựng sẽ tạo tệp nib cho trình điều khiển chế độ xem và tạo tệp nib cho chế độ xem.

Bằng cách có các tệp nib riêng cho cả trình điều khiển khung nhìn và khung nhìn, điều này có nghĩa là hệ thống phân cấp khung nhìn có thể được tải theo yêu cầu.

Thời gian chạy

Khi bạn phân bổ một cá thể bảng phân cảnh bằng cách sử dụng bảng phân cảnh UI, API, ban đầu, tất cả những gì bạn đang phân bổ bộ nhớ cho chính bản thân bảng phân cảnh UI.

Không có bộ điều khiển xem chưa có lượt xem nào.

Khi bạn khởi tạo trình điều khiển chế độ xem ban đầu, nó sẽ tải ngòi cho trình điều khiển chế độ xem ban đầu đó, nhưng, một lần nữa, không có cấu trúc phân cấp chế độ xem nào được tải cho đến khi có người thực sự yêu cầu.

Tôi đã làm việc trong một dự án có quy mô hợp lý (> 20 cảnh theo cách nói theo cốt truyện), và đã gặp nhiều hạn chế và phải liên tục đi đến tài liệu và tìm kiếm google để làm việc.

1. UI là tất cả trong một tập tin. Ngay cả khi bạn tạo nhiều bảng phân cảnh, bạn vẫn có nhiều cảnh / màn hình trong mỗi bảng phân cảnh. Đây là một vấn đề trong các đội trung bình lớn.

2. Thứ hai, chúng không chơi tốt với Bộ điều khiển Container tùy chỉnh nhúng các bộ điều khiển bộ chứa khác, v.v. Chúng tôi đang sử dụng MFSlideMothy trong một ứng dụng Tab và cảnh có một bảng. Điều này là gần như không thể làm với một bảng phân cảnh. Trải qua nhiều ngày, tôi đã dùng đến cách thực hiện XIB khi có sự kiểm soát hoàn toàn.

3. IDE không cho phép chọn các điều khiển ở trạng thái thu nhỏ. Vì vậy, trong một dự án lớn, thu nhỏ chủ yếu là để có được chế độ xem cao và không có gì hơn.

Tôi sẽ sử dụng bảng phân cảnh cho các ứng dụng nhỏ hơn với quy mô nhóm nhỏ và sử dụng phương pháp XIB cho các nhóm / dự án cỡ trung bình.

Nếu bạn muốn sử dụng lại một số UI trong nhiều bộ điều khiển xem thì bạn nên sử dụng XIB