2009-09-29 38 views
9

什麼是將大量XML從RESTful服務異步提取到Core Data存儲區的良好實踐,並且從該商店中動態填充UITableViewREST的好策略 - > XML - >核心數據 - > UITableView?

我想使用的libxml2的xmlParseChunk()函數來分析傳入的XML的塊和翻譯節點及其子到相關管理對象,如節點進來的。

與此同時,這些XML節點變成託管對象,我想依次生成UITableView行。說一次50行。這是現實的嗎?

根據您的經驗,您要做什麼來完成此任務,以保持性能並可能處理數千行?是否有不同的,更簡單的方法可以同樣或更好地工作?

+1

您可能會發現http://cocoawithlove.com/2009/09/optimizing-loading-of-very-large-table.html有用。 – 2009-09-29 18:05:32

回答

14

當然,這是一個非常標準的事情。最簡單的解決方案是在一個MOC上的後臺線程中進行加載,並使用其自己的MOC在主線程上運行UI。每當你得到一大塊你想要出現的數據(比如說50個條目)時,你都有背景MOC​​。

假設您使用前景MOC操縱來合併更改(通過mergeChangesFromContextDidSaveNotification:),那麼無論您何時保存背景MOC,前景MOC都將獲得所有這些更改。假設你使用的是NSFetchedResultsController,它具有委託方法來處理MOC中的變化,如果你使用的是Apple的示例代碼,那麼你可能已經準備好了一切。

一般而言,除非您真的知道自己在做什麼,並且願意花費大量時間調整您的特定情況,否則CoreData將比自己推出的任何內容更快。您可以做的最重要的事情是確保緩慢的事情(例如由​​引起的XML處理和同步閃存I/O)不在阻止用戶交互的主線程上。

+0

+1,但是我很想在一場無防守的死亡比賽中對抗CoreData http://sqlitepp.berlios.de/,看看哪個更快。 – slf 2009-10-08 20:21:15

+3

我絕對可以(並且)在特定的工作負載上擊敗CD直接使用SQLite3。但通常涉及的努力量是猥褻的。我最終將通過使用CoreData獲得更好的應用程序,然後以1/3的時間保存調整我的應用程序的其他部分。 我們不會在真空中編寫代碼。我已經學會了艱難的方式,放棄一些絕對的理論性能並使用節省的時間來實現其他應用程序代碼的實際性能改進是更好的。顯然,具體細節因項目而異。 – 2009-10-09 02:41:33

+0

是否有示例代碼演示如何將多個MOC與合併到一個主要MOC的更改結合使用? – 2009-10-09 09:45:47

2

Joe Hewitt(Facebook應用程序開發人員)已經將他的許多代碼釋放爲開源代碼。它被稱爲Three20。有一個課程非常適合讀取互聯網數據並將其填充到表格中,而無需事先提供數據。用於此的類別被稱爲TTTableViewControllerTTTableViewDataSource

從這裏開始,存儲CoreData並不算什麼,只是按照您認爲適合的提供的鉤子子類。

如果您擔心太多的數據,一次50個聽起來合理。這些類有一個內置的「更多」按鈕來幫助你。

從Three20自述:

互聯網知覺表視圖控制器
TTTableViewController和 TTTableViewDataSource幫你到加載從互聯網上的內容 建表。而不是僅僅 假設你都準備好 去的數據,如UITableView的不通過 默認情況下,TTTableViewController讓 你溝通時,你的數據是 加載,當有錯誤或 沒有顯示。它還可以幫助您 添加一個「更多」按鈕來加載數據的下一頁,並且可選地, 支持通過晃動設備來重新加載數據。

+0

我想我不清楚。我實際上想要填充一個核心數據存儲,它依次填充表視圖。目前尚不清楚這個子類是否解決了這個問題,如果它逐個單元地提取數據(這不是我需要完成的)。 – 2009-10-03 07:33:36

0

沒有人提到RestKit了嗎?我的朋友......嚴重的是,你必須檢查一下。如果你在iOS上(現在在OS X上)使用REST做什麼,特別是如果你想要使用Core Data ......請看看RestKit。我已經在iOS上保存了無數個小時的服務器和我的Core Data模型之間的一些非常複雜的數據同步。 RestKit讓它變得很容易,它幾乎讓你生病。

+0

RestKit似乎很難與XML--它自帶的XML解析器在iOS 5上編譯時有ARC錯誤。總的來說,它看起來很棒 - 特別是對於直線JSON。 – radven 2012-04-26 08:12:00

相關問題