xamarin.ios - Monotouch.Dialog 是所有 UITableviews 的合适替代品吗？

Question

这个问题主要针对Miguel作为MT.Dialog的创建者，但我也想听听其他人的意见。
我目前正在重构一个有很多表 View 的项目。我想知道是否应该用 MT.Dialog 替换所有这些。

我的优点是:

易于使用

简单代码

希望 Xamarin 有一天能跨平台提供它

缺点:

我的细胞是完全定制的。在这种情况下有意义吗？

表现？这是一个问题吗？

打破 MVC 范式(源不再与 View 和 Controller 分离)

对于特定用例，通常只使用 MT.Dialog 还是从它继承更好？你有什么经验？

Answer 1

解决您的一些问题。

MonoTouch.Dialog 和 UITableView 之间的主要区别在于，前者你“加载”了你想要预先呈现的所有数据，然后忘记它。你让 MonoTouch.Dialog 来处理它的渲染、推送 View 和处理部分/元素。使用 UITableView，您需要提供回调方法来返回部分的数量、部分的标题和数据本身。

UITableView 的优势在于，要呈现一百万行具有相同大小和相同单元格的行，您实际上不必预先加载所有数据，您只需等待被回调即可。话虽如此，如果您使用具有不同高度的单元格，这会很快中断，因为 UITableView 将不得不查询所有行的大小。

简而言之:

(1) 是的，即使您使用自定义单元格，您也会受益于更短的代码和更简单的编程模型。是否使用它的其他功能取决于您。

(2) 对于性能，问题归结为您将拥有多少行。就像我之前提到的那样，如果您正在浏览一个潜在的大型数据集，则必须预先将所有这些单元格加载到内存中，或者像 TweetStation 一样，添加功能以“按需”加载。

实际情况是它会消耗更多内存，因为您需要在 MonoTouch.Dialog 中加载数据。最好的优化技术是让 Elements 保持非常轻量。例如，Tweetstation 使用一个“TweetElement”，它只保存推文的 ID，并按需加载实际内容，以保持内存中 TweetElement 的大小非常小。

使用 UITableView，您无需为此付出代价。但是如果您不使用某种数据库，数据仍将在内存中。

如果您的应用程序要求将数据保存在内存中，那么您不妨将数据移动为元素并将其用作模型。

(3) 这有点像稻草人。您的数据“来源”从来都不是真正独立于 UIKit。我知道人们喜欢谈论这些模型是可重用的，但在实践中，你永远无法重用 UITableViewSource 作为除 UITableView 之外的任何东西的源。它的主要用途是支持不需要预先将数据加载到内存中的可扩展控件，它并不是真正将模型与 View 分离。

所以你真正拥有的是一个适配器类，它将 UITableView 的世界与你的实际数据模型(一个数据库、一个 XML 列表、一个内存数组、一个 Redis 连接)连接起来。

使用 UITableView，您的适配器代码位于构造函数和 UITableViewSource 中。使用 MonoTouch.Dialog，您的 adatpro 代码位于将初始 RootElement 填充到 DialogViewController 的代码中。

所以有理由在 MonoTouch.Dialog 上使用 UITableView，但这三个缺点都不是。