> If they don't have as many rich animations as iOS it doesn't make a whole lot of difference to end users.
Actually, that makes much, much more of a difference to end users than notifications systems or "intents" (both of which, I freely admit, are very awesome). Try a demo for five minutes with an Android phone and an iPhone. Even if the Android phone was more productive in the long run -- and I'm not sure it will be, but let's say that it is -- the pretty UI will win every time.
> the same app binary will work with tablets and phones while automagically adjusting the UI to suit the available screen real estate
Is that a good thing? I'm inclined to say that it's not. With a click of a button in the IDE, you can convert your iPhone app to an iPad app, having the OS scale up the UI for you -- it's just a horrible experience. It's not a tablet application. It's an application designed for phone usage patterns, with text columns too wide to read, and reasonably unusable.
The iPad Human Interface Guidelines say that "The differences between Mail on iPhone and Mail on iPad reflect the different user experiences of each device." You can use one binary for both interface idioms, but trying to use the same interface, or a slightly changed one, just ends up in a horrible app. I don't want to use a tablet with auto-scaled phone applications, and if that's what Honeycomb makes developer think is somehow a good thing, then shame on it for ruining the Android tablet experience.
> Ever heard any one complain about Apple's horrid notification system?
I hear complaints all the time. It is awful beyond belief. There is no way to deny that. So was the lack of multitasking about this time last year. That was fixed.
> Not having to deal with memory management is added bonus.
I develop for the iPhone, and I don't "deal" with memory management. I follow two rules: release what you own, don't release what you don't. (I actually like dislike garbage construction because it causes issues with destructors and non-memory resource management, but that's a different point.)
> So all put together I think there are lot many pleasant things to say about Android as a development platform.
I agree. There are. But I don't think it's inherently better than iOS, although the Java roots might make it much more familiar to a large section of the programming population (that, however, might also use some experience in a new type of dynamic language).
Fair points except that the prettiest UI doesn't always win - more productive, more flexible UIs that look decent enough do. And I don't think Android in itself has any limitation that prevents a developer from creating pretty looking apps.
Also GC mostly is huge benefit when it is available - like everything it has its downside as you rightly pointed out, but I prefer that over having to remember to release memory in different code paths. Gives me more time to think about program logic. Plus you can always write native code in NDK when you want more control over object deallocation for performance critical code.
Call it on an object, and it'll release itself (and its memory) sometime in the future, after the current call stack (probably sometime a few runloops ahead). Most things come pre-autoreleased for you, the only time you ever have to manage memory yourself is if you are storing it inside the instance variables of an object, at which point you just have to remember to add a line to the destructor to free it.
Actually, that makes much, much more of a difference to end users than notifications systems or "intents" (both of which, I freely admit, are very awesome). Try a demo for five minutes with an Android phone and an iPhone. Even if the Android phone was more productive in the long run -- and I'm not sure it will be, but let's say that it is -- the pretty UI will win every time.
> the same app binary will work with tablets and phones while automagically adjusting the UI to suit the available screen real estate
Is that a good thing? I'm inclined to say that it's not. With a click of a button in the IDE, you can convert your iPhone app to an iPad app, having the OS scale up the UI for you -- it's just a horrible experience. It's not a tablet application. It's an application designed for phone usage patterns, with text columns too wide to read, and reasonably unusable.
The iPad Human Interface Guidelines say that "The differences between Mail on iPhone and Mail on iPad reflect the different user experiences of each device." You can use one binary for both interface idioms, but trying to use the same interface, or a slightly changed one, just ends up in a horrible app. I don't want to use a tablet with auto-scaled phone applications, and if that's what Honeycomb makes developer think is somehow a good thing, then shame on it for ruining the Android tablet experience.
> Ever heard any one complain about Apple's horrid notification system?
I hear complaints all the time. It is awful beyond belief. There is no way to deny that. So was the lack of multitasking about this time last year. That was fixed.
> Not having to deal with memory management is added bonus.
I develop for the iPhone, and I don't "deal" with memory management. I follow two rules: release what you own, don't release what you don't. (I actually like dislike garbage construction because it causes issues with destructors and non-memory resource management, but that's a different point.)
> So all put together I think there are lot many pleasant things to say about Android as a development platform.
I agree. There are. But I don't think it's inherently better than iOS, although the Java roots might make it much more familiar to a large section of the programming population (that, however, might also use some experience in a new type of dynamic language).