The EventStore is required to perform any operations in EventKit. It can be thought of as the persistent storage, or database, engine for all EventKit data. From EKEventStore you have access to both the calendars and calendar events in the Calendar Application, as well as reminders in the Reminders Application.

Because EKEventStore is like a database engine, it should be long-lived, meaning that it should be created and destroyed as little as possible during the lifetime of an application instance. In fact, it’s recommended that once you create one instance of an EDEventStore in an application, you keep that reference around for the entire lifetime of the application, unless you’re sure you won’t need it again. Additionally, all calls should go to a single EKEventStore instance. For this reason, the Singleton pattern is recommended for keeping a single instance available.

The following code illustrates an easy and efficient way to create a single instance of the EventStore class and make it available statically from within an application:

public class App
{
	public static App Current {
		get { return current; }
	}
	private static App current;

	public EKEventStore EventStore {
		get { return eventStore; }
	}
	protected EKEventStore eventStore;

	static App ()
	{
		current = new App();
	}
	protected App () 
	{
		eventStore = new EKEventStore ( );
	}
}			
			

The code above uses the Singleton pattern to instantiate an instance of the EventStore when the application loads. The EventStore can then be accessed globally from within the application as follows: App.Current.EventStore;

Before being allowed to access any data via the EKEventStore, an application must first request access to either the calendar events data or reminders data, depending on which one you need. To facilitate this, the KEEventStore exposes a method called RequestAccess which, when called, will show an alert view to the user telling them the application is requesting access to either the calendar data, or reminder data, depending on which EKEntityType is passed to it. Because it raises an alert view, the call is asynchronous and will call a completion handler passed as an NSAction (or Lambda) to it which will receive two parameters, a boolean of whether or not access was granted, and an NSError, which, if not-null will contain any error information in the request. For example, the following coded will request access to calendar event data and show an alert view if the request was not granted:

App.Current.EventStore.RequestAccess (EKEntityType.Event, 
	(bool granted, NSError e) => {
		if (granted)
			//do something here
		else
			new UIAlertView ( "Access Denied", 
"User Denied Access to Calendar Data", null,
"ok", null).Show ();
		} );
			

Once the request has been granted, it will be remembered as long as the application is installed on the device and will not pop up an alert to the user. However, access is only given to the type of resource, either calendar events or reminders granted. If an application needs access to both, it should request both.

Because permission is remembered, it’s relatively cheap to make the request each time, so it’s a good idea to always request access before performing an operation.

Additionally, because the completion handler is called on a separate (non-UI) thread, any updates to the UI in the completion handler should be called via InovkeOnMainThread, otherwise an exception will be thrown, and if not caught, the application will crash.

Requirements