First.. let me ask for those of you that have apps in the market.. if I have a 1.5 version out there.. it shows up on any device that is 1.5 or later, right? Now..if I update it to run on 2.0.. will the update be made available or even notify 1.5/1.6 users? Or does it only show up for 2.0 and later users in their market?
As someone else said, one of the appeals of Android, and no doubt one of the biggest reasons every carrier and manufacturer has jumped on board is the ability to customize it. For example, the new Sony phone coming out... it has a really nice custom in-house notification manager that no other phone has. It's that capability that is going to bring a lot of vendors and carrier to Android. Also keep in mind.. competition. If every android device looks/operates exactly the same.. then the only difference really is hardware and name brand recognition. A driving force behind all these companies supporting Android and building to it is to distinguish themselves from others. They want people to buy their phones because the Sense UI is "better" or "easier" than others. Android allows them to do this, and quite easily for the most part compared to say building on Palm's or other OSs out there. So without a doubt you're going to see different UIs and us developers may face UI issues trying to have apps integrate within those custom UIs. HOWEVER, I stand firm when I say.. if your app does NOT work on a given devices customized UI, its the fault of the customizer, not your app. They should absolutely be held to the same standards we are when it comes to developing on Android. If they make custom capabilities that do not work on other devices, what's the point of even using them? Honestly if Sony's custom scrolling notification system is accessible to us Android developers, then really it's only of use to build custom apps specific to that phone. It doesn't benefit Sony to make such a custom modification in hopes that us one-offs will build something from it that only runs on the Sony phone. Most likely they will do in-house stuff with it and offer custom apps for their phone only. I think this is possible, because Verizon has a tab on my moto droid, which I assume is only verizon and/or moto droid apps. So I would imagine Sony could provide a tab on the market specific to their phone, and place apps under it that will only show up for those using that phone. I am not for sure on this tho. Lastly, while I agree it will be a pain for us developers to maintain multiple versions.. keep in mind that updates generally aren't more than a couple a year and as Mark and others said, most things work on newer updates. So unless you get issues with your app for specific API changes, you shouldn't have to worry too much about future updates. Even if you do, I don't see this being much different than most jobs I've had, where we have older versions of software that we still support, fix bugs in, and continue on with newer versions. As for display size changes. as far as I knew, if you built your app to the SDK.. your displays would resize properly in most cases. Not sure about video games, but at least most text based apps with the right layouts should work on any screen size. What are some examples of different screen sizes causing problems? I am curious for my own knowledge to be prepared as I haven't seen that issue brought up much. On Sun, Jan 17, 2010 at 11:40 AM, Daniel <[email protected]> wrote: > The fragmentation problem is mainly with the newest APIs, and > applications taking advantage of them. > > Official, or supported APIs barely change, and if they do, the older > API is backward compatible. > Take for instance the contacts API before 2.0 (Contacts.People), and > the newest (ContactsContract) that supports multiple contacts sources > (multiple google accounts syncing contacts). Using the Contacts.People > API on newer versions (2.0+) still works, its just limited to display > the contacts from the main account but it works, it doesn't break. > > However, when it comes to newer APIs, like lets say Text-to-Speech > (introduced in 1.6), and Dock support (introduced in 2.0), it's a pain > in the butt to make the apps backward compatible with "older" or > outdated devices, and take advantage of those APIs in "newer" or > updated devices, yes, there are ways to introduce these new features, > but its very painful to keep those users that are on older versions of > android happy, without errors and such. > > As of now it is an issue, not that big of an issue but it's there, and > it can just become worse. Keeping track of 3-4 versions is not that > big of a deal, but manufacturers need to move, because I would shoot > myself if I had to keep supporting 5-6 versions of android (1.5, 1.6, > 2.0, 2.1, 2.5?, 2.7?, 3.0?)... that my friends, will be extremely > painful for MOST developers out there. > > -- > 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]<android-developers%[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
