What is better: @SuppressLint or @TargetApi?

Question

I have issues in my app regarding StrictMode and added the code snippet that basically disables the StrictModeHelper. However, Lint complains about setThreadPolicy() now and proposes to either add

@SuppressLint 'NewApi'

or

@TargetApi(Build.VERSION_CODES.GINGERBREAD)

to the onCreate() event of the view.

Which method is prefered ..or are they basically doing the same?

Solution

I have issues in my app regarding StrictMode and added the code snippet that basically disables the StrictModeHelper

Please fix the networking bug.

Which method is prefered ..or are they basically doing the same?

@TargetApi and @SuppressLint have the same core effect: they suppress the Lint error.

The difference is that with @TargetApi, you declare, via the parameter, what API level you have addressed in your code, so that the error can pop up again if you later modify the method to try referencing something newer than the API level cited in @TargetApi.

For example, suppose that, instead of blocking the StrictMode complaints about your networking bug, you were trying to work around the issue of AsyncTask being serialized on newer versions of Android. You have a method like this in your code to opt into the thread pool on newer devices and use the default multithread behavior on older devices:

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

Having @TargetApi(11) means that if Lint detects that I am using something newer than my android:minSdkVersion, but up to API Level 11, Lint will not complain. In this case, that works. If, however, I modified this method to reference something that wasn't added until API Level 14, then the Lint error would appear again, because my @TargetApi(11) annotation says that I only fixed the code to work on API Level 11 and below above, not API Level 14 and below above.

Using @SuppressLint('NewApi'), I would lose the Lint error for any API level, regardless of what my code references and what my code is set up to handle.

Hence, @TargetApi is the preferred annotation, as it allows you to tell the build tools "OK, I fixed this category of problems" in a more fine-grained fashion.

Comments

[richey]

I'm aware that utilizing an Async approach would be preferable, just in my particular case I'll stick to the workaround. Thanks for this detailed and very understandable explanation -- and at this chance, thanks also for your very helpful web pages which helped me a lot to understand some of the concepts of Android programming! R.

[CommonsWare]

@richey: "just in my particular case I'll stick to the workaround" -- that is not a good idea. Mobile devices are mobile. Network connections are rather unstable and may take significantly more time in various circumstances (e.g., weak signal). Performing network I/O on the main application thread means that your app will randomly crash with an ANR in the field.

[Ilya Kogan]

Wow, your code example is the EXACT code that I'm trying to write! What a coincidence :)

[Oliver Pearmain]

Wouldn't it be neater/more consistent to use @TargetApi(Build.VERSION_CODES.HONEYCOMB) given you use the Build.VERSION_CODES.HONEYCOMB in the if statement?

[CommonsWare]

@HaggleLad: Once upon a time, the "quick fix" in Eclipse used the number. I am not certain if there was a syntactical reason at the time or not. Eventually, they did update the "quick fix" to use the Build value. My answer here may have been from back when the "quick fix" still used 11.

[arekolek]

"that I only fixed the code to work on API Level 11 and below, not API Level 14 and below." - don't you mean "and above"?

[CommonsWare]

@arekolek: Correct! I have fixed the answer. Many thanks!