On Mon, Jan 18, 2010 at 11:58 AM, JP <[email protected]> wrote:
> > http://android-developers.blogspot.com/2009/04/backward-compatibility... > This means having to cut off users on older Android releases, no? > Um. No? The entire article is about how to use newer APIs while remaining compatible with older platforms. Am I missing something? > Kevin illustrates the problem nicely. > What is that exactly? I see him talking about incompatible manufacturer customizations and how fixing those are the responsibility of the manufacturer (true), about newer platform versions being compatible with older ones and maintaining support for older ones not being a big deal, and concern about minSdkVersion not filtering app from older platforms which should definitely not be true. I'd just like to understand what the specific concern is. > It is different in that XP through Windows 7 have been released over > the course of, what, eight years now? True, we have gone through a number of releases in the last year. Of course windows has also gone through lots of service packs etc. But regardless, in both cases basically one release builds on another, so you are looking at targeting release X through Y and whatever number of intermediate steps there are between is not that much of an issue (though you will certainly want to be testing against intermediate release to verify there are no surprises). > Users are much more educated and > experienced in what to expect. At work, I, like many users > (hopefully), "just" pick up the phone or send an email, and the > problem will be taken care of. > On a mobile device however... it just kindof ought to work, which > isn't an unreasonable expectation. Being facetious with the backwards > logic, the level of support that Google set aside to support the > release of the N1 seems to confirm that idea. > Sorry I am really not following this part. :} Yes, you should be able to just pick up a phone and use it, and for the most part that is the case (as long as developers properly mark their minSdkVersion to not be visible on older platforms, and the occasional manufacturer-specific bug here and there). I don't know how much support you think Google set aside for the N1 (was it large or small? support for what?) so I am pretty lost there. > As far as OS X goes, during a couple of years of transition, Apple > supported "fat" binaries just like they did when they switched > OpenSTEP from Motorola to Intel a decade earlier. There's experience > with that, and in the mobile environment, this is all new stuff and > needs to be managed accordingly, IMHO. > Sure and when 1.6 came out to introduce new screen support, it also included a lot of compatibility design and code to ensure that existing applications would work on the new screens. (Or when not possible, such as QVGA screens, require that applications be explicitly updated and marked as compatible with them before allowing them to be available to users of those devices). What's different here? > I want to add, no question of course, it would be unjust to criticize > anybody that an expectation wasn't set that Android would be subjected > to a degree of fragmentation when Android was first released > "wayback". Yet, here we are, and it would be disappointing to see the > issue glossed over. > I'm not sure how things are being glossed over...? -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them.
-- 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
