O que é melhor: @SuppressLint ou @TargetApi?

100

Tenho problemas em meu aplicativo em relação StrictModeao trecho de código que basicamente desativa o StrictModeHelper. No entanto, Lint reclama setThreadPolicy()agora e propõe adicionar

@SuppressLint 'NewApi'

@TargetApi(Build.VERSION_CODES.GINGERBREAD)

para o onCreate()evento da vista.

Qual método é preferido ... ou eles estão basicamente fazendo o mesmo?

android eclipse lint

— rico
fonte

176

Tenho problemas em meu aplicativo em relação a StrictMode e adicionei o snippet de código que basicamente desativa o StrictModeHelper

Corrija o bug da rede.

Qual método é preferido ... ou eles estão basicamente fazendo o mesmo?

@TargetApie @SuppressLinttêm o mesmo efeito principal: eles suprimem o erro de Lint.

A diferença é que com @TargetApi, você declara, por meio do parâmetro, qual nível de API você endereçou em seu código, para que o erro possa aparecer novamente se você modificar o método posteriormente para tentar fazer referência a algo mais recente que o nível de API citado em @TargetApi.

Por exemplo, suponha que, em vez de bloquear as StrictModereclamações sobre o bug da rede, você esteja tentando contornar o problema de AsyncTaskser serializado em versões mais recentes do Android. Você tem um método como este em seu código para optar pelo pool de threads em dispositivos mais novos e usar o comportamento multithread padrão em dispositivos mais antigos:

  @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);
    }
  }

Ter @TargetApi(11)significa que se o Lint detectar que estou usando algo mais novo que o meu android:minSdkVersion, mas até o nível 11 da API, o Lint não reclamará. Nesse caso, isso funciona. Se, no entanto, eu modifiquei este método para fazer referência a algo que não foi adicionado até a API de nível 14, então o erro de Lint iria aparecer novamente, porque minha @TargetApi(11)anotação diz que eu só corrigi o código para funcionar na API de nível 11 e ~~abaixo~~ , não API nível 14 e ~~abaixo~~ acima.

Usando @SuppressLint('NewApi'), eu perderia o erro do Lint para qualquer nível de API, independentemente das referências do meu código e para o que meu código está configurado para lidar.

Conseqüentemente, @TargetApié a anotação preferida, pois permite que você diga às ferramentas de construção "OK, corrigi esta categoria de problemas" de uma forma mais refinada.

— CommonsWare
fonte

Estou ciente de que a utilização de uma abordagem Async seria preferível, apenas no meu caso particular, vou ficar com a solução alternativa. Obrigado por esta explicação detalhada e muito compreensível - e nesta oportunidade, obrigado também por suas páginas da web muito úteis que me ajudaram muito a entender alguns dos conceitos da programação Android! R.

— richey de

@richey: "apenas no meu caso particular, vou ficar com a solução alternativa" - isso não é uma boa ideia. Dispositivos móveis são móveis. As conexões de rede são bastante instáveis e podem levar muito mais tempo em várias circunstâncias (por exemplo, sinal fraco). Executar E / S de rede no encadeamento do aplicativo principal significa que seu aplicativo travará aleatoriamente com um ANR no campo.

— CommonsWare

Uau, seu exemplo de código é o código EXATO que estou tentando escrever! Que coincidência :)

— Ilya Kogan

Não seria mais legal / mais consistente usar @TargetApi (Build.VERSION_CODES.HONEYCOMB), dado que você usa Build.VERSION_CODES.HONEYCOMB na instrução if?

— Oliver Pearmain

"que eu apenas consertei o código para funcionar na API de nível 11 e abaixo, não na API de nível 14 e abaixo." - você não quer dizer "e acima"?

— arekolek,