Awesome suggestions, thanks Mark!
kris On Fri, Nov 4, 2011 at 10:33 AM, Mark Murphy <[email protected]> wrote: > 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 -- 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
