iOS Interface Builder 中的架构方法

Posted 2023-03-12

【中文标题】iOS Interface Builder 中的架构方法

【英文标题】：Architectural approach in iOS Interface Builder

【发布时间】：2016-06-20 15:02:04

【问题描述】：

您是否会将下面的设计模型编码为带有分段组的表格视图，这些分段组用自定义单元格类型填充在侧面，或者您会将组放在滚动视图中并使每个部分成为构建的 UIView。

这不是一个基于意见的问题，或者“一般来说”这是一个 ios 开发设计问题。

在 Interface-Builder 中，我有七个屏幕，如下图所示。如果我使用表格视图进行滚动并使用分组部分，这些部分应该无法滚动，因为没有更好的词，它们需要是静态的。这甚至可能吗？

部分标题会一直停留在顶部，直到您滚动过去，这不是我想要的。

我也不能在滚动视图中放置一个静态不可滚动的表格，因为这只是倒退和错误的。同样通过这种方法，我为每个部分设置了不同大小的标题，为每个部分设置了不同的单元格类型。这样做似乎很俗气/hacky。

如果我使用 UIView 构建方法，那就需要大量构建，因为有 7 个屏幕具有这种外观。

基于原生 iOS 开发方法的更好决策是什么？更好地为每个屏幕使用大量自定义 TableView 或使用带有子视图的一堆 UIView？这两种方法对我来说都有重大的权衡，这在我的经验中是不寻常的。您是否看到比我要追求的更好的方法？

【问题讨论】：

它可以有多少行？

它从最少 3 到 5 不等，不包括他们可以输入答案的“其他”的最后一行。

您可能会创建一个 UIView 子类，它可以比使用表格更轻松地完成您想要的操作。该子类会为您需要的行动态添加 UIView 子类。

【参考方案1】：

当您想要完全不同的外观时，使用表格的问题是您经常发现自己在与它作斗争。在某些时候，您甚至可能会尝试编写代码来颠覆公共 API 并去操作单元格或表格视图中的底层视图。

虽然这是“可接受的”并且不被视为“私有 API”，但您可能会发现未来的 iOS 版本会破坏这种行为。

当我想要一些远离餐桌行为的东西时，我不会使用餐桌。

在您的情况下，您可以不使用部分并将标题设置为另一种单元格类型。那应该不会太糟。您的模型的其余部分看起来可以作为表格实现。

【讨论】：

是的，设计选择似乎在未来很容易崩溃，这是一个好点。我需要对此进行全面检查。你的建议就是这样做的。谢谢娄。