BNR iOS编程手册强调了使用故事板的几个“缺点”.我在下面列出了它,我的问题是：这些否定是否仍然适用于iOS 6？
故事板很难与团队合作
故事板拧紧版本控制
故事板破坏编程流程
故事板牺牲灵活性和易于使用的控制
故事板总是创建新的视图控制器实例
我正在寻找正在建设的家伙的答案,最好部署真正的iOS应用程序,并且与“storyboards vs .xib”一样的东西本身.
谢谢
解决方法
我正在使用故事板为一个实质的应用程序,我发现他们是一个真正的生产力福音.我鼓励你尝试看看你是否不同意.
关于问题列表的几个意见：
>我没有意识到队和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一个尝试,并报告你自己的经验.祝你好运！