¿Cómo puedo evitar métodos obsoletos y mantener la compatibilidad hacia atrás?

Posible duplicado:
Cómo tratar las clases obsoletas en Android para mantener la compatibilidad

Me encontré con el método de Display.getWidth() obsoleto y vi que se ha sustituido por android.view.getSize() . Sin embargo getSize() sólo ha estado disponible ya que la API 13 y View no se incluyen en la biblioteca de soporte de V4 Android.

Android Support Library 23.2.0 haciendo que la flecha de la barra de herramientas sea negra
TabLayout no rellena el ancho cuando tabMode se establece en 'scrollable'
Fragmento con ViewPager dentro de Fragmento y FragmentStatePagerAdapter resultados en Excepción (con ejemplo completo)
Soporte para Android Barra de herramientas que no muestra la costumbre dibujable correctamente
Styling Toolbar no funciona con AppCompat

Por lo tanto, si quiero evitar las llamadas obsoletas, ¿cómo puedo hacer esto sin mantener diferentes proyectos / builds para varios niveles de API.

Dado un objeto Display llamado display , esto debería funcionar:

 int width=-1; if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.HONEYCOMB_MR2) { Point size=new Point(); size=display.getSize(size); width=size.x; } else { width=display.getWidth(); }

IOW, utilice Build.VERSION.SDK_INT para derivar entre los casos "antes" y "después" donde se introduce una nueva API.

Esto requerirá que el objetivo de creación (Proyecto> Propiedades> Android en Eclipse) se establezca en el Nivel 13+ de API, por lo que puede llamar a getSize() .

Hay una clase oficial de desarrolladores de Android Creación de interfaces de usuario compatibles con versiones anteriores :

Esta clase demuestra cómo utilizar componentes de interfaz de usuario y API disponibles en versiones más recientes de Android de una manera compatible con versiones anteriores, asegurándose de que su aplicación siga ejecutándose en versiones anteriores de la plataforma.

Abogan por el uso de interfaces Java para las bibliotecas que no son back-portadas para obtener una solución más orientada a objetos. A continuación, se extienden estos en dos clases concretas: una que proporciona un comportamiento alternativo para las plataformas no soportadas y una que llama a la API real de las plataformas soportadas.

Luego hay una clase de fábrica que instancia la clase correcta comprobando la plataforma actual en función del rango de plataforma soportado. En última instancia, sin embargo, se reduce a un condicional como if ( Build.VERSION.SDK_INT >= HONEYCOMB_MR2 ) .