在团队环境中合并时的Interface Builder（XIB）或代码？ [英] Interface Builder (XIB) or Code when merging in a team environment?

问题描述

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

Merging interface builder files with others (and even myself from a different computer) can be a real challenge. The XIB xml is certainly better than NIBs but even as xml, I've found cases where merging and getting a consistent and valid XIB was harder than just taking the other and manually redoing the changes made.

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

I'm wondering what other folks are doing who have multiple folks who can potentially collide on XIBs.

合并所有代码的考虑因素？您是否仅使用XIB进行布局并对其余部分进行编码？或者，你有没有运气合并XIB，随着时间的推移，你只是手动阅读更好？

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

My current approach is using it for strict layout (what it's really good at and painful to code) and setting all the options and data via code. I find code much easier to merge but laying out controls in code is tedious. Thoughts?

推荐答案

合并所有代码的考虑因素？

Was merging a consideration for going all code?

是，否和部分。这取决于以下内容：

Yes, No, and "Portions Of". It depends on things like:

• 所涉人员


• UI的复杂性


• 您需要的实施质量。


• 实施的预期生命周期

• The people involved
• the complexity of the UI
• the quality of the implementation you need.
• the expected lifetime of the implementation

但是，是的，它一直是，并且通常是在案件不是微不足道的时候 - 否则，你只是通过将XIB分解成更小的部分来对抗它。这可以很好地工作（或不工作），具体取决于你所面临的情况。

But yes, it has been, and it often is when the case is just not trivial -- Otherwise, you just fight it by decomposing XIBs into smaller pieces. That can work pretty well (or not), depending on what you are faced with.

你是否只使用XIB进行布局和编码休息？

Do you use XIBs just for layout and code the rest?

取决于很多事情。

• XIB只有它的限制，很像代码重复。我有时会使用它来进行原型设计，其他时候因为这是其他人所青睐的。


• 两者兼而有之可能需要很多胶水。有时，它可能非常混乱 - 例如那个动作真的设置在哪里？。当然，这也可以用来实现一些人认为XIB和程序化分离的良好平衡。 XIB越简单，需要调整的次数越少，并且不太可能导致合并冲突。


• 仅限代码是我的偏好，但有些人更喜欢所见即所得，人们不是很熟悉以编程方式编写UI。同样，如果质量，可重用性和可维护性不是要求（例如敲出原型），那么仅代码可能会过度。

• XIB-only has its restrictions, and is much like code duplication. I use it at times for prototyping, other times because that's what somebody else favored.
• "A little of both" can require a lot of glue. At times, it can be pretty disorganized -- e.g. "where's that action really set?". Of course, this can also be used to achieve what some would consider a good balance of XIB and programmatic separation. The simpler the XIB is, the less often it will need to be adjusted, and less likely it will cause merge conflicts.
• Code-only is my preference, but there are people who just prefer WYSIWYG, and people aren't very familiar writing UIs programmatically. As well, if quality, reusability, and maintainability not requirements (e.g. bang out a prototype), then code-only can be overkill.

或者，你有没有合并XIB的运气，随着时间的推移，你只是手动阅读更好？

Or, have you had any luck merging XIBs and over time you just get better at manually reading?

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

No real luck -- just by breaking them into smaller components. Unfortunately, the "Decompose Interface" option (from IB3) is not available in Xc4's editor.

这篇关于在团队环境中合并时的Interface Builder（XIB）或代码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！