I don't understand what you mean in this case, the only difference is a slight shift in the positioning of the antenna and the use of CDMA chipset instead of GSM chipset. The rest of the hardware is the same, the OS is the same and the apps run exactly the same way as they have on the ATT iPhone 4. How is the VZN iPhone 4 "very different"?
but if this was two different HTC phones for verizon and AT&T where the only difference was the radio it would be fragmentation?
and they all use ARM based CPU's with wifi or GSM for network hardware and the same few resolutions. it's not like Windows NT/2000 had separate versions for x86/MIPS/DEC Alpha and i forgot what else.
the biggest PITA seems to be the manufacturer "optimization"
and i tend to read the release notes for my app updates and i always see stuff like fixing bugs for iOS 3 devices or an app would crash on iphone 4 or 3G or 3GS
You are over simplifying. There are different ARM CPUs in use with different amounts of ram and different graphics capabilities.
We actually do test against everything, no shortcuts. Just because somethings share the same components does not mean they are the same, unless they have the exact same specs.
You may think it's easy but it is not. A Motorola Droid running one version of Android and another with a different version is considered 2 devices. The GSM version of the Droid (Milestone) is again a different device and needs to be tested running on all supported versions of Android. That is basically 1 device that needs to be tested 4 times. We also have different interfaces, virtual keypad, virtual keyboard, a real keyboard, a real keypad, touch interface, physical mouse or touchpad etc
but if this was two different HTC phones for verizon and AT&T where the only difference was the radio it would be fragmentation?
It's different because the nature of the networks is different. GSM supports concurrent data, voice and messaging and Verizon does not. The way the apps switch etc is handled differently.
Ideally it should be write once deploy to many. But when fragmentation occurs you are writing once to deploy to one.
exactly how do they keep claiming Android has more US market share? THe answer, they exclude almost half of iOS devices sold because they can't compete with them,
That graph is showing WEB HITS to sites using stat counter where the user got to that website by using a search engine. It does not cover native apps, history hits (typing an address in nav bar and then clicking completed address from your history), bookmarks, or news readers (RSS). Furthermore, it has NOTHING to do with the percentage of people who actually have devices, and has practically NO bearing on how the app market for either platform is doing. A few months ago, there was a report that said android users were more likely to click on web based ads than iOS users (this was before Android was larger volume wise). Did this have any bearing on app profitability? Not really.
"87% find it a problem" The other 13% are the Fandroids who regularly harass us here.
IF you don't want android users to post here, AI should stop posting SEO Bait anti-android posts with limited connection (at best) to "Apple news and analysis"
when the IBM PC came out, other companies tried to sell computers that also ran DOS. However, they didn't really start selling until someone managed to make one 100% IBM-PC compatible so developers (including the OS developers) could target a single reference standard.
Google apparently didn't learn anything from this. Manufactures were encouraged to customize the OS for their specific devices, which means those devices can't be upgraded unless/until they repeat that same work.
How many Android phones were released before they release a reference standard with the failed Nexus One? How many phones today are even compatible with Nexus One? I suspect few since so few Android phones are on v2.3.x.
How is Google supposed to develop an OS release for all of the phones if there is no reference standard to target? What do developers even target? Do they need to have every Android phone ever released running every version of the OS that given phone supports?
I'm not going to argue if fragmentation is an issue or not. It clearly is (at least for a nice chunk of developers) But this "Survey" is idiotic, and as presented, shouldn't be listened to.
First, where is their methodology? WHat I mean is this:
-How did they select the developers they were interviewing? Was it opt in? Random? Did they choose top developers for both platforms? What was their answer rate compared to the number of developers they invited to take this survey? NONE of this information is openly available in this article, or in the CNN article everyone is quoting.
-What did the final spread of developers look like? How many exclusively developed for Android/iOS, how many were big in both (eg, ROVIO), and how many were exclusive devs looking to branch out?
-What apps were they developing? Developers who work at creating "Native" apps (using the NDK) will have HARDWARE fragmentation issues more than software. So even if all devices were currently ON gingerbread they would still have severe Fragmentation issues. Did Baird take this into account?
-How many developers called a country currently not open to paid apps with Android home? Again, this is a wholly different version of Fragmentation from OS versions while still being software related. Since they mentioned fragmented app stores, I'm guessing this number is rather high as amazon's app store JUST launched and has next to no real presence yet.
Furthermore, where is the information about comparing this data? Are we honestly going to trump a research study that gives us a SINGLE question? Seriously? Where is the AI that dismisses any "pro android" stats because of poor methodology? You don't even KNOW the methodology here and you're treating it as gospel. Now I'm sure if you contact Baird you can get a full copy of the report (most likely for several hundred dollars) Did you? Heck, did ANYONE? The CNN piece was obviously written off of a press release.
And let's look at the question they actually gave us the breakdown for: It has 5 possible answers of which 4 are variations of "Yes, Fragmentation is a problem" Statistically, most respondents would answer in the affirmative because if fragmentation affected you AT ALL, you would answer yes. Even if the fragmentation issue had NOTHING to do with OS versions, or if you thought it was a problem, but one you were willing to code around (like lack of Multitasking/backgrounding was for iOS for the longest time)
Again, I'm not debating that Fragmentation isn't an issue, or even that most developers don't feel this way. I'm sure that they do. What I'm saying is that before sites just blindly post this kind of "research" they figure out how it was gathered and verify it. AI is quick to dismiss any research that is "anti apple" because of poor methodology, so they obviously have ways of finding this information. Why not use it ALL the time instead of republishing bad information as long as it suites you? (for the record, I think ALL sites should do this, and I've said as much on other websites)
This isn't a fan site. It's a site that tries to bill itself as a source of news and analysis. The first step to both of those things is valid information.
You are over simplifying. There are different ARM CPUs in use with different amounts of ram and different graphics capabilities.
We actually do test against everything, no shortcuts. Just because somethings share the same components does not mean they are the same, unless they have the exact same specs.
You may think it's easy but it is not. A Motorola Droid running one version of Android and another with a different version is considered 2 devices. The GSM version of the Droid (Milestone) is again a different device and needs to be tested running on all supported versions of Android. That is basically 1 device that needs to be tested 4 times. We also have different interfaces, virtual keypad, virtual keyboard, a real keyboard, a real keypad, touch interface, physical mouse or touchpad etc
the interface thing i kind of agree but even most keyboard phones have touch these days
for the different speeds of the CPU/GPU this has been handled by the PC game devs long ago. look at the installed base and figure out which percentage you want to support. then write your app for the slowest hardware of your percentage. for the really good devs they do optimizations to support the latest and greatest GPU's. like Epic did with the newest version of Infinity Blade
maybe apple virtualizes the hardware better in it's software but most apps i see still support the iphone 3G and that generation ipod touch. these had no GPU. so devs are writing code for really old devices and then extra code if they want to give eye candy to the 3GS and iphone 4 level phones
when the IBM PC came out, other companies tried to sell computers that also ran DOS. However, they didn't really start selling until someone managed to make one 100% IBM-PC compatible so developers (including the OS developers) could target a single reference standard.
Google apparently didn't learn anything from this. Manufactures were encouraged to customize the OS for their specific devices, which means those devices can't be upgraded unless/until they repeat that same work.
How many Android phones were released before they release a reference standard with the failed Nexus One? How many phones today are even compatible with Nexus One? I suspect few since so few Android phones are on v2.3.x.
How is Google supposed to develop an OS release for all of the phones if there is no reference standard to target? What do developers even target? Do they need to have every Android phone ever released running every version of the OS that given phone supports?
moot point since there is an 18 month cycle for upgrades. my Inspire 4G cost me $20 with Froyo on it. even if i don't get android 2.3 i don't care since by the time there are apps that need it i will be eligible for an upgrade.
before i got the ipad 2 i thought about just getting the first one since it will be 2 years before apps come out for it in force
it's not like the 1990's when computers cost $3000 and you had to buy a fast machine so it would last you many years and that you could upgrade it during that time
when the IBM PC came out, other companies tried to sell computers that also ran DOS. However, they didn't really start selling until someone managed to make one 100% IBM-PC compatible so developers (including the OS developers) could target a single reference standard.
Google apparently didn't learn anything from this. Manufactures were encouraged to customize the OS for their specific devices, which means those devices can't be upgraded unless/until they repeat that same work.
How many Android phones were released before they release a reference standard with the failed Nexus One? How many phones today are even compatible with Nexus One? I suspect few since so few Android phones are on v2.3.x.
How is Google supposed to develop an OS release for all of the phones if there is no reference standard to target? What do developers even target? Do they need to have every Android phone ever released running every version of the OS that given phone supports?
Actually they don't. A majority (well over 90%) of apps can be coded to run exclusively off of the Dalvik Virtual machine. This machine is consistent across devices and is NOT dependent on individual hardware configurations. IF an app is coded to work within the Dalvik framework it should work on all handsets unless it uses an API from a version of Android that device does not have. (the biggest hurdle was developing modern apps that also worked with 1.5, and now that 1.5 is practically gone it can safely be ignored). The SDK allows for an app to optimize itself based on the available hardware specs (resolution, DPI, etc) and all the developer needs to do is make sure those files are available for the app, they DON'T need to code the app specifically for every device.
This is like an Apple developer making an app that can Multitask (os4.0+) but has a version that doesn't multitask for devices that can't handle it. Such as my ipod touch. from 1.6-3.0 this can be done, and a lot of developers configure it properly. Unlike what Steve jobs might say, MOST applications work fine across multiple devices and OS levels because they were programmed using the SDK.
The problem comes when developers try making NATIVE applications (using the NDK) which means they are bypassing the Dalvik VM to access the phone's hardware directly. The primary benefit of doing this is if you want to make high end graphic games. Most games can use the SDK, but for complex rendering, the NDK provides a superior framework (at least until Honeycomb/whatever I is) The big issue is that everyone is trying to develop with the NDK, using fixed resolutions for their app, even if the app doesn't require it. (for example, a simple scroller does NOT need to use the NDK, but a lot of them try, because it's what they're used to with iOS)
As for reference devices, a majority of the phones out there right now are at least at the level of the NexusOne/S when it comes to hardware. Some of them far surpass it. The reason so few devices have 2.3 isn't because the hardware can't support it, it's for other reasons (carrier intervention, Manufacturer laziness, etc).
iOS 4 was released a month after Android 2.2 and has been adopted by a much higher percent of iOS users than Android 2.2.
Andriod 2.3 was released well before iOS 4.3, yet iOS 4.3 is used by a much higher percentage if iOS users.
And the other chart shows that iOS still dominated the mobile market when so many people want to make you believe Android dominates. Because it includes the iPod touch and breaks out the iPad.
iOS 4 was released a month after Android 2.2 and has been adopted by a much higher percent of iOS users than Android 2.2.
Andriod 2.3 was released well before iOS 4.3, yet iOS 4.3 is used by a much higher percentage if iOS users.
And the other chart shows that iOS still dominated the mobile market when so many people want to make you believe Android dominates. Because it includes the iPod touch and breaks out the iPad.
You're comparing a broad OS (4.0) to a specific one (2.2). How many of those 4.x iOS devices are running the fully enabled version of iOS 4.3.1 and not an "older" version of os 4.0 that has significant pruning in API permissions to get it to run on older hardware?
My ipod touch has ios4, but it doesn't have folders, it doesn't have wallpapers, it doesn't have multitasking. So an app developer who wants to use multitasking will have to develop a SEPARATE way for my device to handle the app (different API level) this is like 2.1 to 2.3.
Apple "cheats" these numbers by calling all variations of 4.0 the same. Even though an app will require DIFFERENT programming for dealing with my ipod touch compared to the latest one (disregarding the camera and higher res screen) they're both considered 4.x devices.
A valid comparison to 4.x is 2.x as far as API levels and development go. And as you can see, the numbers are VERY comparable.
As for the other graph, that is MOBILE WEB IMPRESSIONS. And there are countless Stats that show Android ahead. It just depends which service you use. It has NOTHING to do with the number of actual devices out there.
On 26 October 2009, the 2.0 (Eclair) SDK was released.
The 2.1 SDK was released on 12 January 2010.
On 20 May 2010, the 2.2 (Froyo) SDK was released (now at version 2.2.2)
On 6 December 2010, the 2.3 (Gingerbread) SDK was released (now at version 2.3.3)
It's now April of 2011. Are you suggesting that 18 months of Android releases should be considered the same version?
And are you suggesting that Apple somehow makes it harder on developers to bring their latest OS to old devices while scaling the features to what the hardware can support? From a programmers perspective I believe the only real difference is multitasking support. All of the new frameworks are there.
And the "countless" stats that show Android aheadalways exclude both the iPod touch and the iPad. I've yet to see anything that suggests Android is ahead (or even close) when those are included.
yet on MS Windows different resolutions have been standard for years and years and apps have magically adjusted and looked as good. except with LCD's where the monitor has one native resolution. but buying a better LCD will not make your apps look like crap
why are iOS and android having such issues with this?did MS patent it back in the day and no one can do it?
I hear this argument all the time, but it doesn't make sense:
First of all it simply isn't true: try scaling some Windows applications from 320x240 up to 2500x1600 and find out that many can't scale that far down (at least not without becoming unusable) and many others will simply look like crap when you make them very large, because they fill up huge amounts of their windows with unused spacing or hideously ugly oversized controls, have popups or tool windows that don't scale with the main window, etc. The scaling on desktop apps works reasonably well above a certain threshold resolution of about 1024x768 and upwards. Below that resolution you're going to have a really hard time using your computer comfortably, and there is no such thing as automatic scaling that magically optimizes the UI and layout across arbitrary resolutions.
Second, the UI paradigm used on the desktop is completely incomparable to a smartphone or tablet. Desktop user interfaces can use multiple windows, popups, hierarchical menu's, floating tool windows, and all kind of other tricks to cram more content and functionality in the same space. Many of these require a pixel-precise input mechanism to be usable, controlling a typical Windows application with touch input is a disaster, try tapping through a 3-level menu or a minuscule toolbar with your finger some time (e.g. using VNC or X-Windows on an ipad) and you'll find out. Add to that that smartphone/tablet applications are almost exclusively modal, ie: a single window occupies the whole screen, and there is no way to split up an application over multiple windows easily.
Last but not least there is a big difference between scaling up an application, and having it make good use of the screen. You can take MS Paint from Windows 3.11 and scale it up to fill a 2500x1600 screen, but it will not make the application better or easier to use. In fact, it will probably be almost unusable because the raster elements in the UI don't scale at all.
So referring to desktop applications to make a point about phone or tablet applications, it simply doesn't make sense.
You're comparing a broad OS (4.0) to a specific one (2.2). How many of those 4.x iOS devices are running the fully enabled version of iOS 4.3.1 and not an "older" version of os 4.0 that has significant pruning in API permissions to get it to run on older hardware?
My ipod touch has ios4, but it doesn't have folders, it doesn't have wallpapers, it doesn't have multitasking. So an app developer who wants to use multitasking will have to develop a SEPARATE way for my device to handle the app (different API level) this is like 2.1 to 2.3.
Folders and wallpapers are irrelevant for development. Implementing a non-multitasking fallback for 4.x devices without multitasking support is rather trivial, as you'll need the non-multitasking parts for the multitasking version anyway (freezing state, suspend/resume). It's really a matter of hours rather than days.
Of course there are differences in what software and hardware features are supported on various devices but between 4.x releases they are very small and specific. Think gyroscope, game center, multitasking and optional retina display support.
Quote:
Originally Posted by Menno
Apple "cheats" these numbers by calling all variations of 4.0 the same. Even though an app will require DIFFERENT programming for dealing with my ipod touch compared to the latest one (disregarding the camera and higher res screen) they're both considered 4.x devices.
A valid comparison to 4.x is 2.x as far as API levels and development go. And as you can see, the numbers are VERY comparable.
I disagree. There is no cheating, and the required effort to support the complete range of 4.x devices is trivial. In most cases (the ones that don't use any specific features such as the gyroscope or multitasking) the effort is zero. In all other cases we're talking about 10, maybe 20 lines of code to check and disable unsupported features. Even when you start including 3.x devices the effort is minimal. I'm currently writing a game that was developed on a 3GS running the latest 4.x version all the time, making it work on 3.x on 3G-generation devices literally took 2 extra functions, 10 lines total, and an hour of profiling to find performance bottlenecks and tuning down some aspects of the game to make it smooth enough.
All in all I think you have a wrong impression of iOS backwards and forwards compatibility. iOS versions with the same major version are extremely similar, differences are easy to work around, and you'd have to write something extremely specific to run into major compatibility or performance issues that cannot easily be tested with just 2 devices (e.g. a 3G or 1st gen iPod Touch + an iPhone 4 will currently cover about every iPod, iPhone and OS version you'll find 'in the wild')
On 26 October 2009, the 2.0 (Eclair) SDK was released.
The 2.1 SDK was released on 12 January 2010.
On 20 May 2010, the 2.2 (Froyo) SDK was released (now at version 2.2.2)
On 6 December 2010, the 2.3 (Gingerbread) SDK was released (now at version 2.3.3)
It's now April of 2011. Are you suggesting that 18 months of Android releases should be considered the same version?
And are you suggesting that Apple somehow makes it harder on developers to bring their latest OS to old devices while scaling the features to what the hardware can support? From a programmers perspective I believe the only real difference is multitasking support. All of the new frameworks are there.
And the "countless" stats that show Android aheadalways exclude both the iPod touch and the iPad. I've yet to see anything that suggests Android is ahead (or even close) when those are included.
As far as functional API goes, yes, those 18 months are essentially the same version (2.0 and 2.1 are both even considered eclair)
We're talking for DEVELOPING purposes here, and in that there is very little a developer needs to do to push an app to be compatible between 2.1-2.3, or even 1.6-2.3
Again, the ONLY serious issues come when you're talking 1.5 devices OR if the developer is trying to use the NDK.
As far as functional API goes, yes, those 18 months are essentially the same version (2.0 and 2.1 are both even considered eclair)
We're talking for DEVELOPING purposes here, and in that there is very little a developer needs to do to push an app to be compatible between 2.1-2.3, or even 1.6-2.3
Again, the ONLY serious issues come when you're talking 1.5 devices OR if the developer is trying to use the NDK.
if you're porting an app or reusing existing code, you either use NDK so you can use your C/C++ code or you have to rewrite all of your code in Java, right? I just ported a major C++ app that is a cross platform Mac/Windows app to the iPad (using objective-C++), it took less than 2 weeks to get all of that code up and running.
Comments
I don't understand what you mean in this case, the only difference is a slight shift in the positioning of the antenna and the use of CDMA chipset instead of GSM chipset. The rest of the hardware is the same, the OS is the same and the apps run exactly the same way as they have on the ATT iPhone 4. How is the VZN iPhone 4 "very different"?
but if this was two different HTC phones for verizon and AT&T where the only difference was the radio it would be fragmentation?
and they all use ARM based CPU's with wifi or GSM for network hardware and the same few resolutions. it's not like Windows NT/2000 had separate versions for x86/MIPS/DEC Alpha and i forgot what else.
the biggest PITA seems to be the manufacturer "optimization"
and i tend to read the release notes for my app updates and i always see stuff like fixing bugs for iOS 3 devices or an app would crash on iphone 4 or 3G or 3GS
You are over simplifying. There are different ARM CPUs in use with different amounts of ram and different graphics capabilities.
We actually do test against everything, no shortcuts. Just because somethings share the same components does not mean they are the same, unless they have the exact same specs.
You may think it's easy but it is not. A Motorola Droid running one version of Android and another with a different version is considered 2 devices. The GSM version of the Droid (Milestone) is again a different device and needs to be tested running on all supported versions of Android. That is basically 1 device that needs to be tested 4 times. We also have different interfaces, virtual keypad, virtual keyboard, a real keyboard, a real keypad, touch interface, physical mouse or touchpad etc
but if this was two different HTC phones for verizon and AT&T where the only difference was the radio it would be fragmentation?
It's different because the nature of the networks is different. GSM supports concurrent data, voice and messaging and Verizon does not. The way the apps switch etc is handled differently.
Ideally it should be write once deploy to many. But when fragmentation occurs you are writing once to deploy to one.
android developers need to stop looking at fake market numbers and look at the real numbers
http://gs.statcounter.com/#mobile_os...-201101-201103
exactly how do they keep claiming Android has more US market share? THe answer, they exclude almost half of iOS devices sold because they can't compete with them,
That graph is showing WEB HITS to sites using stat counter where the user got to that website by using a search engine. It does not cover native apps, history hits (typing an address in nav bar and then clicking completed address from your history), bookmarks, or news readers (RSS). Furthermore, it has NOTHING to do with the percentage of people who actually have devices, and has practically NO bearing on how the app market for either platform is doing. A few months ago, there was a report that said android users were more likely to click on web based ads than iOS users (this was before Android was larger volume wise). Did this have any bearing on app profitability? Not really.
"87% find it a problem" The other 13% are the Fandroids who regularly harass us here.
IF you don't want android users to post here, AI should stop posting SEO Bait anti-android posts with limited connection (at best) to "Apple news and analysis"
Google apparently didn't learn anything from this. Manufactures were encouraged to customize the OS for their specific devices, which means those devices can't be upgraded unless/until they repeat that same work.
How many Android phones were released before they release a reference standard with the failed Nexus One? How many phones today are even compatible with Nexus One? I suspect few since so few Android phones are on v2.3.x.
How is Google supposed to develop an OS release for all of the phones if there is no reference standard to target? What do developers even target? Do they need to have every Android phone ever released running every version of the OS that given phone supports?
First, where is their methodology? WHat I mean is this:
-How did they select the developers they were interviewing? Was it opt in? Random? Did they choose top developers for both platforms? What was their answer rate compared to the number of developers they invited to take this survey? NONE of this information is openly available in this article, or in the CNN article everyone is quoting.
-What did the final spread of developers look like? How many exclusively developed for Android/iOS, how many were big in both (eg, ROVIO), and how many were exclusive devs looking to branch out?
-What apps were they developing? Developers who work at creating "Native" apps (using the NDK) will have HARDWARE fragmentation issues more than software. So even if all devices were currently ON gingerbread they would still have severe Fragmentation issues. Did Baird take this into account?
-How many developers called a country currently not open to paid apps with Android home? Again, this is a wholly different version of Fragmentation from OS versions while still being software related. Since they mentioned fragmented app stores, I'm guessing this number is rather high as amazon's app store JUST launched and has next to no real presence yet.
Furthermore, where is the information about comparing this data? Are we honestly going to trump a research study that gives us a SINGLE question? Seriously? Where is the AI that dismisses any "pro android" stats because of poor methodology? You don't even KNOW the methodology here and you're treating it as gospel. Now I'm sure if you contact Baird you can get a full copy of the report (most likely for several hundred dollars) Did you? Heck, did ANYONE? The CNN piece was obviously written off of a press release.
And let's look at the question they actually gave us the breakdown for: It has 5 possible answers of which 4 are variations of "Yes, Fragmentation is a problem" Statistically, most respondents would answer in the affirmative because if fragmentation affected you AT ALL, you would answer yes. Even if the fragmentation issue had NOTHING to do with OS versions, or if you thought it was a problem, but one you were willing to code around (like lack of Multitasking/backgrounding was for iOS for the longest time)
Again, I'm not debating that Fragmentation isn't an issue, or even that most developers don't feel this way. I'm sure that they do. What I'm saying is that before sites just blindly post this kind of "research" they figure out how it was gathered and verify it. AI is quick to dismiss any research that is "anti apple" because of poor methodology, so they obviously have ways of finding this information. Why not use it ALL the time instead of republishing bad information as long as it suites you? (for the record, I think ALL sites should do this, and I've said as much on other websites)
This isn't a fan site. It's a site that tries to bill itself as a source of news and analysis. The first step to both of those things is valid information.
You are over simplifying. There are different ARM CPUs in use with different amounts of ram and different graphics capabilities.
We actually do test against everything, no shortcuts. Just because somethings share the same components does not mean they are the same, unless they have the exact same specs.
You may think it's easy but it is not. A Motorola Droid running one version of Android and another with a different version is considered 2 devices. The GSM version of the Droid (Milestone) is again a different device and needs to be tested running on all supported versions of Android. That is basically 1 device that needs to be tested 4 times. We also have different interfaces, virtual keypad, virtual keyboard, a real keyboard, a real keypad, touch interface, physical mouse or touchpad etc
the interface thing i kind of agree but even most keyboard phones have touch these days
for the different speeds of the CPU/GPU this has been handled by the PC game devs long ago. look at the installed base and figure out which percentage you want to support. then write your app for the slowest hardware of your percentage. for the really good devs they do optimizations to support the latest and greatest GPU's. like Epic did with the newest version of Infinity Blade
maybe apple virtualizes the hardware better in it's software but most apps i see still support the iphone 3G and that generation ipod touch. these had no GPU. so devs are writing code for really old devices and then extra code if they want to give eye candy to the 3GS and iphone 4 level phones
and
when the IBM PC came out, other companies tried to sell computers that also ran DOS. However, they didn't really start selling until someone managed to make one 100% IBM-PC compatible so developers (including the OS developers) could target a single reference standard.
Google apparently didn't learn anything from this. Manufactures were encouraged to customize the OS for their specific devices, which means those devices can't be upgraded unless/until they repeat that same work.
How many Android phones were released before they release a reference standard with the failed Nexus One? How many phones today are even compatible with Nexus One? I suspect few since so few Android phones are on v2.3.x.
How is Google supposed to develop an OS release for all of the phones if there is no reference standard to target? What do developers even target? Do they need to have every Android phone ever released running every version of the OS that given phone supports?
moot point since there is an 18 month cycle for upgrades. my Inspire 4G cost me $20 with Froyo on it. even if i don't get android 2.3 i don't care since by the time there are apps that need it i will be eligible for an upgrade.
before i got the ipad 2 i thought about just getting the first one since it will be 2 years before apps come out for it in force
it's not like the 1990's when computers cost $3000 and you had to buy a fast machine so it would last you many years and that you could upgrade it during that time
when the IBM PC came out, other companies tried to sell computers that also ran DOS. However, they didn't really start selling until someone managed to make one 100% IBM-PC compatible so developers (including the OS developers) could target a single reference standard.
Google apparently didn't learn anything from this. Manufactures were encouraged to customize the OS for their specific devices, which means those devices can't be upgraded unless/until they repeat that same work.
How many Android phones were released before they release a reference standard with the failed Nexus One? How many phones today are even compatible with Nexus One? I suspect few since so few Android phones are on v2.3.x.
How is Google supposed to develop an OS release for all of the phones if there is no reference standard to target? What do developers even target? Do they need to have every Android phone ever released running every version of the OS that given phone supports?
Actually they don't. A majority (well over 90%) of apps can be coded to run exclusively off of the Dalvik Virtual machine. This machine is consistent across devices and is NOT dependent on individual hardware configurations. IF an app is coded to work within the Dalvik framework it should work on all handsets unless it uses an API from a version of Android that device does not have. (the biggest hurdle was developing modern apps that also worked with 1.5, and now that 1.5 is practically gone it can safely be ignored). The SDK allows for an app to optimize itself based on the available hardware specs (resolution, DPI, etc) and all the developer needs to do is make sure those files are available for the app, they DON'T need to code the app specifically for every device.
This is like an Apple developer making an app that can Multitask (os4.0+) but has a version that doesn't multitask for devices that can't handle it. Such as my ipod touch. from 1.6-3.0 this can be done, and a lot of developers configure it properly. Unlike what Steve jobs might say, MOST applications work fine across multiple devices and OS levels because they were programmed using the SDK.
The problem comes when developers try making NATIVE applications (using the NDK) which means they are bypassing the Dalvik VM to access the phone's hardware directly. The primary benefit of doing this is if you want to make high end graphic games. Most games can use the SDK, but for complex rendering, the NDK provides a superior framework (at least until Honeycomb/whatever I is) The big issue is that everyone is trying to develop with the NDK, using fixed resolutions for their app, even if the app doesn't require it. (for example, a simple scroller does NOT need to use the NDK, but a lot of them try, because it's what they're used to with iOS)
As for reference devices, a majority of the phones out there right now are at least at the level of the NexusOne/S when it comes to hardware. Some of them far surpass it. The reason so few devices have 2.3 isn't because the hardware can't support it, it's for other reasons (carrier intervention, Manufacturer laziness, etc).
a couple of interesting charts
and
How are these interesting? The first shows web traffic (so no OS breakdown).
And the second shows a breakdown based on large number.
By using that one, Androids breakdown is the following: (Using Market numbers)
1.x=6.2%
2.x=92.88%
3.x=.2%
EDIT: Forgot to post the source: http://developer.android.com/resourc...-versions.html
How are these interesting? The first shows web traffic (so no OS breakdown).
And the second shows a breakdown based on large number.
By using that one, Androids breakdown is the following: (Using Market numbers)
1.x=6.2%
2.x=92.88%
3.x=.2%
EDIT: Forgot to post the source: http://developer.android.com/resourc...-versions.html
iOS 4 was released a month after Android 2.2 and has been adopted by a much higher percent of iOS users than Android 2.2.
Andriod 2.3 was released well before iOS 4.3, yet iOS 4.3 is used by a much higher percentage if iOS users.
And the other chart shows that iOS still dominated the mobile market when so many people want to make you believe Android dominates. Because it includes the iPod touch and breaks out the iPad.
iOS 4 was released a month after Android 2.2 and has been adopted by a much higher percent of iOS users than Android 2.2.
Andriod 2.3 was released well before iOS 4.3, yet iOS 4.3 is used by a much higher percentage if iOS users.
And the other chart shows that iOS still dominated the mobile market when so many people want to make you believe Android dominates. Because it includes the iPod touch and breaks out the iPad.
You're comparing a broad OS (4.0) to a specific one (2.2). How many of those 4.x iOS devices are running the fully enabled version of iOS 4.3.1 and not an "older" version of os 4.0 that has significant pruning in API permissions to get it to run on older hardware?
My ipod touch has ios4, but it doesn't have folders, it doesn't have wallpapers, it doesn't have multitasking. So an app developer who wants to use multitasking will have to develop a SEPARATE way for my device to handle the app (different API level) this is like 2.1 to 2.3.
Apple "cheats" these numbers by calling all variations of 4.0 the same. Even though an app will require DIFFERENT programming for dealing with my ipod touch compared to the latest one (disregarding the camera and higher res screen) they're both considered 4.x devices.
A valid comparison to 4.x is 2.x as far as API levels and development go. And as you can see, the numbers are VERY comparable.
As for the other graph, that is MOBILE WEB IMPRESSIONS. And there are countless Stats that show Android ahead. It just depends which service you use. It has NOTHING to do with the number of actual devices out there.
The 2.1 SDK was released on 12 January 2010.
On 20 May 2010, the 2.2 (Froyo) SDK was released (now at version 2.2.2)
On 6 December 2010, the 2.3 (Gingerbread) SDK was released (now at version 2.3.3)
It's now April of 2011. Are you suggesting that 18 months of Android releases should be considered the same version?
And are you suggesting that Apple somehow makes it harder on developers to bring their latest OS to old devices while scaling the features to what the hardware can support? From a programmers perspective I believe the only real difference is multitasking support. All of the new frameworks are there.
And the "countless" stats that show Android aheadalways exclude both the iPod touch and the iPad. I've yet to see anything that suggests Android is ahead (or even close) when those are included.
yet on MS Windows different resolutions have been standard for years and years and apps have magically adjusted and looked as good. except with LCD's where the monitor has one native resolution. but buying a better LCD will not make your apps look like crap
why are iOS and android having such issues with this?did MS patent it back in the day and no one can do it?
I hear this argument all the time, but it doesn't make sense:
First of all it simply isn't true: try scaling some Windows applications from 320x240 up to 2500x1600 and find out that many can't scale that far down (at least not without becoming unusable) and many others will simply look like crap when you make them very large, because they fill up huge amounts of their windows with unused spacing or hideously ugly oversized controls, have popups or tool windows that don't scale with the main window, etc. The scaling on desktop apps works reasonably well above a certain threshold resolution of about 1024x768 and upwards. Below that resolution you're going to have a really hard time using your computer comfortably, and there is no such thing as automatic scaling that magically optimizes the UI and layout across arbitrary resolutions.
Second, the UI paradigm used on the desktop is completely incomparable to a smartphone or tablet. Desktop user interfaces can use multiple windows, popups, hierarchical menu's, floating tool windows, and all kind of other tricks to cram more content and functionality in the same space. Many of these require a pixel-precise input mechanism to be usable, controlling a typical Windows application with touch input is a disaster, try tapping through a 3-level menu or a minuscule toolbar with your finger some time (e.g. using VNC or X-Windows on an ipad) and you'll find out. Add to that that smartphone/tablet applications are almost exclusively modal, ie: a single window occupies the whole screen, and there is no way to split up an application over multiple windows easily.
Last but not least there is a big difference between scaling up an application, and having it make good use of the screen. You can take MS Paint from Windows 3.11 and scale it up to fill a 2500x1600 screen, but it will not make the application better or easier to use. In fact, it will probably be almost unusable because the raster elements in the UI don't scale at all.
So referring to desktop applications to make a point about phone or tablet applications, it simply doesn't make sense.
You're comparing a broad OS (4.0) to a specific one (2.2). How many of those 4.x iOS devices are running the fully enabled version of iOS 4.3.1 and not an "older" version of os 4.0 that has significant pruning in API permissions to get it to run on older hardware?
My ipod touch has ios4, but it doesn't have folders, it doesn't have wallpapers, it doesn't have multitasking. So an app developer who wants to use multitasking will have to develop a SEPARATE way for my device to handle the app (different API level) this is like 2.1 to 2.3.
Folders and wallpapers are irrelevant for development. Implementing a non-multitasking fallback for 4.x devices without multitasking support is rather trivial, as you'll need the non-multitasking parts for the multitasking version anyway (freezing state, suspend/resume). It's really a matter of hours rather than days.
Of course there are differences in what software and hardware features are supported on various devices but between 4.x releases they are very small and specific. Think gyroscope, game center, multitasking and optional retina display support.
Apple "cheats" these numbers by calling all variations of 4.0 the same. Even though an app will require DIFFERENT programming for dealing with my ipod touch compared to the latest one (disregarding the camera and higher res screen) they're both considered 4.x devices.
A valid comparison to 4.x is 2.x as far as API levels and development go. And as you can see, the numbers are VERY comparable.
I disagree. There is no cheating, and the required effort to support the complete range of 4.x devices is trivial. In most cases (the ones that don't use any specific features such as the gyroscope or multitasking) the effort is zero. In all other cases we're talking about 10, maybe 20 lines of code to check and disable unsupported features. Even when you start including 3.x devices the effort is minimal. I'm currently writing a game that was developed on a 3GS running the latest 4.x version all the time, making it work on 3.x on 3G-generation devices literally took 2 extra functions, 10 lines total, and an hour of profiling to find performance bottlenecks and tuning down some aspects of the game to make it smooth enough.
All in all I think you have a wrong impression of iOS backwards and forwards compatibility. iOS versions with the same major version are extremely similar, differences are easy to work around, and you'd have to write something extremely specific to run into major compatibility or performance issues that cannot easily be tested with just 2 devices (e.g. a 3G or 1st gen iPod Touch + an iPhone 4 will currently cover about every iPod, iPhone and OS version you'll find 'in the wild')
On 26 October 2009, the 2.0 (Eclair) SDK was released.
The 2.1 SDK was released on 12 January 2010.
On 20 May 2010, the 2.2 (Froyo) SDK was released (now at version 2.2.2)
On 6 December 2010, the 2.3 (Gingerbread) SDK was released (now at version 2.3.3)
It's now April of 2011. Are you suggesting that 18 months of Android releases should be considered the same version?
And are you suggesting that Apple somehow makes it harder on developers to bring their latest OS to old devices while scaling the features to what the hardware can support? From a programmers perspective I believe the only real difference is multitasking support. All of the new frameworks are there.
And the "countless" stats that show Android aheadalways exclude both the iPod touch and the iPad. I've yet to see anything that suggests Android is ahead (or even close) when those are included.
As far as functional API goes, yes, those 18 months are essentially the same version (2.0 and 2.1 are both even considered eclair)
We're talking for DEVELOPING purposes here, and in that there is very little a developer needs to do to push an app to be compatible between 2.1-2.3, or even 1.6-2.3
Again, the ONLY serious issues come when you're talking 1.5 devices OR if the developer is trying to use the NDK.
As far as functional API goes, yes, those 18 months are essentially the same version (2.0 and 2.1 are both even considered eclair)
We're talking for DEVELOPING purposes here, and in that there is very little a developer needs to do to push an app to be compatible between 2.1-2.3, or even 1.6-2.3
Again, the ONLY serious issues come when you're talking 1.5 devices OR if the developer is trying to use the NDK.
if you're porting an app or reusing existing code, you either use NDK so you can use your C/C++ code or you have to rewrite all of your code in Java, right? I just ported a major C++ app that is a cross platform Mac/Windows app to the iPad (using objective-C++), it took less than 2 weeks to get all of that code up and running.