保留用户日历中的事件
我正在开发一个需要记住用户从日历中选择的事件的应用程序，并且我遇到了重复事件的问题。
对于非重复事件，我可以只存储 eventIdentifier 并在需要时从事件存储中获取事件。
但重复发生的事件都共享相同的事件标识符。当我返回事件存储来获取事件（基于事件标识符）时，我得到了重复链中的第一个事件……而不是用户选择的事件的第 N 个重复。
由于 EventKit 不支持 NSCoding，我无法通过归档整个 EKEvent 对象来持久保存用户选择的事件。
我正在考虑存储 eventIdentifier 和 Start &结束日期，以便我可以从事件存储中获取正确的事件...但这看起来相当混乱，并且可能会使跟踪用户在启动我的应用程序之间在日历中所做的更改变得棘手。
有什么想法或建议吗？
I'm working on an App that needs to remember events selected by the user from their calendar and I've run into a problem with recurring events.
For non-recurring events I can just store the eventIdentifier and fetch the event from the Event Store when I need it.
But recurring events all share the same eventIdentifier. When I go back to the Event Store to fetch the event (based on the eventIdentifier) I get the very first event in the recurrence chain ... not the Nth recurrence of the event that the user selected.
I can't persist the user selected events by archiving the entire EKEvent object since EventKit doesn't support NSCoding.
I'm considering storing the eventIdentifier and Start & End dates so that I can fetch the correct event from the Event Store ... but that seems pretty kludgy and might make tracking changes the user makes in their calendar between launches of my App tricky.
Any thoughts or suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
即使对于非重复事件，仅事件标识符也是不够的。事实上，当用户将事件移至不同的日历时，它可能会发生变化。对于重复事件，它可能会在分离事件或拆分重复事件时发生变化。因此，通常的做法是使用信息子集（例如标题、开始和截止日期）来搜索事件。您不应依赖事件标识符。
不幸的是，该框架并没有为我们提供事件的原始数据，它只是提供了指定时间间隔内事件的所有发生情况。因此，不存在这样的事情（使用框架）检索单个重复事件，然后扩展其重复次数以获取其第 n 次出现：您需要手动对检索到的事件进行后处理活动，以便找到您感兴趣的活动。
这里的问题是提供的 API 不适用于同步目的。许多开发人员通过使用 Radar 提交错误/功能请求来抱怨并且仍然抱怨这一点。到目前为止，Apple 的回答是 API 实现了不同的目的，因为同步是自动的。但是，通过 iTunes 同步时确实如此，但以编程方式同步则不然。
The event identifier alone is not enough even for non recurring events. Indeed, it can change when the user moves the event to a different calendar. For recurring events, it may change upon detaching an occurrence or splitting the recurrence.Therefore, it is common practice to search for events using a subset of information (say title, start and due date). You should not rely on event identifiers.
Unfortunately, the framework does not provide us with the raw data of an event, it just provides all of the occurrences of the events in a specified interval. Therefore, there is no such thing (using the framework) as the possibility of retrieving a single recurring event and then expanding its recurrence to get its n-th occurrence: you need to manually post-process the retrieved events in order to find the ones you are interested to.
The problem here is that the APIs provided are not meant for sync purposes. Many developers have complained and still complain about this by filing a bug/feature request using Radar. Until now, Apple answer about is that the APIs fulfill a different purpose, since sync is automatic. However, this is true when syncing through iTunes, but not programmatically.