The Calendar Provider is a repository for a user's calendar events. The Calendar Provider API allows you to perform query, insert, update, and delete operations on calendars, events, attendees, reminders, and so on.
The Calender Provider API can be used by applications and sync adapters. The rules vary depending on what type of program is making the calls. This document focuses primarily on using the Calendar Provider API as an application. For a discussion of how sync adapters are different, see Sync Adapters.
Normally, to read or write calendar data, an application's manifest must include the proper permissions, described in User Permissions. To make performing common operations easier, the Calendar Provider offers a set of intents, as described in Calendar Intents. These intents take users to the Calendar application to insert, view, and edit events. The user interacts with the Calendar application and then returns to the original application. Thus your application doesn't need to request permissions, nor does it need to provide a user interface to view or create events.
Basics
Content providers store data and make it accessible to applications. The content providers offered by the Android platform (including the Calendar Provider) typically expose data as a set of tables based on a relational database model, where each row is a record and each column is data of a particular type and meaning. Through the Calendar Provider API, applications and sync adapters can get read/write access to the database tables that hold a user's calendar data.
Every content provider exposes a public URI (wrapped as a Uri object) that uniquely identifies its data set. A content provider that controls multiple data sets (multiple tables) exposes a separate URI for each one. All URIs for providers begin with the string "content://". This identifies the data as being controlled by a content provider. The Calendar Provider defines constants for the URIs for each of its classes (tables). These URIs have the format .CONTENT_URI. For example, Events.CONTENT_URI.
Figure 1 shows a graphical representation of the Calendar Provider data model. It shows the main tables and the fields that link them to each other.
Figure 1. Calendar Provider data model.
A user can have multiple calendars, and different calendars can be associated with different types of accounts (Google Calendar, Exchange, and so on).
The CalendarContract defines the data model of calendar and event related information. This data is stored in a number of tables, listed below.
| Table (Class) | Description |
CalendarContract.Calendars
| This table holds the calendar-specific information. Each row in this table contains the details for a single calendar, such as the name, color, sync information, and so on. |
CalendarContract.Events | This table holds the event-specific information. Each row in this table has the information for a single event—for example, event title, location, start time, end time, and so on. The event can occur one-time or can recur multiple times. Attendees, reminders, and extended properties are stored in separate tables. They each have an EVENT_ID that references the _ID in the Events table. |
CalendarContract.Instances | This table holds the start and end time for each occurrence of an event. Each row in this table represents a single event occurrence. For one-time events there is a 1:1 mapping of instances to events. For recurring events, multiple rows are automatically generated that correspond to multiple occurrences of that event. |
CalendarContract.Attendees | This table holds the event attendee (guest) information. Each row represents a single guest of an event. It specifies the type of guest and the guest's attendance response for the event. |
CalendarContract.Reminders | This table holds the alert/notification data. Each row represents a single alert for an event. An event can have multiple reminders. The maximum number of reminders per event is specified in MAX_REMINDERS, which is set by the sync adapter that owns the given calendar. Reminders are specified in minutes before the event and have a method that determines how the user will be alerted. |
The Calendar Provider API is designed to be flexible and powerful. At the same time, it's important to provide a good end user experience and protect the integrity of the calendar and its data. To this end, here are some things to keep in mind when using the API:
- Inserting, updating, and viewing calendar events. To directly insert, modify, and read events from the Calendar Provider, you need the appropriate permissions. However, if you're not building a full-fledged calendar application or sync adapter, requesting these permissions isn't necessary. You can instead use intents supported by Android's Calendar application to hand off read and write operations to that application. When you use the intents, your application sends users to the Calendar application to perform the desired operation in a pre-filled form. After they're done, they're returned to your application. By designing your application to perform common operations through the Calendar, you provide users with a consistent, robust user interface. This is the recommended approach. For more information, see Calendar Intents.
- Sync adapters. A sync adapter synchronizes the calendar data on a user's device with another server or data source. In the
CalendarContract.Calendars and CalendarContract.Events tables, there are columns that are reserved for the sync adapters to use. The provider and applications should not modify them. In fact, they are not visible unless they are accessed as a sync adapter. For more information about sync adapters, see Sync Adapters.
User Permissions
To read calendar data, an application must include the READ_CALENDAR permission in its manifest file. It must include the WRITE_CALENDAR permission to delete, insert or update calendar data:
xml version="1.0" encoding="utf-8"?>
xmlns:android="http://schemas.android.com/apk/res/android"...>
android:minSdkVersion="14" />
android:name="android.permission.READ_CALENDAR" />
android:name="android.permission.WRITE_CALENDAR" />
...
Calendars Table
The CalendarContract.Calendars table contains details for individual calendars. The following Calendars columns are writable by both an application and a sync adapter. For a full list of supported fields, see the CalendarContract.Calendars reference.
| Constant | Description |
NAME | The name of the calendar. |
CALENDAR_DISPLAY_NAME | The name of this calendar that is displayed to the user. |
VISIBLE | A boolean indicating whether the calendar is selected to be displayed. A value of 0 indicates that events associated with this calendar should not be shown. A value of 1 indicates that events associated with this calendar should be shown. This value affects the generation of rows in the CalendarContract.Instances table. |
SYNC_EVENTS | A boolean indicating whether the calendar should be synced and have its events stored on the device. A value of 0 says do not sync this calendar or store its events on the device. A value of 1 says sync events for this calendar and store its events on the device. |
Querying a calendar
Here is an example that shows how to get all the calendars for a particular user. For simplicity's sake, in this example the query operation is shown in the user interface thread ("main thread"). In practice, this should be done in an asynchronous thread instead of on the main thread. For more discussion, see Loaders. If you are not just reading data but modifying it, see AsyncQueryHandler.
// Projection array. Creating indices for this array instead of doing
// dynamic lookups improves performance.
public static final String[] EVENT_PROJECTION = new String[] {
Calendars._ID, // 0
Calendars.ACCOUNT_NAME, // 1
Calendars.CALENDAR_DISPLAY_NAME // 2
};
// The indices for the projection array above.
private static final int PROJECTION_ID_INDEX = 0;
private static final int PROJECTION_ACCOUNT_NAME_INDEX = 1;
private static final int PROJECTION_DISPLAY_NAME_INDEX = 2;
Why must you include ACCOUNT_TYPE?
If you query on a Calendars.ACCOUNT_NAME, you must also include Calendars.ACCOUNT_TYPE in the selection. That is because a given account is only considered unique given both its ACCOUNT_NAME and its ACCOUNT_TYPE. The ACCOUNT_TYPE is the string corresponding to the account authenticator that was used when the account was registered with the AccountManager. There is also a special type of account called ACCOUNT_TYPE_LOCAL for calendars not associated with a device account. ACCOUNT_TYPE_LOCAL accounts do not get synced.
In the next part of the example, you construct your query. The selection specifies the criteria for the query. In this example the query is looking for all calendars that have the ACCOUNT_NAME "sampleuser@google.com" and the ACCOUNT_TYPE "com.google". The query returns a Cursor object that you can use to traverse the result set returned by the database query. For more discussion of using queries in content providers, see Content Providers.
// Run query
Cursor cur = null;
ContentResolver cr = getContentResolver();
Uri uri = Calendars.CONTENT_URI;
String selection = "((" + Calendars.ACCOUNT_NAME + " = ?) AND ("
+ Calendars.ACCOUNT_TYPE + " = ?))";
String[] selectionArgs = new String[] {"sampleuser@gmail.com", "com.google"};
// Submit the query and get a Cursor object back.
cur = cr.query(uri, EVENT_PROJECTION, selection, selectionArgs, null);
This next section uses the cursor to step through the result set. It uses the constants that were set up at the beginning of the example to return the values for each field.
// Use the cursor to step through the returned records
while (cur.moveToNext()) {
long calID = 0;
String displayName = null;
String accountName = null;
// Get the field values
calID = cur.getLong(PROJECTION_ID_INDEX);
displayName = cur.getString(PROJECTION_DISPLAY_NAME_INDEX);
accountName = cur.getString(PROJECTION_ACCOUNT_NAME_INDEX);
// Do something with the values...
...
}
Modifying a calendar
To perform an update of an calendar, you can provide the _ID of the calendar either as an appended ID to the Uri (withAppendedId()) or as the first selection item. The selection should start with "_id=?", and the first selectionArg should be the _ID of the calendar. You can also do updates by encoding the ID in the URI. This example changes a calendar's display name using the (withAppendedId()) approach:
private static final String DEBUG_TAG = "MyActivity";
...
long calID = 2;
ContentValues values = new ContentValues();
// The new display name for the calendar
values.put(Calendars.CALENDAR_DISPLAY_NAME, "Trevor's Calendar");
Uri updateUri = ContentUris.withAppendedId(Calendars.CONTENT_URI, calID);
int rows = getContentResolver().update(updateUri, values, null, null);
Log.i(DEBUG_TAG, "Rows updated: " + rows);
Inserting a calendar
Calendars are designed to be primarily managed by a sync adapter, so you should only insert new calendars as a sync adapter. For the most part, applications can only make superficial changes to calendars, such as changing the display name. If an application needs to create a local calendar, it can do this by performing the calendar insertion as a sync adapter, using an ACCOUNT_TYPE of ACCOUNT_TYPE_LOCAL. ACCOUNT_TYPE_LOCAL is a special account type for calendars that are not associated with a device account. Calendars of this type are not synced to a server. For a discussion of sync adapters, see Sync Adapters.
Events Table
The CalendarContract.Events table contains details for individual events. To add, update, or delete events, an application must include the WRITE_CALENDAR permission in its manifest file.
The following Events columns are writable by both an application and a sync adapter. For a full list of supported fields, see the CalendarContract.Events reference.
| Constant | Description |
CALENDAR_ID | The _ID of the calendar the event belongs to. |
ORGANIZER | Email of the organizer (owner) of the event. |
TITLE | The title of the event. |
EVENT_LOCATION | Where the event takes place. |
DESCRIPTION | The description of the event. |
DTSTART | The time the event starts in UTC milliseconds since the epoch. |
DTEND | The time the event ends in UTC milliseconds since the epoch. |
EVENT_TIMEZONE | The time zone for the event. |
EVENT_END_TIMEZONE | The time zone for the end time of the event. |
DURATION | The duration of the event in RFC5545 format. For example, a value of "PT1H" states that the event should last one hour, and a value of "P2W" indicates a duration of 2 weeks. |
ALL_DAY | A value of 1 indicates this event occupies the entire day, as defined by the local time zone. A value of 0 indicates it is a regular event that may start and end at any time during a day. |
RRULE | The recurrence rule for the event format. For example, "FREQ=WEEKLY;COUNT=10;WKST=SU". You can find more examples here. |
RDATE | The recurrence dates for the event. You typically use RDATE in conjunction with RRULE to define an aggregate set of repeating occurrences. For more discussion, see the RFC5545 spec. |
AVAILABILITY | If this event counts as busy time or is free time that can be scheduled over. |
GUESTS_CAN_MODIFY | Whether guests can modify the event. |
GUESTS_CAN_INVITE_OTHERS | Whether guests can invite other guests. |
GUESTS_CAN_SEE_GUESTS | Whether guests can see the list of attendees. |
Adding Events
When your application inserts a new event, we recommend that you use an INSERT Intent, as described in Using an intent to insert an event. However, if you need to, you can insert events directly. This section describes how to do this.
Here are the rules for inserting a new event:
- You must include
CALENDAR_ID and DTSTART. - You must include an
EVENT_TIMEZONE. To get a list of the system's installed time zone IDs, use getAvailableIDs(). Note that this rule does not apply if you're inserting an event through the INSERT Intent, described in Using an intent to insert an event—in that scenario, a default time zone is supplied. - For non-recurring events, you must include
DTEND. - For recurring events, you must include a
DURATION in addition to RRULE or RDATE. Note that this rule does not apply if you're inserting an event through the INSERT Intent, described in Using an intent to insert an event—in that scenario, you can use an RRULE in conjunction with DTSTART and DTEND, and the Calendar application converts it to a duration automatically.
Here is an example of inserting an event. This is being performed in the UI thread for simplicity. In practice, inserts and updates should be done in an asynchronous thread to move the action into a background thread. For more information, see AsyncQueryHandler.
long calID = 3;
long startMillis = 0;
long endMillis = 0;
Calendar beginTime = Calendar.getInstance();
beginTime.set(2012, 9, 14, 7, 30);
startMillis = beginTime.getTimeInMillis();
Calendar endTime = Calendar.getInstance();
endTime.set(2012, 9, 14, 8, 45);
endMillis = endTime.getTimeInMillis();
...
ContentResolver cr = getContentResolver();
ContentValues values = new ContentValues();
values.put(Events.DTSTART, startMillis);
values.put(Events.DTEND, endMillis);
values.put(Events.TITLE, "Jazzercise");
values.put(Events.DESCRIPTION, "Group workout");
values.put(Events.CALENDAR_ID, calID);
values.put(Events.EVENT_TIMEZONE, "America/Los_Angeles");
Uri uri = cr.insert(Events.CONTENT_URI, values);
// get the event ID that is the last element in the Uri
long eventID = Long.parseLong(uri.getLastPathSegment());
//
// ... do something with event ID
//
//
Note: See how this example captures the event ID after the event is created. This is the easiest way to get an event ID. You often need the event ID to perform other calendar operations—for example, to add attendees or reminders to an event.
Updating Events
When your application wants to allow the user to edit an event, we recommend that you use an EDIT Intent, as described in Using an intent to edit an event. However, if you need to, you can edit events directly. To perform an update of an Event, you can provide the _ID of the event either as an appended ID to the Uri (withAppendedId()) or as the first selection item. The selection should start with "_id=?", and the first selectionArg should be the _ID of the event. You can also do updates using a selection with no ID. Here is an example of updating an event. It changes the title of the event using the withAppendedId() approach:
private static final String DEBUG_TAG = "MyActivity";
...
long eventID = 188;
...
ContentResolver cr = getContentResolver();
ContentValues values = new ContentValues();
Uri updateUri = null;
// The new title for the event
values.put(Events.TITLE, "Kickboxing");
myUri = ContentUris.withAppendedId(Events.CONTENT_URI, eventID);
int rows = getContentResolver().update(updateUri, values, null, null);
Log.i(DEBUG_TAG, "Rows updated: " + rows);
Deleting Events
You can delete an event either by its _ID as an appended ID on the URI, or by using standard selection. If you use an appended ID, you can't also do a selection. There are two versions of delete: as an application and as a sync adapter. An application delete sets the deleted column to 1. This flag that tells the sync adapter that the row was deleted and that this deletion should be propagated to the server. A sync adapter delete removes the event from the database along with all its associated data. Here is an example of application deleting an event through its _ID:
private static final String DEBUG_TAG = "MyActivity";
...
long eventID = 201;
...
ContentResolver cr = getContentResolver();
ContentValues values = new ContentValues();
Uri deleteUri = null;
deleteUri = ContentUris.withAppendedId(Events.CONTENT_URI, eventID);
int rows = getContentResolver().delete(deleteUri, null, null);
Log.i(DEBUG_TAG, "Rows deleted: " + rows);
Attendees Table
Each row of the CalendarContract.Attendees table represents a single attendee or guest of an event. Calling query() returns a list of attendees for the event with the given EVENT_ID. This EVENT_ID must match the _ID of a particular event.
The following table lists the writable fields. When inserting a new attendee, you must include all of them except ATTENDEE_NAME.
| Constant | Description |
EVENT_ID | The ID of the event. |
ATTENDEE_NAME | The name of the attendee. |
ATTENDEE_EMAIL | The email address of the attendee. |
ATTENDEE_RELATIONSHIP | The relationship of the attendee to the event. One of: RELATIONSHIP_ATTENDEERELATIONSHIP_NONERELATIONSHIP_ORGANIZERRELATIONSHIP_PERFORMERRELATIONSHIP_SPEAKER
|
ATTENDEE_TYPE | The type of attendee. One of: TYPE_REQUIREDTYPE_OPTIONAL
|
ATTENDEE_STATUS | The attendance status of the attendee. One of: ATTENDEE_STATUS_ACCEPTEDATTENDEE_STATUS_DECLINEDATTENDEE_STATUS_INVITEDATTENDEE_STATUS_NONEATTENDEE_STATUS_TENTATIVE
|
Adding Attendees
Here is an example that adds a single attendee to an event. Note that the EVENT_ID is required:
long eventID = 202;
...
ContentResolver cr = getContentResolver();
ContentValues values = new ContentValues();
values.put(Attendees.ATTENDEE_NAME, "Trevor");
values.put(Attendees.ATTENDEE_EMAIL, "trevor@example.com");
values.put(Attendees.ATTENDEE_RELATIONSHIP, Attendees.RELATIONSHIP_ATTENDEE);
values.put(Attendees.ATTENDEE_TYPE, Attendees.TYPE_OPTIONAL);
values.put(Attendees.ATTENDEE_STATUS, Attendees.ATTENDEE_STATUS_INVITED);
values.put(Attendees.EVENT_ID, eventID);
Uri uri = cr.insert(Attendees.CONTENT_URI, values);
Reminders Table
Each row of the CalendarContract.Reminders table represents a single reminder for an event. Calling query() returns a list of reminders for the event with the given EVENT_ID.
The following table lists the writable fields for reminders. All of them must be included when inserting a new reminder. Note that sync adapters specify the types of reminders they support in the CalendarContract.Calendars table. See ALLOWED_REMINDERS for details.
| Constant | Description |
EVENT_ID | The ID of the event. |
MINUTES | The minutes prior to the event that the reminder should fire. |
METHOD | The alarm method, as set on the server. One of: METHOD_ALERTMETHOD_DEFAULTMETHOD_EMAILMETHOD_SMS
|
Adding Reminders
This example adds a reminder to an event. The reminder fires 15 minutes before the event.
long eventID = 221;
...
ContentResolver cr = getContentResolver();
ContentValues values = new ContentValues();
values.put(Reminders.MINUTES, 15);
values.put(Reminders.EVENT_ID, eventID);
values.put(Reminders.METHOD, Reminders.METHOD_ALERT);
Uri uri = cr.insert(Reminders.CONTENT_URI, values);
Instances Table
The CalendarContract.Instances table holds the start and end time for occurrences of an event. Each row in this table represents a single event occurrence. The instances table is not writable and only provides a way to query event occurrences.
The following table lists some of the fields you can query on for an instance. Note that time zone is defined by KEY_TIMEZONE_TYPE and KEY_TIMEZONE_INSTANCES.
| Constant | Description |
BEGIN | The beginning time of the instance, in UTC milliseconds. |
END | The ending time of the instance, in UTC milliseconds. |
END_DAY | The Julian end day of the instance, relative to the Calendar's time zone. |
END_MINUTE | The end minute of the instance measured from midnight in the the Calendar's time zone. |
EVENT_ID | The _ID of the event for this instance. |
START_DAY | The Julian start day of the instance, relative to the Calendar's time zone. |
START_MINUTE | The start minute of the instance measured from midnight, relative to the Calendar's time zone. |
Querying the Instances table
To query the Instances table, you need to specify a range time for the query in the URI. In this example, CalendarContract.Instances gets access to the TITLE field through its implementation of the CalendarContract.EventsColumns interface. In other words, TITLE is returned through a database view, not through querying the raw CalendarContract.Instances table.
private static final String DEBUG_TAG = "MyActivity";
public static final String[] INSTANCE_PROJECTION = new String[] {
Instances.EVENT_ID, // 0
Instances.BEGIN, // 1
Instances.TITLE // 2
};
// The indices for the projection array above.
private static final int PROJECTION_ID_INDEX = 0;
private static final int PROJECTION_BEGIN_INDEX = 1;
private static final int PROJECTION_TITLE_INDEX = 2;
...
// Specify the date range you want to search for recurring
// event instances
Calendar beginTime = Calendar.getInstance();
beginTime.set(2011, 9, 23, 8, 0);
long startMillis = beginTime.getTimeInMillis();
Calendar endTime = Calendar.getInstance();
endTime.set(2011, 10, 24, 8, 0);
long endMillis = endTime.getTimeInMillis();
Cursor cur = null;
ContentResolver cr = getContentResolver();
// The ID of the recurring event whose instances you are searching
// for in the Instances table
String selection = Instances.EVENT_ID + " = ?";
String[] selectionArgs = new String[] {"207"};
// Construct the query with the desired date range.
Uri.Builder builder = Instances.CONTENT_URI.buildUpon();
ContentUris.appendId(builder, startMillis);
ContentUris.appendId(builder, endMillis);
// Submit the query
cur = cr.query(builder.build(),
INSTANCE_PROJECTION,
selection,
selectionArgs,
null);
while (cur.moveToNext()) {
String title = null;
long eventID = 0;
long beginVal = 0;
// Get the field values
eventID = cur.getLong(PROJECTION_ID_INDEX);
beginVal = cur.getLong(PROJECTION_BEGIN_INDEX);
title = cur.getString(PROJECTION_TITLE_INDEX);
// Do something with the values.
Log.i(DEBUG_TAG, "Event: " + title);
Calendar calendar = Calendar.getInstance();
calendar.setTimeInMillis(beginVal);
DateFormat formatter = new SimpleDateFormat("MM/dd/yyyy");
Log.i(DEBUG_TAG, "Date: " + formatter.format(calendar.getTime()));
}
}
Calendar Intents
Your application doesn't need permissions to read and write calendar data. It can instead use intents supported by Android's Calendar application to hand off read and write operations to that application. The following table lists the intents supported by the Calendar Provider:
| Action | URI | Description | Extras |
VIEW
| content://com.android.calendar/time/
You can also refer to the URI with CalendarContract.CONTENT_URI. For an example of using this intent, see Using intents to view calendar data. | Open calendar to the time specified by | None. |
VIEW
| content://com.android.calendar/events/
You can also refer to the URI with Events.CONTENT_URI. For an example of using this intent, see Using intents to view calendar data. | View the event specified by | CalendarContract.EXTRA_EVENT_BEGIN_TIME
CalendarContract.EXTRA_EVENT_END_TIME |
EDIT | content://com.android.calendar/events/
You can also refer to the URI with Events.CONTENT_URI. For an example of using this intent, see Using an intent to edit an event. | Edit the event specified by | CalendarContract.EXTRA_EVENT_BEGIN_TIME
CalendarContract.EXTRA_EVENT_END_TIME |
EDIT
INSERT | content://com.android.calendar/events
You can also refer to the URI with Events.CONTENT_URI. For an example of using this intent, see Using an intent to insert an event. | Create an event. | Any of the extras listed in the table below. |
The following table lists the intent extras supported by the Calendar Provider:
| Intent Extra | Description |
Events.TITLE | Name for the event. |
CalendarContract.EXTRA_EVENT_BEGIN_TIME | Event begin time in milliseconds from the epoch. |
CalendarContract.EXTRA_EVENT_END_TIME | Event end time in milliseconds from the epoch. |
CalendarContract.EXTRA_EVENT_ALL_DAY | A boolean that indicates that an event is all day. Value can be true or false. |
Events.EVENT_LOCATION | Location of the event. |
Events.DESCRIPTION | Event description. |
Intent.EXTRA_EMAIL | Email addresses of those to invite as a comma-separated list. |
Events.RRULE | The recurrence rule for the event. |
Events.ACCESS_LEVEL | Whether the event is private or public. |
Events.AVAILABILITY | If this event counts as busy time or is free time that can be scheduled over. |
The following sections describe how to use these intents.
Using an intent to insert an event
Using the INSERT Intent lets your application hand off the event insertion task to the Calendar itself. With this approach, your application doesn't even need to have the WRITE_CALENDAR permission included in its manifest file.
When users run an application that uses this approach, the application sends them to the Calendar to finish adding the event. The INSERT Intent uses extra fields to pre-populate a form with the details of the event in the Calendar. Users can then cancel the event, edit the form as needed, or save the event to their calendars.
Here is a code snippet that schedules an event on January 19, 2012, that runs from 7:30 a.m. to 8:30 a.m. Note the following about this code snippet:
- It specifies
Events.CONTENT_URI as the Uri. - It uses the
CalendarContract.EXTRA_EVENT_BEGIN_TIME and CalendarContract.EXTRA_EVENT_END_TIME extra fields to pre-populate the form with the time of the event. The values for these times must be in UTC milliseconds from the epoch. - It uses the
Intent.EXTRA_EMAIL extra field to provide a comma-separated list of invitees, specified by email address.
Calendar beginTime = Calendar.getInstance();
beginTime.set(2012, 0, 19, 7, 30);
Calendar endTime = Calendar.getInstance();
endTime.set(2012, 0, 19, 8, 30);
Intent intent = new Intent(Intent.ACTION_INSERT)
.setData(Events.CONTENT_URI)
.putExtra(CalendarContract.EXTRA_EVENT_BEGIN_TIME, beginTime.getTimeInMillis())
.putExtra(CalendarContract.EXTRA_EVENT_END_TIME, endTime.getTimeInMillis())
.putExtra(Events.TITLE, "Yoga")
.putExtra(Events.DESCRIPTION, "Group class")
.putExtra(Events.EVENT_LOCATION, "The gym")
.putExtra(Events.AVAILABILITY, Events.AVAILABILITY_BUSY)
.putExtra(Intent.EXTRA_EMAIL, "rowan@example.com,trevor@example.com");
startActivity(intent);
Using an intent to edit an event
You can update an event directly, as described in Updating events. But using the EDIT Intent allows an application that doesn't have permission to hand off event editing to the Calendar application. When users finish editing their event in Calendar, they're returned to the original application.
Here is an example of an intent that sets a new title for a specified event and lets users edit the event in the Calendar.
long eventID = 208;
Uri uri = ContentUris.withAppendedId(Events.CONTENT_URI, eventID);
Intent intent = new Intent(Intent.ACTION_EDIT)
.setData(uri)
.putExtra(Events.TITLE, "My New Title");
startActivity(intent);
Using intents to view calendar data
Calender Provider offers two different ways to use the VIEW Intent:
- To open the Calendar to a particular date.
- To view an event.
Here is an example that shows how to open the Calendar to a particular date:
// A date-time specified in milliseconds since the epoch.
long startMillis;
...
Uri.Builder builder = CalendarContract.CONTENT_URI.buildUpon();
builder.appendPath("time");
ContentUris.appendId(builder, startMillis);
Intent intent = new Intent(Intent.ACTION_VIEW)
.setData(builder.build());
startActivity(intent);
Here is an example that shows how to open an event for viewing:
long eventID = 208;
...
Uri uri = ContentUris.withAppendedId(Events.CONTENT_URI, eventID);
Intent intent = new Intent(Intent.ACTION_VIEW)
.setData(uri);
startActivity(intent);
Sync Adapters
There are only minor differences in how an application and a sync adapter access the Calendar Provider:
- A sync adapter needs to specify that it's a sync adapter by setting
CALLER_IS_SYNCADAPTER to true. - A sync adapter needs to provide an
ACCOUNT_NAME and an ACCOUNT_TYPE as query parameters in the URI. - A sync adapter has write access to more columns than an application or widget. For example, an application can only modify a few characteristics of a calendar, such as its name, display name, visibility setting, and whether the calendar is synced. By comparison, a sync adapter can access not only those columns, but many others, such as calendar color, time zone, access level, location, and so on. However, a sync adapter is restricted to the
ACCOUNT_NAME and ACCOUNT_TYPE it specified.
Here is a helper method you can use to return a URI for use with a sync adapter:
static Uri asSyncAdapter(Uri uri, String account, String accountType) {
return uri.buildUpon()
.appendQueryParameter(android.provider.CalendarContract.CALLER_IS_SYNCADAPTER,"true")
.appendQueryParameter(Calendars.ACCOUNT_NAME, account)
.appendQueryParameter(Calendars.ACCOUNT_TYPE, accountType).build();
}
