While not a bad idea, I don't think this suggestion will work for my situation. Having only skimmed over the Contacts API I think I'd have the following issues:
1) I believe every user would need a google account and while this is almost a given for Android users, it's entirely conceivable that some users don't want their work contacts intermingling with the account they signed up for. This would necessitate having to have every user to sign up for an additional "work" account which just seems like a needless hurdle. 2) I'm guessing these synced contacts go into the "Google" account on the device and I want them associated with a different account that is solely used by the app. This account is tied to events and other providers so that deleting the app effectively deletes the contacts too. 3) The contacts are a little more than an on/off proposition. I need to be able to control the syncing for certain users and while that functionality could conceivably be moved to the server side it would require a bit of a re-write of that code which I'm trying to stay away from. In the end this approach would be taking the long way around and I'm looking for a more direct way to solve it. Aaron On Thursday, November 15, 2012 7:30:46 PM UTC-8, Spiral123 wrote: > > Don't do it in Android. Use your WebService to sync the desktop > application contacts to a Google contact list using the Contacts API v3 ( > https://developers.google.com/google-apps/contacts/v3/). You can add a > specific label to tag them to your application and even extend the tables > if you wish. > > Once the updates are done on the server side the stock Google > synchronization service works really well to sync them automatically down > to the phone/tablet - with the added advantage that they will be > automatically available and kept up to date on all devices when they > connect. > > As far as I am aware there is no published volume or rate limit on this > API - but I would be surprised if it was less than the 10k per day allowed > for calendar and tasks. > > Nick > > > On Tuesday, November 13, 2012 7:34:25 PM UTC-5, prestona wrote: >> >> I'm developing an application where a user can initially sync all his >> contacts with a desktop application OTA. This is done through a web >> service call that grabs a set of 100 contacts from the server, downloads >> and parses the information, inserts the contacts into the Android Contact >> DB, acknowledges receipt of these contacts, and then repeats the previous >> steps with the next set of 100 contacts until the sync is complete. This >> process works well when a user has contacts on the order or 1000-2000, but >> a typical user of this application can easily have 5000-6000 contacts (with >> power users having upwards of 10000+) in which case things take far longer >> than I'd like. For example, a sample set of approximately 5300 contacts >> can take about 13.5 minutes to complete. Not bad, but I'd like it to be at >> least as efficient as iOS which runs about 8 minutes for the same data set >> if possible. >> >> I've logged the time it takes for each step and, unsurprisingly, the >> bottleneck appears to be with inserting the data into the Android contract >> DB. After scouring the web I've found little help with regards to >> inserting thousands of contacts, but what I have found seems to fall into >> these three groups: >> >> 1) ContentProviderOperation -- The Google recommended way which gave me >> my baseline of 13.5 minutes for 5300 contacts. >> >> 2) Bulk Inserts -- I read that buildInsert tends to be >> more efficient than applyBatch, but when I tried to implement this myself >> it actually took 25 minutes for the same 5300 contacts. I have a feeling a >> lot of this is due to the fact that I need to insert the RawContact >> information and then save the resulting URI for use in creating the >> ContactsContract.Data for the bulkInsert which comes more naturally via the >> backValueReference in the ContentProviderOperation. Additionally, I looked >> at the source code and I don't get the feeling that bulkInsert is >> terribly efficient. >> >> 3) Creating an optimized bulk insert using the DatabaseUtils.InsertHelper >> and transactions -- Unfortunately, this seems geared towards those people >> who created their own content provider because you need access to the >> underlying DB as an instance variable and I've yet to see how that could be >> done with the native contacts DB. >> >> Does anyone have any experience with inserting 5000+ contacts or any >> possible ideas I could look into to help reduce my time? Or should I >> consider the ContentProviderOperation to be as optimized as it's going to >> get? >> >> Thanks. >> > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
