Monotouch.Dialog是否適合所有UITableviews？

Question

這個問題主要針對Miguel作爲MT.Dialog的創建者，但我也希望聽到別人的意見。 我目前正在重構一個有許多表格視圖的項目。我想知道是否應該用MT.Dialog替換它們。

我的優點是：

• 使用方便
• 簡單的代碼
• 希望Xamarin將提供它的跨平臺1天

缺點：

• 我細胞是完全定製的。在這種情況下它有意義嗎？
• 表現？這是一個問題嗎？
• 打破了MVC範式（來源不再從視圖和控制器分開）

它是一般最好只使用MT.Dialog或繼承它的具體使用情況？你有什麼經驗？

Answer 1

我使用MonoTouch.Dialog（它是兄弟QuickDialog for objc），每次使用tableview時都會使用它。這對於簡化代碼非常有幫助，並且可以更好地抽象出表格。

雖然有一個例外，那就是當表格有成千上萬行時，並且數據在數據庫中。 MT.D/QD要求您預先加載所有數據，以便您可以創建這些部分，如果您尚未在內存中存儲對象，那麼速度太慢。

關於「打破MVC」，我有點同意你的看法。因爲這個事實，我從來沒有真正使用MT.D中的反射綁定。通常我最終從頭開始在代碼中創建根，或者使用類似JSON的東西（在我的叉https://github.com/escoz/MonoMobile.Forms中），以便我的域對象不需要了解MT.D.

Answer 2

解決你的一些問題。

MonoTouch.Dialog和UITableView之間的主要區別在於，前者可以「加載」所有要預先渲染的數據，然後將其遺忘。您讓MonoTouch.Dialog負責渲染它，推動視圖並照顧部分/元素。使用UITableView，您需要提供回調方法來返回節的數量，節的標題和數據本身。

UITableView的優勢在於，爲了呈現一百萬行具有相同大小和相同單元格的行，您不必真正加載所有數據，您可以等待被回調。話雖如此，如果你使用不同高度的單元格，這會很快破裂，因爲UITableView將不得不查詢所有行的大小。

因此，在短期：

（1）是的，即使你使用自定義的細胞，你會從更短的代碼和一個簡單的編程模型中受益。無論您是否使用其他功能，都取決於您。

（2）對於性能，問題歸結爲您將擁有多少行。就像我之前提到的那樣，如果您正在瀏覽可能較大的數據集，則必須先將所有這些單元格加載到內存中，或像TweetStation那樣添加功能以「按需」加載。

現實情況是，它會消耗更多的內存，因爲您需要在MonoTouch.Dialog中加載數據。你最好的優化技術是讓你的元素非常輕量。 Tweetstation例如使用「TweetElement」，僅將該ID保存到推文中，並根據需要加載實際內容，以將TweetElement的大小保持在記憶中非常小。

與UITableView，你不支付的價格。但是如果你沒有使用某種數據庫，數據仍然會在內存中。

如果您的應用程序要求數據存儲在內存中，那麼您還可以將數據移動爲元素並將其用作模型。

（3）這是一個有點草的人。您的數據「源」永遠不會獨立於UIKit。我知道人們喜歡談論這些模型是可重用的，但在實踐中，你永遠無法重用UITableViewSource作爲除UITableView之外的任何其他資源。它的主要用途是支持可伸縮控件，它不需要預先將數據加載到內存中，而不是將模型從視圖中分離出來。

因此，您真正擁有的是將UITableView的世界與實際數據模型（數據庫，XML列表，內存數組，Redis連接）橋接的適配器類。

使用UITableView，您的適配器代碼位於構造函數和UITableViewSource中。使用MonoTouch.Dialog，您的adatpro代碼位於將初始RootElement填充到DialogViewController的代碼中。

---

所以有理由在MonoTouch.Dialog上使用UITableView，但它不屬於這三個缺點。