xcode - 这些反对在开发 iOS 6 应用程序时使用 Storyboard 的负面因素是否仍然有效？

Question

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

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

1. Storyboard很难在团队中使用
2. Storyboard搞砸了版本控制
3. Storyboard扰乱了编程流程
4. Storyboard为了易于使用而牺牲了灵 active 和控制性
5. Storyboard总是创建新的 View Controller 实例

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

谢谢

Answer 1

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

我在一个重要的应用程序中使用 Storyboard，我发现它们确实能提高生产力。我鼓励您尝试一下，看看您是否不同意。

对问题列表的一些评论:

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

对我来说，真正关心的是:

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

SB 在布局过程中的便利性以及消除大量使 VC 对象困惑的样板代码是一个巨大的好处。 (我消除的每一行代码都是我不能搞砸的行，也是不能掩盖剩下的真实代码的行。)

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