У меня есть утилита "дамп", которую я использую для изучения ContactsContract, поскольку я не совсем понимаю ее в документации. Когда я сбрасываю контакты, он считает 263 записи в таблице, однако приложение-контакты в моем устройстве перечисляет, что у меня есть 244 ( "Отображение 244 контактов" ).
Может кто-то объяснить несоответствие?
My Sprint LG Contacts Приложение имеет параметры отображения для каждой из учетных записей, которые я синхронизирую, и я пошел и проверил их все, поэтому фильтрация не должна быть.
Основной URI, который я использую в утилите:
Uri uriRawContacts = ContactsContract.RawContacts.CONTENT_URI;
String[] projection = new String [] {
ContactsContract.RawContactsEntity._ID,
ContactsContract.RawContactsEntity.CONTACT_ID,
ContactsContract.RawContactsEntity.DELETED,
ContactsContract.RawContactsEntity.AGGREGATION_MODE,
};
Cursor cursorRaw = cr.query(uriRawContacts, projection, null, null, null);
DumpCursor.dumpAnyCursor(getApplicationContext(), "RawContacts", cr, cursorRaw, ",");
Далее следуют (для каждого _ID в вышеприведенном запросе):
long rawContactId = Long.parseLong(anyCursor.getString(anyCursor.getColumnIndex(RawContacts.CONTACT_ID)));
Uri rawContactUri = ContentUris.withAppendedId(RawContacts.CONTENT_URI, rawContactId);
Uri entityUri = Uri.withAppendedPath(rawContactUri, Entity.CONTENT_DIRECTORY);
Log.d(TAG, "rawContactUri: " + rawContactUri.toString());
Log.d(TAG, "entityUri: " + entityUri.toString());
Cursor c = cr.query(entityUri, new String[] { RawContacts.SOURCE_ID, Entity.DATA_ID, Entity.MIMETYPE, Entity.DATA1 }, null, null, null);
Затем я просматриваю первый запрос, отображает все столбцы в моей проекции, затем, используя поле _ID в первом цикле запросов, я выдаю второй запрос и выгружаю все его столбцы.
Пули из ответа, транспонированного здесь для удобства: Подробнее см. Ссылку. Более конкретно, вам рекомендуется ознакомиться с правилами агрегации. Ссылка: Нажмите здесь, чтобы перейти к исходному цитируемому тексту
- База данных контактов разделена на 3 таблицы контактов, raw контактов и данных.
- Каждая таблица содержит столбец (_ID), который является автоматически увеличиваемым основным
ключ.- Таблица данных содержит всю контактную информацию, такую как номер телефона, идентификатор почты,
адрес и т.д.- Необработанные контакты указывают на созданный фактический контакт. Следовательно, мы используйте необработанные контакты, добавляя контакт.
- Пользователь не может добавлять данные в таблицу контактов. Данные в этом
таблица заселена из-за того, что агрегирование контактов.Причина, по которой ваша логика контактов: _ID для контактов, сырые контакты остаются такими же, пока представляет собой любое объединение контактов место. Допустим, вы добавили два контакта с тем же именем abc. Здесь _ID для необработанные контакты увеличиваются дважды _ID для контактов увеличивается только один раз, когда эти два контакта сливаются из-за к агрегации контактов
Это различие связано с тем, что RawContacts сливается с Contacts из-за правила агрегации.
Вы добавляете контакт в RawContacts, пока в списке отображается Контакты. Следовательно, разность счетчиков.
Ниже приведено описание между Contacts, RawContacts и Data здесь.
Даже если вопрос другой, вы можете получить разницу между Contacts и RawContacts.
В трех таблицах обычно упоминаются имена их контрактных классов. Классы определяют константы для URI содержимого, имен столбцов и значений столбцов, используемых таблицами:
ContactsContract.Contacts таблица: -
Строки, представляющие разные люди, основанные на скоплениях исходных строк контактов.
ContactsContract.RawContacts таблица: -
Строки, содержащие сводку данных человека, относящихся к учетной записи пользователя и типу.
ContactsContract.Data таблица: -
Строки, содержащие детали для сырого контакта, такие как адреса электронной почты или номера телефонов.
для получения дополнительной информации нажмите