Oui, vous pouvez le faire. En fait, il y a plus d'un moyen. (Remarque: la seule partie spécifique à Android de cette réponse est la manière dont vous trouvez la version de la plateforme.)
Supposons que la classe X utilise la méthode void y() à partir de la version 2.0, mais pas avant. Une manière d'invoquer cette méthode sans introduire de dépendances de temps de compilation est d'utiliser la réflexion pour localiser la méthode et d'appeler le invoke dessus. Par exemple:
X x = ...
if (BUILD.VERSION.RELEASE.compareTo("2.0") >= 0) {
// (exception handling omitted ...)
Method m = c.getClass().getDeclaredMethod("y");
m.invoke(x);
}
Une autre façon est de créer une compatibilité de version API adaptateur pour votre application comme ceci:
/** Version compatibility adapter API */
interface Compat {
void doY();
}
/** Adapter class for version 1 */
class CompatV1 {
public void y(X x) {
// do nothing
}
}
/** Adapter class for version 2 */
class CompatV2 {
public void y(X x) {
x.y();
}
}
//
// Code to instantiate the relevant adapter for the current platform.
//
Class<?> compatClass;
// (Exception handling omitted)
if (BUILD.VERSION.RELEASE.compareTo("2.0") < 0) {
compatClass = Class.forName("...CompatV1");
} else {
compatClass = Class.forName("...CompatV2");
}
// (Exception handling omitted)
Compat compat = (Compat) compatClass.newInstance();
// The adapter object can be passed around as a parameter, wrapped
// as a singleton or injected using dependency injection.
// Invoke X.y() as follows:
X x = ...
compat.y(x);
La deuxième version semble un poids lourd de bits, mais il présente les avantages que la dynamique (le code lent, non typé) est exécuté une seule fois et le code spécifique à la version est isolé du reste du code. Dans la vraie vie, vous mettriez probablement un certain nombre de méthodes dans l'interface de l'adaptateur. Cette approche nécessite un peu plus de réflexion pour comprendre comment concevoir l'API de compatibilité afin d'isoler proprement les dépendances de version du reste du code. Vous devrez peut-être également réviser l'API de l'adaptateur et créer de nouvelles classes d'adaptateur pour chaque nouvelle version majeure (incompatible).
Enfin, si les modifications de l'API de la plate-forme que vous devez adapter à entraîner l'utilisation des classes ou des méthodes dans l'ancienne version qui sont supprimés dans la nouvelle version, vous devrez compiler vos différentes classes d'adaptation (par exemple, la CompatV* classes) en utilisant différents SDK Android. Cela rendra vos processus de construction plus compliqués.
Pour d'autres "prend" sur ce problème, lisez les articles suivants sur le blog Android:
En plus de vos réponses, voici quelques exemples de projets qui démontrent les techniques: http://github.com/commonsguy/cw-advandroid/tree/ master/Contacts/Pick/http://github.com/commonsguy/cw-advandroid/tree/master/Contacts/Spinners/ – CommonsWare