views:

137

answers:

2

I'm working on an Android app in which I would like to use multi-touch. However, I do not want to completely leave out those still running a 1.x OS phone. How do you program the app so that you can use the 2.x multi-touch APIs (or any other higher level API for that matter) and still allow it to gracefully degrade on 1.x systems. If you create a project in Eclipse for 1.x can you even still access the 2.x APIs? Basically I want it to show up in the marketplace and work on all 1.6 and higher phones and just allow access to the higher level functionality if available.

Also, if anyone can point me to any data on the number of 1.x devices vs. 2.x devices in use, it would be greatly appreciated.

+1  A: 

There's a good Android article on this topic called "Backward Compatibility for Applications." Essentially there are two things you can do:

  1. Set the minSdkVersion so that the app identifies itself as being compatible with a version of Android lower than what it was compiled on.

  2. Use reflection to access newer APIs.

You can also create a wrapper class for speed/ease of use, but that's just a flavor of #2.

As for platform usage, Google released this data a few months ago.

Daniel Lew
For option 1, I assume you must then do a version check before calling any of the upper level APIs to ensure that those are not called on lower level devices? Just having those APIs in the code won't cause it to crash?
Adam Haile
I ask because that article you linked to actually says to set minSDKVersion so that the app is NOT installed on lower API level devices...
Adam Haile
On a side note... maybe I'll ignore multi-touch for now... had no idea there were so few 2.x devices in use! Guess I'm spoiled with my Droid.
Adam Haile
@Adam: That data is several months old, and 1) a lot of people have bought the Nexus One, Desire, etc since then, and 2) 2.1 updates are being rolled out for us poor souls with older phones. Apparently, the Hero/G2, one of the very popular early phones, will start getting 2.1 at the end of this week. So in other words the proportion of 2.x devices out there is going to rocket soon.
Steve H
@Adam: I think that's a typo, I believe they meant to write "to ensure your app will be installed on older devices" because there's no other reason to use minSdkVersion. @Steve - I sure hope that most devices get upgraded to 2.x, but I'm still going to support 1.5 until I see data to the contrary.
Daniel Lew
+2  A: 

Here is how I use the AccountManager on 2.* but have a fallback on 1.* where it isn't available.

I build with the 2.1 SDK, but my Manifest states

<uses-sdk android:minSdkVersion="3" />

This does allow the app to run on 1.5 devices upwards.

I restrict my use of android.accounts.AccountManager to a wrapper class, I called it UserEmailFetcher.

It will be possible to use this class on 2.* devices. However on earlier devices a java.lang.VerifyError will fire the first time this class is encountered in the code. This I catch, and perform some fallback action.

String name;
try {
   name = UserEmailFetcher.getEmail(this); 
} catch (VerifyError e) {
   // Happens if the AccountManager is not available (e.g. 1.x)
}

Hope that helps.

Jim Blackler
Ahh, it looks like you have to do both a lower in level and a wrapper. Awesome, thanks!
Adam Haile
Jim - In your wrapper class are you using reflection to load the the library? Or is it VerrifyError that just gets thrown whenever you try to load an unavailable class? If you're not using reflection, that looks WAY easier than what the Google Backwards Compatibility document shows.
Adam Haile
@Adam Haile, no I don't use reflection, it doesn't seem to be necessary with this technique.
Jim Blackler