Qu'est-ce qui constitue exactement une "synchronisation complète du calendar" dans EKCalendar?

La documentation de la class EKCalendar indique pour la propriété calendarIdentifier :

Une synchronisation complète avec le calendar perdra cet identifiant. Vous devriez avoir un plan pour traiter un calendar dont l'identifiant n'est plus récupérable en mettant en cache ses autres propriétés.

Quand exactement se produit une "synchronisation complète" et quelles propriétés sont susceptibles de changer en plus de l'identifiant calendarIdentifier ?

Quand exactement une "synchronisation complète" se produit-elle?
Le Guide de programmation du calendar et des callbacks explique ces questions de cette façon:

Si une modification de la database Calendrier se produit à l'extérieur de votre application, le kit d'events est en mesure de détecter la modification par notification afin que votre application puisse agir de manière appropriée. Les modifications apscopes aux éléments du calendar avec le kit d'events sont automatiquement synchronisées avec le calendar associé (CalDAV, Exchange, etc.).

Je vois de tels scénarios d'events "full sync" pendant que votre application est ouverte:
1. L' user envoie votre application en arrière-plan et ouvre l'application Calendrier. Il modifie le nom du calendar, ajoute / modifie / supprime des events ou supprime même un calendar.
2. L' user applique quelques modifications au calendar iCloud sur Mac. L'appareil iOS est averti que le calendar iCloud a été modifié de sorte qu'il doit être synchronisé.
3. L' application tierce reçoit une notification silencieuse, iOS la lance en arrière-plan, l'application crée un événement d'agenda basé sur la notification.

En général, cela signifie que l'événement "synchronisation complète" peut se produire à tout moment.

Comment détecter et gérer l'événement "full sync"?
L'observation des modifications externes de la database du calendar explique ces questions de cette manière:

Il est possible qu'un autre process ou une autre application modifie la database Calendrier lorsque votre application est en cours d'exécution. Si votre application récupère des events ou des callbacks d'agenda, vous devez vous inscrire pour être averti des modifications apscopes à la database Calendrier. Ce faisant, vous vous assurez que les informations de calendar et de callback que vous affichez à l'user sont à jour.

Voici un exemple de code pour l'inscription à une telle notification:

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

Je pense qu'il est logique de recréer des instances de classs EKCalendar et recache calendarIdentifier si nécessaire.

Quelles propriétés sont susceptibles de changer en plus de l'identifiant calendarIdentifier?
Je ne trouve aucune documentation sur cette question. Mais puisque le calendar peut même ne pas exister à un moment donné (par exemple, l'user le supprime manuellement dans l'application Calendrier) alors toute propriété de l'object EKCalendar peut être invalide après que l'événement "synchronisation complète" se produise.

Aussi, il est logique de lire les liens ci-dessus pour plus d'informations et de détails.

La synchronisation complète se produit lorsqu'un calendar est ajouté. Tous les calendars ajoutés sont mis en cache sur le système (iOS ou MacOS) et reçoivent un identifiant unique. Cela peut être facilement vérifié sur MacOS – si vous allez dans le directory ~/Library/Calendars/ vous verrez une list avec des directorys comme:

 3CC21C9A-0B3C-4A76-B2B0-8D3643CF2992.exchange/ 45EF644F-672A-453A-ACC9-A565F017F766.calendar/ 

qui sont les identifiants uniques qui peuvent être vérifiés avec calendarIdentifier .

Afin de tester comment les modifications de calendarIdentifier sur iOS, vous pouvez créer un calendar dans iCloud avec le nom testcal et utiliser le code suivant pour get l'identifiant:

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

Après cela, désactivez le calendar (Paramètres -> iCloud -> Calendriers, choisissez "Supprimer de mon iPhone") et activez-le. Lorsque vous exécutez à nouveau le code, vous verrez un identifiant différent, bien que le calendar soit le même.

Un autre cas où je vois qu'une synchronisation complète sera exécutée est si le cache local est corrompu. Dans ce cas, le calendar devrait essayer de le rebuild.

Donc, ce n'est pas une bonne idée de find un calendar par son identifiant et vous pouvez utiliser le titre, le type, la couleur et etc. pour l'identifier uniquement.

Basé sur le forum iTunes, quand il est en pleine synchronisation n'est pas spécifié et dépend d'eux:

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

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

Reliées aux propriétés qui sont susceptibles de changer sont toutes celles qui peuvent être accédées par d'autres threads, (même que calendarIdentifier ), donc celles qui ne sont pas atomiques et peuvent être changées, ici celles que j'ai pu find:

 allowsContentModifications, CGColor, immutable,title,type,allowedEntityTypes,source,subscribed,supportedEventAvailabilities