evermeer / EVCloudKitDao

Simplified access to Apple's CloudKit
Other
645 stars 65 forks source link

Should both public and private DBs be checked for notifications? #53

Open tbaggett opened 8 years ago

tbaggett commented 8 years ago

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?

01/20/2016 15:38:16:975 Marquees)[459:.] AppDelegate.swift(257) application(_:didReceiveRemoteNotification:):
    Push received

01/20/2016 15:38:16:976 Marquees)[459:.] AppDelegate.swift(259) application(_:didReceiveRemoteNotification:):
    Not a CloudKit Query notification.

01/20/2016 15:38:16:978 Marquees)[459:.] EVCloudKitDao.swift(1195) didReceiveRemoteNotification(_:executeIfNonQuery:inserted:updated:deleted:completed:):
    WARNING: The retrieved notification is not a CloudKit query notification.
===>userInfo = [ck: {
    ce = 2;
    cid = "iCloud.com.tommyb.Marquees";
    nid = "363ec9be-24c5-4c2f-949e-5989c0567272";
}]
notification = <CKNotification: 0x14470a510; notificationType=0, notificationID=<CKNotificationID: 0x144725e90; UUID=363ec9be-24c5-4c2f-949e-5989c0567272>, containerIdentifier=iCloud.com.tommyb.Marquees>

Thanks for the needed clarification on this.

evermeer commented 8 years ago

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?

tbaggett commented 8 years ago

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.

evermeer commented 8 years ago

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...

evermeer commented 8 years ago

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.

tbaggett commented 8 years ago

Okay, sounds great. Getting something next week will be fine. Thanks for your attention on this.