[TIMOB-1894] Android: support read-write contacts

Description

Comments

1. Bill Dawson 2011-04-15

   assigning to Herr T for milestoning.

2. Moshe Marciano 2011-04-15

   for me the priority should be upgraded to high, this situation leaves cross-platform apps crippled on one platform

3. Bill Dawson 2011-04-15

   Research for M04

4. Bill Dawson 2011-04-15

   This was put into M04 only for research purposes to try to scope the effort. After review, my assessment is that this is will be a fairly major effort.
   

   • iOS has it "easy" -- each Person is backed by a ref to an actual address book object, an ABRecordRef (AB being the prefix for address book stuff). So when properties are changed on Titanium's TiContactsPerson, the properties are then just changed on that object. Android doesn't do this provider stuff with objects, rather via queries in provider database system. So when changes are made to properties of a PersonProxy in Titanium Android, we can't just turn around and update an in-memory object.
   • Similarly, iOS has it "easy" because when it comes time to save any and all changes made to one or more contact persons during the session -- i.e., when the Titanium JS code calls Titanium.Contacts.save() -- they just need to call ABAddressBookSave and all changes to ABRecordRefs up to that point are committed. In the case of Android, we'll have to work harder in the sense of somehow caching changes and applying them at save() time.
   • Android, since 2.0, has the notion of aggregated contacts. When you present the contacts picker to the user, for example, you get a listing of aggregated contacts. When the user selects a contact, they get an aggregated contact record in our PersonProxy. If the Titanium JS code then modifies properties on that PersonProxy and Titanium.Contacts.save() is called, which of the aggregated contact entries should be updated? We have to think about that carefully. (Note: If I use my Android 2.2 phone and go to People, pick a contact which I know is an aggregate and click the menu and choose "Edit", I'm prompted with a list of the underlying (non-aggregate) entries and asked to select which one I want to edit. So you can see this is an issue.)
   • We're currently supporting pre-2.0 contacts because we support Android 1.6. (Android Contacts API went through a major overhaul starting in 2.0.) This is already a PITA and will be more so for writable contacts. For example, the most straightforward way to try to cache changes and apply them later with Titanium.Contacts.save() would be to cache them in an array list containing Android ContentProviderOperation instances and then use ContentResolver.applyBatch when Titanium.Contacts.save() is called. None of that stuff is available in Android 1.6.

   Assigning for further milestoning.

5. Don Thorp 2011-04-15

   This is a natural fit for the next release when we drop support for Api Level 4.

6. Alan Leard 2011-07-29 Customer's would like to see this implemented as soon as it's possible. Bumping priority to gain visibility.
7. Eduardo Gomez 2011-08-01

   Associated HD ticket

   Another Customer relies on this, http://appc.me/c/APP-673928
8. Moshe Marciano 2011-08-12 I think google offers a migration plan with code to code samples on how to move from the pre 2.0 release to the new contact model. http://developer.android.com/resources/articles/contacts.html
9. Michael Gangolf 2012-05-06 is there a fallback solution at the moment or is it not possible to save contacts at all for now?
10. Vishal Duggal 2012-06-15 Raised a separate ticket for modify contact functionality. TIMOB-9589
11. Lee Morris 2017-03-16 Closing ticket as fixed.

JSON Source