timimahoney
commented
5 months ago It’s tempting to try to save the zone on every app launch, but this will result in an extra unnecessary network request every launch. This is a bit inefficient since it’s only necessary one time.
You could potentially remember whether or not you saved the zone and only save the zone on the first ever app launch, but this adds a (tiny) bit of extra complexity. It could also lead to problems if your logic is incorrect.
Another possibility is to pro-actively save the zone if you’re reasonably sure that it isn’t saved. For example, the sample app could add the zone to save when the user adds the first contact to the database. This might be a good compromise, and the logic would be relatively simple.
You’re right about the telemetry problem, but it might not be as bad as it seems. With the current approach, each user will likely only receive one zoneNotFound error in their entire lifetime (the first time they save a contact). This should be distinguishable in the telemetry from a case where a user repeatedly gets this error.
No matter what approach you take, you’d want to make sure to react properly to the zoneNotFound error.
The sample app creates a custom zone when the accountChange event is triggered or if a .zoneNotFound error occurs while sending records. This naturally leads to .zoneNotFound errors on the first upload(s) until it fixes itself.
Is there a specific reason it's done this way? Would it be possible to call
self.syncEngine.state.add(pendingDatabaseChanges: [ .saveZone(CKRecordZone(zoneName: Self.zone.zoneID.zoneName)) ])at app launch and have it finish before any other sync operations can occur?Or is the approach in this sample project the recommended way and you just have to live with those error occurring once. This makes it especially hard to use the Telemetry Error feature in the CloudKit dashboard because you can never be sure if those errors are genuine.