Meh, When Apple went 2X mode on iPhone apps, people complained it looked too ugly and waited for Devs to make universal apps (which automatically go to High Res iPad version).
@juanvaldez He does raise a valid point. How am I, as a developer, going to write an Android applications that looks good on 4", 5", 7", 8" and 10" screen sizes? The answer: I'm not, because it would be a nightmare. Which is why I write iPhone OS applications. Fragmentation really isn't helping Android.
@drange I'm going to ask a few questions, most from a very uninformed vantage point.
Firstly, isn't the resolution what you would care about most as the developer? So, even if these did have different sizes, its the resolution you are trying to develop for. If that's correct, then your main concern would be, 'do these have standard resolutions'. If they do, it's somewhat easier (e.g. the 7" actually matching the Dell Streak's resolution)? If the 10"matched the resolution of the 9.7" iPad, while there would be tons of code to re-write, you'd have a very good idea of how it'd look, right?
Can you tell me how this is a different case than the PC. Is it market size? There are so many more resolutions and screen sizes to deal with, so does Windows and/or the drivers make that more manageable for developers? Or is it just the costs/benefits pay off more?
Still, like I'm saying, choice is normally good. While I don't think this would triple sales, developers would obviously be better off having triple sales even if it meant triple the sizes they have to deal with (just taking the current example in isolation.)
Really, I understand the problems in general of developing for Android, especially when compared to the iPhone and in the future compared to WP7. But, I'm under the impression that new devices, as long as they are not creating new niches aren't doing as much damage as some people would lead others to believe. And judging from the growth of the App store and compatibility of the apps, many developers are doing a good job at accommodating for consumers wishes to have their choice (here I understand the depth of development going into apps hasn't reached as deep as the app store and that coding for the app store can be a more custom rather than least-common-denominator product).
@juanvaldez >> Firstly, isn't the resolution what you would care about most as the developer? So, even if these did have different sizes, its the resolution you are trying to develop for.
You're right, resolution influences the UI design more than screen size, though the latter can also have quite some impact on usability, for example when buttons get too small to hit consistently on smaller screen sizes.
>> Can you tell me how this is a different case than the PC. Is it market size? There are so many more resolutions and screen sizes to deal with, so does Windows and/or the drivers make that more manageable for developers?
On PC's the UI toolkits are completely geared towards multiple, resizable windows, scrolling areas and accurate pointing devices, as well as large screen resolutions. IE: you can stuff much more in a window, and the stuff you put in it can be much smaller. Also, you can use multiple overlapping windows, and the screen aspect ratio is normally constant (no rotation). So size constraints are much less an issue. Which is why most desktop applications aren't size constraint at all, in fact, applications that don't allow resizing are typically preceived as very annying. Anyway, try imagining a Windows or OS X desktop with 320x240, 320x480 or 800x480, without a mouse, and you'll probably have to agree that it would be pretty difficult to write complex applications fthat work well using the normal desktop UI toolkits.
>> Still, like I'm saying, choice is normally good. While I don't think this would triple sales, developers would obviously be better off having triple sales even if it meant triple the sizes they have to deal with (just taking the current example in isolation.)
Choice isn't always and only a good thing, it also has downsides. If I target Android, I have to either write for the lowes common denominator, or pick a range of more-or-less comparable devices and target only these. Note that this isn't only about screen size, but also about CPU and GPU capabilities. Especially with games, it quickly becomes a nightmare if you have to cover devices with both OpenGL ES1 and ES2. With screens ranging from 0.0768 to almost 1 megapixel resolution. With 500Mhz to 1Ghz CPU's. Of course bigger development studio's can have different people working on different versions for different devices, but for me, as a lone developer who develops for mobile as a hobby, next to a day job, I'd rather pick a uniform platform over a fragmented one with a similar userbase. If many developers do the same, it leads to less applications and lower average quality, which is exactly what the Android Market shows.
>> But, I'm under the impression that new devices, as long as they are not creating new niches aren't doing as much damage as some people would lead others to believe.
Well it all depends on the application itself of course, and the device differences. For many applications, resolution and screen size are large irrelevant, particularly for the simpler ones that don't have many controls. But as you add layers of UI complexity, the differences get much more annoying. Of course you can work around everything, try to be resolution-independent where possible, but like I said: it's all a tradeoff between implementation effort and possible revenue that every developer needs to make. Would you rather develop for 3 million iPads sold and put all your effort into optimizing it for that hardware, or for 10 million Android tablets ranging from Android 1.5 to 2.2, screen sizes from 5" to 10", CPU's ranging from 500Mhz to 1 Ghz, with the very probable risk it will influence the quality and features of your application?
@drange Thanks again. I will focus on one thing you say and relate it to a point you made earlier:
"Would you rather develop for 3 million iPads sold and put all your effort into optimizing it for that hardware, or for 10 million Android tablets ranging from Android 1.5 to 2.2, screen sizes from 5" to 10", CPU's ranging from 500Mhz to 1 Ghz, with the very probable risk it will influence the quality and features of your application?"
I think, and again, I'm not in the development community. There are good reasons to go after both. First, lets use your numbers (though you are definitely being more generous than you should be, hehe). If there are 3x the # of Android tablets as Apple then it first would be dependent on what kind of developer you are. Again, I'll use you as an example. You're alone and you have to maximize your results from your limited time. If Android tablets are more prevalent, selling faster than the iPad *AND* there are less developers developing for the Android tablets then you can actually try to limit your consumer supported devices by more than 50% while focusing on the more future-proof consumer devices, besides those owners show that they have a larger propensity to consume, while having less competition in the marketplace relative to the iPhone.
@juanvaldez Well, I have to be completely honest and admit that I don't actually have any experience developing for Android. But I can tell you that I've been in the position to either go for iPhone OS or Android, and I decided to go for the first, specfically with platform uniformity in mind. My impression is that I can deliver a higher quality application that is guaranteed to work on a larger installed base than I could guarantee on Android. I only need one (or in my case 2) devices to test on, I know the exact hardware capabilities, and I know that the platform will be supported and updated in the future, on the hardware I'm targetting right now.
Maybe I'm different from other developers, but I like the idea of having some form of control over what devices and OS versions my application will be deployed to. It allows me to focus on maxing out the capabilities of the hardware and software, and I believe it will allow better support and updates in the future.
With iPhone, Jobs chooses for you. With Android, the market will choose. Android is just now gearing up. In a year or so, standards will shape up. Things like the original Droid (with its unusual screen ratio) will disappear. Also, people buying the older model phones won't be buying apps.
And the company that gets out updates to the latest version of Android in a shorter time will attract more sales.
By the way, doesn't the new iPhone have a different resolution than all the older iPhones? Doesn't that mean that as an iPhone developer you have to support two different screen sizes?
The Rip is the latest addition to the Boogie eWriter line, devices that let you scribble notes and drawings and can be wiped away with the press of a button.
The most commented posts on Engadget over the past 24 hours.
Now that we've thrown 'em off the trail, use the form below to get in touch with the people at Engadget. Please fill in all of the required fields because they're required.
Meh, When Apple went 2X mode on iPhone apps, people complained it looked too ugly and waited for Devs to make universal apps (which automatically go to High Res iPad version).
Three different screen sizes? Lunacy.
@Wesscoast You don't like choice? Poor guy.
I say this highly doubting I'll buy this.
@juanvaldez
He does raise a valid point. How am I, as a developer, going to write an Android applications that looks good on 4", 5", 7", 8" and 10" screen sizes? The answer: I'm not, because it would be a nightmare. Which is why I write iPhone OS applications. Fragmentation really isn't helping Android.
@drange I'm going to ask a few questions, most from a very uninformed vantage point.
Firstly, isn't the resolution what you would care about most as the developer? So, even if these did have different sizes, its the resolution you are trying to develop for. If that's correct, then your main concern would be, 'do these have standard resolutions'. If they do, it's somewhat easier (e.g. the 7" actually matching the Dell Streak's resolution)? If the 10"matched the resolution of the 9.7" iPad, while there would be tons of code to re-write, you'd have a very good idea of how it'd look, right?
Can you tell me how this is a different case than the PC. Is it market size? There are so many more resolutions and screen sizes to deal with, so does Windows and/or the drivers make that more manageable for developers? Or is it just the costs/benefits pay off more?
Still, like I'm saying, choice is normally good. While I don't think this would triple sales, developers would obviously be better off having triple sales even if it meant triple the sizes they have to deal with (just taking the current example in isolation.)
Really, I understand the problems in general of developing for Android, especially when compared to the iPhone and in the future compared to WP7. But, I'm under the impression that new devices, as long as they are not creating new niches aren't doing as much damage as some people would lead others to believe. And judging from the growth of the App store and compatibility of the apps, many developers are doing a good job at accommodating for consumers wishes to have their choice (here I understand the depth of development going into apps hasn't reached as deep as the app store and that coding for the app store can be a more custom rather than least-common-denominator product).
TIA if you get to any of the above.
@juanvaldez
>> Firstly, isn't the resolution what you would care about most as the developer? So, even if these did have different sizes, its the resolution you are trying to develop for.
You're right, resolution influences the UI design more than screen size, though the latter can also have quite some impact on usability, for example when buttons get too small to hit consistently on smaller screen sizes.
>> Can you tell me how this is a different case than the PC. Is it market size? There are so many more resolutions and screen sizes to deal with, so does Windows and/or the drivers make that more manageable for developers?
On PC's the UI toolkits are completely geared towards multiple, resizable windows, scrolling areas and accurate pointing devices, as well as large screen resolutions. IE: you can stuff much more in a window, and the stuff you put in it can be much smaller. Also, you can use multiple overlapping windows, and the screen aspect ratio is normally constant (no rotation). So size constraints are much less an issue. Which is why most desktop applications aren't size constraint at all, in fact, applications that don't allow resizing are typically preceived as very annying. Anyway, try imagining a Windows or OS X desktop with 320x240, 320x480 or 800x480, without a mouse, and you'll probably have to agree that it would be pretty difficult to write complex applications fthat work well using the normal desktop UI toolkits.
>> Still, like I'm saying, choice is normally good. While I don't think this would triple sales, developers would obviously be better off having triple sales even if it meant triple the sizes they have to deal with (just taking the current example in isolation.)
Choice isn't always and only a good thing, it also has downsides. If I target Android, I have to either write for the lowes common denominator, or pick a range of more-or-less comparable devices and target only these. Note that this isn't only about screen size, but also about CPU and GPU capabilities. Especially with games, it quickly becomes a nightmare if you have to cover devices with both OpenGL ES1 and ES2. With screens ranging from 0.0768 to almost 1 megapixel resolution. With 500Mhz to 1Ghz CPU's. Of course bigger development studio's can have different people working on different versions for different devices, but for me, as a lone developer who develops for mobile as a hobby, next to a day job, I'd rather pick a uniform platform over a fragmented one with a similar userbase. If many developers do the same, it leads to less applications and lower average quality, which is exactly what the Android Market shows.
>> But, I'm under the impression that new devices, as long as they are not creating new niches aren't doing as much damage as some people would lead others to believe.
Well it all depends on the application itself of course, and the device differences. For many applications, resolution and screen size are large irrelevant, particularly for the simpler ones that don't have many controls. But as you add layers of UI complexity, the differences get much more annoying. Of course you can work around everything, try to be resolution-independent where possible, but like I said: it's all a tradeoff between implementation effort and possible revenue that every developer needs to make. Would you rather develop for 3 million iPads sold and put all your effort into optimizing it for that hardware, or for 10 million Android tablets ranging from Android 1.5 to 2.2, screen sizes from 5" to 10", CPU's ranging from 500Mhz to 1 Ghz, with the very probable risk it will influence the quality and features of your application?
@drange Thanks again. I will focus on one thing you say and relate it to a point you made earlier:
"Would you rather develop for 3 million iPads sold and put all your effort into optimizing it for that hardware, or for 10 million Android tablets ranging from Android 1.5 to 2.2, screen sizes from 5" to 10", CPU's ranging from 500Mhz to 1 Ghz, with the very probable risk it will influence the quality and features of your application?"
I think, and again, I'm not in the development community. There are good reasons to go after both. First, lets use your numbers (though you are definitely being more generous than you should be, hehe). If there are 3x the # of Android tablets as Apple then it first would be dependent on what kind of developer you are. Again, I'll use you as an example. You're alone and you have to maximize your results from your limited time. If Android tablets are more prevalent, selling faster than the iPad *AND* there are less developers developing for the Android tablets then you can actually try to limit your consumer supported devices by more than 50% while focusing on the more future-proof consumer devices, besides those owners show that they have a larger propensity to consume, while having less competition in the marketplace relative to the iPhone.
@juanvaldez
Well, I have to be completely honest and admit that I don't actually have any experience developing for Android. But I can tell you that I've been in the position to either go for iPhone OS or Android, and I decided to go for the first, specfically with platform uniformity in mind. My impression is that I can deliver a higher quality application that is guaranteed to work on a larger installed base than I could guarantee on Android. I only need one (or in my case 2) devices to test on, I know the exact hardware capabilities, and I know that the platform will be supported and updated in the future, on the hardware I'm targetting right now.
Maybe I'm different from other developers, but I like the idea of having some form of control over what devices and OS versions my application will be deployed to. It allows me to focus on maxing out the capabilities of the hardware and software, and I believe it will allow better support and updates in the future.
@drange
With iPhone, Jobs chooses for you. With Android, the market will choose. Android is just now gearing up. In a year or so, standards will shape up. Things like the original Droid (with its unusual screen ratio) will disappear. Also, people buying the older model phones won't be buying apps.
And the company that gets out updates to the latest version of Android in a shorter time will attract more sales.
By the way, doesn't the new iPhone have a different resolution than all the older iPhones? Doesn't that mean that as an iPhone developer you have to support two different screen sizes?