Estoy volviendo a trabajar en una aplicación que trabajé hace un tiempo, cuando yo tenía todo lo construido en torno a Android 2.2 Froyo.

He actualizado el SDK para la última Api y noté que el ClipboardManager cuenta de que estaba utilizando están en desuso. He actualizado el código para utilizar el nuevo ClipData modelo y lo probé en mi Froyo teléfono y, por supuesto, tengo un NoClassDefFoundError en el nuevo código.

He echado un vistazo alrededor y no he encontrado ninguna real de los debates de la estrategia general para mantener la compatibilidad hacia atrás.

No estoy del todo seguro de cómo debo manejar esta y otras situaciones en las que la API es diferente, porque quiero que los usuarios de todas las versiones para ser capaz de utilizar mi aplicación.

Debo estar haciendo una verificación de la siguiente manera?

if(version == old){
   use old API;
} else {
   use new API;
}

Si es así, tengo código obsoleto en mi clase y Eclipse tendrá la advertencia de allí para siempre.

Por otro lado, yo sólo podía construir en contra de una antigua versión de la API y la esperanza de que las nuevas versiones se manejarlo bien. Pero luego me corre el riesgo de la construcción contra buggy o de bajo rendimiento código cuando una mejor alternativa disponible.

¿Cuál es la mejor manera de lidiar con esto?

InformationsquelleAutor HXCaine | 2011-06-12

3 Comentarios

  1. 17

    Usted puede hacer eso (comprobación de la versión de la API).

    También puede utilizar la reflexión para llamar a las nuevas clases.

    Yo no me preocuparía por obsoleto el uso de métodos como todas las versiones de Android son compatibles hacia atrás, diciendo que desea ver cuando las cosas son para 3.0 Honeycomb como estos son un poco diferentes.

    He aquí una explicación de cómo utilizar la reflexión: (sí lo ha hecho antes, así que tal vez la búsqueda de la reflexión)

    http://www.youtube.com/watch?v=zNmohaZYvPw&feature=player_detailpage#t=2087s

    Estoy buscando que el proyecto esta en disponible, pero hasta entonces, aquí está el código:

    (Usted puede hacer esto en una clase que extiende de la Aplicación es decir, una configuración de tiempo)

     public static Method getExternalFilesDir;
    
        static {
                try {
                        Class<?> partypes[] = new Class[1];
                        partypes[0] = String.class;
                        getExternalFilesDir = Context.class.getMethod("getExternalFilesDir", partypes);
                } catch (NoSuchMethodException e) {
                        Log.e(TAG, "getExternalFilesDir isn't available in this devices api");
                }
        } 

    Ahora getExternalFilesDir() sólo está disponible en la API de nivel 8 o superior, así que quiero utilizar este si que tiene (Froyo), pero de lo contrario me necesita otro método.

    Ahora tengo mi prueba para el método que yo pueda seguir adelante y tratar de empleo:

      if(ClassThatExtendsApplication.getExternalFilesDir != null){
                Object arglist[] = new Object[1];
                arglist[0] = null;  
                File path = (File) ClassThatExtendsApplication.getExternalFilesDir.invoke(context, arglist);
               //etc etc
      } else {
          //Not available do something else (like your deprecated methods /or load a different class /or notify they should get a newer version of Android to enhance your app ;-))
      }

    Esperanza de que la ayuda de los accesos directos y un montón de google 🙂

    P. S. si en la otra cosa que usted desea utilizar su deprectated métodos todavía, sólo tiene que añadir el @SuppressWarnings("deprecation") anotación por encima de ella, Esto va a deshacerse de la advertencia y se han hecho por las razones correctas cuando usted está usando la última API cuando sea posible.

  2. 4

    Aquí está un ejemplo:

    import android.os.Build;
    
    public static int getWidth(Context mContext){
        int width=0;
        WindowManager wm = (WindowManager) mContext.getSystemService(Context.WINDOW_SERVICE);
        Display display = wm.getDefaultDisplay();
    
        if(VERSION.SDK_INT > VERSION_CODES.HONEYCOMB){                   
            Point size = new Point();
            display.getSize(size);
            width = size.x;
        } 
        else{ 
            width = display.getWidth();  //deprecated, use only in Android OS<3.0.
        } 
        return width;
    } 

    como se puede ver la sección de código:

      if(VERSION.SDK_INT > VERSION_CODES.HONEYCOMB){                   
                Point size = new Point();
                display.getSize(size);
                width = size.x;
            } 

    sólo está disponible para Android 3.0 y versiones posteriores, si desea que este código disponga al menos para Jelly Bean (Android 4.1) uso:

      if(VERSION.SDK_INT > VERSION_CODES.JELLY_BEAN){                   
                Point size = new Point();
                display.getSize(size);
                width = size.x;
            } 

    VERSIÓN.SDK_INT El usuario visible SDK de la versión del framework; su posible
    los valores se definen en Construir.VERSION_CODES.

    Más información acerca de: Construir.La VERSIÓN

    Y se puede ver la VERSION_CODES constats aquí: Construir.VERSION_CODES

  3. 2

    Se han identificado correctamente los dos posibles soluciones: decidir en tiempo de ejecución de la API para el uso de, o de usar siempre el viejo de la API.

    Si ayuda, puede ser sólo un año o así hasta dispositivos con la antigua API forma una pequeña proporción de la instalación de la base de que puede cambiar completamente a la nueva API y no preocuparse de perder demasiados usuarios.

    • EN GoogleIO se ha mencionado que los múltiples versiones va a ser una cosa común con Android, así que vale la manipulación de este deprectation problema para varias versiones, como parece que va a ser un problema continuo.

Dejar respuesta

Please enter your comment!
Please enter your name here