Update calendar of .end instances via events.dtend

Question

When I update the CalendarContract.Events DTEND column, why doesn't this change appear in the CalendarContract.Instances END column?

My application allows the user to view and change calendar events using the CalendarContract.Events API. The code updates the Events table, and then reads it back (later) using the Instances table. For example, changes in TITLE work fine (i.e. I am updating events and can read the change in instances). Changes to Events.DTEND do indeed appear in Instances.DTEND, but how can I get this update so that it also appears in .END instances?

This is important because, apparently, the Android calendar application (and my application too) uses .BEGIN instances and .END instances to determine what to display on 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 is to add a 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"); 

Warning: this case only shows how to update non-recursive events. One-time events have a null value of RRULE.

I suspect that the provider code uses only the values ​​that you provide, instead of updating the start date first (obviously, if the user changes the start date that you would have to provide anyway). This makes sense in terms of reducing access to db. Too bad Google has not documented anything.