20

The documentation for the EKCalendar class states this for the calendarIdentifier property:

A full sync with the calendar will lose this identifier. You should have a plan for dealing with a calendar whose identifier is no longer fetch-able by caching its other properties.

When exactly does a "full sync" occur and what properties are liable to change besides the calendarIdentifier?

Whirlwind
  • 14,286
  • 11
  • 68
  • 157
user1869469
  • 491
  • 4
  • 13
  • here you can find some explanations. http://oleb.net/blog/2012/05/creating-and-deleting-calendars-in-ios/ – Ilan Aug 24 '13 at 08:11
  • 1
    This refers to syncing a local calendar with a CalDAV or iCloud calendar. When this happens, the local calendar can no longer be retrieved using `calendarWithIdentifier`. So If you cached `calendarIdentifier`, it won't be of any use. You should either access the [iCloud calender](http://stackoverflow.com/questions/13869118/ios-ekevent-store-recreating-icloud-calendars-in-a-loop-wont-save-local) or, as the documentation suggests, cache the values of those properties of the calender that you want to use later. – Hadi Brais Jul 24 '15 at 20:44

3 Answers3

5

When exactly does a "full sync" occur?
Calendar and Reminders Programming Guide explains this questions in this way:

If a change to the Calendar database occurs from outside of your app, Event Kit is able to detect the change by notification so your app can act appropriately. Changes made to calendar items with Event Kit are automatically synced to the associated calendar (CalDAV, Exchange, and so on).

I see such scenarios of "full sync" events while your app is open:
1. User sends your app to background and opens Calendar app. He changes calendar name, adds/edits/deletes events or even removes some calendar.
2. User applies some changes to iCloud calendar on Mac. iOS device is notified that iCloud calendar was changed so it has to be synchronized.
3. Third-party app receives silent notification, iOS launches it in background, app creates some calendar event based on notification.

In general it means that "full sync" event can happen at any time.

How to detect and handle "full sync" event?
Observing External Changes to the Calendar Database explains this questions in this way:

It’s possible for another process or app to modify the Calendar database while your app is running. If your app fetches calendar events or reminders, you should register to be notified about changes to the Calendar database. By doing so, you ensure that the calendar and reminder information you display to the user is current.

Here is code sample for registering to such notification: 

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(storeChanged:)
                                             name:EKEventStoreChangedNotification
                                           object:eventStore];

I think it makes sense to recreate instances of EKCalendar classes and recache calendarIdentifier if needed.

What properties are liable to change besides the calendarIdentifier?
I can't find any documentation about this question. But since calendar can even doesn't exist at some moment (for example user manually removes it in Calendar app) then any property of EKCalendar object can be invalid after "full sync" event happens.

Also it makes sense to read above links for more information and details.

Vlad Papko
  • 13,184
  • 4
  • 41
  • 57
  • The "When" part of this answer is incorrect. There's a difference between a normal "Sync" and a "Full Sync". Actions such as renaming a calendar or adding an event do not trigger a full sync, and therefore do not cause the calendarIdentifier to change. See [VolenD's answer](https://stackoverflow.com/a/31631746/4515489) for an example of how to trigger a full sync. – jk7 Jun 06 '22 at 20:48
2

Full sync happens when a calendar is added. All added calendars are cached on the system (iOS or MacOS) and receive a unique ID. This can be easily checked on MacOS - if you go to directory ~/Library/Calendars/ you will see a list with directories like:

3CC21C9A-0B3C-4A76-B2B0-8D3643CF2992.exchange/

45EF644F-672A-453A-ACC9-A565F017F766.calendar/

which are the unique IDs that can be checked with calendarIdentifier.

In order to test how calendarIdentifier changes on iOS you can create a calendar in iCloud with name testcal and use the following code to get the identifier:

EKEventStore *eventStore = [[EKEventStore alloc] init];
NSArray *cal = [eventStore calendarsForEntityType:EKEntityTypeEvent];
for (EKCalendar *i in cal) {
    if([i.title isEqualToString:@"testcal"]) {
        NSLog(@"%@", i.calendarIdentifier);
    }
}

After that, disable the calendar (Settings -> iCloud -> Calendars, choose "Delete from My iPhone") and enable it. When you execute the code again, you will see a different identifier, although the calendar is the same.

Another case where I see that a full sync will be executed is if the local cache is corrupted. In this case the Calendar should try to rebuild it.

So, it is not a good idea to find a calendar by its identifier and you can use title, type, color and etc. to identify it uniquely.

VolenD
  • 3,592
  • 18
  • 23
  • This is the correct answer for what can lead to a full sync that causes calendarIdentifier to change. – jk7 Jun 06 '22 at 20:50
0

Based on iTunes forum, when it is full sync is not specified and depends on them:

http://www.openradar.appspot.com/15671424

https://idmsa.apple.com/IDMSWebAuth/login?appIdKey=4a75046cda87eab6386a9eae8caabb9824e328b9abc988119b39296495ec184c&path=/login.jspa#926856.

Related to the properties which are liable to change are all of them which can be accessed by other threads, (same than calendarIdentifier) hence the ones that are nonatomic and can be changed, here the ones that I could find:

allowsContentModifications, CGColor, immutable,title,type,allowedEntityTypes,source,subscribed,supportedEventAvailabilities
juanmajmjr
  • 1,055
  • 7
  • 11