635.1W / P Fournisseurs de contenu – en particulier Contacts

Transcription

635.1W / P Fournisseurs de contenu – en particulier Contacts
635.1W / PROGRAMMATION
Fournisseurs de contenu – en particulier Contacts
1. Principes
 Les fournisseurs de contenu gèrent de l’information et la rendent accessible aux autres
applications.
 L’accès aux informations peut être soumis à des permissions spécifiques (à déclarer dans
le Manifest).
 Tous les fournisseurs de contenu exposent leurs fonctionnalités via une interface
commune qui permet d’accéder (CRUD) aux informations qu’ils gèrent.
 L’accès à l’ensemble des fournisseurs de contenu est modélisé par la classe abstraite :
android.content.ContentResolver  L’activité fournit une instance concrète de cette classe via getContentResolver().
 Les différents fournisseurs de contenu sont identifiés par une URI et les informations
qu’ils gèrent sont exposées sous forme tabulaire. Les tables ont toutes une colonne
nommée _ID qui contient l’identifiant de la ligne.
2. Interaction avec un fournisseur de contenu
 Pour interagir avec un fournisseur de contenu, il faut connaître :
- l’URI du fournisseur de contenu ;
- les noms des colonnes (champs) ;
- les types des champs ;
- l’identifiant (si nécessaire).
 Ces informations sont en général fournies sous forme de constantes par les classes qui
modélisent le fournisseur de contenu (c’est le cas pour les classes de bibliothèque implantant
les fournisseurs de contenu standards – contacts, calendrier, etc. ; c’est une bonne pratique que
devraient mettre en œuvre les fournisseurs de contenu nouvellement développés).
 Principales méthodes (de ContentResolver) :
- query() ;
- insert() ;
- update() ;
- delete().
3. Contacts
 Les contacts, nous l’avons vu, sont un fournisseur de contenu standard.
 Architecture :
Voir http://developer.android.com/resources/articles/contacts.html
 Un contact est l’agrégation de plusieurs sources de données (provenant de divers comptes
de synchronisation). Chaque source est modélisée par RawContact et les informations
effectives sont mémorisées dans les tables Data.
Peter Daehne
1/2
Version 1.0 – 18.05.2012
 Les classes suivantes du package android.provider.ContactsContract définissent
des constantes nécessaires à l’interrogation de la base de données des contacts :
- Contacts : les contacts en général ;
- Data : les constantes pour les tables Data ;
- CommonDataKinds : encapsule un ensemble de classes décrivant, sous forme de
constantes, les différents types de données pouvant être stockés dans les tables Data ;
parmi celles-ci, on peut noter les classes membres StructuredName,
StructuredPostal, Phone, Email, etc.
 Toutes ces classes exportent en général la constante CONTENT_URI qui est l’URI
désignant la table dans laquelle sont stockées les informations
 Lorsqu’on récupère un contact (comme vu précédemment), l’application Contacts
retourne une URI qui contient le chemin d’accès complet au contact :
- À partir de cette URI, il est possible de récupérer la Contacts.LOOKUP_KEY qui est
l’identifiant permanent d’un contact – celui qu’il faut stocker si on veut mémoriser la
référence d’un contact (voir méthode getLookUpKey() du projet 24-LectureContact).
- À partir de l’identifiant permanent, on peut récupérer l’identifiant (interne) au moyen
duquel on pourra interroger les différentes tables mémorisant les informations des
contacts (voir méthode getContactId() du projet 24-LectureContact).
 Pour
interroger la base des contacts, on emploie la méthode query() du
ContentResolver ; celle-ci retourne une instance de Cursor qui s’exploite exactement
comme un Cursor obtenu à partir d’une base de données locale.
Peter Daehne
2/2
Version 1.0 – 18.05.2012