Я сделал SQLite для программирования баз данных для Android, но я ничего не знаю о Контент-провайдер, за исключением этого: "Как я уже говорил Страница разработчика Android, SDK для Android объяснил" Content-provider ", поскольку он используется для хранения и извлекать данные".
Но тогда
Любой пример или помогает!
Я нашел одно существенное различие:
Сохранение ваших данных в базе данных - один из хороших способов сохранения данных, но в Android-базах, созданных на Android, существует оговорка visible только для приложение, которое их создало. То есть база данных SQLite, созданная на Android одним приложением, может использоваться только этим приложением, а не другими приложениями.
Итак, если вы need to share data between applications, you need to use the content provider model as recommended in Android. В этой статье представлены основы поставщиков контента и способы их реализации.
Я нашел эту статью на этой ссылке
Действительно приятная информация.
Какая разница между "Content-Provider" и "SQLite База данных"?
ContentProvider - это фасад - API, который вы можете реализовать, который предоставляет базы данных другим процессам. Он может быть реализован таким образом, что данные хранятся в базе данных SQLite, но это не обязательно.
Что лучше хранить данные, когда?
Это невозможно ответить абстрактно. Вообще говоря, если только что-то не требует использования ContentProvider, просто используйте базу данных.
Я сделал много хороших приложений с тысячами пользователей, использующих их, которые просто использовали методы SQLite. Но это было давно, и мне пришлось вручную написать много кода, о котором теперь можно легко позаботиться ContentProvider. В то время я не был сторонником использования Content Providers, потому что это, казалось, только усложняло код.
Однако за последние пару лет, когда Android развился, я перешел на ContentProvider, так как он экономит время и позволяет вам делать больше. Теперь я использую его широко. Когда у вас есть класс Content Provider, ваша жизнь станет намного проще. С ContentProvider я могу легко справиться с Cursor Loaders, Loader Callbacks и Bulk Inserts, для которых мне приходилось писать все вручную в прошлом, и все же он работал не так эффективно. Особенно при обновлении списка, которое теперь автоматически обновляется благодаря одному методу notifychange(). Это означает, что теперь мне не нужно вводить собственные слушатели и вручную обновлять контент в виде списка и адаптерах. Кроме того, мне не нужно беспокоиться об открытии и закрытии баз данных или беспокоиться о утечке памяти. Все это обрабатывается Поставщиком контента. Единственная проблема, с которой я сталкиваюсь, заключается в том, что вы не можете выполнять сложные запросы в ContentProviders. В этом случае вы все равно можете использовать необработанные запросы и использовать старомодное ручное взаимодействие с sqlite.
Если вы ранее написали свой собственный DbAdapter, Helper и Observer, вы можете безопасно переносить их в свои новые приложения, не тратя время на конвертацию всего в ContentProvider. Но, основываясь на моем опыте, я настоятельно рекомендую перейти на ContentProvider. Потребуется некоторое время, чтобы привыкнуть к этому, но как только у вас будет опыт, вы останетесь с ним.
ОБНОВЛЕНИЕ 2017 Теперь я переключился на Realm, гораздо лучший способ использовать базы данных на любой платформе. Проведите несколько часов, изучая его, и сэкономьте бесчисленные часы в карьере разработки приложений.
По умолчанию поставщики контента не являются потокобезопасными. Если у вас есть несколько потоков, использующих контент-провайдер, вы можете увидеть множество разных исключений и другие несоответствия данных. Самый простой способ исправить это - использовать синхронизированное ключевое слово для каждого из открытых методов, предоставляемых поставщиком контента.
Таким образом, доступ к этим методам может получить только один поток за раз.
У меня есть потребность в новом приложении Serval Maps для импорта данных из двоичных файлов в базу данных, используемую внутри приложения. Чтобы сделать это и хорошо играть с остальной частью приложения, лучше всего:
Создайте новый поток для импорта, чтобы другие потоки не пострадали, особенно в потоке, отвечающем за обновление пользовательского интерфейса; а также Приостановите кратко в конце каждого импорта, чтобы дать другим потокам, которые больше должны использовать синхронизированные методы.
То, как контент-провайдеры в Android работают, обеспечивает уровень абстракции между остальной частью вашего кода и базовой базой данных. В основном это связано с тем, насколько я могу сказать, что поставщики контента могут получать доступ к данным из других мест, кроме баз данных.
Это означает, что вы не можете выполнять необработанные SQL-запросы в базовой базе данных, и вам нужно указать различные компоненты SQL-запроса, используя переменные, переданные различным методам, таким как метод запроса. Если у вас есть задача, которая не вписывается в то, как SQL обрабатывается поставщиком контента, у вас есть два варианта:
Подумайте в сторону запроса, возможно, вы сможете получить нужные вам данные по альтернативным запросам и получить доступ к результатам от курсора; а также Используйте URI для обычного доступа к данным и специальный URI, который соответствует конкретному запросу для тех задач, которые не имеют альтернатив.
Поставщики контента используются, когда вы хотите делиться своими данными между приложениями.
Если у вас есть база данных, прикрепленная к приложению, и вы хотите, чтобы другое приложение использовало некоторые данные, вы можете реализовать поставщика контента, который предоставляет данные
Основное отличие: когда вашему приложению нужно обмениваться информацией с другими приложениями, используйте Content-Provider. SQLite только данные хранилища для приложения, которое его создает
Я читаю этот ответ, ища одинаковые сомнения, поэтому подумал об обмене. он утверждает -
Хорошая практика - обеспечить дополнительный уровень абстракции над вашими данными, чтобы облегчить внутреннее изменение. Что делать, если вы решите изменить базовую структуру базы данных позднее? Если вы используете ContentProvider, вы можете содержать все структурные изменения внутри него, где, как если бы вы его не использовали, вы вынуждены изменять все области кода, на которые влияют структурные изменения. Кроме того, приятно иметь возможность повторно использовать один и тот же стандартный API для доступа к данным, а не засорять ваш код низкоуровневым доступом к базе данных.
Таким образом, использование поставщика контента было бы хорошей идеей.
Подумайте о продвинутых системах управления контентом. Каждый объект (страница, изображение, новостная статья, элемент события и т.д.) Имеет контент, адрес, пользовательские разрешения и способы взаимодействия с ним из разных частей системы. Поставщики контента делают это для Android. Теперь вы можете обмениваться файлами или изображениями, которые вы могли сохранить в своем приложении. Вы также можете создавать настраиваемые совлокальные объекты, такие как контакты бизнеса, редактируемые заметки и т.д. И укажите безопасность и приложение по умолчанию для работы с таким объектом, когда вы открываете их из любого другого приложения.
Одно из отличий заключается в том, что контент-провайдеры поддерживают платформу для наблюдателей контента. Вам понадобится реализовать собственный шаблон Observable для базы данных SQLite.
Как автоматически выполнить повторный запрос с помощью LoaderManager