> This is exactly my point. Why shouldn't a 1.6 user be able to use the > application but just not have access to the voice commands (unless of > course they are the raison d'etre)? If I have application 'x' I'm > forced to release two versions - or in fact 'n' versions, one for each > OS profile - and rely on the user to purchase the right one. > > As an app developer I'd want to produce one version of my app that was > able to make use of all the latest features but then fall back to the > smaller footprint API profile on a phone running (say) 1.6 - and late > binding is the key to this. I can't resolve calls to 2.1 features that > are not present in earlier versions of Android, so I'd write defensive > code that disabled 2.1 dependent features when running on a 1.6 phone. > As a developer I'd also be able to present a clear message to my user > as to which features are/are not available on their phone. > > We have, and will continue to have, different phones at different OS > levels, so I see this as a key point in economical app development. > There is also a degree of anecdotal evidence supporting the claim that > forwards compatibility isn't perfect either.
You have a point and I'm not fluent enough in the Android world to fully answer that. I can only guess this declarative approach is preferred so that you won't have to litter your code with feature tests, like you would in i.e. vanilla javascript. > No, I agree that this is not an inherent problem with Android. However > the features I describe above are critical for Android to offer an > economical development model. Otherwise developers will have two big > problems: > - Additional support overhead caused by people trying to run an > application designed for version x+1 on a version x phone. > - People posting poor reviews/ratings of applications that were > designed for a later version of Android than they have on their phone. Of course what people do now is to just provide different builds of the same application, using minSdkVersion and maxSdkVersion. The x+1 problem manifests itself when this latter attribute is left out. If this had been specified, the user wouldn't even get to see the application in the marked in the first place. Not a problem unique to Android btw., I've had several NetBeans plugins break upon a new version of the IDE. Versioning is a hard problem! > These are ecosystem problems that are being seen today, but the > correct approach by Google can mitigate this. We could also do with > manufacturers releasing device profiles for the SDK, this would also > allow a degree of platform testing to be conducted in an economical > fashion. One must assume Google is aware of this. I'd be interested in the response if you directed them to Android engineers at [http:// groups.google.com/group/android-developers]. /Casper
-- You received this message because you are subscribed to the Google Groups "The Java Posse" 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/javaposse?hl=en.
