As a developer, what's relevant to me is the addressable platform.
Here the comparison is between a bunch of android phones with a mind boggling matrix of hardware and OS versions... to just one of the iOS devices.
Having ported an app between the iPhone/iPod and the iPad, and having done the transition to "retina" resolution, the fragmentation in the iOS universe is about as much as I'm willing to take.
Is there a single hardware & OS combination for android that is comparable to the size of the iPhone & iPod touch, iOS 4.x installed base?
I really don't know, and have no idea where I'd go to find out.
The thought of trying to support an android port of my apps, with the seemingly lower return on investment that the android application stores seems to give doesn't seem profitable.
* Everything is sized relatively, but the only way to size to a % of the screen (that I've found) is to pad a view with empty views with different weights, and set the middle view to 0dp (density-independent pixels, which, because of some manufacturers' lies and trickery, aren't always density-independent) tall, and have it resize later. But wait! Setting it to 0dp messes up other aspects of resizing!
* The order of operations that Android goes through to resolve layouts, if it's even logical, is incredibly opaque, and at the very least, not at all intuitive. For example, denoting a view "A" to be above another view, let's call it "B", is not the same as denoting view "B" to be below view "A". Now try that with four views, arranged in a T formation. Hellish! And good luck trying to resize an image to clamp its left, top, and right edges to the screen, and crop it at the bottom - it won't work unless you clamp only a corner (i.e. top and left) then have it resize to fill the third clamped dimension, that is unless you're using other special tactics to mess around with other parts of your layout, in which case you'll waste a LOT of time finding the right answer, or one good enough to use.
* The concept of resource overlays in Android is a huge, huge, huge pain in the ass. Possibly necessary given the complete fragmentation of the devices.
* Devices will actually lie to you about their screen dpi/resolution because they think it'll be better
* Some devices might have bad defaults, or not allow you to select a button without tapping it (i.e. with a directional pad) while others will.
* Weak-linking and adding in checks for future functionality is not possible, to my knowledge, on Android. Adding in support for Honeycomb features entails actually not supporting them directly, but proxying them through a compatibility library.
* The error-checking for XML layouts and themes is weak.
* XML layouts and creating views in the equivalent of a view controller is entirely different and the mapping is not 1:1. Combining the approaches piecemeal complicates the whole process enormously.
* Asynchronous data can only really be loaded one way without causing lower-end devices to crash on large datasets, and that is with the whole cursor/content provider ecosystem, which is a poor excuse of an abstraction given Java's power.
* Parsing stuff tends to be dog-slow unless you spend an inordinate amount of time paying attention to it.
* Certain upcoming platforms running Android - and developed by Google itself - don't even support the NDK, which means you can't even dip into C/C++ for performance anymore for said platform.
God, I miss developing on iOS. It's too bad our app got rejected for using In-App Subscriptions, then rejected for not using In-App Subscriptions.
I understand the frustration of getting a rejection from Apple, it probably wouldn't sting as much if they had better bedside manner. When it happened to me, I was livid for about 5 minutes, thinking it was actually due to a bug on their end. Then I investigated it and discovered that it was actually my mistake, and didn't feel so bad. But a little less terseness and I wouldn't have had that initial anger because I would have correctly understood the reason for the rejection.
I appreciate greatly the long list of issues you just presented. Despite the tone of my previous post, I was on the fence about android.
I'm dismayed to hear that google doesnt' seem to be supporting the NDK as much going forward, as one of the alternative solutions I'd considered was using the Unity engine. Unity is a game engine, but it can be used to make just about anything you want, and you could concievably do a regular, say, business app in it, with the advantage that the same app can be produced for multiple platforms, including iOS and android.
It seems to me, the way to support android would be to do a web app. Presumably the browser, being based on webkit, works and is reasonably targetable. But that limits android as a platform to situations where a web app works as a business model.
To be clear, the NDK will probably remain supported and first-class on mobile devices. Given that I have an NDA for the current Android device I'm targeting, I can't say anything really specific about it, only that the NDK is not designed to work with it (though it would appear that it does support JNI). So I wouldn't discount Unity necessarily.
I have half a mind to just write up a new UI framework in OpenGL or something, and use it as a vehicle to learn OpenGL better, but I don't have the time or the money to do so, and ultimately I can worth with the stuff that's already there, albeit with constant frustration and platform angst.
Comments
As a developer, what's relevant to me is the addressable platform.
Here the comparison is between a bunch of android phones with a mind boggling matrix of hardware and OS versions... to just one of the iOS devices.
Having ported an app between the iPhone/iPod and the iPad, and having done the transition to "retina" resolution, the fragmentation in the iOS universe is about as much as I'm willing to take.
Is there a single hardware & OS combination for android that is comparable to the size of the iPhone & iPod touch, iOS 4.x installed base?
I really don't know, and have no idea where I'd go to find out.
The thought of trying to support an android port of my apps, with the seemingly lower return on investment that the android application stores seems to give doesn't seem profitable.
Ha. You don't know how good you have it. On Android:
* Certain devices decode h.264 wrong and crash, others don't, and it's hard to reproduce and virtually impossible to test
* No, there is no Android device dominating the others. Not even close. Program to API 7 or API 8 if you must, but the whole thing's a headache.
* No expectations for resolution
* This freaking bug (ARGH!!!!!!): http://code.google.com/p/android/issues/detail?id=1353
* Everything is sized relatively, but the only way to size to a % of the screen (that I've found) is to pad a view with empty views with different weights, and set the middle view to 0dp (density-independent pixels, which, because of some manufacturers' lies and trickery, aren't always density-independent) tall, and have it resize later. But wait! Setting it to 0dp messes up other aspects of resizing!
* The order of operations that Android goes through to resolve layouts, if it's even logical, is incredibly opaque, and at the very least, not at all intuitive. For example, denoting a view "A" to be above another view, let's call it "B", is not the same as denoting view "B" to be below view "A". Now try that with four views, arranged in a T formation. Hellish! And good luck trying to resize an image to clamp its left, top, and right edges to the screen, and crop it at the bottom - it won't work unless you clamp only a corner (i.e. top and left) then have it resize to fill the third clamped dimension, that is unless you're using other special tactics to mess around with other parts of your layout, in which case you'll waste a LOT of time finding the right answer, or one good enough to use.
* The concept of resource overlays in Android is a huge, huge, huge pain in the ass. Possibly necessary given the complete fragmentation of the devices.
* Devices will actually lie to you about their screen dpi/resolution because they think it'll be better
* Some devices might have bad defaults, or not allow you to select a button without tapping it (i.e. with a directional pad) while others will.
* Weak-linking and adding in checks for future functionality is not possible, to my knowledge, on Android. Adding in support for Honeycomb features entails actually not supporting them directly, but proxying them through a compatibility library.
* The error-checking for XML layouts and themes is weak.
* XML layouts and creating views in the equivalent of a view controller is entirely different and the mapping is not 1:1. Combining the approaches piecemeal complicates the whole process enormously.
* Asynchronous data can only really be loaded one way without causing lower-end devices to crash on large datasets, and that is with the whole cursor/content provider ecosystem, which is a poor excuse of an abstraction given Java's power.
* Parsing stuff tends to be dog-slow unless you spend an inordinate amount of time paying attention to it.
* Certain upcoming platforms running Android - and developed by Google itself - don't even support the NDK, which means you can't even dip into C/C++ for performance anymore for said platform.
God, I miss developing on iOS. It's too bad our app got rejected for using In-App Subscriptions, then rejected for not using In-App Subscriptions.
I understand the frustration of getting a rejection from Apple, it probably wouldn't sting as much if they had better bedside manner. When it happened to me, I was livid for about 5 minutes, thinking it was actually due to a bug on their end. Then I investigated it and discovered that it was actually my mistake, and didn't feel so bad. But a little less terseness and I wouldn't have had that initial anger because I would have correctly understood the reason for the rejection.
I appreciate greatly the long list of issues you just presented. Despite the tone of my previous post, I was on the fence about android.
I'm dismayed to hear that google doesnt' seem to be supporting the NDK as much going forward, as one of the alternative solutions I'd considered was using the Unity engine. Unity is a game engine, but it can be used to make just about anything you want, and you could concievably do a regular, say, business app in it, with the advantage that the same app can be produced for multiple platforms, including iOS and android.
It seems to me, the way to support android would be to do a web app. Presumably the browser, being based on webkit, works and is reasonably targetable. But that limits android as a platform to situations where a web app works as a business model.
Thanks again!
To be clear, the NDK will probably remain supported and first-class on mobile devices. Given that I have an NDA for the current Android device I'm targeting, I can't say anything really specific about it, only that the NDK is not designed to work with it (though it would appear that it does support JNI). So I wouldn't discount Unity necessarily.
I have half a mind to just write up a new UI framework in OpenGL or something, and use it as a vehicle to learn OpenGL better, but I don't have the time or the money to do so, and ultimately I can worth with the stuff that's already there, albeit with constant frustration and platform angst.