Android versus iPhone Development: A Comparison
greensopinion.blogspot.com
greensopinion.blogspot.com
Heh, this is probably true of Objective-C, it's just funny to hear a Java developer say this about any other technology...
You can indeed write much more concise and clear code in it, but for some reason the "proper" way to write java is to use a ton of factories, defining new class (and immediately extending them with more subclasses) for every little thing, wrappers, interfaces and so on.
It's one of the reasons I really dislike Java.
Although the author says this, the fact that 18 new android handsets can be released in a year is one of the problems with both Android and, to some degree, Windows Mobile.
The iPhone OS isn't really revolutionary. Even their interface on their home screen is pretty simple, it's just a more rigid desktop metaphor, Apple dock and all. It's the hardware that truly stands out. The hardware features Apple's carefully thought out design and style, along with an incredibly well done multi-touch screen. The awesome hardware accompanying the incredibly polished and functional screen are really the biggest selling points of the iPhone that no one has matched yet.
It's the same win that Apple's laptops provide over the multitude of OEMs that produce other computers. But it's obvious that hardware design is more important to consumers than the development platform, thus developers are going to have to cope.
My guess is that Apple doesn't really care: they'll eventually end up with some reasonable, but minority stake in the market... more or less like the computer market.
In any case, I hope they stay in a smallish chunk of the market like the computers - they're nice phones, but I am simply not interested in a hacker-unfriendly platforms, and I'd hate to see it become the major, or only one. Android wins by a mile (or two) from that point of view.
In fact, I'm disappointed that there are no upcoming Android phones with decent keyboards, so I won't be getting an upgrade any time soon.
Er...Preferences -> General -> Layout -> All-in-one?
And in this context, I think that's fair enough. There are far more developers out there with more than a passing familiarity with Java & the Java toolchain, than there are for Objective-C/XCode.
By the sounds of it, it will be easier for those developers to develop for Android phones than the iPhone. Regardless of the relative technical merits of the platforms viewed in isolation, the ability to re-use your existing Java chops is going to be valuable.
(I speak as someone who has done equally small amounts of development in both environments - personally, I prefer Objective-C development)
As to memory management: given that Cocoa's retain/release/autorelease is not painful and my most agonizing debugging sessions with java all seem to revolve around theorizing WTF the garbage collector is doing and why... Well I think the productivity opinion is arguable as well.
That seems unfortunate, as with some of the android phones you essentially want the developer version (or something similarly unlocked) so that you can eg kill background processes when you don't need them to improve battery life
Objective-C has an easy to follow pattern, reference counting, which is used consistently throughout the language and libraries.
Creating a class is no more (or less) typing than Java or C++. The syntax is different, but harder to remember? Not really convinced of that. There are basically six things to remember:
@interface for declaring a class header @implementation for declaring a class implementation @end for ending either -whatever for an instance method +whatever for a class method and [object message] for message passing syntax
For instance if you try to write a C extension for Python or Tcl or other systems using reference counting you'll notice that if you don't know every well the internals it can be not obvious when to increment or not the refcount.
I use refcount myself in Redis, and again for people not used to Redis internals to implement a new command may not be trivial exactly for this problem of reference counting. Reference counting is not something to expose for a language that aims to be a such an higher level. In short every language with complex OOP system should have some kind of automatic memory management IMHO.