1

В настоящее время я работаю над Couchbase Lite и отображает каждый документ в UITableView.CBLLiveQuery vs kCBLDocumentChangeNotification

Мои вопросы, если document_id: abc12345 обновляется на стороне сервера (CouchDB) (либо вручную, либо с любого другого приложения IOS/Android/Web), что лучший подход к обновлению документа _id : abc12345 в UITableView.

В нынешней ситуации я использую CBLLiveQuery, и я не счастлив с ним, потому что он нуждается в CBLView (отображение/пониженную функции, и я индексировать его на основе _rev из CBLDocument) и создания CBLQuery, а затем вызывая livequery [livequery start];, а затем наблюдения с КВО, а затем бла-бла-бла ...

self.liveQuery = [self startLiveQueryViewWithDatabase:database]; [self.liveQuery addObserver:self forKeyPath:@"rows" options:0 context:NULL]; [self.liveQuery start];

Тот факт, который я заметил, что всякий раз, когда экземпляр живой запрос вызывается впервые метод KVO -(void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context вызывается без каких-либо изменений в CBLDocument на сервере.

Когда какой-либо документ на сервере обновлен, -(void)observeValueForKeyPath: не даст мне то, что было изменено/какой документ был изменен. _id. Он просто дает мне кучу идентификаторов документов _id.

Когда я узнал о kCBLDocumentChangeNotification, он дает мне правильный ID документа _id, который был обновлен.

[[NSNotificationCenter defaultCenter] addObserverForName:kCBLDocumentChangeNotification object:self queue:nil usingBlock:^(NSNotification *note) { CBLDatabaseChange* changes = note.userInfo[@"change"]; NSLog(@"Document : [%@]",changes.documentID); [self updateUserInterface:changes]; }];

пожалуйста, мне нужно знать, какая концепция лучше реализовать любой из них, какой из них будет занимать меньше времени (если это возможно технически).

ответ

2

Query - это действие поиска результатов из индекса вида. Теперь представление может индексировать что угодно в базе данных. Он, наряду с запросом, может извлекать все документы, набор документов, кучу свойств или одно свойство из документов (ов) или некоторые значения, которые вычисляются на основе свойств в документе (документах).

И, liveQuery - это механизм наблюдения за обновлениями этих индексов представления, то есть уведомляет об изменениях блока испускания представления.

A kCBLDocumentChangeNotification просто уведомляет об изменениях, произошедших с конкретным документом, то есть уведомляет о новой редакции.

/** This notification is posted by a CBLDocument in response to a change, i.e. a new revision. 
    The notification's userInfo contains a "change" property whose value is a CBLDatabaseChange 
    containing details of the change. 
    NOTE: This is *not* a way to detect changes to all documents. Only already-existing CBLDocument 
    objects will post this notification, so when a document changes in the database but there is 
    not currently any CBLDocument instance representing it, no notification will be posted. 
    If you want to observe all document changes in a database, use kCBLDatabaseChangeNotification.*/ 
extern NSString* const kCBLDocumentChangeNotification; 

Так,
- использовать liveQuery для получения обновлений для вашего запроса.
- используйте kCBLDocumentChangeNotification для получения обновлений из документа.
- используйте kCBLDatabaseChangeNotification для обновления всех документов.

+0

Спасибо, В 'liveQuery' KVO просто вызывает' - (void) observValueForKeyPath: (NSString *) keyPath ofObject: (id) изменение объекта: (NSDictionary *) изменить контекст: (void *) context' даже без каких-либо изменение документа на сервере. который излишне толкает метод в стеке. тогда как 'kCBLDocumentChangeNotification' не вызывает ненужных вызовов методов. Я знаю, что 'kCBLDocumentChangeNotification' медленнее, чем' liveQuery', но задержка незначительна.Любые дополнительные разъяснения будут указаны. – iNasir

+0

Как я уже сказал, в liveQuery вы наблюдаете «строки», и вы будете уведомлены каждый раз, когда у него будет новое значение. –