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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. «Бритва Оккама». Не создавайте сущностей без веской причины.

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

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

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