xcode – 在开发iOS 6应用程序时,这些仍然是有效的反对使用故事板吗？

概述使用故事板代替传统的.xib策略是我仍然在摔跤的事情,因为对于采用不太了解它的功能有什么犹豫,而没有真正了解它正在做什么,以及我真正的控制失去. BNR iOS编程手册强调了使用故事板的几个“缺点”.我在下面列出了它,我的问题是：这些否定是否仍然适用于iOS 6？ 故事板很难与团队合作 故事板拧紧版本控制 故事板破坏编程流程 故事板牺牲灵活性和易于使用的控制 故事板总是创建新的视图控制器实例 我正 使用故事板代替传统的.xib策略是我仍然在摔跤的事情,因为对于采用不太了解它的功能有什么犹豫,而没有真正了解它正在做什么,以及我真正的控制失去.

BNR iOS编程手册强调了使用故事板的几个“缺点”.我在下面列出了它,我的问题是：这些否定是否仍然适用于iOS 6？

故事板很难与团队合作
故事板拧紧版本控制
故事板破坏编程流程
故事板牺牲灵活性和易于使用的控制
故事板总是创建新的视图控制器实例

我正在寻找正在建设的家伙的答案,最好部署真正的iOS应用程序,并且与“storyboards vs .xib”一样的东西本身.

谢谢

解决方法 我不认为iOS 6修复了这些情况.更重要的是,xcode 4.5并不能解决这个问题,甚至试图这样做.列出的问题似乎反映了意见或风格偏好,也许是一些错误的信息.这些不是可以在代码中修复的那种东西.

我正在使用故事板为一个实质的应用程序,我发现他们是一个真正的生产力福音.我鼓励你尝试看看你是否不同意.

关于问题列表的几个意见：

>我没有意识到队和SB的任何问题,但如果2是真的
(这不是),这将解释这个问题.我认为这是一个
基于2的误解
>不真实我使用Git宗教,并经常犯.没问题在提交期间,SB以其源代码形式(XML)显示.差异工作完美,实际上提供了一些洞察如何实现SB.这减少了神秘的“封面”行为的感觉,这是一个不熟悉的问题.
>不同意他们不会扰乱流量,它们提供不同的流程 – 这是他们获得权力的地方.许多程序员在MVC学科的分离中找到价值. SB介绍了UI元素放置和支持代码之间的分离.这是一个自然的分裂,并消除了一堆无意识的代码(这消除了打字错误的机会,并且“去除了”遗留下来的真实代码).
>部分同意 – 它们肯定会提高易用性.但我根本找不到任何牺牲品.即使使用SBs,如果需要,您也可以随时恢复对任何对象的编码.没有任何灵活性或控制的牺牲.
>不知道这是什么意思,为什么这可能是一个问题.当然,我们为不同的场景创建不同的风投 – 这很自然.但是肯定可以在SB中重用VC类.该项目可能是一个关于如何设置SB对象的类的误解.很容易忘记做这个步骤,有时会让初学者感到困惑.但是纠正这个问题是微不足道的.

对我而言,真正的担忧是：

>使用SBs需要大量的屏幕房地产开发.在小显示屏上使用SB可能会令人沮丧.
>具有许多场景的高度复杂的UI应该被分割成多个SB.完全支持多个SB,但很容易失败. (这就像重构一个太大的方法,通常我注意到,在某些事情已经变得凌乱之后,我需要重新编码)

在布局过程中SB的便利性以及消除了夹杂VC对象的大量样板代码是一个巨大的好处. (我消除的每一行代码都是我无法解决的一行代码,而一行不能掩盖真正的代码.)

简而言之,我无法想象没有SBs就会恢复生机.是的,这是一个变化.但我没有发现任何真正的严重缺点.特别重要的是要记住,即使使用SB,所有非SB编码技术仍然可行.给SB一个尝试,并报告你自己的经验.祝你好运！

总结

以上是内存溢出为你收集整理的xcode – 在开发iOS 6应用程序时,这些仍然是有效的反对使用故事板吗？全部内容，希望文章能够帮你解决xcode – 在开发iOS 6应用程序时,这些仍然是有效的反对使用故事板吗？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。