Would you rather use testing Build.VERSION.SDK_INT or reflection to test for existence?

Question

Here's a question for all Android programmers out there:

When using old and new API methods in my apps, I found two ways to approach the different API methods.

1. Test for SDK_INT as in

   if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.JELLY_BEAN) {
       holder.content.setBackground(background);
   } else {
       holder.content.setBackgroundDrawable(background);
   }
   

2. Program a "Compat" class that uses reflection to test for method existence as in

   private static final Method sApplyMethod = findApplyMethod();
   
   private static Method findApplyMethod() {
       try {
           Class<?> cls = SharedPreferences.Editor.class;
           return cls.getMethod("apply");
       } catch (NoSuchMethodException unused) {
           // fall through
       }
       return null;
   }
   
   public static void apply(final SharedPreferences.Editor editor) {
       if (sApplyMethod != null) {
           try {
               sApplyMethod.invoke(editor);
               return;
           } catch (InvocationTargetException unused) {
               // fall through
           } catch (IllegalAccessException unused) {
               // fall through
           }
       }
       editor.commit();
   }
   

Now, the latter one is taking from a great book "50 Android hacks" by Carlos Sessa. I was taught that using exception handling for flow control is a bad thing and not to be done. If you can test against something, don't deliberately run into exception handling. Thus, method 2 would not be considered "clean".

But: on a mobile device, which is the preferred approach? Which one is faster on the long run?

Thanks for all your opinions!

Answer 1

which is the preferred approach?

IMHO, use Build.

Which one is faster on the long run?

Build.

More importantly, Build tells you what is supported, because you are reading the JavaDocs and making the determination of whether to do something based upon that documentation.

There are many public methods on public Java classes, where the classes are in the Android SDK, but the methods are not. Those get marked with @hide in the AOSP source code and are stripped out when creating the android.jar that we link to, when creating the JavaDocs, etc. Those represent methods that are "not ready for prime time" in the eyes of the Android team, but need to be public for internal use within the framework. The reflection technique will happily report that such hidden methods are available for use, even though:

• Their method signatures may differ (parameters, return type, exceptions) from what eventually was released in the SDK, either due to Android team changes or manufacturer changes

• The behavior of those hidden methods is undocumented and therefore may not match the functionality documented when those methods were released

I'm a big @Macarse fan, but this is one case where we'll have to agree to disagree.