iOS：使用CoreData的聊天應用程序

我正在爲iOS開發聊天應用程序。該應用程序將允許用戶創建聊天室並與聊天室中的成員聊天（如IRC聊天室）。iOS：使用CoreData的聊天應用程序

該應用程序的流程是;

用戶可以加入聊天室
信息將被存儲在coradata支持的SQLite DB
有當地消息沒有提及，並在服務器上的消息（所有這些都涉及到了消息特定用戶只能存儲在他的本地數據庫中）
我正在使用NSFetchResultController更新並刷新聊天表。收到聊天時，它將被存儲到數據庫，表格視圖將加載新聊天。
所有的核心數據操作都在主線程中完成
的batchsize用於提取請求是20和performfetch方法被稱爲在viewDidLoad

問題

當聊天收到UI掛起了一段時間（1 - 在iPhone 4中2秒）。（如果我暫停執行它表明，東西在[tableview中endUpdate]發生在取數據控制器代表）
要轉到最新聊天在聊天視圖當前用戶必須負荷全部由DB的聊天記錄

問題

有沒有更好的辦法來處理這個要求？可以使用fetchresultcontroller嗎？
我怎樣才能以分頁的方式加載聊天 - 比如什麼sup或 viber - 使用fetchresultcontroller。
如果我使用背景模式與多個託管對象上下文會有任何性能改進？

來源

2014-03-05 Clement Prem

即使使用NSFetchedResultsController它也是非常好的，它被設計用於這樣的操作。
批量大小有點像分頁。看看this post，第一個答案顯示瞭如何使用限制和批處理大小，如分頁。
取決於你的意思，更新/保存到核心數據很可能在後臺線程中處理（我建議這樣做）。提取是一個不同的故事，請記住all UI changes have to be be done on the main thread.。

最好將數據變異和數據提取視爲兩個獨立的任務，這樣您就可以在路上優化它們。我強烈認爲讀書this article對此事的更多信息：

CoreData大師馬庫斯Zarra表明我下面的辦法，建立在上述父/子方法，但僅僅增加了額外的上下文寫入磁盤。正如之前提到的，長寫操作可能會在短時間內阻塞主線程，導致UI凍結。這種智能方法將寫入分離到自己的專用隊列中，並使UI保持平滑。

來源

2014-03-05 10:57:24

所有的核心數據操作都在主線程

這是你的問題做。主線程上只能通過NSFetchResultController訪問對象。更新NSManagedObject應在具有併發子NSManagedObjectContext的背景隊列上完成。

來源

2014-03-05 10:42:15

我不太確定。如何插入一個新的行並獲取它，需要1到2秒？這應該是足夠快的主線程，我認爲還有其他事情正在進行。 –

核心數據，特別是'NSFetchedResultsController'，不僅「插入和提取」模型。它查詢部分對象，監視更改，在需要模型屬性值時觸發故障，處理更改，保存到磁盤等等。如果你在主線程上進行更新和保存，你會不必要地阻塞所謂的只讀「NSFetchedResultsController」。 –

是的，我知道它是這樣做的，但根據我的經驗，它發生在微秒而不是秒。我在後臺線程上使用了一個單獨的上下文來處理緩慢的事情（例如：在數據庫中插入3000個新條目），但我不需要打擾大部分時間。通常情況下，更改速度足夠快，可以在主線程上完成。 –

你將需要在後臺線程上做CoreData的東西。這裏有很多示例（here's one），但我的建議是使用MagicalRecord，它使CoreData併發操作非常簡單。

來源

2014-03-05 10:43:13

學習核心數據本身將比使用包裝核心數據的第三方框架更進一步。甚至MagicalRecord的創造者也表示，你最好先學習核心數據**。創建子上下文和「NSOperation」子類不是高級主題，值得學習。 –

不能與核心數據的主人爭吵:)非常真實。 –

對於你的問題2.

您創建一個新的數組-namely chatArray - 走過去的20個聊天從你的數據庫，然後加載與chatArray聊天表視圖。在Tableview標題上顯示加載更多按鈕，當用戶達到頂部並按下該按鈕時，從chatArray中刪除所有對象，並從數據庫中添加最後20條聊天記錄，然後重新加載您的表。這個過程繼續。

我在fetchresultcontroller中功能不強，而且會做一些研究並讓你知道。

來源

2014-03-05 10:59:48

iOS：使用CoreData的聊天應用程序

回答

相關問題