2

I'm currently developing an app (minimum SDK 14) using many of the new APIs. Looking at some Google statistics made me think things over - about 35% of devices still run Android versions less than 4 (2.3 Gingerbread in most cases). Since I don't want to lose customers, I started to think about adding android 4- support, but I'd need to completely re-work the app for that.

So I thought about creating an extra version, fully optimized for SDK 9-10, whilst the other will be fully optimized for android 4.0 and above. Since I have minSDK and maxSDK options available in the Manifest, I can ensure that any user will only see the appropriate version on the Play Store. What do you think about such approach, any disadvantages (except for investing more time) that I didn't see?

Droidman
  • 11,485
  • 17
  • 93
  • 141

2 Answers2

5

When the user upgrades their version of Android, how do they know to look for a new version of your app?

It's possible to adapt at runtime to the android version on the device. 

switch(Build.VERSION.SDK_INT)
{
   case Build.VERSION_CODES.HONEYCOMB: 
...
}

And you can use Android Version as one of the criteria for selecting resources.

res/layout-v12
  ...

Also you may need to annotate some methods to avoid compiler warnings/errors:

@TargetApi(Build.VERSION_CODES.FROYO)

In my opinion using these techniques is easier and more reliable than supporting separate source trees.

Dale Wilson
  • 9,166
  • 3
  • 34
  • 52
  • But, this would still require revamping the whole project. And why is this `more reliable [that] supporting separate source trees`? – Vikram Aug 16 '13 at 16:29
  • Suppose you had some functionality in common (if you don't you really have two different applications, not one version of the same app) When you make a change in App_For_Gingerbread, you also have to remember to make exactly the same change in App_For_Honeycomb. It is a maintenance nightmare. – Dale Wilson Aug 16 '13 at 16:31
  • The alternative is to refactor the common code into a library, but you are back to "revamping the entire project" – Dale Wilson Aug 16 '13 at 16:32
  • 1
    And what do you do when the NEXT release of android comes out and has more new features you want to use. Does that mean yet another version of your application? You'll drive yourself and your users batty trying to keep up. – Dale Wilson Aug 16 '13 at 16:33
  • This is an excellent approach. Might also be the only one if you want to keep your sanity. I guess you meant to use `efficient` in place of `reliable`. – Vikram Aug 16 '13 at 16:39
  • Actually I meant reliable having often had to fix copy/paste/tweak code that developed bugs when one pasted copy was fixed but the other was not. But efficient (from the point of view of developer time) certainly applies, too. – Dale Wilson Aug 16 '13 at 16:42
  • my app is pretty RAM-intensive since I have custom ListViews and a lot of database queries.. about 25-30MB of RAM at runtime. Usually android 4- devices do not have strong hardware, implementing all that support stuff would even increase RAM consumption..? – Droidman Aug 16 '13 at 18:17
4

Do not create two seperate apps. Create one app which supports multiple OS versions. Using the Android Support Library and ActionBarSherlock allows you to support Android 2.3 without too much difficulty.

Most developers, including Google, support Android 2.3 this way in their apps.

Brian Attwell
  • 9,239
  • 2
  • 31
  • 26
  • what about the license with ActionBarSherlock? I'm developing a free and a paid version (unlocks via in-app-billing) of the app, am I allowed to use that in the paid version? – Droidman Aug 16 '13 at 18:01
  • 1
    ActionBarSherlock has an Apache license. You may use it in for-profit apps as long as you acknowledge the author Jake Wharton. – Dale Wilson Aug 16 '13 at 20:36