views:

108

answers:

4

Is there a simple line of code that would allow only loading the code if the OS version meets the requirements?

Lets say I have my target OS as 2.2 but the min sdk is 3 for android 1.5 so even if i have some code in my project that isn't compatable with 1.5 it will still compile since the target OS is 2.2. Anyway, I want to ad a feature that requires code that's not in the 1.5 SDK and will cause a crash if it's loaded on a 1.5 phone. Is there a simple thing like this that I can do? So i dont have to make the entire app not available to 1.5 users?

 if (Android OS == >2.1){
            //Insert code here that requires 2.1 and up}
        else{
            //insert code that would appear is OS is <2.1}
A: 

See Backward compatibility for Android (using Reflection).

JRL
A: 

You can check with Build.VERSION.RELEASE, it gives you the current version of your android system (1.5,1.6,2.1,2.2)

There is more on Build.VERSION

Colin Hebert
+3  A: 

Yes, you can do that. In fact there is more than one way. (Note: the only Android specific part of this answer is the way that you find out the platform version.)

Suppose that class X has method void y() in version 2.0 onwards, but not before.

One way to invoke this method with out introducing any compile time dependencies whatsoever is to use reflection to locate the Method and call invoke on it. For example:

X x = ...
if (BUILD.VERSION.RELEASE.compareTo("2.0") >= 0) {
    // (exception handling omitted ...)
    Method m = c.getClass().getDeclaredMethod("y");
    m.invoke(x);
}

Another way is to create a version compatibility adapter API for your application like this:

/** Version compatibility adapter API */
interface Compat {
    void doY();
}

/** Adapter class for version 1 */
class CompatV1 {
    public void y(X x) {
       // do nothing
    }
}

/** Adapter class for version 2 */
class CompatV2 {
    public void y(X x) {
       x.y();
    }
}

// 
// Code to instantiate the relevant adapter for the current platform.
//
Class<?> compatClass;
// (Exception handling omitted)
if (BUILD.VERSION.RELEASE.compareTo("2.0") < 0) {
    compatClass = Class.forName("...CompatV1");
} else {
    compatClass = Class.forName("...CompatV2");
}
// (Exception handling omitted)
Compat compat = (Compat) compatClass.newInstance();

// The adapter object can be passed around as a parameter, wrapped
// as a singleton or injected using dependency injection.

// Invoke X.y() as follows:

X x = ...
compat.y(x);

The second version looks a bit heavyweight, but it has the advantages that the dynamic (slow, non-type-safe) code is executed just once, and that the version specific code is isolated from the rest of the code. In real life, you would probably put a number of methods into the adapter interface.

This approach requires a bit more thought, to work out how to design the compatibility API so that it cleanly isolates the version dependencies from the rest of the code. You might also to have to revise the adapter API, and create new adapter classes for each new (incompatible) major release.

Finally, if the platform API changes that you need to adapt to entail using classes or methods in the older version that are removed in the newer version, then you will need to compile your various adapter classes (e.g. the CompatV* classes) using different Android SDKs. This will make your build processes rather more complicated.

Stephen C