Qu'est-ce qui est mieux: @SuppressLint ou @TargetApi?

100

J'ai des problèmes dans mon application concernant StrictModeet j'ai ajouté l'extrait de code qui désactive fondamentalement le StrictModeHelper. Cependant, Lint se plaint setThreadPolicy()maintenant et propose soit d'ajouter

@SuppressLint 'NewApi'

@TargetApi(Build.VERSION_CODES.GINGERBREAD)

à l' onCreate()événement de la vue.

Quelle méthode est préférable ... ou font-ils essentiellement la même chose?

android eclipse lint

— richey
source

176

J'ai des problèmes dans mon application concernant StrictMode et j'ai ajouté l'extrait de code qui désactive fondamentalement StrictModeHelper

Veuillez corriger le bogue de réseau.

Quelle méthode est préférable ... ou font-ils essentiellement la même chose?

@TargetApiet @SuppressLintont le même effet de base: ils suppriment l'erreur Lint.

La différence est qu'avec @TargetApi, vous déclarez, via le paramètre, quel niveau d'API vous avez adressé dans votre code, de sorte que l'erreur puisse réapparaître si vous modifiez ultérieurement la méthode pour essayer de référencer quelque chose de plus récent que le niveau d'API cité dans @TargetApi.

Par exemple, supposons qu'au lieu de bloquer les StrictModeplaintes concernant votre bogue de réseau, vous essayiez de contourner le problème de la AsyncTasksérialisation sur les nouvelles versions d'Android. Vous avez une méthode comme celle-ci dans votre code pour activer le pool de threads sur les appareils plus récents et utiliser le comportement multithread par défaut sur les appareils plus anciens:

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

Cela @TargetApi(11)signifie que si Lint détecte que j'utilise quelque chose de plus récent que mon android:minSdkVersion, mais jusqu'au niveau API 11, Lint ne se plaindra pas. Dans ce cas, cela fonctionne. Si, cependant, je modifiais cette méthode pour faire référence à quelque chose qui n'a pas été ajouté avant le niveau d'API 14, l'erreur Lint réapparaîtrait, car mon @TargetApi(11)annotation indique que j'ai uniquement corrigé le code pour qu'il fonctionne sur le niveau d'API 11 et ~~inférieur~~ au - dessus, pas API de niveau 14 et ~~inférieur~~ .

En utilisant @SuppressLint('NewApi'), je perdrais l'erreur Lint pour n'importe quel niveau d'API, indépendamment de ce que mon code fait référence et de ce que mon code est configuré pour gérer.

Par conséquent, @TargetApiest l'annotation préférée, car elle vous permet de dire aux outils de construction "OK, j'ai corrigé cette catégorie de problèmes" d'une manière plus fine.

— CommonsWare
source

Je suis conscient que l'utilisation d'une approche Async serait préférable, juste dans mon cas particulier, je m'en tiendrai à la solution de contournement. Merci pour cette explication détaillée et très compréhensible - et à cette occasion, merci également pour vos pages Web très utiles qui m'ont beaucoup aidé à comprendre certains des concepts de la programmation Android! R.

— richey

@richey: "dans mon cas particulier, je m'en tiendrai à la solution de contournement" - ce n'est pas une bonne idée. Les appareils mobiles sont mobiles. Les connexions réseau sont plutôt instables et peuvent prendre beaucoup plus de temps dans diverses circonstances (par exemple, signal faible). L'exécution d'E / S réseau sur le thread d'application principal signifie que votre application se bloquera de manière aléatoire avec un ANR sur le terrain.

— CommonsWare

Wow, votre exemple de code est le code EXACT que j'essaie d'écrire! Quelle coïncidence :)

— Ilya Kogan

Ne serait-il pas plus ordonné / plus cohérent d'utiliser @TargetApi (Build.VERSION_CODES.HONEYCOMB) étant donné que vous utilisez le Build.VERSION_CODES.HONEYCOMB dans l'instruction if?

— Oliver Pearmain

"que j'ai corrigé le code uniquement pour qu'il fonctionne au niveau d'API 11 et inférieur, et non au niveau d'API 14 et inférieur." - ne voulez-vous pas dire "et au-dessus"?

— arekolek