Contact database in android

Основы Contacts API в Android

Интерфейс работы с контактами изменился начиная с 5-ой версии API Android SDK : провайдер Contacts и все его составляющие получили статус @Deprecated. Теперь за работу с контактами отвечает провайдер ContactsContract, который внёс изменения в структуру хранения контактов, более адаптированную для Android устройств, позволяющую хранить контакты из разных источников и предоставлять их пользователю как единую сущность. В настоящее время объект описания контакта на мобильном устройстве включает не только имя и номер телефона, но и Email, Twitter, Facebook и т.д. Новый ContactsContract API позволяет системе агрегировать похожие контакты и выдавать их пользователю в одной записи, а также связывать контакт с разного рода данными.

Пользовательские данные хранятся в центральном репозитории устройства, которым управляет поставщик контактов — эффективный и гибкий компонент Android. Поставщик контактов — это источник данных, которые отображаются в приложении «Контакты» на Вашем устройстве.

Структура поставщика контактов

Поставщик контактов содержит в себе три типа данных о пользователе, как это представлено на рисунке. Каждый тип данных хранится в отдельной таблице :

В качестве наименований таблиц обычно используются названия соответствующих классов-контрактов ContactsContract. Эти классы определяют константы для URI контента, названий столбцов и значений в столбцах этих таблиц :

ContactsContract.Contacts
Строки в таблице Contacts содержат данные о пользователях, полученные путем агрегации строк необработанных контактов.

ContactsContract.RawContacts
Строки в таблице RawContacts содержат сводные данные о пользователях, относящиеся к пользовательским учетным записям и их типам.

ContactsContract.Data
Строки в таблице Data содержат сведения о необработанных контактах, например email или номера телефонов.

Имеются и другие таблицы, представленные классами-контрактами ContactsContract и представляющие собой вспомогательные таблицы. Эти таблицы поставщик контактов использует для управления своими операциями и поддержки определенных функций, имеющихся в приложении устройства «Контакты» или приложениях для телефонной связи.

Разрешения на доступ к поставщику контактов

Приложения, которым требуется доступ к поставщику контактов для чтения или записи, должны определить разрешения в файле манифеста приложения :

Профиль пользователя

Разрешения на доступ к данным поставщика контактов не распространяются на работу с профилями пользователя.

Примечание : данные о контактах пользователя являются личными и конфиденциальными. Владельцы мобильных устройств заботятся о своей конфиденциальности и часто не проявляют желания предоставлять приложениям возможности сбора данных о них самих и/или их контактах. Если владельцам не до конца ясно, для чего требуется предоставить приложению разрешение на доступ к данным контактов, они могут присвоить Вашему приложению низкий рейтинг, или вообще откажутся его устанавливать.

Строка контактов профиля связана со строкой необработанных контактов в каждой из систем, в которой используется профиль. В каждой строке необработанного контакта профиля может содержаться несколько строк данных. Константы для доступа к профилю пользователя представлены в классе ContactsContract.Profile.

Для доступа к профилю пользователя требуются отдельные разрешения. Наряду с разрешениями READ_CONTACTS и WRITE_CONTACTS (чтение и запись контакта) для доступа к профилю пользователя необходимы разрешения android.Manifest.permission#READ_PROFILE и android.Manifest.permission#WRITE_PROFILE на чтение и запись соответственно.

Помните, что профиль пользователя представляет собой конфиденциальную информацию. При запросе доступа к личной информации на устройстве пользователя обязательно укажите, для чего вам требуется доступ к профилю пользователя.

Примечание : если при получении нескольких строк контактов необходимо определить, какая из них является профилем пользователя, анализируйте значение столбца IS_USER_PROFILE этой строки. Для профиля пользователя значение должно быть «1».

Пример чтения контактов

Рассмотрим простой пример чтения списка контактов и вывода их в журнал Log. Ниже представлен листинг метода onCreate главного модуля приложения MainActivity.

Перед выполнением запроса проверим, имеются ли у нас необходимые разрешения на доступ к контактам. Для этого используем метод ContextCompat.checkSelfPermission, которому в качестве параметров передадим контекст модуля и идентификатор разрешений списка контактов. Если приложение имеет разрешения (permission), то метод вернет значение PERMISSION_GRANTED, в противном случае PERMISSION_DENIED.

При наличии необходимых разрешений вызываем метод чтения контактов readContacts, представленный ниже. В противном случае запросим необходимые разрешения методом ActivityCompat.requestPermissions, которому в качестве параметров необходимо передать контекст модуля, список запрашиваемых разрешений и «определенную в модуле константу» (PERMISSIONS_REQUEST_READ_CONTACTS).

Примечание : при запросе приложением «разрешения» методом requestPermissions(), система открывает стандартное диалоговое окно подтверждения доступа. Приложение не может изменить интерфейс диалогового окна. Если имеется необходимость представить пользователю дополнительную информацию, то это желательно сделать перед открытием окна запроса подтверждения. После запроса первого подтверждения и получения положительного ответа система запоминает результат ответа и больше не открывает окно подтверждения доступа.

Результат выполнения запроса на получение разрешений система возвращает вызовом callback метода onRequestPermissionsResult, листинг которого представлен ниже.

Листинг callback метода запроса разрешений

Система вызывает callback метод onRequestPermissionsResult при запросе разрешений методом requestPermissions. В качестве параметров методу передается массив запрошенных permissions и массив разрешений grantResults.

В примере проверяем результат полученного от системы ответа. При наличии необходимых разрешений вызывается метод readContacts.

Листинг метода чтения контактов

Метод чтения контактов readContacts в качестве параметра получает контекст приложения, используемый для вызова метода getContentResolver().query и получения результата в виде курсора. Если курсор содержит список контактов, то метод в цикле перебирает этот список и выводит в Log параметры контактов (id, name, phone). Метод можно доработать, чтобы он возвращал список контактов в виде List .

Листинг класса Contact

Класс описания контакта, используемого в методе чтения контактов устройства.

Источник

Правильная работа с БД в Android

Приветствую всех дроидеров в эти непростые для нас времена.
Честно говоря, заколебала эта шумиха о патентах, войнах и т.д., но в данной статье речь пойдет не об этом.
Я не собирался писать статью на данную тему, так как везде всего полно о работе с базой данных в Android и вроде бы все просто, но уж очень надоело получать репорты об ошибках, ошибках специфичных и связанных с БД.
Поэтому, я рассматрю пару моментов с которыми я столкнулся на практике, чтобы предостеречь людей, которым только предстоит с этим разбираться, а дальше жду ваших комментариев на тему решения указанных проблем после чего внесу изменения в пост и мы сделаем отличный туториал, который будет образцом работы с SQLite в Android не только для начинающих, но и для тех, кто уже знаком с основами и написал простые приложения.

Способы работы с БД

Существует три способа работы с данными в БД, которые сразу бросаются на ум:
1) Вы создаете пустую структуру базы данных. Пользователь работает с приложением(создает заметки, удаляет их) и база данных наполняется. Примером может служить приложение NotePad в демо-примерах developer.android.com или на вашем дроид-девайсе.
2) Вы уже имеете готовую БД, наполненную данными, которую нужно распространять с приложением, либо парсите данные из файла в assets.
3) Получать данные из сети, по мере необходимости.
Если есть какой-то еще один или два способа, то с радостью дополню данный список с вашей помощью.
Все основные туториалы расчитаны как раз на первый случай. Вы пишите запрос на создание структуры БД и выполняете этот запрос в методе onCreate() класса SQLiteOpenHelper, например так:

Примерно так. Более полный вариант класса и других составляющих можно посмотреть по ссылке внизу статьи.
Дополнительно можно переопределить методы onOpen(), getReadableDatabase()/getWritableDatаbase(), но обычно хватает того, что выше и методов выборки данных.
Далее, экземпляр этого класса создаем в нашем приложении при его запуске и выполняем запросы, то бишь проблемная часть пройдена. Почему она проблемная? Потому что, когда пользователь качает приложения с маркета, то не задумывается о вашей базе данных и может произойти что угодно. Скажем сеть пропала или процесс другой запустился, или вы написали уязвимый к ошибкам код.

Кстати, есть еще один момент, на который стоит обратить внимание. Переменную экземпляра нашего класса можно создать и хранить в объекте Application и обращаться по мере необходимости, но нужно не забывать вызывать метод close(), так как постоянный коннект к базе — это тяжелый ресурс. Кроме того могут быть коллизии при работе с базой из нескольких потоков.
Но есть и другой способ, например, создавать наш объект по мере необходимости обращения к БД. Думаю это вопрос предпочтения, но который также необходимо обсудить.

А теперь самое главное. Что, если нам понадобилось использовать уже сушествующую БД с данными в приложении?
Немного погуглив, Вы сразу наткнетесь на такую «замечательную статью» — www.reigndesign.com/blog/using-your-own-sqlite-database-in-android-applications в которой, как покажется, есть нужная панацея. Но не тут то было. В ней еще и ошибок несколько.

Вот они:
1) В методе createDataBase() строка:
SQLiteDatabase dbRead = getReadableDatabase();
и далее код… содержит crash приложения на НТС Desire, потому что получаем БД для чтения(она создается), но не закрывается.
Добавляем строкой ниже dbRead.close() и фикс готов, но момент спорный.
Вот что говорит дока на тему метода getReadableDatabase():
Create and/or open a database. This will be the same object returned by getWritableDatabase() unless some problem, such as a full disk, requires the database to be opened read-only. In that case, a read-only database object will be returned. If the problem is fixed, a future call to getWritableDatabase() may succeed, in which case the read-only database object will be closed and the read/write object will be returned in the future.
Like getWritableDatabase(), this method may take a long time to return, so you should not call it from the application main thread, including from ContentProvider.onCreate().
И так. Данный метод не стоит вызывать в главном потоке приложения. В остальном все понятно.
2) Ошибка: No such table android_metadata. Автор поста выкрутился, создав данную таблицу заранее в БД. Не знаю на сколько это правильный способ, но данная таблица создается в каждой sqlite-бд системой и содержит текущую локаль.
3) Ошибка: Unable to open database file. Здесь много мнений, разных мнений, которые Вы можете прочесть по ссылкам ниже.

Возможно, что проблемы связаны с тем, что один поток блокирует БД и второй не может к ней обратиться, возможно проблема в правах доступа к приложению(было замечено, что чаще проблемы с БД проявляются на телефонах марки НТС именно на тех моделях, которые нельзя рутануть, хотя не только на них, например на планшетах Асер), но как бы то ни было проблемы эти есть.
Я склоняюсь к варианту, что проблема в потоках, не зря ведь нам не рекомендуют вызывать методы создания базы в главном потоке.

Возможно выходом из этого будет следующее решение(рассматривается вариант №2). Используя первый вариант работы с базой, наполнить ее данными после создания, например:

Данный подход еще нужно проверить на практике, но так как этот пост нацелен на выработку верного коллективного решения по данной тематике, то комментарии и пробы на даннную тему только приветствуются.
Мораль истории такова: если вы нашли какой-то хороший кусок кода для вашего решения, то проверьте его, не поленитесь, прежде чем копипастить в свой проект.

Вцелом, данный пост показывает(касательно способа №2) как делать не надо, но и также содержит пару любопытных мыслей.
Метод getReadableDatabase() можно переопределить например так:

Кстати: следуя практике самой платформы, поле первичного ключа стоит называть «_id».

Пишите в комментарии свои используемые практики. Мы сделаем данный пост лучше для всех, а может и мир станет чуточку добрее.

UPD Только что проверил свой подход. Все работает в эмуляторе, но будьте осторожны.

Файлик data.txt лежит в assets такой:
Zametka #1
Zametka #2
Zametka #3
Zametka #4

И класс приложения:

Отмечу, что данный класс используется только для демонстрации и проверки того, что произойдет при вызове методов getReadableDatabase()/getWritableDatabase() и создании базы. В реальных проектах код нужно адаптировать.
Кроме того в базе появилась табличка android_metadata(без моего участия), поэтому указанная выше ошибка решена.
Надеюсь кому-то пригодится.

Любопытные дополнения №1(от хабраюзера Kalobok)

Источник

Основы Contacts API в Android

Введение

Начиная с версии 5 API Android SDK интерфейс работы с контактами изменился, а основной контент провайдер Contacts и все его составляющие получили черную метку @Deprecated. Теперь за работу с контактами отвечает провайдер ContactsContract. Эти изменения связаны с изменением структуры хранения контактов, более адаптированной для Android устройств, которым требуется хранить контакты из множества разных источников и предоставлять их пользователю как единую сущность. Ведь сегодня, определенный контакт на нашем мобильном устройстве это не только имя и номер телефона, мы можем захотеть сохранить eMail, Im, Twitter, Facebook аккаунт определенного человека, и при этом, мы не хотим чтобы у нас нас появилось миллион непонятных записей. Поэтому новый Contacts API позволяет Android агрегировать похожие контакты и представлять их пользователю в одной записи, а также связывать контакт с разного рода данными.

Структура данных

На устройстве основная информация о контактах хранится в трех таблицах, на деле их там конечно больше, но мы рассмотрим основные три: contacts, raw_contacts и data. Чтобы было более наглядно я набросал простую схему в Dia.

В таблице contacts хранятся агрегированные контакты, каждая запись в этой таблице представляет собой пользовательский контакт (единую сущность) – объединение одного или нескольких сырых (необработанных) контактов из таблицы raw_contacts. Как видно на схеме, связь между этими таблицами один ко многим (1-N). Одна запись в таблице raw_contacts представляет собой так называемый сырой контакт. Сырой контакт, на языке Android, означает какой-то конкретный набор данных для определенного контакта. Но сами основные данные в этой таблице не хранятся, они хранятся в таблице data, и связь между raw_contacts и data также один ко многим. В таблице data хранятся непосредственно данные. Причем каждая строка этой таблицы это набор данных определенного типа для контакта. Какого именно типа данные хранятся в строке определяется столбцом mimetype_id, в котором содержится id типов данных определенных в таблице mimetype(например vnd.android.cursor.item/name, vnd.android.cursor.item/photo). Теперь разберемся во всем по подробней и с примерами.

Работаем с контактами

Хорошо, допустим мы хотим добавить контакт (Robert Smith, моб.тел. 11-22-33), как нам это сделать? В таблицу contacts мы сами, явно, не можем добавить контакт, так как система сама формирует эту таблицу агрегируя похожие raw_contacts. Идентичность контактов система определяет в основном по имени (одинаковые имена, фамилии и т.п.), но и по другим критериям, каким именно и как ими управлять можно посмотреть в документации. То есть, если мы добавим raw_contact нашего Роберта (Robert Smith) и свяжем его с данными типа vnd.cursor.android.item/phone, а потом у нас появится “похожий”, для системы, Robert Smith связанный с данными типа vnd.cursor.android.item/email и еще один с данными типа vnd.cursor.android.item/photo, то у нас в контактах будет один Robert Smith с фотографией, мобильным и email’ом.

Теперь попробуем переложить это на код. За таблицы и их поля отвечает, как я уже говорил, класс ContactsContract и его внутренние классы и интерфейсы. Например интерфейсом к таблице raw_contacts является класс ContactsContract.RawContacts, а за таблицу data класс ContactsContract.Data. Будьте внимательны когда изучаете их константы – интерфейсы к столбцам – обращайте внимание на метки read/write и read only.

Из написанного выше следует, что для начала, мы должны добавить сырой контакт, а потом связывать его с данными. Добавить пустой контакт можно так:

В контактах у вас должен появиться пустой (Unknown) контакт, ни с чем не связанный. Добавим ему имя. Чтобы это сделать, мы должны связать наш новый контакт с новыми данными используя его id, который можно достать из прошлого запроса. Основные интерфейсы к полям таблицы данных содержаться в классе-контейнере ContactsContract.CommonDataKinds и его внутренних классах и интерфейсах. Например, сейчас нам понадобиться
класс ContactsContract.CommonDataKinds.StrucruredName содержащий нужные нам константы для добавления имени, а также константу MIME типа, которой мы пометим наше поле в таблице данных.

Если мы добавим контакт таким образом, то в списке контактов у нас появиться Robert Smith. Теперь идем дальше, добавим нашему контакту еще и телефон. Для этого нам понадобиться класс ContactsContract.CommonDataKinds.Phone, который является интерфейсом к данным телефонного номера.

Теперь в контактах у нас есть Robert Smith которому можно позвонить. Но вот так добавлять контакт и данные к нему, в несколько запросов, дорого и накладно. Поэтому существует класс ContentProviderOperation, который позволяет построить запрос, который выполнит все наши операции за одну транзакцию. Именно им и рекомендуют пользоваться. Вот так можно добавить нашего Роберта используя ContentProviderOperation.

Вот таким образом в Android можно добавлять контакты. Будьте осторожны используя ContentProviderOperation, так как слишком большой запрос может долго выполняться. Вообще все операции лучше производить в отдельном потоке, потому, что у пользователя, например, может быть слабый телефон и много контактов.

В остальном все другие операции выполняются обычным образом, используя те провайдеры, которые вам необходимы, с некоторыми оговорками. Например, удаление контакта из таблицы contacts удалит все raw_contacts с ним связанные и т.д.

Вот так можно попробовать найти нашего Роберта в контактах:

На этом хотелось бы завершить статью, все же это были только основные сведения о Contacts API в Andoid. Я надеюсь мне удалось описать здесь основные принципы, а вся конкретика зависит от того, что вам необходимо сделать в процессе работы. Можно просто руководствоваться этими принципами и находить в официальной документации интерфейсы которые вам нужны для работы. Успехов!

Источник