Quand utiliser un fournisseur de contenu
Je comprends que les fournisseurs de contenu sont conçus pour permettre le partage public des 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 à le faire? Des inconvénients?
Dans le passé, je venais tout juste 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 (car j'aurai une classe SQliteOpenHelper à l'intérieur de celle-ci) et plus de travail que nécessaire?
Si vous n'envisagez pas de partager des données, ne pensez pas aux fournisseurs de contenu. Ils sont puissants mais difficiles à écrire et il sera bête de les mettre en œuvre si vous les utilisez 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, je devais é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 encore, cela avait du sens et rendait l'application plus agréable.
Je dirais que c’est vraiment une bonne idée d’utiliser un ContentProvider même si vous n’avez pas l’intention de le rendre public.
Il est recommandé de fournir un niveau supplémentaire d'abstraction sur vos données pour faciliter les modifications en interne. Que faire si vous décidez de modifier la structure de la base de données sous-jacente ultérieurement? Si vous utilisez un ContentProvider, vous pouvez contenir tous les changements structurels qu'il contient. Dans ce cas, comme si vous n'en utilisiez pas, vous êtes obligé de modifier toutes les zones du code affectées par les changements structurels. 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 jeter des déchets dans votre code avec un accès de bas niveau à la base de données.
En outre, il est toujours possible que vous souhaitiez exposer vos données ultérieurement. Si vous n'utilisez pas un ContentProvider à l'avance, il sera beaucoup plus difficile de l'adapter ultérieurement.
Ensuite, il y a les autres parties d'Android où ContentProvider sont obligatoires/recommandés, par exemple lorsque vous utilisez SyncAdapters et si vous souhaitez un Widget d'application impliquant par exemple un accès aux données.
En résumé, l'écriture d'une ContentProvider à l'avance est très légère (une fois que vous avez appris l'API, ce qui est de toute façon une bonne idée), il est donc logique de le faire, même pour des données privées.
Jetez un coup d'œil au MOTODEV Studio for 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 si cela n'a pas d'incidence importante sur les performances, utilisez-le à l'avenir. Dans la plupart des scénarios, ce sera le cas.
Je conviens que ContentProviders est un peu difficile à comprendre, mais il est certainement utile, 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 dans lequel vous pouvez avoir 5 tables dans votre base de données, mais vous devez en joindre quelques-unes dans certains ordres avant de les utiliser. Et créez un URI de contenu pour chacune de ces jointures. Vous pouvez ensuite utiliser chacun ces URI comme une table :)
Je vous suggère d'aller de l'avant avec Content Provider, vous serez étonné de voir à quel point il est puissant.
De mon point de vue, le fournisseur de contenu offre de nombreux avantages, mais il suffit de partager des données avec d'autres applications. Si vous devez vous synchroniser avec le serveur à l'aide d'un Sync-Adapter, 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 ... puis le fournisseur de contenu est 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 associées au fournisseur de contenu.
À propos, vous pouvez rapidement construire votre base de données et votre CP en moins de 5 minutes en utilisant 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 est 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 (SQLiteOpenHelper descendent) suffit.
Voir Rasoir d'Occam Ne créez pas une entité sans une très bonne raison.
L'utilisation d'un fournisseur de contenu peut vous aider à atteindre un niveau d'abstraction supplémentaire: si vous le placez dans votre propre application, le temps de développement de votre projet sera considérable. Toutefois, 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 vous recommanderais d'utiliser SQLcipher pour chiffrer 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 une "photo instantanée" des valeurs opérationnelles pour le débogage et les tests.)
N'utilisez pas le fournisseur de contenu si vous ne souhaitez pas partager des 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 d'autres applications peuvent y accéder.