-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should both public and private DBs be checked for notifications? #53
Comments
Sorry, I was out with the Flu for a couple of days... So here is my late response: Hmm.. This might be an EVCloudKitDao design issue. The CKFetchNotificationChangesOperation will get all notifications for both public and private. So it would not matter for which one you call it. But... In the fetchChangeNotifications is a call to the publicDb in order to get a specific record. I think it should also do a 2nd call to the privateDb in order to process the records there. but then... It should also handle named containers. I have to think this one through a little more... As for your second issue, indeed it is a CloudKit notification, but it's not a CloudKitQueryNotification. I have no idea what the notification is exactly. I have seen a notification like this before, but I had it only once. If it was a query notification, then there would also be a query key in that userInfo. So, do you have an idea what it could be? |
Sorry to hear you were sick. That is never fun. I hope you're feeling better now. If I've understood correctly, I can make a single call to the publicDB method with the expectation that all notifications will be handled. Do you have any thoughts on when you may have time to investigate and address whatever changes are needed to make it work correctly? I'm not sure what type of notifications those are either. They don't specify any of the CKNotificationType enumeration values. I will ignore them for now, but they do occur every time I run the app in my case. |
Yes, that would be my intention. One call to process the notifications for all known databases. I'm already restructuring the code a little to make it easier for me to implement. As I can see it now you would not have to change anything. Maybe I will make the call a static functions since it does not need to be executed for a specific database. I will keep you posted about the progress... |
I have made progress. The functions in EVCloudKitDao can now be called for each container/database independently. Now the next thing to do is to loop through all instantiated databases in the EVCloudData functions fetchChangeNotifications and didReceiveRemoteNotification. It will probably be this weekend when I have time to do that. |
Okay, sounds great. Getting something next week will be fine. Thanks for your attention on this. |
The fetchChangeNotifications method is accessed via EVCloudData.privateDB and EVCloudData.publicDB. If my app is storing data in both the public and private DBs, should calls to both DB's fetchChangeNotifications methods be made?
Also, I see messages like this in the console all the time, indicating that received notifications are not CloudKit Query notifications, even though they do appear to be just that. Is this indicating a problem, or can it be safely ignored?
Thanks for the needed clarification on this.
The text was updated successfully, but these errors were encountered: