Quelle est l'utilité des fournisseurs de contenu privés ?

Question

L'Android Guide du développeur dit

Les fournisseurs de contenu sont également utiles pour lire et écrire des données qui sont privées à votre application et non partagées.

En général, les fournisseurs de contenu sont utilisés pour fournir des données à différentes applications ou pour partager des données entre elles. Je me demandais s'il y a une utilité à avoir des fournisseurs privés et à ne pas vouloir les partager. Y a-t-il des avantages qu'un accès direct à la base de données ou au système de fichiers ne procure pas ?

Merci, Rajath

Answer 1

1. Il planifie automatiquement tous les accès à la base de données côté serveur et de synchronisation dans un thread d'arrière-plan. Cependant, dans le frontend de votre application, le Content Resolver/Provider exécutera normalement les requêtes/transactions à partir du thread UI par défaut. Vous devez effectuer toutes les transactions de manière asynchrone (c'est-à-dire en utilisant un fil d'exécution CursorLoader ) pour garantir le bon fonctionnement de votre application du côté de l'interface utilisateur.
2. Il localise l'accès ré-entrant à la base de données à partir de n'importe quel thread qui accède par l'intermédiaire de ContentProvider Ainsi, le verrouillage peut s'effectuer entièrement dans les appels de contournement du ContentProvider, plutôt que d'en assurer le suivi dans une couche de base de données, un service et une couche d'interface utilisateur.
3. Dans le cadre de ce qui précède, il fournit également une belle interface singleton à vos données - Si vous avez dix classes d'activité dans votre application, il suffit de passer par les appels statiques ContentResolver de chacun d'eux, plutôt que de devoir gérer l'ouverture/la fermeture d'une SQLiteDatabase dans chaque activité lorsque vous passez d'une activité à une autre dans votre application.
4. Le ContentProvider est très étroitement lié au modèle SyncAdapter -- ce qui signifie que c'est à peu près la seule façon de procéder si vous voulez garder votre base de données en synchronisation avec une base de données hébergée par un serveur sur le net. (votre application reflète une situation de type REST api).
5. Il est lié à l'interface ContentObserver de ContentResolver -- Il s'agit d'une interface où (parmi beaucoup d'autres choses utiles) une vue peut s'enregistrer comme observant un ensemble spécifique de données (à travers le curseur de ces données). Ensuite, si vous introduisez un changement dans le ContentProvider, le CP peut notifier le CR, qui peut à son tour notifier tous les curseurs pertinents, qui à leur tour vont requérir et provoquer la mise à jour de la vue. C'est beaucoup plus propre que de devoir garder manuellement la trace de vos vues pour pouvoir les invalider et les redessiner.

En ce qui concerne le verrouillage ré-entrant de la base de données, il ne le fait pas complètement, mais il aide - votre classe ContentProvider implémente quatre fonctions simples (interface CRUD) et, si vous choisissez de la surcharger, une cinquième, batchAdd() - Ceci localise votre verrouillage. La réponse la plus simple est de simplement marquer les quatre/cinq déclarations de fonctions "synchronisées" au niveau de la fonction et le tour est joué. C'est beaucoup plus propre que d'essayer de comprendre le verrouillage à partir de 20 endroits qui accèdent à votre base de données dans 5 activités différentes.