Quand utiliser un fournisseur de contenu

Je comprends que les fournisseurs de contenu sont conçus pour permettre le partage public de données entre les applications. Cependant, je me demande si quelqu'un a des idées sur la création d'un fournisseur de contenu à utiliser uniquement dans votre propre application. Y aurait-il des avantages à faire cela? Des inconvénients?

Dans le passé, je viens d'implémenter SQliteOpenHelper pour accéder aux données de ma base de données, mais j'envisage de créer un fournisseur de contenu. J'ai l'impression que l'approche URI pour demander des données est claire et concise. D'autre part, l'utilisation d'un fournisseur de contenu uniquement pour mon application sera-t-elle redondante (puisque j'aurai en son sein une classe SQliteOpenHelper) et plus de travail que nécessaire?

Si vous ne prévoyez pas de partager des données, ne pensez pas aux fournisseurs de contenu. Ils sont puissants mais difficiles à écrire et il sera juste ridicule de les implémenter si vous comptez les utiliser en interne.

Cependant, je me demande si quelqu'un a des idées sur la création d'un fournisseur de contenu à utiliser uniquement dans votre propre application.

Bien sûr ... par exemple, pour une ancienne application de liste TODO que j'ai écrite, j'ai dû écrire un fournisseur de contenu pour permettre à d'autres applications de récupérer et d'accéder aux états des tâches. Cela faisait partie des exigences, mais plus que cela, cela avait du sens et rendait l'application plus agréable.

Je dirais que c'est certainement une bonne idée d'utiliser un ContentProvidermême si vous n'avez pas l'intention de le rendre public.

Il est recommandé de fournir un niveau d'abstraction supplémentaire sur vos données pour faciliter le changement en interne. Que faire si vous décidez de modifier ultérieurement la structure de la base de données sous-jacente? Si vous utilisez un, ContentProvidervous pouvez contenir toutes les modifications structurelles, alors que, comme si vous n'en utilisiez pas, vous êtes obligé de modifier toutes les zones du code qui sont affectées par les modifications structurelles. En outre, il est agréable de pouvoir réutiliser la même API standard pour accéder aux données plutôt que de gâcher votre code avec un accès de bas niveau à la base de données.

De plus, il est toujours possible que vous souhaitiez exposer vos données à l'avenir. Si vous n'utilisez pas un ContentProviderà l'avant, il sera beaucoup plus difficile de le moderniser à une date ultérieure.

Ensuite, il y a les autres parties de l'Android où ContentProviderles éléments sont requis / recommandés, par exemple lors de l'utilisation de SyncAdapters et si vous voulez un widget d'application qui implique l'accès aux données par exemple.

En résumé, il y a très peu de frais généraux impliqués dans l'écriture d'un ContentProviderdébut (une fois que vous avez appris l'API, ce qui est une bonne idée de toute façon), il est donc logique de le faire, même pour les données privées.

Jetez un œil à MOTODEV Studio pour Eclipse. C'est un environnement de développement qui étend Eclipse. Ils ont un outil où vous pouvez générer automatiquement un fournisseur de contenu pour une base de données. Si un fournisseur de contenu facilite l'accès à vos données et que cela n'a pas d'impact significatif sur les performances, utilisez-le. Dans la plupart des scénarios, ce sera le cas.

En bref, Content Providersaide à gérer efficacement vos données . Je suggérerais de les utiliser pour les raisons suivantes.

• Il agit comme une couche d'abstraction entre votre interface utilisateur et votre base de données . Vous pouvez implémenter la validation des données dans ContentProviders pour valider les données saisies par l'utilisateur. Il vous permet également de modifier la structure de la base de données sans toucher à l'interface utilisateur et aux autres parties.
• Ils jouent bien avec d'autres classes de framework Android comme SyncAdapter. Par exemple, vous pouvez actualiser automatiquement une liste, lorsqu'une valeur dans une base de données change en utilisant ContentProviders avec CursorLoader. Sans ContentProviders, vous devez implémenter vous-même de nombreuses fonctionnalités comme celles-ci.
• Nous pouvons exposer en toute sécurité nos données privées à d'autres applications . L'utilisation de ContentProviders nous permettra de partager nos données facilement et en toute sécurité avec d'autres applications.

Donc, même si vous n'avez besoin d'aucune de ces fonctionnalités maintenant, vous pourriez en avoir besoin à l'avenir et il est bon de faire un effort supplémentaire et de les implémenter dès maintenant.

Je suis d'accord que les ContentProviders sont un peu difficiles à comprendre, mais ils sont vraiment utiles, même si vous souhaitez les utiliser en interne pour votre propre application. La meilleure chose à ce sujet est que vous pouvez personnaliser les fournisseurs de contenu pour les URI appropriés.

Voici un scénario où vous pouvez avoir 5 tables dans votre base de données, mais vous devez en joindre quelques-unes dans certaines commandes avant de les utiliser. Et créez un URI de contenu pour chacune de ces jointures. Vous pouvez alors chacun utiliser ces URI comme table :)

Je vous suggère d'aller de l'avant avec Content Provider, vous serez étonné de voir à quel point il est puissant.

À mon avis, le fournisseur de contenu présente de nombreux avantages, à part le simple partage de données avec d'autres applications. Si vous avez besoin de vous synchroniser avec le serveur à l'aide d'un adaptateur de synchronisation, utilisez la messagerie Google Cloud, mettez à jour automatiquement l'interface utilisateur lorsque les données sous-jacentes de la base de données changent à l'aide de Loaders, implémentez la recherche, utilisez des widgets ... alors le fournisseur de contenu est fait pour vous.

Je préfère que vous suiviez les instructions car un jour, vous devrez peut-être implémenter certaines des fonctionnalités ci-dessus attachées au fournisseur de contenu

En passant, vous pouvez rapidement créer votre base de données et votre CP en moins de 5 minutes à l'aide du générateur de fournisseur de contenu

Comme indiqué dans la documentation: création d'un fournisseur de contenu

Vous n'avez pas besoin d'un fournisseur pour utiliser une base de données SQLite si l'utilisation se fait entièrement dans votre propre application.

Alors pourquoi se donner la peine de développer ces frais généraux? Vous voulez un développement plus facile et plus rapide, non? Donc une couche d'abstraction (descendant de SQLiteOpenHelper) suffit.

Voir Rasoir d'Occam Ne créez pas d'entités sans une très bonne raison.

N'utilisez pas de fournisseur de contenu si vous ne souhaitez pas partager de données avec d'autres applications. Utilisez simple sqlitedatabase pour effectuer des opérations de base de données. Soyez prudent lorsque vous utilisez des fournisseurs de contenu pour stocker des données confidentielles, car vos informations confidentielles peuvent être consultées par d'autres applications

L'utilisation d'un fournisseur de contenu peut vous aider à atteindre un niveau d'abstraction supplémentaire - En le plaçant dans votre propre application, vous augmentez considérablement le temps de développement de votre projet. Cependant, si vous l'utilisez pour partager des données, des paramètres d'application ou des configurations entre plusieurs applications, le fournisseur de contenu est votre choix.

Surveillez vos niveaux de sécurité et je recommanderais d'utiliser SQLcipher pour crypter les données à la réinitialisation (DAR) si votre fournisseur de contenu écrit sur SQLite. (J'ai utilisé un fournisseur de contenu dans quelques solutions et fourni la possibilité de prendre un «instantané» en direct des valeurs opérationnelles pour le débogage et les tests.)