Backwards Compatibility: Strategies and Tactics

AnDevCon III

Backwards
Compatibility:
Strategies and
Tactics
Copyright © 2012 CommonsWare, LLC

Device Mix

image Copyright © 2012 Google, Inc. – reprinted with permission


Device Mix
● The Market Is Not the World
● Kindle Fire
● NOOK Tablet
● Wearables (WIMM, I'm Watch, etc.)
● Miscellaneous non-Market devices
● If You Distribute to These, Take Their Versions Into
Account!


Device Mix
● Predictions Sure To Go Wrong
● November 2012: ICS and newer reaches majority status
– New device sales
– Upgrades for existing devices
● December 2012: Mayan Apocalypse
● April 2013: Android 2.x below 20%
● September 2013: Android 2.x below 5%
● December 2013: Ragnarök


Competing Strategies
● Old API-Centric
● Lowest common denominator
● Today: Android 2.3, maybe 2.2
● Only deal with newer things when unavoidable
● New API-Centric
● More aggressively support newer capabilities
– Particularly with respect to UI
● Today: ICS
● Gracefully degrade for older devices


Forwards, Not Backwards
● Older Ain't Gettin' Any Bigger
● Aim for the increasing market share, not the decreasing
share
● Sneezers' Devices
● Bloggers, media, etc.
● Tend towards newer devices
● If you look stale, may impact their interest in you


Forwards, Not Backwards
● Distinctive, Not Decomposing
● Are there new features that can give you a competitive
edge?
– Even if not all the users can take advantage of them
● It's the Way the (Web) World Works
● IE6-only versus graceful degradation
● Well-trod path, needing Android-specific tactics


Targets and Strategies
● Old API-Centric
● Build target = min SDK version = lowest common
denominator
● Target SDK version no higher than min SDK version
● New API-Centric
● Build target = oldest version that has everything you are
using directly (or via library)
● Min SDK version = oldest you are supporting
● Target SDK version = current-ish Android version

Validating Compatibility
● Compile-Time: Lint
● Keep your Android SDK tools/ADT updated!
● Will warn you when you try using newer stuff on older
minSdkVersion
– Requires manual lint run from Eclipse menu
● Use annotations to suppress warnings
– @TargetApi(NN)


Validating Compatibility
● Testing
● Directly via emulator
● Directly via available hardware
● Bulk-testing Services
– TestDroid Cloud
– LessPainful
– Apkudo
– Etc.


Libraries for Compatibility
● Android Support Package
● Fragments
– Large subset, but not everything from native API Level 11+
● Loaders
● GridLayout
● *Compat Classes
– Access to newer constants
– Helper methods to get at newer capabilities while gracefully
degrading to no-ops/defaults
● Separate Implementations


Libraries for Compatibility
● Action Bar Sherlock
● Implementation of ActionBar for Android 2.x
● Same API as native API Level 11+
● Nine Old Androids
● Implementation of android.animation framework
for Android 1.x/2.x


Ad-Hoc Backports
● Find AOSP Code, Clone, Fix
● New widgets (e.g., Switch)
● Other stuff largely separable from firmware
● Challenges
– Finding resources
– Dealing with package-private methods


Library/Backport Strategy
● Use as Temporary Scaffolding
● Know which API levels a given library or backport is
addressing
● May vary by what you are using
● Remove In Time
● Once you no longer are supporting the older API levels,
drop the scaffold and re-test


Java Version Guards
● Android 2.x+
● Wrap any references to items from newer API level in a
test of the API level

if (Build.VERSION.SDK_INT>Build.VERSION_CODES.GINGERBREAD) {
// do something
}


Java Version Guards
● Android 2.x+
● Wrap any references to items from newer API level in a
test of the API level

if (Build.VERSION.SDK_INT>=Build.VERSION_CODES.GINGERBREAD) {
@TargetApi(11)
// do something needing API Level 11+
}


Java Version Guards
● Scenario: AsyncTask
● Serialized if targetSdkVersion >= 14
● Use executeOnExecutor() to force to classic thread
pool model
● Problem: executeOnExecutor() new to API Level 11
● Solution: version guard block


Java Version Guards
● Android 1.x
● Problem: Dalvik complains if you load a class that refers
to items from a newer API level
● Solution
– Isolate newer-API items in a separate helper class
– Only refer to that helper class within a version guard block


Java Version Guards
● The Old API-Centric Approach
● Use version guard to detect newer API level
● Use reflection to access items that only exist at that API
level
● Benefit: can leave build target on older API level
– Build target only affects what you directly reference


Versioned Resources
● Use -vNN Resource Set Suffix
● Apply to resources valid for API Level NN and higher
● Scenario
– res/values/ = good for anything
– res/values-v11/ = good for Honeycomb and newer
● Example
– Style in -v11 that references Theme.Holo
– Style with same name in default directory that does not
reference Theme.Holo


Versioned Components
● Components Valid for Certain API Levels
● Activity only needed on Android 3.1+
● Different app widgets for API Level 11, older devices
● Technique
● Boolean resource, contained in two resource sets
– Default plus -vNN set
● Use boolean resource in android:enabled attribute in
manifest
– Disabled components do not show up anywhere


Scenario: Preferences
● Goals
● Want to use PreferenceFragments and headers on API
Level 11 and higher
● Want preferences to still work on Android 2.x
● Option #1: Different PreferenceActivity Classes
● Use versioned components trick to dictate which one is
available
● Use action, not component, in launching Intent
● Reuse preference XML as best you can


Scenario: Preferences
● Option #2: Version Guards
● One PreferenceActivity
● onBuildHeaders() only called on API Level 11+
● Reuse preference XML as best you can
● Option #3: Backport
● Find current implementation (source, resources)
● Convert to use Android Support fragments
● Most difficulty, but consistent implementation,
look-and-feel

QOTD
“You’re a Web developer in Java” is the first thing I tell every person
mentioning fragmentation. There are no tablets. There are no
phones. There’s no Google TV. There is only an unlimited set of
configurations of every conceivable feature. Write your application
in a dynamic, progressively enhancing manner that follows well-
documented patterns and you will be just fine.
Jake Wharton


Backwards Compatibility: Strategies and Tactics

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Backwards Compatibility: Strategies and Tactics

Similar to Backwards Compatibility: Strategies and Tactics (20)

More from CommonsWare

More from CommonsWare (20)

Recently uploaded

Recently uploaded (20)

Backwards Compatibility: Strategies and Tactics