Your previous statement that 95% of API calls will work is highly misleading. The bottom line is many API calls are basic OS level stuff that would apply to any version, so of course most of them will be the same. The problem is that the really useful "new" API's aren't supported on older devices in Android. And these are the ones that users will notice, not the umpteen low-level calls to do things like manage memory and data (for example).
You are correct in stating that both iOS and Android have fragmentation. But your attempts to somehow imply they are similar or that Android fragmentation isn't an issue are way off base. iOS is nothing like Android in this regard.
Can you cite some of the new APIs you've used? For example, do you recall an new API implemented in iOS 5 that you chose to use, that perhaps you then replaced with a new one in iOS 6? I'm reviewing the Apple site but can't find a good example.
The point of an SDK is provide a framework that will not change that developers can rely on. If a provider dramatically altered their SDK every release, it would break software that's dependent on it left and right. This is why SDKs and APIs remain mostly the same, with perhaps a 5% deprecation rate over time--they have to be set in stone, because even a minute change will have a ripple effect in the environment of software written to take advantage of it.
iOS is like Android in this regard, and like Windows, OS X, etc. This is how you can update from iOS 5 to iOS 6 and 99.9% of the applications will continue to work as they did previously.
Quote:
Originally Posted by mjtomlin
Sure it does, but why would I bother? The iOS user base moves forward so quickly, there's no reason to support an older version. Why make things difficult for myself when I don't need to?
Do you know how many iOS devices are running version 5.x? >80% and it only took one week to hit >30%
And I know every new device being sold today will have iOS 5.x installed. So if Apple sells 50 million more devices this quarter; potentially 25 million more customers (Apple has stated the new customer ratio is about 50%).
This is where Android's issue of fragmentation comes into play, because not every Android device sold is running the latest OS, so as a developer I'm kinda forced to support multiple versions or just pick the version that's the least common denominator and not worry about any new stuff.
This is part of the problem in understanding fragmentation. Updating iOS devices to support new APIs is great, but if Apple selectively turns other software features off, what are you left with? That "fragmentation" is no different than Android. You end up with iOS 6 devices that are fully-capable, and iOS 6 devices that can only perform a subset of what iOS 6 is capable of, like the 3GS.
Regardless of what platform you develop for, you have to write checks to ensure your platform supports whatever you're going to do. If you're writing an app for iOS, you have to check that it supports what you want to do--what if you want to bring up Siri? You can't do that on a majority of devices, so you have to check. The same is true for Android. The same applies to Windows--I can't make Windows 8-specific calls in Windows 7.
Quote:
Originally Posted by krabbelen
Except that iOS (and Mac OS updates for that matter) are improvements across the board. They do add new features to all devices, speed them up and generally make them more usable. (for example, I have a G4 PowerMac that is about 10 or 11 years old and it runs better than ever on 10.6 Leopard). Therefore, it isn't just a marketing gimmick (and the one or two highlighted features that are restricted to newer hardware are clearly laid out in the keynote or announcement).
Apple computer and devices are very usable for several years, and hold their resale value very well, precisely because they are easily upgradeable to the next two or three major versions of the OS. And there are usually hundreds of improvements, and the code generally gets leaner and faster, with newer implementations and better approaches to many core services and features. There is no doubt that the upgrades extend the life and performance of the older devices; and there is no doubt that this contributes to the high satisfaction rates given by Apple customers.
Of course, a few highlighted features from the keynote are only supported on later hardware. That goes with the territory. You may even call that a type "fragmentation". But for you to equate that with the Fragmentation on the Android platform is highly disingenuous.
For one thing, ALL iPhones and iPads and iPod touches ship with the latest version of iOS. The real nub here is that NEW Android devices are still shipping with version 2.3, etc. Not only that, but no-one -- not Google, not the OEM, not the Carrier -- is giving a definitive answer about what device will ever receive what upgrade and how and when. (Contrast this with simply pressing the upgrade button on your iOS device the day the new version is released, for devices up to about three years old for a guaranteed improvement). For you to blow this off as nothing and try and paint iOS in the same fragmentation mess as Android is laughable. By all accounts, each new release of Android will NEVER have a significant share of Android devices.
I have heard arguments like yours form the Android camp numerous times, and it basically comes down to what you implied: no-one really cares if their Android device is up-to-date with the latest version (or even two versions back) because the api's are the same, and the only real new features anyway have to do with new hardware features so you have to get a new phone anyway (which isn't likely to have the latest version either, but hey). A few of the pro-Android comments on this thread are acting like fragmentation is a "Feature". ...maybe Google really is more like MS than we thought.
So, what is Google doing from version to version? Are there any real improvements, or not? Is it just a case of a couple new, high-profile things that relate to new hardware? Or, is Google simply stuck with developing to the lowest common denominator, just like its developers?
What about the iPhone and the slowdown controversy? Perhaps a precursor to removing certain features on older devices--like Siri and Navigation on 3GS.
In Android's updates, while they do add new features to the each release, it's building off the previous release (which is the same as iOS). 90% of Android is available to 2.3, only slightly less in 2.1. A lot of the differences are under the hood. For example, "Project Butter" has very little to do with the external framework--that is mostly an Android-internal initiative to make improvements to Android that are transparent to developers and users.
To an iOS developer:
Can you adjust your project's build settings to target from iOS 6 to 5? If so, does it build successfully immediately or does it fail? If it fails, how many errors and can you cite three (if there are?) If you do that again and choose iOS 4, what happens in that instance?
It is important to realize that if Apple makes iOS 6 available to an iPhone 3GS but removes most of what makes it "iOS 6", then it's really just a marketing gimmick. In that way, the phone might as well still have iOS 5--and that's basically like an Android device not receiving an update.
Even if the 3GS can't get all the features that are available in iOS 6, it still gets bug fixes, technological enhancements and additions that actually make it worthwhile, and even desirable, to upgrade. Furthermore, I'd rather have a phone that is supported then one that is dumped on me, and then I'm forgotten as a customer, until my renewal is due that is.
iPhone and iPod Touch users have a choice to upgrade if the device is compatible. Android users are at the mercy of the device makers, which 95% of them don't care about your software. They are only interested in you buying another device later. If it happens to have updated software then your in luck. Otherwise your out of luck.
Sorry, but Google is showing how poor their understanding of methodology is.
...
In fact, it undoubtedly overestimates the percentage of ICS users for a number of reasons:
We went over this in another thread back in late May. You're (intentionally?) misrepresenting how the platform version stats are calculated. They're not based on frequency of access or whether or not a user installed an app.
What is your factual basis to claim that many Android phones are used as feature phones? Can you cite a usage study?
Can you adjust your project's build settings to target from iOS 6 to 5? If so, does it build successfully immediately or does it fail? If it fails, how many errors and can you cite three (if there are?) If you do that again and choose iOS 4, what happens in that instance?
Yes, I can, but I don't want to. If I choose target iOS4, than I can't use Storyboard for UI design. But if use separate .xib files for UI in iOS5, you can target to iOS4 without problem.
BTW, I've tried to download Android and Eclipse because I want to know how to program on Android. Really, it's horrible! How come a developer could create beautiful apps with a horrible tools? No wonder most of Android apps has horrible UI.
A platform can't move forward if your user base is holding it back. This is clearly what's happening to Android because the users can't update their devices. Where's the incentive for the developer to support the newest OS when a majority of users are still using 2.3.x ?
Certainly there are limits to what you can do with compatibility libraries and reflection, but it's not accurate to say that developers can't use newer APIs on older devices.
We went over this in another thread back in late May. You're (intentionally?) misrepresenting how the platform version stats are calculated. They're not based on frequency of access or whether or not a user installed an app.
Instead of simply making an assertion, why don't you point out the error in my statement? The fact is that Google says that their numbers are based on GooglePlay access over the past 14 days. I simply pointed out a number of errors in that logic.
What is your factual basis to claim that many Android phones are used as feature phones? Can you cite a usage study?
Do you really need a study to know that some feature phones use Android? If I had said that the number was large or provided a percentage, that would be a factual matter that would need evidence. But since I simply said that it skews the numbers, if even a single feature phone runs Android, my statement is correct.
And, yes, there are feature phones that run Android.
Instead of simply making an assertion, why don't you point out the error in my statement? The fact is that Google says that their numbers are based on GooglePlay access over the past 14 days. I simply pointed out a number of errors in that logic.
I did, repeatedly, in a thread about a month ago. To repeat myself: When a device access the Play Store, it sends a unique ID and its Android version. These are stored by Google. If that device is later reactivated, it's not counted twice. If it's upgraded to a newer version of the OS, only the latest version is counted. The count isn't based on how many times a user access the Store, or if they install an app. It's only based on if they access it all, even once.
Obviously, it won't count devices that don't use the Play Store, but aside from the Kindle Fire, these are few and far between. Unsurprisingly, devices without access to the official Play Store don't sell well. Since we know the Android OS version of the Fire, Google's stats are accurate. There's no deception involved.
Do you really need a study to know that some feature phones use Android? If I had said that the number was large or provided a percentage, that would be a factual matter that would need evidence. But since I simply said that it skews the numbers, if even a single feature phone runs Android, my statement is correct.
And, yes, there are feature phones that run Android.
That's a really tortured argument. You made an assertion, but provided absolutely no basis for it. Honestly, claiming that even a single Android feature will skew the results is absurd, given that there are 400 million activated Android devices. By the way, can you cite specific models of feature phones that use Android? Do you have any data about how prevalent they are? Somehow I don't think so. I think this is just another attempt to smear Google.
The Android situation is more complex than Google wants to admit.
Today I could go online and order a device running Android Jelly Bean. I could also choose a device running Ice Cream Sandwich or Gingerbread or even Froyo. Yes there are still "brand new" phones in your local Best Buy and cell phone provider running Android 2.2.
Remember what kind of message Google is trying to send. Today they're emphasizing users who regularly visit Google Play because that's the group that media companies and app developers care about.
Tomorrow when Google claims a majority of smart phones are shipping with Android remember that number includes millions of people who don't visit Google Play often enough to be counted and people who don't even have a data plan, but have an Android phone because that's what they were convinced to get.
You know, when my dad had a Samsung Android phone from 2009, he didn't know what Android was, and he never installed any new apps in the 2 years that he had it. As far as I know, he didn't know how. And he didn't know what "root" meant. Near the end of his 2-year contract, he ditched it because the touch screen developed a fatal flaw and would not respond to input on one side. He got himself an iPhone 4S. Now, he not only knows what version of iOS he's using, he's downloaded dozens of apps. And I didn't have to teach him any of it. That's the real secret to combating OS fragmentation: make it so dirt simple, even your parents could do it. If you have to be a tech-savvy person to do it, or if you have to wait until your carrier officially releases it, your OS is doomed to fragmentation.
And, yes, there are feature phones that run Android.
Are there feature phones that run Google Android, meaning the Google licensed version required for using the PlayStore (afaik)? I had just assumed that a smartphone would be required to offer Google services, a part of Google Android.
I don't know of any feature phones that run a licensed Android, but that doesn't mean they don't exist. To be fair I've seen mention that some were being considered in the past but I can't actually find them and don't even know that they were Google versions rather than knock-offs anyway. What link do you have to the ones you saw? Still current?
My wife and i, both had Motorola androids for 2 years. The phones worked pretty good for about 6 months. Then they both started glitching, hang ups, apps would open and close on its own, and constant "force close" messages. Finally, by the end of 2-year Verizon contract the phones would call people in my address book on it's own! I thought it was a bad batch of phones, maybe a beta version of phones or something. My brother-in-law bought the new Motorola android less than year ago - same thing is happening to him now. It seems that any kind of "sandwich" google releases tastes like crap.
I was hoping that Google's Android would be a real competition to iPhone thus forcing Apple to create even greater things, but was I wrong. When Steve Jobs presented the very first iPhone, he said that iPhone was 5 years more advanced than any other smart phone. He was wrong - iPhone is more like 25 years more advanced than Android. I have a friend who still uses the very first iPhone. It is very noticeably slower than iPhone 4, but still makes calls, sends messages, takes pictures, and plays music. I'm sure that 20 years from today Android will be the same crap that it is today.
This is part of the problem in understanding fragmentation. Updating iOS devices to support new APIs is great, but if Apple selectively turns other software features off, what are you left with? That "fragmentation" is no different than Android. You end up with iOS 6 devices that are fully-capable, and iOS 6 devices that can only perform a subset of what iOS 6 is capable of, like the 3GS.
Perhaps you're not understanding fragmentation and where it actually makes a difference...
Adding or removing end user features does not fragment a platform. This is what is usually referred to as "product differentiation." Which means using particular features to make a model or device better than another to create a product line. Devices are a medium for platforms, they allow the user the ability to make use of the platform. Different products can have different features, but as long as the platform is the same across the line, there is no real fragmentation. The platform is basically the operating system; iOS. All Apple devices ship with the same version of the operating system-they may not have all the same user features, but the underlying resources, code, and support are the same, thus, the devices are running the exact same platform.
The fact that you are so hell bent in wondering if you're able to target multiple OS versions in iOS proves that you as an Android developer are worried about the problem as it exists on Android. It is a non-issue on iOS. Yes, it is possible to write an app that runs on multiple versions of the OS. Most do, in fact. I think a lot of apps in the AppStore require 4.0 or later.
From a user point of view, there is nothing inherently wrong with a fragmented platform. They buy a device it comes with an OS to do stuff. What all it can do is usually always limited to that particular device. Fragmentation is mostly a problem as far as support is concerned. Apple bragging about user base statistics is to the benefit of the developer, not the end user. However it does ultimately affect the end user as well by allowing them to run apps that make use of some brand new technology a developer might use to make the experience of using his/her app much better.
The key issue with Android is not the fragmented mess it is, but that there's no way for users to help defragment it. They're stuck and as such so are the developers that write apps for them.
Certainly there are limits to what you can do with compatibility libraries and reflection, but it's not accurate to say that developers can't use newer APIs on older devices.
Moving new APIs to support older versions of an operating system is a nice work-around, but you cannot move any kind of architectural change to an older OS. Apple has added things like ARC, GCD, c-blocks, etc., which make writing programs easier and running programs more efficient. These are changes made to the compiler, core foundation and kernel and cannot be passed back.
Can you cite some of the new APIs you've used? For example, do you recall an new API implemented in iOS 5 that you chose to use, that perhaps you then replaced with a new one in iOS 6? I'm reviewing the Apple site but can't find a good example.
The point of an SDK is provide a framework that will not change that developers can rely on. If a provider dramatically altered their SDK every release, it would break software that's dependent on it left and right. This is why SDKs and APIs remain mostly the same, with perhaps a 5% deprecation rate over time--they have to be set in stone, because even a minute change will have a ripple effect in the environment of software written to take advantage of it.
iOS is like Android in this regard, and like Windows, OS X, etc. This is how you can update from iOS 5 to iOS 6 and 99.9% of the applications will continue to work as they did previously.
You can't find them because iOS 6 SDK is not available to the public and it is still under NDA. But I can tell you this. The API changes (new and modified) are 100 pages long. There are hundreds of new API and hundreds of modified API. There are few apps right now that will crash under iOS 5 and most of the issues with them can only be fixed when the developer update their code and build using the new Xcode that will be release when iOS is released. I remember when Apple released iOS 4 my apps used to crash because Apple changes how memory management is handled in UITableView. Apple released iOS 4 GM and started accepting updates a week prior to the final iOS 4 release.
With every major release (iOS x.0) the rate of apps that will not work as they should is higher than you think. Usually more than 40% of my apps will not work or crash when I try to use certain feature. Apple does modify a lot of iOS APIs between major releases.
Yes, I can, but I don't want to. If I choose target iOS4, than I can't use Storyboard for UI design. But if use separate .xib files for UI in iOS5, you can target to iOS4 without problem.
BTW, I've tried to download Android and Eclipse because I want to know how to program on Android. Really, it's horrible! How come a developer could create beautiful apps with a horrible tools? No wonder most of Android apps has horrible UI.
I did the same thing a while back and again few months ago and the experience is still shitty. The whole thing is a nightmare! You spend hours following instructions on multiple websites.
Why should the manufacturer of the cellphone provide a free upgrade?
The main result of that is that the customer will hang on to the old phone instead of paying for a new one. I simply can't see the reason for doing that, unless you are evil and want to lock the customer into a walled garden, where the stupid customer believe he his happy for no other reason than having a system that he believes serves him well.
Why should the manufacturer of the cellphone provide a free upgrade?
The main result of that is that the customer will hang on to the old phone instead of paying for a new one. I simply can't see the reason for doing that, unless you are evil and want to lock the customer into a walled garden, where the stupid customer believe he his happy for no other reason than having a system that he believes serves him well.
<p style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;">Why should the manufacturer of the cellphone provide a free upgrade?</p>
<p style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;padding-top:0px;padding-right:0px;padding-bottom:0px;padding-left:0px;">The main result of that is that the customer will hang on to the old phone instead of paying for a new one. I simply can't see the reason for doing that, unless you are evil and want to lock the customer into a walled garden, where the stupid customer believe he his happy for no other reason than having a system that he believes serves him well.</p>
Huh? Perhaps I'm misunderstanding you because it sounds like you're implying that it's an ethical and kind company that doesn't provide updates for their SW-based products. Is that what you're saying?
Moving new APIs to support older versions of an operating system is a nice work-around, but you cannot move any kind of architectural change to an older OS. Apple has added things like ARC, GCD, c-blocks, etc., which make writing programs easier and running programs more efficient. These are changes made to the compiler, core foundation and kernel and cannot be passed back.
I didn't claim that you could. But there have been several claims in this thread that developers can't use newer APIs on older devices, and that's just not the case. Speaking of compiler improvements, apps packaged for older devices can take advantage of improvements in the Android build tools. Each new rev of the SDK includes more lint checks, which apply to all versions of the OS, and the NDK includes performance improvements, bug fixes, and security improvements regularly as well. Obviously, you're not going to be able to backport something like Renderscript, but quite a bit of the new UI code (fragments, action bars, property animation, gestures), Bluetooth (http://code.google.com/p/backport-android-bluetooth/) and utility APIs (https://github.com/candrews/HttpResponseCache) can be backported.
Having said that, I think we're at at turning point for ICS. Gingerbread has peaked, and started to decline. ICS' growth increases every month. And there's a slate of old LG, HTC, Samsung, and Motorola devices set to get ICS this quarter. It'll work itself out in due time.
Comments
Quote:
Originally Posted by EricTheHalfBee
Shidell, I suggest you go here....
https://developer.apple.com/library/ios/navigation/
Your previous statement that 95% of API calls will work is highly misleading. The bottom line is many API calls are basic OS level stuff that would apply to any version, so of course most of them will be the same. The problem is that the really useful "new" API's aren't supported on older devices in Android. And these are the ones that users will notice, not the umpteen low-level calls to do things like manage memory and data (for example).
You are correct in stating that both iOS and Android have fragmentation. But your attempts to somehow imply they are similar or that Android fragmentation isn't an issue are way off base. iOS is nothing like Android in this regard.
Can you cite some of the new APIs you've used? For example, do you recall an new API implemented in iOS 5 that you chose to use, that perhaps you then replaced with a new one in iOS 6? I'm reviewing the Apple site but can't find a good example.
The point of an SDK is provide a framework that will not change that developers can rely on. If a provider dramatically altered their SDK every release, it would break software that's dependent on it left and right. This is why SDKs and APIs remain mostly the same, with perhaps a 5% deprecation rate over time--they have to be set in stone, because even a minute change will have a ripple effect in the environment of software written to take advantage of it.
iOS is like Android in this regard, and like Windows, OS X, etc. This is how you can update from iOS 5 to iOS 6 and 99.9% of the applications will continue to work as they did previously.
Quote:
Originally Posted by mjtomlin
Sure it does, but why would I bother? The iOS user base moves forward so quickly, there's no reason to support an older version. Why make things difficult for myself when I don't need to?
Do you know how many iOS devices are running version 5.x? >80% and it only took one week to hit >30%
And I know every new device being sold today will have iOS 5.x installed. So if Apple sells 50 million more devices this quarter; potentially 25 million more customers (Apple has stated the new customer ratio is about 50%).
This is where Android's issue of fragmentation comes into play, because not every Android device sold is running the latest OS, so as a developer I'm kinda forced to support multiple versions or just pick the version that's the least common denominator and not worry about any new stuff.
This is part of the problem in understanding fragmentation. Updating iOS devices to support new APIs is great, but if Apple selectively turns other software features off, what are you left with? That "fragmentation" is no different than Android. You end up with iOS 6 devices that are fully-capable, and iOS 6 devices that can only perform a subset of what iOS 6 is capable of, like the 3GS.
Regardless of what platform you develop for, you have to write checks to ensure your platform supports whatever you're going to do. If you're writing an app for iOS, you have to check that it supports what you want to do--what if you want to bring up Siri? You can't do that on a majority of devices, so you have to check. The same is true for Android. The same applies to Windows--I can't make Windows 8-specific calls in Windows 7.
Quote:
Originally Posted by krabbelen
Except that iOS (and Mac OS updates for that matter) are improvements across the board. They do add new features to all devices, speed them up and generally make them more usable. (for example, I have a G4 PowerMac that is about 10 or 11 years old and it runs better than ever on 10.6 Leopard). Therefore, it isn't just a marketing gimmick (and the one or two highlighted features that are restricted to newer hardware are clearly laid out in the keynote or announcement).
Apple computer and devices are very usable for several years, and hold their resale value very well, precisely because they are easily upgradeable to the next two or three major versions of the OS. And there are usually hundreds of improvements, and the code generally gets leaner and faster, with newer implementations and better approaches to many core services and features. There is no doubt that the upgrades extend the life and performance of the older devices; and there is no doubt that this contributes to the high satisfaction rates given by Apple customers.
Of course, a few highlighted features from the keynote are only supported on later hardware. That goes with the territory. You may even call that a type "fragmentation". But for you to equate that with the Fragmentation on the Android platform is highly disingenuous.
For one thing, ALL iPhones and iPads and iPod touches ship with the latest version of iOS. The real nub here is that NEW Android devices are still shipping with version 2.3, etc. Not only that, but no-one -- not Google, not the OEM, not the Carrier -- is giving a definitive answer about what device will ever receive what upgrade and how and when. (Contrast this with simply pressing the upgrade button on your iOS device the day the new version is released, for devices up to about three years old for a guaranteed improvement). For you to blow this off as nothing and try and paint iOS in the same fragmentation mess as Android is laughable. By all accounts, each new release of Android will NEVER have a significant share of Android devices.
I have heard arguments like yours form the Android camp numerous times, and it basically comes down to what you implied: no-one really cares if their Android device is up-to-date with the latest version (or even two versions back) because the api's are the same, and the only real new features anyway have to do with new hardware features so you have to get a new phone anyway (which isn't likely to have the latest version either, but hey). A few of the pro-Android comments on this thread are acting like fragmentation is a "Feature". ...maybe Google really is more like MS than we thought.
So, what is Google doing from version to version? Are there any real improvements, or not? Is it just a case of a couple new, high-profile things that relate to new hardware? Or, is Google simply stuck with developing to the lowest common denominator, just like its developers?
What about the iPhone and the slowdown controversy? Perhaps a precursor to removing certain features on older devices--like Siri and Navigation on 3GS.
In Android's updates, while they do add new features to the each release, it's building off the previous release (which is the same as iOS). 90% of Android is available to 2.3, only slightly less in 2.1. A lot of the differences are under the hood. For example, "Project Butter" has very little to do with the external framework--that is mostly an Android-internal initiative to make improvements to Android that are transparent to developers and users.
To an iOS developer:
Can you adjust your project's build settings to target from iOS 6 to 5? If so, does it build successfully immediately or does it fail? If it fails, how many errors and can you cite three (if there are?) If you do that again and choose iOS 4, what happens in that instance?
Quote:
Originally Posted by Shidell
It is important to realize that if Apple makes iOS 6 available to an iPhone 3GS but removes most of what makes it "iOS 6", then it's really just a marketing gimmick. In that way, the phone might as well still have iOS 5--and that's basically like an Android device not receiving an update.
Even if the 3GS can't get all the features that are available in iOS 6, it still gets bug fixes, technological enhancements and additions that actually make it worthwhile, and even desirable, to upgrade. Furthermore, I'd rather have a phone that is supported then one that is dumped on me, and then I'm forgotten as a customer, until my renewal is due that is.
iPhone and iPod Touch users have a choice to upgrade if the device is compatible. Android users are at the mercy of the device makers, which 95% of them don't care about your software. They are only interested in you buying another device later. If it happens to have updated software then your in luck. Otherwise your out of luck.
Another reason NOT to buy Android.
We went over this in another thread back in late May. You're (intentionally?) misrepresenting how the platform version stats are calculated. They're not based on frequency of access or whether or not a user installed an app.
What is your factual basis to claim that many Android phones are used as feature phones? Can you cite a usage study?
Quote:
Originally Posted by Shidell
To an iOS developer:
Can you adjust your project's build settings to target from iOS 6 to 5? If so, does it build successfully immediately or does it fail? If it fails, how many errors and can you cite three (if there are?) If you do that again and choose iOS 4, what happens in that instance?
Yes, I can, but I don't want to. If I choose target iOS4, than I can't use Storyboard for UI design. But if use separate .xib files for UI in iOS5, you can target to iOS4 without problem.
BTW, I've tried to download Android and Eclipse because I want to know how to program on Android. Really, it's horrible! How come a developer could create beautiful apps with a horrible tools? No wonder most of Android apps has horrible UI.
This is an oversimplification. Android provides support for writing backwards-compatible apps. For starters, there's the Android Support Library, which packages newer APIs into a library that can be bundled with apps: http://developer.android.com/tools/extras/support-library.html. The community has expanded on this with additional libraries, such as ActionBarSherlock (http://actionbarsherlock.com/), NotificationCompat2 (https://github.com/JakeWharton/NotificationCompat2), and NineOldAndroids (https://github.com/JakeWharton/NineOldAndroids). Google provides documentation on writing code that works across versions (http://developer.android.com/training/basics/supporting-devices/platforms.html and http://developer.android.com/training/backward-compatible-ui/index.html).
Certainly there are limits to what you can do with compatibility libraries and reflection, but it's not accurate to say that developers can't use newer APIs on older devices.
Instead of simply making an assertion, why don't you point out the error in my statement? The fact is that Google says that their numbers are based on GooglePlay access over the past 14 days. I simply pointed out a number of errors in that logic.
Do you really need a study to know that some feature phones use Android? If I had said that the number was large or provided a percentage, that would be a factual matter that would need evidence. But since I simply said that it skews the numbers, if even a single feature phone runs Android, my statement is correct.
And, yes, there are feature phones that run Android.
I did, repeatedly, in a thread about a month ago. To repeat myself: When a device access the Play Store, it sends a unique ID and its Android version. These are stored by Google. If that device is later reactivated, it's not counted twice. If it's upgraded to a newer version of the OS, only the latest version is counted. The count isn't based on how many times a user access the Store, or if they install an app. It's only based on if they access it all, even once.
Obviously, it won't count devices that don't use the Play Store, but aside from the Kindle Fire, these are few and far between. Unsurprisingly, devices without access to the official Play Store don't sell well. Since we know the Android OS version of the Fire, Google's stats are accurate. There's no deception involved.
That's a really tortured argument. You made an assertion, but provided absolutely no basis for it. Honestly, claiming that even a single Android feature will skew the results is absurd, given that there are 400 million activated Android devices. By the way, can you cite specific models of feature phones that use Android? Do you have any data about how prevalent they are? Somehow I don't think so. I think this is just another attempt to smear Google.
Quote:
Originally Posted by Bregalad
The Android situation is more complex than Google wants to admit.
Today I could go online and order a device running Android Jelly Bean. I could also choose a device running Ice Cream Sandwich or Gingerbread or even Froyo. Yes there are still "brand new" phones in your local Best Buy and cell phone provider running Android 2.2.
Remember what kind of message Google is trying to send. Today they're emphasizing users who regularly visit Google Play because that's the group that media companies and app developers care about.
Tomorrow when Google claims a majority of smart phones are shipping with Android remember that number includes millions of people who don't visit Google Play often enough to be counted and people who don't even have a data plan, but have an Android phone because that's what they were convinced to get.
You know, when my dad had a Samsung Android phone from 2009, he didn't know what Android was, and he never installed any new apps in the 2 years that he had it. As far as I know, he didn't know how. And he didn't know what "root" meant. Near the end of his 2-year contract, he ditched it because the touch screen developed a fatal flaw and would not respond to input on one side. He got himself an iPhone 4S. Now, he not only knows what version of iOS he's using, he's downloaded dozens of apps. And I didn't have to teach him any of it. That's the real secret to combating OS fragmentation: make it so dirt simple, even your parents could do it. If you have to be a tech-savvy person to do it, or if you have to wait until your carrier officially releases it, your OS is doomed to fragmentation.
Quote:
Originally Posted by jragosta
And, yes, there are feature phones that run Android.
Are there feature phones that run Google Android, meaning the Google licensed version required for using the PlayStore (afaik)? I had just assumed that a smartphone would be required to offer Google services, a part of Google Android.
I don't know of any feature phones that run a licensed Android, but that doesn't mean they don't exist. To be fair I've seen mention that some were being considered in the past but I can't actually find them and don't even know that they were Google versions rather than knock-offs anyway. What link do you have to the ones you saw? Still current?
My wife and i, both had Motorola androids for 2 years. The phones worked pretty good for about 6 months. Then they both started glitching, hang ups, apps would open and close on its own, and constant "force close" messages. Finally, by the end of 2-year Verizon contract the phones would call people in my address book on it's own! I thought it was a bad batch of phones, maybe a beta version of phones or something. My brother-in-law bought the new Motorola android less than year ago - same thing is happening to him now. It seems that any kind of "sandwich" google releases tastes like crap.
I was hoping that Google's Android would be a real competition to iPhone thus forcing Apple to create even greater things, but was I wrong. When Steve Jobs presented the very first iPhone, he said that iPhone was 5 years more advanced than any other smart phone. He was wrong - iPhone is more like 25 years more advanced than Android. I have a friend who still uses the very first iPhone. It is very noticeably slower than iPhone 4, but still makes calls, sends messages, takes pictures, and plays music. I'm sure that 20 years from today Android will be the same crap that it is today.
Quote:
Originally Posted by Shidell
This is part of the problem in understanding fragmentation. Updating iOS devices to support new APIs is great, but if Apple selectively turns other software features off, what are you left with? That "fragmentation" is no different than Android. You end up with iOS 6 devices that are fully-capable, and iOS 6 devices that can only perform a subset of what iOS 6 is capable of, like the 3GS.
Perhaps you're not understanding fragmentation and where it actually makes a difference...
Adding or removing end user features does not fragment a platform. This is what is usually referred to as "product differentiation." Which means using particular features to make a model or device better than another to create a product line. Devices are a medium for platforms, they allow the user the ability to make use of the platform. Different products can have different features, but as long as the platform is the same across the line, there is no real fragmentation. The platform is basically the operating system; iOS. All Apple devices ship with the same version of the operating system-they may not have all the same user features, but the underlying resources, code, and support are the same, thus, the devices are running the exact same platform.
The fact that you are so hell bent in wondering if you're able to target multiple OS versions in iOS proves that you as an Android developer are worried about the problem as it exists on Android. It is a non-issue on iOS. Yes, it is possible to write an app that runs on multiple versions of the OS. Most do, in fact. I think a lot of apps in the AppStore require 4.0 or later.
From a user point of view, there is nothing inherently wrong with a fragmented platform. They buy a device it comes with an OS to do stuff. What all it can do is usually always limited to that particular device. Fragmentation is mostly a problem as far as support is concerned. Apple bragging about user base statistics is to the benefit of the developer, not the end user. However it does ultimately affect the end user as well by allowing them to run apps that make use of some brand new technology a developer might use to make the experience of using his/her app much better.
The key issue with Android is not the fragmented mess it is, but that there's no way for users to help defragment it. They're stuck and as such so are the developers that write apps for them.
Quote:
Originally Posted by derekmorr
This is an oversimplification. Android provides support for writing backwards-compatible apps. For starters, there's the Android Support Library, which packages newer APIs into a library that can be bundled with apps: http://developer.android.com/tools/extras/support-library.html. The community has expanded on this with additional libraries, such as ActionBarSherlock (http://actionbarsherlock.com/), NotificationCompat2 (https://github.com/JakeWharton/NotificationCompat2), and NineOldAndroids (https://github.com/JakeWharton/NineOldAndroids). Google provides documentation on writing code that works across versions (http://developer.android.com/training/basics/supporting-devices/platforms.html and http://developer.android.com/training/backward-compatible-ui/index.html).
Certainly there are limits to what you can do with compatibility libraries and reflection, but it's not accurate to say that developers can't use newer APIs on older devices.
Moving new APIs to support older versions of an operating system is a nice work-around, but you cannot move any kind of architectural change to an older OS. Apple has added things like ARC, GCD, c-blocks, etc., which make writing programs easier and running programs more efficient. These are changes made to the compiler, core foundation and kernel and cannot be passed back.
Quote:
Originally Posted by Shidell
Can you cite some of the new APIs you've used? For example, do you recall an new API implemented in iOS 5 that you chose to use, that perhaps you then replaced with a new one in iOS 6? I'm reviewing the Apple site but can't find a good example.
The point of an SDK is provide a framework that will not change that developers can rely on. If a provider dramatically altered their SDK every release, it would break software that's dependent on it left and right. This is why SDKs and APIs remain mostly the same, with perhaps a 5% deprecation rate over time--they have to be set in stone, because even a minute change will have a ripple effect in the environment of software written to take advantage of it.
iOS is like Android in this regard, and like Windows, OS X, etc. This is how you can update from iOS 5 to iOS 6 and 99.9% of the applications will continue to work as they did previously.
You can't find them because iOS 6 SDK is not available to the public and it is still under NDA. But I can tell you this. The API changes (new and modified) are 100 pages long. There are hundreds of new API and hundreds of modified API. There are few apps right now that will crash under iOS 5 and most of the issues with them can only be fixed when the developer update their code and build using the new Xcode that will be release when iOS is released. I remember when Apple released iOS 4 my apps used to crash because Apple changes how memory management is handled in UITableView. Apple released iOS 4 GM and started accepting updates a week prior to the final iOS 4 release.
With every major release (iOS x.0) the rate of apps that will not work as they should is higher than you think. Usually more than 40% of my apps will not work or crash when I try to use certain feature. Apple does modify a lot of iOS APIs between major releases.
As I recall, and confirmed via Forbes ( http://www.forbes.com/sites/darcytravlos/2012/06/12/the-importance-of-apples-wwdc-keynote-address/ ), Apple announced that over 80% of the 365M iOS devices are running iOS 5.
From that article "Again, leading into the iOS6 discussion were these facts: 365M iOS devices have been sold and 80% of these have upgraded to iOS 5."
Quote:
Originally Posted by fuwafuwa
Yes, I can, but I don't want to. If I choose target iOS4, than I can't use Storyboard for UI design. But if use separate .xib files for UI in iOS5, you can target to iOS4 without problem.
BTW, I've tried to download Android and Eclipse because I want to know how to program on Android. Really, it's horrible! How come a developer could create beautiful apps with a horrible tools? No wonder most of Android apps has horrible UI.
I did the same thing a while back and again few months ago and the experience is still shitty. The whole thing is a nightmare! You spend hours following instructions on multiple websites.
Why should the manufacturer of the cellphone provide a free upgrade?
The main result of that is that the customer will hang on to the old phone instead of paying for a new one. I simply can't see the reason for doing that, unless you are evil and want to lock the customer into a walled garden, where the stupid customer believe he his happy for no other reason than having a system that he believes serves him well.
Why should the manufacturer of the cellphone provide a free upgrade?
The main result of that is that the customer will hang on to the old phone instead of paying for a new one. I simply can't see the reason for doing that, unless you are evil and want to lock the customer into a walled garden, where the stupid customer believe he his happy for no other reason than having a system that he believes serves him well.
Huh? Perhaps I'm misunderstanding you because it sounds like you're implying that it's an ethical and kind company that doesn't provide updates for their SW-based products. Is that what you're saying?
I didn't claim that you could. But there have been several claims in this thread that developers can't use newer APIs on older devices, and that's just not the case. Speaking of compiler improvements, apps packaged for older devices can take advantage of improvements in the Android build tools. Each new rev of the SDK includes more lint checks, which apply to all versions of the OS, and the NDK includes performance improvements, bug fixes, and security improvements regularly as well. Obviously, you're not going to be able to backport something like Renderscript, but quite a bit of the new UI code (fragments, action bars, property animation, gestures), Bluetooth (http://code.google.com/p/backport-android-bluetooth/) and utility APIs (https://github.com/candrews/HttpResponseCache) can be backported.
Having said that, I think we're at at turning point for ICS. Gingerbread has peaked, and started to decline. ICS' growth increases every month. And there's a slate of old LG, HTC, Samsung, and Motorola devices set to get ICS this quarter. It'll work itself out in due time.