| 5cd969369a0e025bad07ad32bda9c8c4f0630457 |
|
03-Aug-2012 |
Michael Chan <mchan@android.com> |
Renamed calendarcommon to calendarcommon2 to avoid naming conflict with OEM devices
Change-Id: Ia765b4c17bfc00e283c66c440b8561fcd7b8e4dc
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| 0332925aa9db8c4826327edd85030a4791b7a8e6 |
|
29-Apr-2012 |
Michael Chan <chanm@google.com> |
Fixed so potential memory leaks.
Bug: 6396900
Change-Id: Id02c323b567bfc49ae1da4dbe4335ba150241232
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| fa2f3b5b13ae14bf023aa45120b617e53d42a9dc |
|
17-Mar-2012 |
Alon Albert <aalbert@google.com> |
Move Duration to common
Change-Id: I6a758ff462cd5338e7b12a5c000ab3613addb399
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| d5be35c42732d610040a64dd5bab782ef10014ab |
|
23-Jul-2011 |
Andy McFadden <fadden@android.com> |
Change the way event updates are handled
The previous implementation went to great lengths to avoid hitting
the database any more than necessary. Because event updates may
only be touching a handful of fields, this required handling a
variety of situations in which only partial data was available.
In some cases a few fields were queried from the database.
We want to validate requests more robustly as part of opening the
calendar provider, so we now pull the events out of the database,
merge them with the new values, and validate the result before
issuing the update.
"Bulk" updates are no longer issued as a single database command
(though they do all happen within a single transaction). Each event
update is validated individually. As a result, the partial-update
mechanism may be applied to events edited in bulk.
This doesn't introduce any new validation tests, but some of the
existing tests are now applied more broadly, so there is some risk of
previously-accepted requests being rejected.
The validateEventData() function was split into two parts. The code
that dealt with bad requests by stripping out undesirable fields
is now in scrubEventData(). Long-term we want to eliminate the
"scrub" pass.
Also, fixed the code that updates LAST_DATE in an update transaction
so that changing from a regular event or limited recurrence to an
infinitely-repeating recurrence causes LAST_DATE to be nulled out.
Bug 2519655,5057401
Change-Id: Ic5c510951334a11adb8bdc58c01d863bcf8bc01a
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| bf61571797b7b6a390d35f16aad7765ea348e5ae |
|
13-Jul-2011 |
Andy McFadden <fadden@android.com> |
Move a couple more classes to calendar-common
Move RecurrenceProcessor and DateException, so that app code can
access the recurrence generator. Useful for e.g. bug 4977517.
Change-Id: Id52f51873da0c4214333e17ed3a70987e0f40340
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| 93e0bbb921cce7a5cec355521bc570c03c9d6a1c |
|
07-Jul-2011 |
Andy McFadden <fadden@android.com> |
Relocate common Calendar classes
Move some classes from android.pim to com.android.calendarcommon.
Bug 4575374
Change-Id: I3cb6a59bf761b97973c2590f71bdf8e28575adb0
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| b09eb917f2490a1dae20709a667df845a2e67c94 |
|
28-Jun-2011 |
Andy McFadden <fadden@android.com> |
Tweak instance generation
The code that regenerates the Instances table understands _sync_id
and originalSyncId, but is generally unaware of originalId.
This isn't a supported mode of operation for the app -- you're not
allowed to create a recurrence exception until after the event has
been synchronized with the server -- but you can hit it with the
provider's exception creation URI.
This change doesn't fix the problem, but does take a step toward it.
In particular:
- Deletion of existing instances is now correct. This may be more
visually jarring than the previous approach when creating
exceptions in airplane mode: instead of seeing a doubled-up event,
you'll see the original event vanish (it adds an instance for
the exception, but can't find the recurrence).
- isRecurrenceEvent() now recognizes an event with a non-empty
originalId as a recurrence exception.
- Some stuff in updateRecurrenceInstancesLocked() was hitting the
database, some was assuming that values were in the set of goodies
passed in. This was potentially wrong for event updates, which
could have a partial set of goodies.
- The exception creation URI code now only updates the affected
Instances entries, instead of blowing away the entire table.
Two new tests have been added to exercise the various paths through
the instance regeneration code.
Also, adjusted the code that updates the Attendees table when an
exception changes selfAttendeeStatus to be more tolerant of transient
situations.
Bug 4473786
Change-Id: Ibd409373be002e71d5709ee1c17eb16976481ce2
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| 4caf8d015918f619a67d321a152f150a01022717 |
|
23-Jun-2011 |
Andy McFadden <fadden@android.com> |
There can be only one MetaData
Instead of creating a new MetaData in CalendarInstancesHelper, use
the one created by CalendarProvider2.
Bug 4815094
Change-Id: I88633e4694e7879efaad601536e84cab2bc96e8d
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| b9644fe24edf9e25f0b21c1394e88d25070e0238 |
|
14-Jun-2011 |
RoboErik <epastern@google.com> |
Rename Calendar.java to CalendarContract.java
Change-Id: Iecdf0141d6baeed4a93b4f219a72f7ed8a5b9ff3
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| 9ec70fada3d8f7cf56d6b0d0947823ec5bce572c |
|
04-Jun-2011 |
Alon Albert <aalbert@google.com> |
Prepare Calendar Provider for GData 2.0 & Partial Update
This CL prepares support for GData 2.0 by adding the _SYNC_7 column to the Events table.
This column will contain the edit URL which used to be in SYNC_VERSION but in 2.0, will hold the eTag instead.
It also prepares for Partial Update by adding a column called lastSynced to Events & a column called canPartiallyUpdate to Calendars.
If a sync adapter sets canPartiallyUpdate to 1, the provider will dup events before modifying them locally and mark them as dups using the lastSynced column.
When a sync adapter then updates an event and sets DIRTY to 0, the provider will remove the duplicated event.
Since no sync adapters yet set canPartiallyUpdate or use SYNC_7, this change should effectivly be a NOP.
Change-Id: I651056b3c0306391e9e559ceb185e77187118846
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| 2ce7955da7dffec7819ed38be85e72df8a6f33dc |
|
03-Jun-2011 |
RoboErik <epastern@google.com> |
Support cleanup of Calendar.java
-replaced refs to columns interfaces with the class where possible
-added support for selection/selection args in instance queries
-further cleanup
Change-Id: I97ee0c7ed1703696166fd4a007e232a42cece376
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| c8383567db3ade2aea28447ad3bd09ac3033bcd7 |
|
06-May-2011 |
RoboErik <epastern@google.com> |
Upgrade Calendars table and db to v300
Changes several column names in the calendars table and jumps
the versioning for the db up to 300.
Change-Id: I515b3e0a54d73c8a6d25ca2d9f7c153fae68a210
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|
| f5930ab5c4c0fe728cb8fdf923d482b4f272eb1f |
|
13-Apr-2011 |
RoboErik <epastern@google.com> |
Refactors CP2 to pull instances code into a separate file
Change-Id: I2e6046dcdec0f134724d8220525bd2395677f19e
/packages/providers/CalendarProvider/src/com/android/providers/calendar/CalendarInstancesHelper.java
|