故事板与在代码中完成它

Question

我在一家公司工作,我们有几个iOS开发人员,我们一起使用GIT在同一个项目中工作.我们从不在开发过程中使用Storyboards或.xib文件,因为几乎不可能正确地合并它们.

随着iOS7的推出,我想到了Storyboard和编码所有UI"旧方法"之间的根本区别,而没有使用Interface Builder.

这里有没有人做到这一点？最重要的是,你可以在Storyboard中做些什么,你不能在XCode 5的代码中做什么？

Answer 1

我将把你的问题分成两部分:NIB和故事板.

就NIB而言,源代码控制问题可能很痛苦但可管理,主要是因为您通常每个视图控制器都有一个NIB文件.您可以想象一种情况,即您有两个开发人员在NIB驱动的应用程序的两个不同部分上工作而没有任何合并问题.故事板是不同的,因为您只有一个文件描述了应用程序的大多数(如果不是全部)UI.显然,那里存在更大的冲突问题.

如果使用正确,NIB可以非常有用并节省时间.这是一个例子:iPad上的iPhoto App具有非常复杂的UI.该UI的绝大多数是以编程方式布局的.但是,该应用程序还使用NIB加载图形元素,然后在代码中进行布局.这是刷子面板的工作方式 - 所有刷子都是在NIB中创建的.这意味着Apple 不必拥有数十个相同的图像/图像视图alloc/init代码片段.所有创建都可以在NIB中进行(在iPhoto UI上的WWDC 2012会话中对此进行了详细讨论 - 非常值得追踪).

所以,发钞银行-有时好,可以为您节省大量的时间,而且虽然有是合并的问题,他们可以在很多情况下轻松进行管理和处理.

然后我们来到故事板.故事板很有趣.一方面,它们对于直接应用程序和平台新手开发人员非常有用且有用.我刚刚将一个UINavigationController基于NIB的应用程序转换为故事板,并且节省了大量时间(特别是在桌面视图之外,因为使用故事板可以利用原型单元).

但是,如果你正在与一些开发人员合作开展一个大型项目,我不相信故事板是有益的.正如你所说,存在合并冲突的大问题,并且与NIB不同,解决它们并不容易,因为单个故事板文件控制着你的所有应用UI.

这就是我的建议(并且可以随意忽略我!) - 如果您正在开发应用程序并完全使用代码来完成布局/ UI ,请考虑NIB是否可以节省您的时间.他们可能不会 - 他们不适合所有人 - 但至少值得考虑是值得的.您可能会惊讶于有多少大型应用程序实际使用NIB(iPhoto,正如我所提到的,还有Apple提供的许多内置应用程序,以及大型团队提供的许多流行的第三方应用程序).我可能不会考虑故事板,除非你是一个独立的开发人员在一个应用程序上进行相当简单的导航.这不是以任何方式记录故事板 - 我喜欢使用它们 - 它只是它们不适合协作.

有人发表了这条评论以回答你的问题 - 我想讨论一下:

你无法在故事板中做任何事情,也无法在代码中做到.对象,手势识别器,segues甚至约束 - 都可以通过编程方式进行构建

这在技术上是正确的,但实际上故事板/ NIB中的东西比代码容易得多.一个很好的例子是自动布局.虽然您完全可以在代码中管理自动布局约束,但严酷的现实是,ASCII自动布局表示比IB中的视觉表示更难处理.这是尤其如此上的XCode 5,那里有在IB自动布局大规模的改进(我无法详细介绍太多,因为它仍然在保密协议,但苹果公开谈点的变化在这里).