17

使用故事板一段时间后，我发现它们非常有用，但是它们确实有一些限制，或者至少是不自然的做事方式。虽然看起来应该为您的应用程序使用单个故事板，但当您获得一个中等大小的应用程序时，这会带来几个问题。

  1. 团队合作变得更加困难，因为 Storyboard 中的冲突可能难以解决（也欢迎任何与此相关的提示）
  2. 故事板本身可能会变得非常混乱和难以管理。

所以我的问题是什么是最佳使用实践？

我考虑过使用混合方法，将逻辑任务拆分为单独的故事板，但这会导致 UX 流程在代码和故事板之间拆分。对我来说，这感觉像是创建可重用操作（例如登录操作等）的最佳方式。

我还应该考虑给 Xibs 一个地方吗？这篇文章对很多问题都有很好的概述，它建议对于只有一个屏幕的场景，应该在这种情况下使用 xibs。Apple 支持从情节提要中实例化未连接的场景，这再次让我感到不寻常，这表明 xibs 将来不会有一席之地，但我可能是错的。

4

2 回答 2

23

你是对的，分解故事板是最好的方法。分解不仅仅是使部分 UI 更可重用。它还使得在团队中使用故事板更易于管理。

最近，我的许多故事板都包含四个或更少的场景。一个人单独构建和维护一个或多个这样的 UI 模块是很容易的。这种做法减少或消除了合并冲突。

如果我确实需要在其他人拥有的情节提要中进行更改，我会先询问所有者他或她是否有任何本地更改。如果是这样，我有时会让所有者为我添加更改。分解仍然需要一些协调，但它远不如完整的应用故事板。自从我开始这个练习以来，我没有遇到任何合并困难。

至于 XIB，我认为我在文章中写的不够多。它们仍然非常有用。它们非常适合单视图控制器。然而，这并不是他们真正闪耀的地方。XIB 有一个故事板可能永远不会有的优势。XIB 最基本的单元是 UIView，而故事板的基本单元是 UIViewController。由于 XIB 可以保存 UIView 的集合，因此它们非常适合直观地创建自定义控件。在 XIB 中，我可以直观地构建一个旋转拨号或 GPS 小部件。然后我可以将这些控件和小部件放入情节提要或其他 XIB 中。这种 XIB 在 iPad 应用程序中更常见，因为它们具有更大的屏幕，能够容纳许多控件和小部件。在情节提要的 UIViewController 中构建 UISwitch 是不自然的。

现在最好的消息。可以在 Interface Builder 中连接故事板，而无需编写任何代码。我计划在 WWDC 之后发布这项技术，因为 Apple 可能会在 iOS 6 中发布类似的功能。但是，既然你问了，我决定现在就发布它。您可以在我的博客和GitHub上找到更多详细信息，而不是重复我对 RBStoryboardLink 工作原理的解释。这将使您的 UIStoryboard 体验更加愉快。

于 2012-06-11T02:19:25.540 回答
1

我发现这篇文章在使用 StoryBoard 时提到了很多问题，作者提出的一件事是在一个 StoryBoard 中使用大量 nib 文件，我同意他不应该这样做，但还有其他问题，例如：

我的根视图控制器已成为许多 segue 的源视图控制器，因此它的 prepareForSegue: 已成为一个愚蠢的大方法，其中连续填充了许多“if (segue.identifier isEqualToString:@”...")”语句

和

可以为情节提要中的视图控制器分配标识符。不幸的是，这个标识符属性没有在 UIViewController 类中公开。这使得在运行时执行视图控制器层次结构的安全自省变得非常困难。如果为视图控制器和 segues 公开标识符，那就太好了。

和...更多其他问题，我认为它确实有道理，我担心现在是否应该使用 StoryBoard？

于 2012-10-09T03:33:07.630 回答