Skip to content
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

LocalAddressBook: set/update ContactsContract.Settings.* when address books are renamed and updated #1113

Closed
Tracked by #1111
rfc2822 opened this issue Nov 1, 2024 · 3 comments · Fixed by #1123
Closed
Tracked by #1111
Assignees
Labels
bug Something isn't working

Comments

@rfc2822
Copy link
Member

rfc2822 commented Nov 1, 2024

Currently, settings are only set when address book accounts are created over create().

@sunkup
Copy link
Member

sunkup commented Nov 4, 2024

The settings are not stored in the account though. I remember you said something about it in call, but please me remind me again, why do we need to save the same settings again?

@rfc2822
Copy link
Member Author

rfc2822 commented Nov 4, 2024

I don't mean the AccountSettings, but the ContactsContract.Settings.* data rows, which are currently only set in LocalAddressBook.create():

// initialize Contacts Provider Settings
val values = ContentValues(2)
values.put(ContactsContract.Settings.SHOULD_SYNC, 1)
values.put(ContactsContract.Settings.UNGROUPED_VISIBLE, 1)
addressBook.settings = values

The SHOULD_SYNC is just a hint that this account's contacts (in our terms: the contacts of this local address book) are syncable.

More important is the UNGROUPED_VISIBLE setting. We should also add a comment to this line that it's especially required for making contacts work over Bluetooth (especially with some car systems).

When now an address book is renamed, the rename operation creates a new account, but doesn't set for instance UNGROUPED_VISIBLE for the new account. So contacts of this address book (= contacts of address books which have been renamed) won't work anymore on car Bluetooh. Surely funny when debugging that 😃

@sunkup sunkup linked a pull request Nov 4, 2024 that will close this issue
4 tasks
@sunkup
Copy link
Member

sunkup commented Nov 5, 2024

Note for myself: Streamline account creation process. Right now renameAccount() creates an account itself, but should in the best case scenario simply reuse the create method in the companion object.

EDIT: Reusing the method looks like a bad idea. It simplifies the implementation only a little, but makes it less modular at the same time. The more modular approach is supperior in extensibility and testability does not suffer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
2 participants