creez-des-applications-pour-android

5.3 Le partage de contenus entre applications
5.3.1 Côté client : accéder à des fournisseurs
Les fournisseurs de contenu permettent l’encapsulation de données, et, pour accéder à ces données,
il faudra utiliser les fameuses URI. Ici, nous ne saurons pas où ni comment les données sont
stockées. Dans une base de données, dans un fichier, sur un serveur distant ? Cela ne nous regarde
pas, du moment que les données nous sont mises à disposition.
Cependant, quel que soit le type de stockage, les données nous sont toujours présentées de la
même manière. En effet, et un peu comme une base de données relationnelle, un fournisseur de
contenu présente les données à une application extérieure dans une ou plusieurs tables. Chaque
entrée dans la table est représentée dans une ligne et chaque colonne représente un attribut.
Une chose importante à savoir avant de faire appel à un fournisseur de contenu : vous devez savoir
par avance la structure des tables (ses attributs et les valeurs qu’ils peuvent prendre), car
vous en aurez besoin pour exploiter correctement ce fournisseur de contenu. Il n’y a pas moyen
d’obtenir ce genre d’informations, il faut que le développeur du fournisseur vous communique
cette information.
[[information]] | Un fournisseur n’a pas besoin d’avoir une clé primaire. S’il en a une, elle peut
l’appeler _ID, même si ce n’est pas nécessaire. Si vous le faites, alors Android pourra faire
quelques traitements automatiquement. Par exemple, si vous voulez lier des données depuis un
fournisseur vers une ListView, il vaut mieux que la clé primaire s’appelle _ID de façon à ce que
le ListView puisse deviner tout seul qu’il s’agit d’une clé primaire.
Examinons les éléments architecturaux des fournisseurs de contenu, ainsi que la relation qui
existe entre les fournisseurs de contenu et les autres abstractions qui permettent l’accès aux données.
5.3.1.1 Accéder à un fournisseur
Il est possible d’accéder aux données d’une autre application avec un objet client ContentResolver.
Cet objet a des méthodes qui appellent d’autres méthodes, qui ont le même nom, mais qui se
trouvent dans un objet fournisseur, c’est-à-dire l’objet qui met à disposition le contenu pour
les autres applications. Les objets fournisseurs sont de type ContentProvider. Aussi, si
votre ContentResolver a une méthode qui s’appelle myMethod, alors le ContentProvider
aura aussi une méthode qui s’appelle myMethod, et quand vous appelez myMethod sur votre
ContentResolver, il fera en sorte d’appeler myMethod sur le ContentProvider.
[[question]] | Pourquoi je n’irais pas appeler ces méthodes moi-même ? Cela irait plus vite et ce
serait plus simple !
Parce que ce n’est pas assez sécurisé ! Avec ce système, Android est certain que vous avez reçu les
autorisations nécessaires à l’exécution de ces opérations.
Vous vous rappelez ce qu’on avait fait pour les bases de données ? On avait écrit des méthodes qui
permettent de créer, lire, mettre à jour ou détruire des informations dans une base de données.
Eh bien, ces méthodes, appelées méthodes CRUD, sont fournies par le ContentResolver. Ainsi,
si mon ContentResolver demande poliment à un ContentProvider de lire des entrées dans
la base de données de l’application dans laquelle se trouve ce ContentProvider, il appellera sur
lui-même la méthode lireCesDonnées pour que soit appelée sur le ContentProvider la même
méthode lireCesDonnées.
365