Quando usar um provedor de conteúdo

103

Eu entendo que os provedores de conteúdo são feitos para permitir o compartilhamento público de dados entre aplicativos. No entanto, gostaria de saber se alguém tem ideias sobre como fazer um Provedor de conteúdo para usar apenas em seu próprio aplicativo. Haveria alguma vantagem em fazer isso? Quaisquer desvantagens?

No passado, acabei de implementar o SQliteOpenHelper para acessar dados do meu banco de dados, mas estou pensando em criar um Provedor de Conteúdo. Acho que a abordagem de URI para solicitar dados é clara e concisa. Por outro lado, usar um Provedor de Conteúdo apenas para meu aplicativo será redundante (já que dentro dele terei uma classe SQliteOpenHelper) e mais trabalho do que preciso?

android android-contentprovider Pzanno
fonte
2
Fiz uma biblioteca para tornar o provedor de conteúdo fácil de escrever. Ainda mais fácil do que escrever SQLiteOpenHelper simples. github.com/coocood/VContentProvider
coocood

Respostas:

59

Se você não planeja compartilhar dados, não pense em provedores de conteúdo. Eles são poderosos, mas difíceis de escrever e será uma tolice implementá-los se você for usá-los internamente.

No entanto, gostaria de saber se alguém tem ideias sobre como fazer um Provedor de conteúdo para usar apenas em seu próprio aplicativo.

Claro ... por exemplo, para um antigo aplicativo de lista TODO que escrevi, tive que escrever um provedor de conteúdo para permitir que outros aplicativos recuperassem e acessassem os estados de tarefas. Fazia parte dos requisitos, mas mais do que isso fazia sentido e tornava o aplicativo mais agradável.

Cristian
fonte
34
Concordo com sua justificativa, mas também acho importante (especialmente para os iniciantes) que, uma vez que o Provedor de Conteúdo seja implementado, você ganhe muitos benefícios. Por exemplo, você pode usar o CursorLoaderpara realizar consultas assíncronas ... você tem acesso a uma instância singleton (o ContentResolver) para realizar consultas, etc. Claro, você pode implementar seu próprio carregador para usar em seu banco de dados SQLite ... é claro que você poderia implementar o acesso a uma única instância de banco de dados em todo o aplicativo ... e, claro, um ContentProvider não é necessário, a menos que você deseje compartilhar
Alex Lockwood
11
dados com outros aplicativos. Dito isso, há muitos benefícios na implementação de seu próprio provedor de conteúdo, então você não deve descartá-lo só porque seu aplicativo não compartilha seus dados.
Alex Lockwood
8
Sim, você está completamente certo, mas ainda acho que não vale a pena o esforço na maioria dos casos. Eu fiz pelo menos 12 aplicativos Android diferentes (publicados na Play Store) e nunca precisei de um ContentProvider. Na verdade, o último aplicativo em que estávamos trabalhando foi inicialmente feito com um ContentProvidere acabamos de excluí-lo, pois é realmente mais chato de usar do que deveria (até escrevi uma biblioteca para facilitar a implementação de ContentProviders básicos : github.com/casidiablo/persistence, mas nunca usei meu próprio XD).
Cristian
1
@Cristian fornece conselhos práticos. Até mesmo o documento Android afirma que não devemos usar ContentProviderse não precisarmos - "Você não precisa de um provedor para usar bancos de dados ou outros tipos de armazenamento persistente se o uso for inteiramente dentro de seu próprio aplicativo e você não precisar qualquer um dos recursos listados acima. Em vez disso, você pode usar um dos sistemas de armazenamento descritos na página Salvar dados do aplicativo. ". Caso contrário, acabamos de engenharia.
Cheok Yan Cheng
Resumo: Se você não planeja compartilhar seus dados, pode evitar o Provedor de Conteúdo, mas, por outro lado, o Provedor de Conteúdo facilita sua vida se você quiser alterar o banco de dados do seu aplicativo. por exemplo, de SQLite para MangoDB.
Prashant
116

Eu diria que é definitivamente uma boa ideia usar um, ContentProvidermesmo que você não pretenda torná-lo público.

É uma boa prática fornecer um nível extra de abstração sobre seus dados para facilitar a alteração interna. E se você decidir alterar a estrutura do banco de dados subjacente posteriormente? Se você usar um, ContentProviderpoderá conter todas as alterações estruturais dentro dele, enquanto, como se não usasse um, você é forçado a alterar todas as áreas do código que são afetadas pelas alterações estruturais. Além disso, é bom ser capaz de reutilizar a mesma API padrão para acessar dados em vez de sujar seu código com acesso de baixo nível ao banco de dados.

Além disso, sempre existe a chance de você querer expor seus dados no futuro. Se você não usar um ContentProvideradiantado, será muito mais difícil adaptá-lo posteriormente.

Depois, há as outras partes do Android onde ContentProvideros são necessários / recomendados, como ao usar SyncAdapterse você deseja um App Widget que envolve acesso a dados, por exemplo.

Em resumo, há muito pouca sobrecarga envolvida em escrever um ContentProviderfront (uma vez que você tenha aprendido a API, o que é uma boa ideia), então faz sentido fazer isso, mesmo para dados privados.

Paul Drummond
fonte
1
Eu não poderia concordar mais. Ele força você a abstrair sua camada de dados de uma forma que praticamente garante que um novo desenvolvedor não seja capaz de acoplar a IU a ela.
Gabriel
3
Imediatamente após aprender o Android, comecei a pensar da mesma forma exatamente por esse motivo. Mesmo se não for público, você sempre pode se beneficiar da maior abstração e do ponto único de implementação de suas decisões de arquitetura. Eu amo ContentProviders.
davidcsb
1
Você pode tornar o provedor de conteúdo disponível apenas para seu próprio aplicativo com este atributo:android:exported="false"
Toby 1 Kenobi
4
Na minha humilde opinião, você pode e deve lidar com seus dados de uma forma completamente abstrata, sem a necessidade de implementar ContentProvider.
hmartinezd
2
Enquanto estava implementando uma solução de provedor de conteúdo para meu banco de dados sqlite interno (sem interação com outros aplicativos), vi o comentário em developer.android.com/guide/topics/providers/… que afirma que você não precisa de um provedor para usar um banco de dados SQLite se o uso for inteiramente dentro de seu próprio aplicativo.
Selçuk Cihan
7

Dê uma olhada no MOTODEV Studio for Eclipse. É um ambiente de desenvolvimento que estende o Eclipse. Eles têm uma ferramenta onde você pode gerar automaticamente um provedor de conteúdo para um banco de dados. Se um provedor de conteúdo torna mais fácil o acesso aos seus dados e não tem um impacto significativo no desempenho, vá em frente e use-o. Na maioria dos cenários, esse será o caso.

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
fonte
5

Em suma, Content Providersajuda a gerenciar seus dados de forma eficaz . Eu sugeriria usá-los pelos seguintes motivos.

  • Ele atua como uma camada de abstração entre sua IU e o banco de dados . Você pode implementar a validação de dados em ContentProviders para validar os dados inseridos pelo usuário. Ele também permite que você modifique a estrutura do banco de dados sem tocar na IU e em outras partes.
  • Eles funcionam muito bem com outras classes de estrutura do Android como SyncAdapter. Por exemplo, você pode atualizar automaticamente uma lista, quando um valor em um banco de dados muda usando ContentProviders junto com CursorLoader. Sem ContentProviders, você tem que implementar várias funcionalidades como essas por conta própria.
  • Podemos expor com segurança nossos dados privados para outros aplicativos . Usar ContentProviders nos permitirá compartilhar nossos dados de forma fácil e segura com outros aplicativos.

Portanto, mesmo que você não precise de nenhuma dessas funcionalidades agora, poderá precisar delas no futuro e é bom ir mais longe e implementá-las agora.

Siva Prakash
fonte
Ótima resposta. Descrição de uma única frase ContentProviderse três razões distintas pelas quais devemos usá-los. Às vezes, as explicações simples são as melhores. +1
AdamInTheOculus
4

Concordo que ContentProviders são um pouco difíceis de entender, mas eles são definitivamente úteis, mesmo se você quiser usá-los internamente em seu próprio aplicativo. A melhor coisa sobre isso é que você pode personalizar os provedores de conteúdo para URIs adequados.

Aqui está um cenário onde você pode ter 5 tabelas em seu banco de dados, mas você precisa juntar algumas delas em certas ordens antes de usá-las. E faça um URI de conteúdo para cada uma dessas junções. Você poderia então usar esses URIs como uma tabela :)

Eu sugiro que você vá em frente com o Provedor de Conteúdo, você ficará surpreso ao ver como ele é poderoso.

Shubhayu
fonte
2

No meu ponto de vista, o provedor de conteúdo vem com muitas vantagens, quanto mais compartilhar dados com outros aplicativos. Se você precisar sincronizar com o servidor usando um Sync-Adapter, use google cloud messaging, atualize automaticamente a IU quando os dados subjacentes no banco de dados mudarem usando Loaders, implemente a pesquisa, use widgets ... então o provedor de conteúdo é para você.

Eu prefiro que você siga as orientações porque um dia você pode precisar implementar alguns dos recursos acima anexados ao provedor de conteúdo

A propósito, você pode construir rapidamente seu banco de dados e CP em menos de 5 minutos usando o gerador de provedor de conteúdo

Phillip Kigenyi
fonte
1

Conforme dito na documentação: Criando um provedor de conteúdo

Você não precisa de um provedor para usar um banco de dados SQLite se o uso for inteiramente dentro do seu próprio aplicativo.

Então, por que se preocupar em desenvolver essa sobrecarga? Você quer um desenvolvimento mais fácil e rápido, certo? Portanto, uma camada de abstração (descendente SQLiteOpenHelper) é o suficiente.

Veja a Navalha de Occam Não faça entidades sem uma boa razão.

stoarch
fonte
0

Não use o provedor de conteúdo se não quiser compartilhar dados com outros aplicativos. Use sqlitedatabase simples para executar operações de banco de dados. Tenha cuidado ao usar provedores de conteúdo para armazenar dados confidenciais porque suas informações confidenciais podem ser acessadas por outros aplicativos

user3030895
fonte
Por padrão, os provedores de conteúdo não são expostos e é fácil gerenciar as restrições de acesso a eles. Votar negativamente por espalhar informações incorretas.
TBridges42 de
2
@ TBridges42 Você está (estava) errado. Na verdade, até que os Provedores de Conteúdo API Nível 17 fossem expostos . E na hora da resposta 25% dos dispositivos Android foram afetados por esse comportamento e ainda 10% na hora do seu comentário . Portanto, é mais o contrário: o seu comentário é perigoso, pois você afirma algo para ser seguro que é / não foi o fato.
Murmel
0

Usar um provedor de conteúdo pode ajudar em um nível adicional de abstração - colocá-lo em seu próprio aplicativo adiciona um tempo de desenvolvimento significativo ao seu projeto. No entanto, se você o estiver usando para compartilhar dados, configurações de aplicativos ou configurações em vários aplicativos, o Provedor de Conteúdo é a sua escolha.

Observe seus níveis de segurança e eu recomendaria usar SQLcipher para criptografar dados na redefinição (DAR) se seu provedor de conteúdo estiver gravando em SQLite. (Eu usei um provedor de conteúdo em algumas soluções e forneci a capacidade de tirar uma "foto instantânea" ao vivo dos valores operacionais para depuração e teste.)

Jim Row
fonte