这些仍然是在开发iOS 6应用程序时使用Storyboard的有效否定吗？

Question

使用故事板代替传统的.xib策略是我仍在努力解决的问题,因为有些犹豫不决,采用的东西如此多,并没有真正理解它在做什么,以及我真的控制了什么失去.

BNR iOS编程手册突出了使用Storyboard的几个"缺点".我在下面列出了它们,我的问题是: 这些底片在iOS 6中仍然有效吗？

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

我正在寻找那些正在构建的人的答案,最好是部署真正的iOS应用程序,并且自己也在努力解决"storyboards vs .xib"问题.

谢谢

Answer 1

我认为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,并报告您自己的经验.祝好运!

Answer 2

我普遍同意jbbenni.我在你的观点中看到的唯一"有效"批评是关于"故事板总能创建一个新实例".基本上,这意味着虽然您可以连接一个按钮来推动堆栈上的视图控制器,但是如果没有额外的代码,您就无法连接按钮以弹出堆栈.这已在Xcode 4.5中使用"退出segues"解决,这使您可以指示要回弹到先前的控制器而不是创建新实例.

许多抱怨的故事板的另一个限制是你无法在故事板中嵌入子视图控制器.Xcode 4.5也解决了这个问题.

故事板是iOS开发的重要一步.诸如"它使合并变得困难"之类的投诉是没有根据的; 故事板比其他代码更难合并; 你只需要花时间去实际读取差异,而不是将它作为"不是Obj-C;无法读取".

自推出以来,我已经在团队环境中成功使用了故事板.不要让不知情的人吓跑你.他们很棒.