Thanks Rob but what I'm thinking about goes beyond an alternative UI. At the moment my app supports 1.5+ and has reached a very good level of stability. The sort of changes I have in mind for a Honeycomb version would probably be combined with a complete rewrite.
If I do a complete rewrite then it really doesn't make sense to support anything below 2.1 (since the current percentage of devices in that bracket is very small, and will only get smaller). Therefore, in an ideal world (!), I would like the 1.5/1.6 users to use the existing, well-tested version and the other users will get the newer stuff. I think we're going to see a need for this more and more as we progress through SDK levels. For a given app, the dev will gradually increase the min SDK level because it's just not worth all the extra testing involved. >From the 1.5/1.6 user perspective, he will see less and less apps in the Android Market. In fact, the only apps he will see are ones that were abandoned completely by the dev. The good apps (still being maintained) will not be available at all because of this inability to specify multiple APKs. This is particularly problematic for paid apps. If you increase the min SDK level and then a lower SDK user reflashes his device, he will no longer be able to install your app. He won't even see it on the Market. That will then lead to support emails along with the cumbersome directions on how to install a legacy APK manually. The biggest problem however, is that the current single-APK approach is significantly affecting dev up-take of Honeycomb features. Certainly in my case, and probably many others. On 3 March 2011 14:39, Rob <[email protected]> wrote: > having one apk to rule them all is a tricky thing to manage. i just > recently launched with normal, large, and xlarge layouts along with > landscape for large and xlarge. it is not easy, it takes a ton of > regression testing, but is totally worth it. > > there are some people that are developing seperate apps for tablet. i > wouldn't recommend it, personally. maybe if you pull out all business > logic and throw it in a library it may be easier but there would be a > ton of redundant work. abstract out the work of building out the > views, and that will allow you to manage each resolution re-using the > same techniques. > > > one tip is to have a very easily accessible flag that allows you to > differentiate which device you're running on. > > //check to see if we have a tablet, large or phone, and then set the > global flag > int screenLayout = > getResources().getConfiguration().screenLayout; > model.isTablet = ((screenLayout & > Configuration.SCREENLAYOUT_SIZE_MASK) == > Configuration.SCREENLAYOUT_SIZE_XLARGE); > > //if isTablet is false, check to see if we have a Large > device, else > we have a phone > if(model.isTablet == false){ > model.isLarge = ((screenLayout & > Configuration.SCREENLAYOUT_SIZE_MASK) == > Configuration.SCREENLAYOUT_SIZE_LARGE); > if(model.isLarge){ > model.deviceSize = "Large"; > }else{ > model.deviceSize = "Phone"; > } > }else{ > model.deviceSize = "Tablet"; > model.isLarge = false; > } > > throw in a isLandscape if that matters as well. > > public boolean isLandscape(Context context) { > int orientation = > context.getResources().getConfiguration().orientation; > return (orientation == Configuration.ORIENTATION_LANDSCAPE); > } > > by using these flags on simple singleton model, you can easily build > out the appropriate view for any scenario....except for small. just > add a new flag for that ;) > > -rob > > On Mar 2, 11:51 pm, Mark Carter <[email protected]> wrote: > > One of the main reasons I have not started any Honeycomb-specific > > development is because of the extra complexity it would bring to my > existing > > codebase. > > > > If it were possible to upload multiple APKs (targeting different SDK > level > > ranges) for the same app, I would be much more likely to take advantage > of > > features of the latest SDK releases. > > > > I know it's possible to do all this using various approaches like > reflection > > but I don't want to risk introducing bugs to those running on older > levels. > > Also why should "old" users receive all the updates that are just fixing > > Honeycomb-issues? > > > > If I could develop a Honeycomb (and later) APK (and upload that alongside > > the existing APK) then that would solve these problems. > > > > BTW, for me, having a completely separate app for Honeycomb, is not an > > option. > > > > Is this something that has been discussed much before? Is it ever likely > to > > happen? > > -- > 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
