In a lot of cases you can probably avoid checking the API version at all. For example as Andy McFadden describes in the backwards compatibility blog post, it is natural to simply test for the particular class or other API that you are wanting to use at the time you use it:
http://android-developers.blogspot.com/2009/04/backward-compatibility-for-android.html On Mon, Dec 21, 2009 at 9:47 AM, Mark Murphy <[email protected]>wrote: > Mark Wyszomierski wrote: > > Hi, > > > > I'm using the level 5 sdk to compile my app, but set my target to sdk > > level 3 in my manifest. All is fine. > > > > I may need to use some level 5 classes (ExifInterface) though. What's > > the right way to go about using them while not fouling things up for > > devices running older sdk versions? Do we simply restrict use of the > > newer API methods to completely separate class files? Something like > > this: > > > > // Test.java > > class Test > > { > > public boolean sdkDependentItem() { > > if (Build.VERSION.SDK.equals("5")) { > > return (new sdk5()).getItem(); > > } > > else { > > return (new sdk3and4()).getItem(); > > } > > } > > } > > > > // sdk5.java > > class sdk5 { > > public boolean getItem() { > > // can use sdk level 5 apis in here ok. > > } > > } > > > > // sdk3and4.java > > class sdk3and4 { > > public boolean getItem() { > > // can use sdk level 3 and 4 apis in here ok. > > } > > } > > > > so as long as the api methods are completely separated into files that > > the older devices won't invoke, we should be ok? > > I wouldn't do: > > if (Build.VERSION.SDK.equals("5")) { > > Instead, parse it to an integer and do a >=5 comparison. After all, most > DROIDs are now on API 6 (i.e., Android 2.0.1). And, once you drop older > SDK support, you can use SDK_INT and skip the parse step. > > If you are going to make the request a lot, you might consider having > your two implementations extend a common abstract class or implement a > common interface. Then, you can make the determination of which one to > use once and hold onto that object, calling it by the common interface > as needed. > > Otherwise, the notion of "if I don't load the class, there will be no > harm in it referencing newer API capabilities" is sound. > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://twitter.com/commonsguy > > _The Busy Coder's Guide to Android Development_ Version 2.8 > Available! > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
