2010-11-15 3 views
1

J'ai une classe personnalisée ContentProvider, que j'ai initialement développé dans le même fichier de projet avec l'application qui l'utilise. Cependant, puisque cette application est destinée à être l'un des nombreux utilisateurs de la ContentProvider, je veux le partager dans un projet différent. Le code est en cours de développement sur le PDK Android, mais les futurs clients peuvent être développés sur le SDK (sur un SDK personnalisé, ou un plugin SDK, etc.).Existe-t-il un moyen «approprié» de séparer l'implémentation d'un fournisseur de contenu de ses utilisateurs?

Le problème auquel je suis confronté concerne les constantes de la classe ContentProvider, par ex. CONTENT_URI, les noms de colonnes et certaines constantes utilisées pour interpréter les valeurs renvoyées par les requêtes. Ceux-ci ne peuvent évidemment pas être accédés d'un autre projet. Il me semble que j'ai 3 options à ce stade:

1) Ignorer le problème, et tapez les valeurs directement dans le code de l'application utilisateur. Cela rend toutefois l'accès à la ContentProvider plus laid. Je devrais changer certaines colonnes, pour encoder certaines colonnes avec des chaînes au lieu d'entiers, pour maintenir le code maintenable.

2) Placez les constantes dans une classe distincte et incluez une copie complète dans les applications en utilisant le ContentProvider. Je ne suis pas fan du code de duplication. Garder une copie de ce code dans chaque application cible, rendra certaines choses légèrement plus ennuyeuses à maintenir.

3) Abuser le fait que je développe sur le PDK, et exposer une bibliothèque de plate-forme, comme décrit dans vendor/sample/frameworks/PlatformLibrary. Cependant, les bibliothèques de plate-forme n'ont pas de fichier manifeste, ce qui si ma compréhension est correcte signifie que je ne peux pas inclure un ContentProvider. Cela signifie que j'aurais besoin d'un projet "normal" pour le ContactProvider, et un autre pour exposer la classe avec les valeurs constantes. Cela semble tellement faux.

La réponse à Class structure for a ContentProvider having multiple sub tables semble impliquer l'option (1), qui semble probablement être la meilleure option actuellement.

Cependant, peut-être que j'ai raté un autre, soigné &, façon de faire cela? En gardant à l'esprit que je développe sur le PDK, je voudrais certainement que mon ContentProvider soit utilisable de la même manière que les fournisseurs de stock de Google.

Répondre

3

Vous avez probablement déjà au moins une classe/interface qui définit le « contrat » de vos ContentProvider en utilisant des constantes statiques pour les noms de colonnes, un URI contenu, etc.

Si vous mettez cela dans sa propre bibliothèque SDK Android projet (juste pour que les classes Android soient sur le build/classpath), vous pouvez ensuite utiliser cette bibliothèque à partir de votre application réelle SDK/PDK ContentProvider et également le distribuer en tant que myapp-api.jar JAR pour les autres à utiliser.

De cette façon, vous obtenez le meilleur des deux mondes: Aucun code obsolète (parce que votre ContentProvider en dépend) et d'autres personnes peuvent utiliser de bonnes constantes pour les URI et les noms de colonnes.

Pour un exemple de classe de contrat, voir ContactsContract.

Questions connexes