¿Qué es mejor: @SuppressLint o @TargetApi?


100

Tengo problemas en mi aplicación StrictModey agregué el fragmento de código que básicamente deshabilita StrictModeHelper. Sin embargo, Lint se queja setThreadPolicy()ahora y propone agregar

@SuppressLint 'NewApi'

o

@TargetApi(Build.VERSION_CODES.GINGERBREAD)

al onCreate()evento de la vista.

¿Qué método se prefiere ... o básicamente están haciendo lo mismo?

Respuestas:


176

Tengo problemas en mi aplicación con respecto a StrictMode y agregué el fragmento de código que básicamente deshabilita StrictModeHelper

Corrija el error de red.

¿Qué método se prefiere ... o básicamente están haciendo lo mismo?

@TargetApi y @SuppressLint tienen el mismo efecto central: suprimen el error de pelusa.

La diferencia es que @TargetApiusted declara, a través del parámetro, qué nivel de API ha abordado en su código, de modo que el error puede aparecer nuevamente si luego modifica el método para intentar hacer referencia a algo más nuevo que el nivel de API citado en@TargetApi .

Por ejemplo, suponga que, en lugar de bloquear las StrictModequejas sobre su error de red, intenta solucionar el problema de AsyncTaskser serializado en versiones más nuevas de Android. Tiene un método como este en su código para optar por el grupo de subprocesos en los dispositivos más nuevos y utilizar el comportamiento de subprocesos múltiples predeterminado en los dispositivos más antiguos:

  @TargetApi(11)
  static public <T> void executeAsyncTask(AsyncTask<T, ?, ?> task,
                                          T... params) {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
      task.executeOnExecutor(AsyncTask.THREAD_POOL_EXECUTOR, params);
    }
    else {
      task.execute(params);
    }
  }

Tener @TargetApi(11)significa que si Lint detecta que estoy usando algo más nuevo que mi android:minSdkVersion, pero hasta el nivel de API 11, Lint no se quejará. En este caso, funciona. Sin embargo, si modifiqué este método para hacer referencia a algo que no se agregó hasta el nivel de API 14, el error de Lint volvería a aparecer, porque mi @TargetApi(11)anotación dice que solo arreglé el código para que funcione en el nivel de API 11 y más abajo , no API nivel 14 y menos arriba.

Al usar @SuppressLint('NewApi'), perdería el error de Lint para cualquier nivel de API, independientemente de lo que mi código haga referencia y para qué esté configurado mi código para manejar.

Por lo tanto, @TargetApies la anotación preferida, ya que le permite decirle a las herramientas de compilación "OK, arreglé esta categoría de problemas" de una manera más detallada.


Soy consciente de que sería preferible utilizar un enfoque Async, solo que en mi caso particular me ceñiré a la solución. Gracias por esta explicación detallada y muy comprensible, y en esta oportunidad, gracias también por sus páginas web muy útiles que me ayudaron mucho a comprender algunos de los conceptos de programación de Android. R.
richey

9
@richey: "solo en mi caso particular, me ceñiré a la solución alternativa", esa no es una buena idea. Los dispositivos móviles son móviles. Las conexiones de red son bastante inestables y pueden llevar mucho más tiempo en diversas circunstancias (p. Ej., Señal débil). Realizar E / S de red en el hilo principal de la aplicación significa que su aplicación se bloqueará aleatoriamente con un ANR en el campo.
CommonsWare

2
¡Vaya, su ejemplo de código es el código EXACTO que estoy tratando de escribir! Qué coincidencia :)
Ilya Kogan

4
¿No sería más ordenado / más consistente usar @TargetApi (Build.VERSION_CODES.HONEYCOMB) dado que usa Build.VERSION_CODES.HONEYCOMB en la declaración if?
Oliver Pearmain

1
"que solo arreglé el código para que funcione en el nivel de API 11 e inferior, no en el nivel de API 14 o inferior". - ¿No te refieres a "y más"?
arekolek
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.