On Fri, Nov 4, 2011 at 10:14 AM, Zsombor <[email protected]> wrote: > And my code is currently full of conditional > statements that check the current Droid version so I only use newer > features (like drag-drop, etc.) if I'm able to.
You may be able to clean that up by using interfaces: -- define an interface for all application functionality that you want that is tied to version -- create multiple implementations of that interface for distinct versions, leveraging inheritance where possible -- use the right implementation via a one-time API level check (e.g., set up a singleton implementation using a static initializer) You can see some of this in the ActionBarCompat SDK sample (API Level 14), where they have different implementations for pre-Honeycomb, Honeycomb, and Ice Cream Sandwich. Or, a more cut-down sample using the singleton approach can be found here: https://github.com/commonsguy/cw-advandroid/tree/master/Contacts/Spinners In this case, I have an interface and two implementations for dealing with Contacts vs. ContactsContract. All the version-specific stuff is isolated; the main code simply refers to the singleton without concern over version. > I also have to deal with devices with small screens and large screens, > so the navigation is different on them. For this, I also have to > support the new resource-identifiers that check the screen's width. You can just use the classic -normal, -large, etc. resource identifiers. The new ones are opportunistic, if using them will give you demonstrably better results. OTOH, if you're willing to ignore pre-Honeycomb tablets (e.g., original Samsung Galaxy Tab 7), you might be able to get away with using the new identifiers simply for your Honeycomb/Ice Cream Sandwich cases and assume everything else is -normal (or perhaps -small if you're supporting that). > It's working alright but things are just getting messier and more > complicated with every new Droid release. So is there a silver bullet > to this, or are we stuck in the increasingly over-complicated world of > backport libraries and conditional class loading based on the current > os version? IMHO, backport libraries *are* the silver bullet, to the extent that silver bullets exist. Code once, run across versions. Somebody could create libraries that wrap up other APIs (e.g., new drag-and-drop stuff) in a way that if you code to the library, older devices simply no-op the behaviors and newer devices use the newer APIs. I am not aware of any of these, outside of ActionBarSherlock that you're already using. Long term, somebody might do for Android what Cairngorm does for Flex: provide an application skeleton and framework that simplifies some common application patterns. Such a solution could bundle up a lot of this version-specific stuff, and you'd code to that solution. Beyond that, I recommend caffeine. :-) -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy Warescription: Three Android Books, Plus Updates, One Low Price! -- 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
