12

使用故事板代替传统的 .xib 策略是我仍在努力解决的问题，因为在没有真正了解它在做什么以及我真正控制什么的情况下，我对采用在幕后做这么多事情的东西有些犹豫输。

BNR iOS Programming Book 强调了使用 Storyboard 的几个“缺点”。我在下面列出了它们，我的问题是： 这些负面因素在 iOS 6 中仍然有效吗？

  1. 故事板很难在团队中使用
  2. 故事板搞砸了版本控制
  3. 故事板打乱了编程流程
  4. 故事板为了易用性而牺牲了灵活性和控制力
  5. 故事板总是创建新的视图控制器实例

我正在寻找那些真正在构建，最好是部署真正的 iOS 应用程序并且自己在“storyboards vs .xib”问题上苦苦挣扎的人的答案。

谢谢

4

2 回答 2

11

我不认为 iOS 6 解决了这些情况。更重要的是，xcode 4.5 没有修复它们，甚至没有尝试这样做。列出的问题似乎反映了观点或风格偏好，也许还有一些错误信息。这些不是可以在代码中修复的东西。

我正在将情节提要用于一个重要的应用程序，我发现它们是一个真正的生产力福音。我鼓励您尝试他们，看看您是否不同意。

关于问题列表的一些评论：

  1. 我不知道团队和 SB 有任何问题，但如果 2 是真的（事实并非如此），那就可以解释这种担忧。我认为这是基于2的误解。
  2. 不对。我虔诚地使用 Git，并且经常提交。没问题。在提交期间，SB 以其源代码形式 (XML) 显示。差异完美地工作，实际上提供了一些关于如何实现 SB 的见解。这减少了神秘的“幕后”行为的感觉，这成为熟悉的问题。
  3. 不同意。他们不会破坏流程，他们提供不同的流程 - 这是他们获得力量的地方。许多程序员在 MVC 规则强加的分离中发现了价值。SB 引入了 UI 元素放置和支持代码之间的分离。这是一个自然的拆分，并消除了大量无意识的代码（消除了拼写错误的机会，并“整理”了剩余的真实代码）。
  4. 部分同意 - 它们肯定会提高易用性。但我根本找不到任何牺牲。即使在使用 SB 时，如果需要，您也可以随时恢复为对任何对象进行手动编码。没有牺牲灵活性或控制力。
  5. 不知道这意味着什么，以及为什么它可能是一个问题。当然，我们会为不同的场景创建不同的 VC——这很自然。但是在 SB 中重用 VC 类当然是可能的。此项可能是对如何为 SB 对象设置类的误解。这一步很容易忘记，有时会让初学者感到困惑。但是改正是微不足道的，很快设置类就成了一种习惯。

对我来说，真正的担忧是：

  1. 使用 SB 需要大量的屏幕空间用于开发。在小型显示器上使用 SB 可能会令人沮丧。
  2. 具有许多场景的高度复杂的 UI 应拆分为多个 SB。完全支持多个 SB，但很容易失败。（这就像重构一个变得太大的方法。通常我注意到我需要在某些东西已经变得混乱之后重构代码。）

SB 在布局过程中的便利性以及消除大量使 VC 对象混乱的样板代码是一个巨大的好处。（我删除的每一行代码都是我无法搞砸的行，也是无法掩盖剩下的真实代码的行。）

简而言之，我无法想象没有SB的生活。是的，这是一个变化。但我没有发现任何真正严重的缺点。尤其重要的是要记住，即使使用 SB，所有非 SB 编码技术仍然有效。试一试SB，并报告您自己的经验。祝你好运！

于 2012-09-29T13:25:06.250 回答
7

我一般同意jbbenni。我在您的观点中看到的唯一“有效”批评是关于“故事板总是创建一个新实例”。基本上，这意味着尽管您可以连接一个按钮来将视图控制器推送到堆栈上，但如果没有额外的代码，您无法连接一个按钮来弹出堆栈。这已经在 Xcode 4.5 中通过“exit segues”解决了，它让你表明你想要弹回之前的控制器而不是创建一个新的实例。

许多人抱怨的故事板的另一个限制是您不能在故事板本身中嵌入子视图控制器。Xcode 4.5 中也解决了这个问题。

故事板是 iOS 开发向前迈出的重要一步。诸如“合并困难”之类的抱怨是没有根据的；故事板并不比其他代码更难合并；您只需要花时间实际阅读差异，而不是将其掩饰为“不是 Obj-C；无法阅读”。

自从引入故事板以来，我已经在团队环境中成功使用了故事板。不要让不知情的人吓跑你。他们真棒。

于 2012-09-29T14:46:52.840 回答