Utilisation d’un fournisseur de contenu (content provider)

Utilisation d’un fournisseur de contenu (content provider)

Composantes d’une Uri

Le modèle simplifié de construction d’une Uri est constitué du schéma, de l’espace de noms des données et, éventuellement, de l’identifiant de l’instance. Ces différents composants sont séparés par des barres de fraction, comme dans une URL. Le schéma d’une Uri de contenu est toujours content://. L’Uri content://constants/5 représente donc l’instance constants d’identifiant 5. La combinaison du schéma et de l’espace de noms est appelée « Uri de base » d’un fournisseur de contenu ou d’un ensemble de données supporté par un fournisseur de contenu. Dans l’exemple précédent, content://constants est l’Uri de base d’un fournisseur de contenu qui sert des informations sur « constants » (en l’occurrence, des constantes physiques). L’Uri de base peut être plus compliquée. Celle des contacts est, par exemple, content:// contacts/people, car le fournisseur de contenu des contacts peut fournir d’autres données en utilisant d’autres valeurs pour l’Uri de base. L’Uri de base représente une collection d’instances. Combinée avec un identifiant d’instance (5, par exemple), elle représente une instance unique. La plupart des API d’Android s’attendent à ce que les URI soient des objets Uri, bien qu’il soit plus naturel de les considérer comme des chaînes. La méthode statique Uri.parse() permet de créer une instance d’Uri à partir de sa représentation textuelle. Obtention d’un descripteur D’où viennent ces instances d’Uri ? Le point de départ le plus courant, lorsque l’on connaît le type de données avec lequel on souhaite travailler, consiste à obtenir l’Uri de base du fournisseur de contenu lui-même. CONTENT_URI, par exemple, est l’Uri de base des contacts représentés par des personnes – elle correspond à content://contacts/people. Si vous avez simplement besoin de la collection, cette Uri fonctionne telle quelle ; si vous avez besoin d’une instance dont vous connaissez l’identifiant, vous pouvez utiliser la méthode addId() d’Uri pour la lui ajouter, afin d’obtenir une Uri pour cette instance précise. Vous pourriez également obtenir des instances d’Uri à partir d’autres sources – vous pouvez récupérer des descripteurs d’Uri pour les contacts via des sous-activités répondant aux intentions ACTION_PICK, par exemple. Dans ce cas, l’Uri est vraiment un descripteur Livre Android.book Page 280 Dimanche, 8. novembre 2009 12:23 12 customer 27921 at Fri Mar 11 19:19:45 +0100 2011 Propriété de Albiri Sigue Chapitre 27 Utilisation d’un fournisseur de contenu (content provider) 281 opaque… jusqu’à ce que vous décidiez de la déchiffrer à l’aide des différentes méthodes d’accès de la classe Uri. Vous pouvez également utiliser des objets String codés en dur (« content:// contacts/ people », par exemple) et les convertir en instances Uri grâce à Uri.parse(). Ceci dit, ce n’est pas une solution idéale car les valeurs des Uri de base sont susceptibles d’évoluer au cours du temps. Création des requêtes À partir d’une Uri de base, vous pouvez exécuter une requête pour obtenir des données du fournisseur de contenu lié à cette Uri. Ce mécanisme ressemble beaucoup à SQL : on précise les « colonnes » qui nous intéressent, les contraintes permettant de déterminer les lignes du résultat, un ordre de tri, etc. La seule différence est que cette requête s’adresse à un fournisseur de contenu, pas directement à un SGBDR comme SQLite. Le point névralgique de ce traitement est la méthode managedQuery(), qui attend cinq paramètres : 1. L’Uri de base du fournisseur de contenu auquel s’adresse la requête ou l’Uri d’instance de l’objet interrogé. 2. Un tableau des propriétés d’instances que vous voulez obtenir de ce fournisseur de contenu. 3. Une contrainte, qui fonctionne comme la clause WHERE de SQL. 4. Un ensemble éventuel de paramètres à lier à la contrainte, par remplacement des éventuels marqueurs d’emplacements qu’elle contient. 5. Une instruction de tri facultative, qui fonctionne comme la clause ORDER BY de SQL. Cette méthode renvoie un objet Cursor à partir duquel vous pourrez ensuite récupérer les données produites par la requête. Les « propriétés » sont aux fournisseurs de contenu ce que sont les colonnes aux bases de données. En d’autres termes, chaque instance (ligne) renvoyée par une requête est formée d’un ensemble de propriétés (colonnes) représentant, chacune, un élément des données. Tout ceci deviendra plus clair avec un exemple : voici l’appel de la méthode managedQuery() de la classe ConstantsBrowser du projet ContentProvider/Constants : constantsCursor=managedQuery(Provider.Constants.CONTENT_URI, PROJECTION, null, null, null); Les paramètres de cet appel sont :  ● l’Uri passée à l’activité par l’appelant (CONTENT_URI), qui représente ici l’ensemble des constantes physiques gérées par le fournisseur de contenu ; ● la liste des propriétés à récupérer (voir le code ci-après) ; ● trois valeurs null, indiquant que nous n’utilisons pas de contrainte (car l’Uri représente l’instance que nous voulons), ni de paramètres de contrainte, ni de tri (nous ne devrions obtenir qu’une seule ligne). private static final String[] PROJECTION = new String[] { Provider.Constants._ID, Provider.Constants.TITLE, Provider.Constants.VALUE}; Le plus gros « tour de magie », ici, est la liste des propriétés. La liste des propriétés pour un fournisseur de contenu donné devrait être précisée dans la documentation (ou le code source) de celui-ci. Ici, nous utilisons des valeurs logiques de la classe Provider qui représentent les différentes propriétés qui nous intéressent (l’identifiant unique, le nom et la valeur de la constante). S’adapter aux circonstances Lorsque managedQuery() nous a fourni un Cursor, nous avons accès au résultat de la requête et pouvons en faire ce que nous voulons. Nous pouvons, par exemple, extraire manuellement les données du Cursor pour remplir des widgets ou d’autres objets. Cependant, si le but de la requête est d’obtenir une liste dans laquelle l’utilisateur pourra choisir un élément, il est préférable d’utiliser la classe SimpleCursorAdapter, qui établit un pont entre un Cursor et un widget de sélection comme une ListView ou un Spinner. Pour ce faire, il suffit de copier le Cursor dans un SimpleCursorAdapter que l’on passe ensuite au widget – ce widget montrera alors les options disponibles. La méthode onCreate() de ConstantsBrowser, par exemple, présente à l’utilisateur la liste des constantes physiques : @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); constantsCursor=managedQuery(Provider.Constants.CONTENT_URI, PROJECTION, null, null, null); ListAdapter adapter=new SimpleCursorAdapter(this, R.layout.row, constantsCursor, new String[] {Provider.Constants.TITLE, Provider.Constants.VALUE}, new int[] {R.id.title, R.id.value}); setListAdapter(adapter); registerForContextMenu(getListView()); }  Après l’exécution de managedQuery() et l’obtention du Cursor, ConstantsBrowser crée un SimpleCursorAdapter avec les paramètres suivants : ● L’activité (ou un autre Context) qui crée l’adaptateur. Ici, il s’agit de ConstantsBrowser elle-même. ● L’identifiant du layout utilisé pour afficher les éléments de la liste (R.layout.row). ● Le curseur (constantsCursor). ● Les propriétés à extraire du curseur et à utiliser pour configurer les instances View des éléments de la liste (TITLE et VALUE). ● Les identifiants correspondants des widgets TextView qui recevront ces propriétés (R.id.title et R.id.value.