When I access the recordFields
on a CKQueryNotification
returned from a subscription, I get this error:
Could not cast value of type '__NSCFDictionary' (0x1009f0630) to 'CKRecordValue' (0x1009fc050).
I process the notification like this:
let notification: CKNotification = CKNotification(fromRemoteNotificationDictionary: userInfo as! [String : NSObject])
It seems to work fine and I get a CKQueryNotification
.
The notification recordFields prints out like:
<CKQueryNotification: 0x156ef2bf0; notificationType=1, notificationID=<CKNotificationID: 0x156ef41e0; UUID=ba82325d-ab9e-4805-bb26-994a1122900b>, containerIdentifier=iCloud.com.skyvalleystudio.RaceTiming, subscriptionID=Marks for 06597454-4EAD-434E-BC03-CE51D987C79F, queryNotificationReason=1, recordFields={
location = {
altitude = 0;
course = "-1";
horizontalAccuracy = 0;
latitude = "37.33296424";
longitude = "-122.03937369";
speed = "-1";
timestamp = "484712160.263403";
verticalAccuracy = "-1";
};
timeStamp = 484712160;
user = "_2031e89e9ade8345c7d4248f3ec3a2e6";
}, recordID=<CKRecordID: 0x156ef1670; 568D257C-E849-4492-A810-CB7076FC5A22:(_defaultZone:__defaultOwner__)>, isPublicDatabase=1>
So it looks like the recordFields dictionary is there and populated. I try to access is like this:
let timestamp = notification.recordFields!["timeStamp"] as? NSDate
Then I get the error.
UPDATE I filed a Apple bug report 26251611.
The CLLocation is not being decoded in the CKNotification creation is my best guess.
One possible workaround is processing the userInfo directly, but I had problems with processing the CKReference. It seems like the CKRecordValue protocol adopters should be better handled when the CKNotification is created.
UPDATE Closed as duplicate of 24643471. It's still open at this time...