Когда использовать контент-провайдера

Я понимаю, что контент-провайдеры предназначены для публичного обмена данными между приложениями. Однако мне интересно, есть ли у кого-нибудь мысли о том, чтобы заставить контент-провайдера использовать только в вашем приложении. Есть ли какие-либо преимущества для этого? Есть ли недостатки?

В прошлом я только что реализовал SQliteOpenHelper для доступа к данным из моей базы данных, но я думаю о создании провайдера контента. Я чувствую, что подход URI к запросу данных ясен и лаконичен. С другой стороны, будет ли использование контент-провайдера только для моего приложения избыточным (так как в нем будет класс SQliteOpenHelper) и больше работы, чем мне нужно?

9 ответов

Решение

Если вы не планируете обмениваться данными, не думайте о контент-провайдерах. Они мощные, но трудные для написания, и будет просто глупо реализовывать их, если вы собираетесь использовать их внутри.

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

Конечно... например, для старого приложения со списком TODO, которое я написал, мне пришлось написать поставщика контента, чтобы другие приложения могли получать и получать доступ к состояниям задач. Это было частью требований, но более того, оно имело смысл и делало приложение более привлекательным.

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

Хорошей практикой является предоставление дополнительного уровня абстракции над вашими данными, чтобы облегчить внутреннее изменение. Что если вы решите изменить базовую структуру базы данных позже? Если вы используете ContentProvider вы можете содержать все структурные изменения внутри него, где, как будто вы не используете его, вы вынуждены изменить все области кода, на которые влияют структурные изменения. Кроме того, приятно иметь возможность повторно использовать тот же стандартный API для доступа к данным, а не засорять ваш код низкоуровневым доступом к базе данных.

Кроме того, всегда есть вероятность, что вы захотите представить свои данные в будущем. Если вы не используете ContentProvider заранее, будет гораздо сложнее переоборудовать его на более поздний срок.

Затем есть другие части Android, где ContentProviderтребуется / рекомендуется, например, при использовании SyncAdapters и если вы хотите, чтобы приложение Widget включало, например, доступ к данным.

Таким образом, при написании ContentProvider сразу (как только вы изучите API, что в любом случае является хорошей идеей), так что имеет смысл это делать, даже для личных данных.

Взгляните на MOTODEV Studio для Eclipse. Это среда разработки, которая расширяет Eclipse. У них есть инструмент, с помощью которого вы можете автоматически генерировать контент-провайдера для базы данных. Если поставщик контента облегчает доступ к вашим данным, и это не оказывает существенного влияния на производительность, используйте его. В большинстве случаев это будет так.

Короче,Content Providers помогает эффективно управлять вашими данными. Я бы предложил использовать их по следующим причинам.

  • Он действует как уровень абстракции между вашим пользовательским интерфейсом и базой данных. Вы можете реализовать проверку данных в ContentProviders для проверки данных, введенных пользователем. Это также позволяет вам изменять структуру базы данных, не касаясь пользовательского интерфейса и других частей.
  • Они хорошо сочетаются с другими классами фреймворка Android, такими как SyncAdapter, Например, вы можете автоматически обновлять список, когда значение в базе данных изменяется с помощью ContentProviders вместе с CursorLoader, Без ContentProviders вы должны реализовать множество подобных функций самостоятельно.
  • Мы можем безопасно предоставлять наши личные данные другим приложениям. Использование ContentProviders позволит нам легко и безопасно делиться нашими данными с другими приложениями.

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

Я согласен, что ContentProviders немного сложны для понимания, но они определенно полезны, даже если вы хотите использовать их для собственного приложения. Лучше всего то, что вы можете настроить контент-провайдеры для подходящих URI.

Вот сценарий, в котором у вас может быть 5 таблиц в вашей базе данных, но вам нужно объединить несколько из них в определенных порядках, прежде чем использовать их. И создайте URI контента для каждого из этих объединений. Затем вы можете использовать каждый URI в качестве таблицы:)

Я предлагаю вам продолжить работу с контент-провайдером, вы будете удивлены, увидев, насколько он мощный.

На мой взгляд, контент-провайдер обладает множеством преимуществ, не говоря уже о том, чтобы делиться данными с другими приложениями. Если вам необходимо выполнить синхронизацию с сервером с помощью Sync-Adapter, использовать облачный обмен сообщениями Google, автоматически обновлять пользовательский интерфейс, когда базовые данные в БД изменяются с помощью Loaders, осуществлять поиск, использовать виджеты... тогда поставщик контента для вас.

Я предпочитаю, чтобы вы следовали рекомендациям, потому что однажды вам может понадобиться реализовать некоторые из перечисленных выше функций, предоставляемых контент-провайдеру.

Кстати, вы можете быстро построить свою базу данных и CP за менее чем 5 минут, используя генератор контент-провайдера

Как сказано в документации: создание провайдера контента

Вам не нужен поставщик для использования базы данных SQLite, если использование полностью в вашем собственном приложении.

Так зачем заниматься разработкой этих накладных расходов? Вы хотите более легкую и быструю разработку, верно? Так что достаточно одного уровня абстракции (потомок SQLiteOpenHelper).

Смотрите бритву Оккама. Не делайте сущностей без очень веских причин.

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

Следите за уровнем безопасности, и я бы порекомендовал использовать SQLcipher для шифрования данных при сбросе (DAR), если ваш контент-провайдер пишет в SQLite. (Я использовал контент-провайдера в нескольких решениях и предоставил возможность сделать "мгновенный снимок" операционных значений для отладки и тестирования.)

Не используйте контент-провайдер, если не хотите делиться данными с другими приложениями. Используйте простую sqlitedatabase для выполнения операций с базой данных. Будьте осторожны при использовании контент-провайдеров для хранения конфиденциальных данных, потому что ваши конфиденциальные данные могут быть доступны для других приложений

Другие вопросы по тегам