Programming iOS 6, 3rd Edition

Calendar Database

The calendar database is accessed as an instance of the EKEventStore class. This instance is expensive to obtain but lightweight to maintain, so your usual strategy, in an app where you’ll be working with the user’s calendar database, will be to instantiate EKEventStore (by calling [EKEventStore new]) early in the life of the app or of some other appropriate object, such as a view controller, and to maintain that instance in an instance variable until you no longer need it. That’s the strategy adopted by the examples in this chapter; my EKEventStore instance is called self.database throughout.

New in iOS 6, an attempt to work with the calendar database will fail unless the user has authorized access. You should start by calling authorizationStatusForEntityType: with either EKEntityTypeEvent (to work with calendar events) or EKEntityTypeReminder (to work with reminders). If the returned EKAuthorizationStatus is EKAuthorizationStatusNotDetermined, you can call requestAccessToEntityType:completion:, with a non-nil completion block taking a BOOL and an NSError; this causes a system alert to appear, prompting the user to grant your app permission to access the user’s Calendar or Reminders. You can modify the body of this alert by setting the “Privacy — Calendars Usage Description” key (NSCalendarsUsageDescription) or the “Privacy — Reminders Usage Description” key (NSRemindersUsageDescription) in your app’s Info.plist to tell the user why you want to access the database. ...