Tratar métodos obsoletos en android

Actualmente estoy creando una aplicación que apunta a la API 23, con una API mínima de 19.
En API 23 algunos de los métodos del componente android.widget.TimePicker fueron reemplazados.

Por ejemplo:

TimePicker.getCurrentHour(); 

Fue sustituido por:

 TimePicker.getHour(); 

Ahora, cuando se utiliza TimePicker en mi aplicación, debería comprobar si el dispositivo está utilizando API 22 o superior con la siguiente instrucción if:

 if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) TimePicker.getHour(); else TimePicker.getCurrentHour(); 

Lo que hice fue ampliar la clase TimePicker e implementar los métodos obsoletos como esto:

 public class TimePicker extends android.widget.TimePicker { public TimePicker(Context context) { super(context); } public void setCurrentHour(int hour) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) super.setHour(hour); else super.setCurrentHour(hour); } public void setCurrentMinute(int minute) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) super.setMinute(minute); else super.setCurrentMinute(minute); } public int getCurrentHour() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) return super.getHour(); else return super.getCurrentHour(); } public int getCurrentMinute() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) return super.getMinute(); else return super.getCurrentMinute(); } } 

Por lo que el usuario que utiliza esta clase no afectará el cambio de los métodos (solo debería reemplazar la importación de la clase TimePicker en su implementación).

¿Es la manera correcta de hacerlo? O hay una mejor solución?

Gracias

3 Solutions collect form web for “Tratar métodos obsoletos en android”

La forma en que has realizado es una buena práctica hasta donde puedo leer de la parte mostrada.

Sin embargo, como he visto hasta ahora, la mejor práctica ha sido hacer diferentes subdivisiones de cada clase que se pretende publicar y apilar el programa durante la instalación.

Esto básicamente significa que if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) va en la parte superior de la clase.

Si su proyecto pretende ir en más versiones, sugiero esto:

 public class Example extends moreExamples implements additionalExamples{ switch(Build.VERSION.SDK_INT){ case Build.VERSION_CODES.M: codeVersionM(); break; case Build.VERSION_CODES.L: codeVersionL(); break; case Build.VERSION_CODES.K: codeVersionK(); break; default: errorNoBuildImplemented(); } } 

Lo que has hecho está bien, pero probablemente no sea la mejor solución porque:

  • Está utilizando los nombres de métodos antiguos en lugar de los nuevos
  • La creación de una clase personalizada obliga a utilizar esa clase personalizada en sus diseños y código en sustitución de la clase del marco. Es preferible evitar crear vistas personalizadas si es posible.

Hay generalmente 2 maneras recomendadas:

1) Continúe utilizando el método obsoleto hasta que actualice su minSDK. Llamará internamente al nuevo método en la nueva implementación:

 @Deprecated public void setCurrentHour(@NonNull Integer currentHour) { setHour(currentHour); } 

2) Cree una clase auxiliar estática que llamará al método correcto según la versión del SDK. Eso es lo que hace la biblioteca de soporte para muchas clases ya ( TextViewCompat , ViewCompat , …):

 public class TimePickerCompat { public static void setHour(TimePicker timePicker, int hour) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { timePicker.setHour(hour); } else { timePicker.setCurrentHour(hour); } } } 

Es mejor usar los nombres de los nuevos métodos. De esta manera, eventualmente puede deshacerse de su clase de compatibilidad cuando suba su versión min sdk a 23, sin tener que cambiar ningún código que no sea su importación.

 @SuppressWarnings("deprecation") public class TimePicker extends android.widget.TimePicker { public TimePicker(Context context) { super(context); } public TimePicker(Context context, AttributeSet attrs) { super(context, attrs); } public TimePicker(Context context, AttributeSet attrs, int defStyleAttr) { super(context, attrs, defStyleAttr); } @RequiresApi(api = Build.VERSION_CODES.LOLLIPOP) public TimePicker(Context context, AttributeSet attrs, int defStyleAttr, int defStyleRes) { super(context, attrs, defStyleAttr, defStyleRes); } public void setHour(int hour) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) super.setHour(hour); else super.setCurrentHour(hour); } public void setMinute(int minute) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) super.setMinute(minute); else super.setCurrentMinute(minute); } public int getHour() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) return super.getHour(); else return super.getCurrentHour(); } public int getMinute() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) return super.getMinute(); else return super.getCurrentMinute(); } } 
  • Reembolso de las compras de prueba al probar Google in-App
  • Subir archivo de imagen desde android a un servidor web aspx
  • Alineación derecha del texto en android?
  • Cómo agregar KmlLayer a M4B Google Map para empresas?
  • Deep linking en Android no inicia la aplicación y redirige a Android market market
  • Android Realm, objetos de consulta por atributo secundario
  • Cancelación de la conexión Http en android
  • Qué tan grande es la resolución de la pantalla con el desarrollo de Android
  • La solicitud de servicio web no funciona en el navegador android android; Pero está trabajando en el navegador de PC
  • Contar todos los valores Firebase Java API
  • Cómo rotar Bitmap sin crear uno nuevo?
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.