Backwards Compatibility: Strategies and Tactics

1,753 views
1,566 views

Published on

From the AnDevCon III conference

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,753
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
35
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Backwards Compatibility: Strategies and Tactics

  1. 1. AnDevCon III Backwards Compatibility: Strategies and TacticsCopyright © 2012 CommonsWare, LLC
  2. 2. Device Mix image Copyright © 2012 Google, Inc. – reprinted with permissionCopyright © 2012 CommonsWare, LLC
  3. 3. Device Mix ● The Market Is Not the World ● Kindle Fire ● NOOK Tablet ● Wearables (WIMM, Im Watch, etc.) ● Miscellaneous non-Market devices ● If You Distribute to These, Take Their Versions Into Account!Copyright © 2012 CommonsWare, LLC
  4. 4. 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ökCopyright © 2012 CommonsWare, LLC
  5. 5. 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 devicesCopyright © 2012 CommonsWare, LLC
  6. 6. Forwards, Not Backwards ● Older Aint 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 youCopyright © 2012 CommonsWare, LLC
  7. 7. 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 ● Its the Way the (Web) World Works ● IE6-only versus graceful degradation ● Well-trod path, needing Android-specific tacticsCopyright © 2012 CommonsWare, LLC
  8. 8. 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 versionCopyright © 2012 CommonsWare, LLC
  9. 9. 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)Copyright © 2012 CommonsWare, LLC
  10. 10. Validating Compatibility ● Testing ● Directly via emulator ● Directly via available hardware ● Bulk-testing Services – TestDroid Cloud – LessPainful – Apkudo – Etc.Copyright © 2012 CommonsWare, LLC
  11. 11. 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 ImplementationsCopyright © 2012 CommonsWare, LLC
  12. 12. 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.xCopyright © 2012 CommonsWare, LLC
  13. 13. 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 methodsCopyright © 2012 CommonsWare, LLC
  14. 14. 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-testCopyright © 2012 CommonsWare, LLC
  15. 15. 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 }Copyright © 2012 CommonsWare, LLC
  16. 16. 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+ }Copyright © 2012 CommonsWare, LLC
  17. 17. 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 blockCopyright © 2012 CommonsWare, LLC
  18. 18. 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 blockCopyright © 2012 CommonsWare, LLC
  19. 19. 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 referenceCopyright © 2012 CommonsWare, LLC
  20. 20. 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.HoloCopyright © 2012 CommonsWare, LLC
  21. 21. 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 anywhereCopyright © 2012 CommonsWare, LLC
  22. 22. 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 canCopyright © 2012 CommonsWare, LLC
  23. 23. 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-feelCopyright © 2012 CommonsWare, LLC
  24. 24. 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 WhartonCopyright © 2012 CommonsWare, LLC

×