依靠ABAddressBook & EKEventKit 还是我自己的？
我即将开发一个应用程序，该应用程序需要为“客户”安排活动等。我在之前的一个项目（一年前）中曾与 ABAddressBook 合作过，所以知道它的优点和优点。限制。没有使用活动套件的经验。
我相信苹果公司说，如果您依赖这些框架（和数据源），您应该只在您的应用程序中存储 ABRecordID 或 eventIdentifier...那么将来您会检索地址簿对象（或事件对象）并将它们与一些本地数据进行比较，然后再继续？！？
因此，如果我想列出应用程序中的所有用户客户端，我首先构建一个客户端对象数组（其中包含每个客户端的全名和 ABRecordID），然后从 AddressBook 中获取每个 ABRecordID 并将全名与我已存储在本地，然后才在表视图中显示每个客户的姓名？
这看起来很麻烦......而且我什至还没有开始使用日历（尽管 EKEventKit 文档对此信息很少）。这被认为可靠吗？
在我踏上这条道路之前，有人有什么建议吗？
I'm about to embark on an app that will require scheduling of events for "clients" among other things. I've worked with ABAddressBook a bit on a previous project (year ago) so knew then its advantages & limitations. No experience with Event Kit.
I believe Apple says if you rely on these frameworks (and data sources) you should only store the ABRecordID or eventIdentifier in your application...then in the future you'd retrieve the address book object (or the event object) and compare them to some local data before proceeding?!?
So, if I want to list all a user's clients in the app i'd first build an array of client objects (that contain the full name and an ABRecordID for each client) then fetch each ABRecordID from AddressBook and compare the full name to what I've stored locally and only THEN display each client's name in the table view?
This seems cumbersome...and I haven't even started with the calendar (though EKEventKit docs are light on this info). Is this considered reliable?
Anyone have any advice before I embark along this path?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我做了类似的事情。我确实将
eventIdentifier存储在设备上，然后用它来获取事件。这是有风险的，因为文档指出，如果事件的日历发生变化，则 eventIdentifier 属性很可能也会发生变化。似乎没有一种“合理”的方法来存储以编程方式创建的日期并在将来获取它。I did something similar to this. I did indeed store the
eventIdentifieron the device then used it to fetch the event. This is risky since the documentation states that if the calendar of an event changes, the eventIdentifier property will most likely change as well. There doesn't seem to be a "sound" method of storing a programmatically created date and fetching it in the future.