在团队环境中合并时的界面生成器 (XIB) 或代码？答案

【问题标题】：Interface Builder (XIB) or Code when merging in a team environment?在团队环境中合并时的界面生成器 (XIB) 或代码？
【发布时间】：2011-09-17 18:19:53
【问题描述】：

将界面构建器文件与其他人（甚至我自己来自另一台计算机）合并可能是一个真正的挑战。 XIB xml 肯定比 NIB 好，但即使是 xml，我也发现合并和获得一致且有效的 XIB 比仅采用另一个并手动重做所做的更改更难的情况。

我想知道其他人在做什么，他们有多个人可能会在 XIB 上发生冲突。

是否合并考虑所有代码？您是否仅将 XIB 用于布局并编写其余部分？或者，你有没有运气好合并了 XIB，随着时间的推移，你在手动阅读方面变得更好了？

编辑：我目前的方法是使用它进行严格的布局（它真正擅长且编写代码很痛苦）并通过代码设置所有选项和数据。我发现代码更容易合并，但在代码中布局控件很乏味。想法？

【问题讨论】：

标签： iphone objective-c ios ipad interface-builder

【解决方案1】：

是否考虑合并所有代码？

是、否和“部分”。这取决于以下内容：

相关人员
用户界面的复杂性
您需要的实施质量。
实现的预期生命周期

但是，是的，它一直是，而且通常是在情况并非微不足道的情况下——否则，您只需通过将 XIB 分解成更小的部分来对抗它。这可能会很好（或不会），这取决于您面临的情况。

您是否仅将 XIB 用于布局并编码其余部分？

取决于很多事情。

XIB-only 有其限制，很像代码复制。我有时将它用于原型设计，有时是因为这是其他人喜欢的。
“两者都有一点”可能需要大量胶水。有时，它可能非常混乱 - 例如。 “那个动作真的设置在哪里？”。当然，这也可以用来实现一些人认为 XIB 和程序分离的良好平衡。 XIB 越简单，需要调整的频率就越低，导致合并冲突的可能性也就越小。
仅代码是我的偏好，但有些人更喜欢 WYSIWYG，而且人们不太熟悉以编程方式编写 UI。同样，如果质量、可重用性和可维护性不是要求（例如，敲出原型），那么纯代码可能是矫枉过正。

或者，你有没有运气好合并 XIB，随着时间的推移，你在手动阅读方面变得更好了？

没有真正的运气 - 只是将它们分解成更小的组件。不幸的是，“分解接口”选项（来自 IB3）在 Xc4 的编辑器中不可用。

【讨论】：

【解决方案2】：

我发现 IB 更适合你提到的布局，但可能这只是我的原因，因为我是这样长大的。加上代码比布局更可重用。

就我而言，在运行时两者的行为相同，尽管我对此不是 100% 确定的。 IB 中的原型比代码中的痛苦少，我知道客户肯定不会对您在代码中进行原型设计有任何价值。

【讨论】：

同意代码的可重用性更高，也同意 IB 中的布局更好。这是我目前的方法（在 IB 中进行严格的布局并在代码中配置控件，我可以轻松地保存、复制粘贴和比较）。如果我必须在错误的合并情况下重做布局，它会很快，因为它是严格的布局和重新绑定。等待其他人的消息...
把这个作为答案，因为这基本上是我得出的结论，我还没有听到其他容易合并的建议。代码更易于重复使用（剪切和粘贴），并且界面生成器中的严格布局最容易。

【解决方案3】：

我所做的是不费心尝试合并，完全接受分支版本或您的版本。这意味着您必须对谁可以更改界面代码以及提交和更新有点自律，实际上我们还没有发现它是一个问题，但我想这取决于您的环境。不要以此为借口停止使用界面生成器，没有什么比尝试挖掘其他人的代码以找到一个按钮更糟糕的了，这样您就可以计算出用户单击它时会发生什么。 如果没有 Interface Builder，您就是不尊重 MVC 分离。

【讨论】：

MVC 并不规定 Interface Builder。我已经在多个平台上以多种语言编写了 MVC 模式。有些有设计师，有些没有。 MVC 规定您的视图与您的控制器是分开的。可以有一个视图类、一个控制器类和一个模型类而没有 xib 并尊重 MVC。 MVC 在 1978/1979 年回到 Xerox Parc，我非常确定界面生成器不存在 :) heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html
你说得对，我只是从没有使用界面生成器的 iOS 应用程序的经验中说的更多。他们倾向于将所有视图构建代码卡在视图控制器中。