-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Contact LOOKUP_KEY #140
Labels
enhancement
New feature or request
Comments
vestrel00
changed the title
Add support for ContactsContract.ContactsColumns#LOOKUP_KEY
Add support for Contact LOOKUP_KEY
Dec 21, 2021
vestrel00
added a commit
that referenced
this issue
Jan 1, 2022
I'm doing a lot of research and documentation here! It is definitely tougher than just coding 😭 But I WILL PERSEVERE FOR THE COMMUNITY ❤️ 🔥 |
18 tasks
vestrel00
added a commit
that referenced
this issue
Jan 23, 2022
vestrel00
added a commit
that referenced
this issue
Jan 23, 2022
This was referenced Jan 25, 2022
Closed
RawContactContact.kt extensions may return incorrect result if Contact has been linked/unlinked
#176
Closed
vestrel00
added a commit
that referenced
this issue
Jan 25, 2022
…updated sample app to use lookup key instead of ID
This is released in https://github.com/vestrel00/contacts-android/releases/tag/0.2.0 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As the official documentation states,
ContactsContract.ContactsColumns#LOOKUP_KEY
is...This will be useful for consumers that want to save a reference to a Contact in order to load it later. Currently, the only way for consumers to do this is via the
Contact.id
, which could change "as a result of a sync or aggregation".Problem
Here is a common scenario that could occur,
Solution
Implement
Contact.lookupKey
so that consumers can save a reference to a Contact that can be held long term.Notes
As mentioned in #139, it seems like the LOOKUP_KEY is the same across devices as long as data has been synced (up-to-date) with the servers!
This is probably also required to implement #70 .
The text was updated successfully, but these errors were encountered: