ios - 构建自定义 UIPickerView

Question

我正在尝试构建自定义 UIPickerView替换类主要用于学习目的，但为了在我正在开发的应用程序中实现这一点。我在应用程序的 UI 上投入了大量时间和精力，现在默认设置为 UIPickerView。只是不合适。

我看到了 Dribble模拟一个看起来很漂亮的日期/时间选择器，但意识到在 hell 中没有机会 UIPickerView可以在没有一些重大黑客攻击的情况下大量定制。

经过大量阅读和调查，我发现UIPickerView使用 UITableView s 代表它的组件，而不是简单的 UIScrollView正如我最初假设的那样。这令人困惑，原因有两个:

定制UITableViewCell s 是臀部的主要疼痛。并不是说它很辛苦，只是费力并且很少产生所需的结果。不知怎的UIPickerView尽管开销很小，但设法实现了这一目标。我假设组件中的每一行只使用 UITableViewCellStyleDefault带有自定义 View 的 contentView但你知道他们对假设的看法。

让我失望的第二件事是 UIPickerView符合UITableViewDataSource协议(protocol)，但不是 UITableViewDelegate协议(protocol)。这似乎有点奇怪，因为代理负责通过 – tableView:heightForRowAtIndexPath: 提供正确的高度。 UIPickerView但是确实允许您通过 – pickerView:rowHeightForComponent: 设置组件的大小

与此一致，使用表格 View 似乎也是一个奇怪的选择，因为它们本身不会像 ScrollView 使用 pagingEnabled 那样“捕捉”到指定的行。 .

谁能解释为什么默认 UIPickerView不符合上述代表？使用 UIScrollView 实现我的自定义选择器会更容易吗？代替或应该 UITableView提供所需的功能？

Answer 1

UIPickerView实际上符合UITableViewDelegate协议(protocol)，但只是没有在公共(public) header 中公开它。您可以使用 class_copyProtocolList 自行检查。功能。

在内部使用 UITableView 可以更轻松地实现具有大量行的选择器，因为 UITableView 为重用单元格提供了很好的支持，否则 Apple 将需要再次为选择器重新实现该逻辑 - 这没有多大意义(对不起，我没有看到在这种情况下自定义 UITableViewCell 有什么大问题，所以很难评论)

由于 UITableView 是 UIScrollView 子类，您可以使其“捕捉”到特定位置，检查 scrollViewWillEndDragging:withVelocity:targetContentOffset: UIScrollViewDelegate 中的方法可用于该目的的协议(protocol)。