After looking in the source repo I'd have to say the database design of both Contacts and Calendar is unsuitable for multi-host synchronization (or you will be competing with GSync for the dirty flags).
I you're in control of the system image the best way would probably be to fork the code for the Calendar and Contacts providers and add a proper changelog to both databases. On 30 Mar, 14:46, AL <aaron.long.l...@gmail.com> wrote: > Hi, Experts > > Our team is creating an Exchange ActiveSync client for an Android > product. > > We met the issue of tracking contacts/calendar changes. Here are some > proposals we can image. Please advise or give your suggestions. > > 1. Like Funambol SyncML for Android, before the sync session, > calculate each PIM record's hash then figure out the add/update/delete > change. > Pros: no dependence on android sync framework > Cons: time cost is high. It takes 4 minutes to scan 1000 records in my > emulator. Considering we will launch the sync once any record change > occurs on device, it is not acceptable. > > 2. Make use of _sync_dirty field and _deleted_people table in PIM > database. The problem is, ContactsProvider does not allow the client > application to access _deleted_people and clear the _sync_dirty field. > So we have to modify the ContactsProvider andCalendarProvider. > The possible change maybe: Add an EasContactsProvider, extended from > ContactsProvider, then export it by adding a provider section in > GoogleContactsProvider's AndroidManifest.xml. In EasContactsProvider, > override insertInternal, updateInternal, deleteInternal and > queryInternal to allow Exchange ActiveSync service to access > _deleted_people table or clear the _sync_dirty flag. > Pros: performance is good > Cons: seems not a formal way. > > 3. Broadcast change notification Intent in ContactsProvider/CalendarProvider. > The change notification includes record uri, change > type and the process id that causes this change. Sync Engine will log > these changes and will not use any _sync fields in later sync session. > Changes in ContactsProvider andCalendarProvider: > For change on single record, if main table is changed, report the > change. If child table is changed, report UPDATE for the main record. > For changes (update/delete) on multiple records, if main table is > changed, query out the records and report change for each. If child > table is changed, query out the records and report UPDATE for each > main record. > Pros: Other sync engines can also make use of this change > notification. > Cons: Low performance when multiple changes occur. > If Google enhances its content observer to broadcast detail change > info (uri, type, pid), that will be nice. The pid is used for a sync > engine to check if a change is caused by itself. > > 4. Make use of the Android sync framework. To be honest, I doubt > whether the current sync framework supports contacts/calendar content > provider to be sync'd by multiple sync protocols without modifying > Google's code. If any expert has any useful information, please let me > know. > > Regards > Aaron --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
