Question

When I update the CalendarContract.Events DTEND column, why doesn’t the change show up in the CalendarContract.Instances END column?

My app allows the user to view and change calendar events using the CalendarContract.Events APIs. The code performs an update to the Events table and then reads it back (later) using the Instances table. Changes to TITLE, for example, work fine (that is, I update Events and can read back the change in Instances). Changes to Events.DTEND do show up in Instances.DTEND, but how can I get that update to also show up in Instances.END?

This is important since, evidently, the Android calendar app (and my app, too) uses Instances.BEGIN and Instances.END to determine what to display in the calendar.

Here is my update code:

  ContentResolver cr = getContentResolver();
  ContentValues values = new ContentValues();
  values.put (Events.CALENDAR_ID, calendarId);
  values.put (Events.TITLE, title);
  values.put (Events.DTEND, eventEnd.getTimeInMillis());
  String where = "_id =" + eventId +
                 " and " + CALENDAR_ID + "=" + calendarId;
  int count = cr.update (Events.CONTENT_URI, values, where, null);
  if (count != 1)
     throw new IllegalStateException ("more than one row updated");

Thanks.

Answer 1

The solution turns out to be adding the start date:

  ContentResolver cr = getContentResolver();
  ContentValues values = new ContentValues();
  values.put (Events.CALENDAR_ID, calendarId);
  values.put (Events.TITLE, title);
  values.put (Events.DTSTART, eventStart.getTimeInMillis());
  values.put (Events.DTEND, eventEnd.getTimeInMillis());
  String where = "_id =" + eventId +
                 " and " + CALENDAR_ID + "=" + calendarId;
  int count = cr.update (Events.CONTENT_URI, values, where, null);
  if (count != 1)
     throw new IllegalStateException ("more than one row updated");

A word of caution: this case only shows how to update nonrecurring events. Nonrecurring events have a null RRULE.

I suspect what the provider code is doing is using only the values you provide instead of refetching the start date itself (obviously if the user changes the start date you would have to provide it anyway). This makes sense from the perspective of reducing db accesses. Too bad Google didn’t document any of this.