We are facing a weird behavior with cblDatabaseChange NSNotification. Sometimes randomly when we open our app, we can’t get database change due this notification “problem”.
We are observing the notification with this line: NotificationCenter.default.addObserver(strongSelf, selector: #selector(databaseChange(_:)), name: NSNotification.Name.cblDatabaseChange, object: database)
We are sure that our object is not begin deallocated in any moment of the life cycle. Also we are sure that we are not removing the object as observer in NotificationCenter.default.
If there is something that we are doing wrong, please lets us know. Thanks!
I am unclear on the “problem”. You will only be notified if there are changes to the database. Are you suggesting that sometimes you make changes to the database and you don’t get notified ?
Although you are sure that your observer is not deallocated (which I cannot confirm from your source code above) , can you please add the database observing code to your AppDelegate and retest. If possible , try with the block based version of the API - simpler to get going than having to declare a separate selector etc…BTW, it is not a requirement that you put this in your AppDelegate (although its a common pattern to do it in a separate Singleton manager class for instance) - With the test, I would like to eliminate the case of observers getting deallocated.
I am unclear on the “problem”. You will only be notified if there are changes to the database. Are you suggesting that sometimes you make changes to the database and you don’t get notified ?
Yes, basically when we open the app we don’t get database changes notifications. We need to restart the app and then maybe we can start receiving those notifications.
We know the data is already there because we close all connections to external couchbase nodes and then restart the app and the data is there!.
Although you are sure that your observer is not deallocated (which I cannot confirm from your source code above) , can you please add the database observing code to your AppDelegate and retest. If possible , try with the block based version of the API - simpler to get going than having to declare a separate selector etc…BTW, it is not a requirement that you put this in your AppDelegate (although its a common pattern to do it in a separate Singleton manager class for instance) - With the test, I would like to eliminate the case of observers getting deallocated.
I can confirm that the observers are not getting deallocated. And we also tried the block based notification API.
Weird! That should definitely work. This is with CBL 1.4.1, right? The observer API is different in 2.0. I’m not aware of any issues in 1.4.1 with notifications.
Just to restate the obvious: your observer will only be called for database changes that occur after it’s registered.