将 Interface Builder 设置转换为 Objective-C答案

【问题标题】：Translating Interface Builder settings into Objective-C将 Interface Builder 设置转换为 Objective-C
【发布时间】：2020-09-27 16:09:57
【问题描述】：

为了理解 Interface Builder 的逻辑，如果有一个工具可以使用在 IB 的帮助下创建的 xcode 项目 (cocoa/objc) 并生成一个“等效”项目，其中所有（或其中一些）IB 设置已被翻译成 objc 代码。

这样的工具存在吗？

【问题讨论】：

标签： objective-c xcode cocoa interface-builder

【解决方案1】：

这样的工具存在吗？

据我所知没有。

拥有一个接受 xcode 项目的工具会很有用 (cocoa/objc) 在 IB 的帮助下创建并生产一个“等效”项目，其中所有（或部分）IB 设置已经翻译成objc代码了。

它可能没有您想象的那么大。您并不需要非常详细地了解 Interface Builder 的“逻辑”，您只需要了解它做什么和不做什么。

我们仍然将其称为 Interface Builder 的 Xcode 部分（尽管它作为一个单独的应用程序的时间已经超过了一些 Xcode 用户的存在时间）本质上只是创建对象、配置它们、将它们连接在一起并序列化生成的对象图到文件。它不会^*生成任何代码，也不会做任何神奇的事情。当您的应用程序运行时，故事板或 xib 文件的内容会被读取并反序列化，以创建与您在 IB 中指定的对象图匹配的对象图。

如果您想查看 IB 创建的对象是如何配置的，您可以查看 xib 或故事板文件，也可以检查程序中的对象。序列化文件大多只是调用对象和它们之间的关系。这是来自 xib 文件的标签：

<label opaque="NO" userInteractionEnabled="NO" contentMode="left" horizontalHuggingPriority="251" verticalHuggingPriority="251" text="Apple" textAlignment="natural" lineBreakMode="tailTruncation" baselineAdjustment="alignBaselines" adjustsFontSizeToFit="NO" translatesAutoresizingMaskIntoConstraints="NO" id="HDj-93-0Hv">
    <rect key="frame" x="59" y="114" width="45" height="21"/>
    <fontDescription key="fontDescription" type="system" pointSize="17"/>
    <nil key="textColor"/>
    <nil key="highlightedColor"/>
</label>

关于标签本身的所有信息都在那里，并且不需要花很多时间来了解如何编写创建标签并以相同方式配置它的 Objective-C 或 Swift 代码。可能最困难的部分是检查与其他对象的关系，例如自动布局约束。为此，请查看上面的 id 字段：

id="HDj-93-0Hv"

该 ID 是指向其他对象的链接。这是一个约束：

<constraint firstItem="HDj-93-0Hv" firstAttribute="top" secondItem="vUN-kp-3ea" secondAttribute="top" constant="70" id="rM0-in-vEv"/>

这只是另一个对象规范，但由于约束必须引用其他对象，因此您会看到包含一些 ID。上面指定了标签的 ID，还有封闭视图的 ID，还有约束本身的 ID。

另一种方法是查看应用中的对象。您可以在调试器中查看对象的属性，查看它们连接到什么，打印出它们的约束等。使用视图层次结构工具可以很好地了解视图的排列方式。

我敢肯定，如果您有一个包含大量视图和它们之间的大量关系的大型故事板，那么通过 XML 进行选择或使用调试器会变得很复杂，您并没有错。但是，如果您有一个工具可以将故事板转换为 Objective-C 或 Swift 代码，那么生成的代码将不会不那么复杂。

^*整个“它不生成代码”的想法在 SwiftUI 中消失了，因为当您在该框架的声明式样式中工作时，Xcode 会将图形视图布局映射到您的代码。

【讨论】：

"它不生成任何代码" 嗯，在某种程度上它确实生成了。我的意思是，如果您在 IB 中设计了具有特定框架和特定字体的 UILabel，那么在运行时，someone 需要创建一个 UILabel 并为其分配该框架和该字体（并将其放入相同的超级视图）。这是一种的代码生成。换句话说，在非常真实的意义上，笔尖由指令组成，并且在运行时，这些指令被遵守。因此，OP 要求这些指示并非完全不合理。
实际上，这里的 OP 的想法与 PaintCode 并没有太大区别，PaintCode 可以让您为绘制的图像执行所描述的那种事情，即生成将导致相同的图像。同样，Zeplin 允许您设计 UILabel 标签并为您提供生成该标签的代码。
@matt 你把代码和数据混为一谈了。当然，您可以将情节提要文件中的 XML 称为“代码”，但这里的重要思想是 IB 在任何时候都不会发出任何 Objective-C 或 Swift 代码。 XML 文件中的信息实际上是序列化的对象。重要的原因是许多其他 GUI 工具确实生成源代码而不是序列化对象，来自其他环境或只是假设 IB 工作原理的人会发现它令人困惑，直到有人解释它。
是的，我认为我们达成了广泛的共识。我希望我们的 cmets 能够幸存下来，因为它们为您的回答提供了有用的脚注。
我也同意你的观点，使用代码而不是罐头对象，这肯定是 SwiftUI 动机的一部分。干杯，感谢您长期以来提供的出色答案。