Sí, se puede hacer eso. De hecho, hay más de una forma. (Nota: la única parte específica de Android de esta respuesta es la forma en que descubres la versión de la plataforma.)
Supongamos que la clase X tiene el método void y() en la versión 2.0 en adelante, pero no antes.
Una forma de invocar este método sin introducir ninguna dependencia de tiempo de compilación es utilizar la reflexión para localizar el Método y llamar al invoke en él. Por ejemplo:
X x = ...
if (BUILD.VERSION.RELEASE.compareTo("2.0") >= 0) {
// (exception handling omitted ...)
Method m = c.getClass().getDeclaredMethod("y");
m.invoke(x);
}
Otra forma es crear una API de adaptador de compatibilidad de la versión para su aplicación como esta:
/** 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 segunda versión se ve un peso pesado poco, pero tiene las ventajas de que la dinámica (el código lento, no seguro para tipos) se ejecuta solo una vez y el código específico de la versión está aislado del resto del código. En la vida real, probablemente pondría una cantidad de métodos en la interfaz del adaptador.
Este enfoque requiere un poco más de reflexión, para resolver cómo diseñar la API de compatibilidad para que aísle limpiamente las dependencias de versión del resto del código. También es posible que tenga que revisar la API del adaptador y crear nuevas clases de adaptadores para cada nueva versión principal (incompatible).
Por último, si los cambios en la API de plataforma que necesita para adaptarse a implicar el uso de clases o métodos en la versión anterior que son eliminado en la versión más reciente, entonces necesitará para compilar sus diversas clases de adaptador (por ejemplo, el CompatV* clases) usando diferentes SDK de Android. Esto hará que tus procesos de compilación sean más complicados.
Por otra "toma" en este problema, lea los siguientes artículos en el blog de Android:
Además de sus respuestas, he aquí algunos ejemplos de proyectos que demuestran las técnicas: http://github.com/commonsguy/cw-advandroid/tree/ master/Contacts/Pick/http://github.com/commonsguy/cw-advandroid/tree/master/Contacts/Spinners/ – CommonsWare