Google's mobile phone plans hit delays: report

[Danno]

NEW YORK (Reuters) - New mobile phones being developed by Google Inc
(GOOG.O: Quote, Profile, Research, Stock Buzz) and more than 30
partners based on software called Android will arrive in the fourth
quarter, a schedule that some cellular carriers and program makers are
struggling to meet, The Wall Street Journal reported on Monday.

Google had said in November that the phones would come out by the
second half of 2008, the Journal reported.

<snip>

Android also has not won broad support from large mobile-software
developers, and *****some said it is hard to develop programs******
while Google makes changes as it finishes its own software, the
Journal reported.

~~~~~~~~~~~~~~~~~~~~~`

More available at link

How can it be hard to develop in I wonder....

[Danno]

http://www.reuters.com/article/rbssWirelessTelecommunicationServices/idUSN2242217020080623

Ooops...Forgot link..

[Michael Neale]

It is WSJ trying to generate news in a slow tech news week:
http://googlewatch.eweek.com/content/hello_android/journal_weaves_fud_web_for_google_android.html

Although changing the APIs may pose a bit of a challenge to
developers, so that could annoy people.

[David Watson]

I haven't done any Android development, but have done some iPhone
stuff. (The 2008 Apple Design Award for Best Healthcare & Fitness
Application is sitting on my desk. If that's not a big enough hint,
I'm not sure what you'd need. :) ) It's quite pleasant to program for,
and you can get a lot done in a short while - and it's pretty easy to
integrate with a Java backend. Initially, when we started developing
our app, we had wished for the ability to use Java, but it was quite
easy to pick up. ObjC was a bit weird at first, but after spending 5-6
weeks with it, it's grown on me. The collections APIs are kind of
strange, and I find myself missing generics, but on the other hand,
the dynamic features are extremely nice as well. And the ability to go
down to low-level bit manipulation was necessary several times, in
order to get the performance needed, something which I'm not sure
would be possible with Android.

We've had a small but significant number of people ask us about
offering our application on RIM or Windows Mobile. The answer we've
given has basically been, "No, but thanks for asking." If we do
support another platform, it will almost certainly be Android.
However, seeing the customer base does not yet exist, it doesn't
really make sense to start developing for it yet. What Apple did makes
a great deal of sense. They didn't come out with the SDK while the
platform was brand new, but rather waited until they had a good
customer base, and people went nuts for the SDK.

One other thing is very good about the iPhone, from our perspective -
there are currently only 3 flavors of the platform (iPhone, iPhone 3G,
and iPod Touch). It's pretty much known what the capabilities are,
whereas with Android, who knows? Our application definitely pushes the
limits of what you can currently do on a phone, and having a very
capable minimum device is good for us.

Another question I have about Android is I'm not sure exactly what
Google's incentive is here. They don't make the hardware, and the
software is free (GPL, I think?). What is there to ensure that they
support it for the long term?

Another thing that is in Apple's favor is that they have provided a
mechanism for worldwide distribution of iPhone apps. They may take 30%
of the purchase price, but I tend to think that's worth it, as I'm
sure all those servers aren't cheap, and they are paying the credit
card fees, etc. I would imagine Apple gets a much better deal from the
credit card companies than most people can get, since they do *so
much* volume. I'm not sure how distribution of Android apps will work,
but my guess is that it won't be as straightforward as what Apple has
provided.

I'd love to be proven wrong about Android. Being able to use our
existing code in a mobile app would quite nice. On the other hand, I
love my iPhone, too. :)

[Chris Adamson]

On Jun 24, 8:34 am, David Watson <davidgrillwat...@gmail.com> wrote:

> One other thing is very good about the iPhone, from our perspective -
> there are currently only 3 flavors of the platform (iPhone, iPhone 3G,
> and iPod Touch). It's pretty much known what the capabilities are,
> whereas with Android, who knows? Our application definitely pushes the
> limits of what you can currently do on a phone, and having a very
> capable minimum device is good for us.

That's an important contrast I've made to people, having looked
closely at both APIs, and having worked with iPhone a lot over the
last few months. The iPhone SDK is fairly tightly coupled to the
hardware it runs on, so Apple can basically say "in real terms, here's
what's going to happen when you call X." Android is a spec that
hardware developers will have to implement (or gracefully degrade out
of, if they can't bring the goods), so it does seem like there's a
"write once, debug everywhere" risk that the iPhone doesn't have.
I've wondered on my personal blog if this is a Big Design Up Front
scenario.

On the other hand, you're stuck with the iPhone hardware that Apple
sells you. I worked with a client that is developing a custom mobile
hardware device for the medical industry, and after evaluating the
iPhone and Android platforms, we agreed that Android made more sense
for them, as they have a hardware partner who can build them a custom
Android device, whereas Apple may well object to bolting third party
hardware onto an iPhone and de-emphasizing or hiding the iPhone
brand. So the flexibility of the Android hardware versus the
predictability of the iPhone hardware cuts both ways.

--Chris