
"Android Tools Are Horrendous, OS Is Hideous," FB iPhone Dev Joe Hewitt Tweets - siglesias
http://finance.yahoo.com/news/Android-Tools-Are-Horrendous-siliconalley-175763215.html?x=0&.v=1
======
dpcan
In other news, other developers have different opinions. He has the problem of
coming FROM iPhone. If you come from Web/Windows dev to Android, it's a blast.
I have some trouble with the devices, screen sizes, background apps slowing
things down, etc, etc. But overall, it's very manageable, and I've been loving
developing for Android.

Eclipse however.... not a fan. On my old XP box, I'll be working along and it
will just vanish. No error. No crash. No stall. Just vanish. Like it traveled
back in time right before my eyes or something. I've never had a dev tool do
that to me before :)

------
gte910h
Agreed. (I run a product development shop mostly working on mobile projects
these days).

As a former embedded Linux developer, I really really want android to knock
the socks off of the world. But its not.

Problems:

Its carrier based OS update model causes hideous OS Version fragmentation.

Eclipse is so painful to use many people just avoid it and use the command
line tools.

You have to write Java.

There are a dozen deal breaking quirks between basic control behaviors on the
different systems.

\--

All this with the fact there are HUGE economic issues with 85% of the world
being unable to charge for apps in the Android store, flooding the market with
free apps, makes the Android platform a bit of a question mark.

With Windows 7 Phone going with a Centralized OS Version release as Apple is
doing, I think we're going to recommend it as a secondary platform over the
free Android.

~~~
cma
Android allows you to install apps from any source; people in other countries
can sell apps through other channels. Can't do that on the iPhone.

~~~
gte910h
The issue is not that they can sell

It's that they can't sell easily so are instead giving away their product,
effectively flooding the market with free goods.

~~~
ZeroGravitas
Offering economic incentives by making it easy to generate revenue from direct
sales seems unlikely to stem the flood.

If you don't like the competition then you should be happy they're limited to
ad revenue in the App store, which will only be the right solution for a
subset of apps.

If you've got a moral issue with American companies being slow to enable other
options for developers in certain nations then you need to think of a better
way of expressing that than worrying about them "flooding the market" with
their products and implying that they're substandard.

------
martythemaniak
-The UI designer is no good, but the other tools are great. Eclipse works great and if you don't like it you're free to build your own environment (as they are all separate and documented)

\- "[Droid X is] not THAT good. Stick with your iPhone." Quoth The Dude:
"That's just, like, your opinion, man"

\- Don't like java? Don't use it. Use Scala or whatever you like. No one's
gonna sit over your shoulder and tell you which tools to use.

------
ben1040
Having now developed apps for both iPhone and Android, the one thing I feel
Android really lacks is a good equivalent to Apple's Interface Builder.

Interface Builder makes it pretty easy to lay out a decent-looking app GUI on
iOS and not have to think about it a lot, so you can focus on the code and
functionality of your app. It takes more effort while writing that XML on
Android to end up with an attractively designed interface, and short of
running it in several different emulators it's tough to get an idea of what
it'll look like on different devices in terms of display resolution and
dimensions.

------
andreyf
_Basically, it looks like there's no pleasing this guy._

I think some people are just wired this way. As much as I love most
technologies I use, I could rattle off a dozen flaws in any one I use
extensively. Of course, it's a waste of time to simply complain, but twitter
is a great way to immediately release that tension without wasting _too_ much
time.

------
m0nastic
To be fair to Joe, while in the middle of presumably working on an Android
application, he has been posting tweets about his frustrations with that
process.

This isn't quite the same thing as a blog post or article lambasting the
Android platform. I wouldn't read too much into this.

~~~
nir
Exactly. Every developer, working on any platform, might tweet stuff like that
from time to time. Coming from someone of his experience it's definitely
interesting as HN discussion, but completely insane as a Yahoo!Finance story
(with AAPL/GOOG charts, as if the stocks turn based on a coder's tweets..)

------
briancooley
There are a lot of things about Android that are annoying. Sadly, Java is far
from the most annoying thing for me. Besides, if you want to write in
something besides Java, you have more hope on Android than iOS at this point
[1].

The most annoying thing to me is the lack of a really good equivalent to
Interface Builder. Building UI's in XML is tedious and error-prone.

Along those lines, there seems to be a problem with doing the XML layouts in
Eclipse. There have been reports suggesting that the layout tool is creating a
memory leak which eventually leads to the 20-seconds-to-switch-tabs problem.

There are things I definitely prefer about Android versus iOS, like the
Activity/Intent framework. I feel that it encourages a much more modular
design.

The code signing and deployment process is also much easier on Android.

I also like XmlPullParser slightly better than NSXMLParser (though the
performance might be worse), but that's just a personal preference. And if you
really want a SAX parser, you have that in Android too.

IMO, on both platforms you'll be pulling a bit of hair out

[1] Mark Murphy's commonsware site has a 0.4 version of a book called _Android
Beyond Java_ with an incomplete chapter on writing apps in Scala. I've never
tried writing an Android app in Scala, so caveat emptor. I am also aware of
some efforts to get Clojure on Dalvik, but I understand that it is very slow
out of the box due to reflection.

~~~
drivebyacct2
But you can write in plenty of other languages. ASE gives you TONS of options
for other languages you can use to target the Dalvik VM. Not to mention that
Mono on Android just launched (a beta?) a few days ago.

~~~
briancooley
Yes, ASE is great, though some would complain that not all of the API's are
wrapped and that some if not all of the supported languages suffer performance
hits.

That's kind of my point, really. There are already some options in the wild,
and they're bound to get better, so that's definitely a plus for Android.

------
JunkDNA
I seem to read really mixed reports about the Android fragmentation problem.
For every report like Joe's, I see others that say developing for Android is
fine. I can't get a good read on where the actual truth is.

I work in a group that does research on mobile healthcare applications. We're
not a software company, so we can't afford to have a whole pile of devices
here for testing. With the iOS platform, at least I can be confident things
work if I can test on my iPhone and our iPod touch test units. That said,
Android is going to eventually be too big to ignore sometime soon. I'd be
curious what other devs around here have experienced. Maybe we should be using
PhoneGap to avoid those sorts of problems?

~~~
briancooley
I haven't had any device-specific error reports for the few Android apps that
I have worked on, but they are pretty vanilla.

There are occasionally comments in the android-developers group about issues
specific to particular phones. Seems like the Droid is often mentioned, and
the thread I recall was with the camera.

I imagine it would be frustrating to get a crash report, not be able to
duplicate it, and have your app work fine on the dev phone in your possession.

edit: here's the thread: [http://groups.google.com/group/android-
developers/browse_thr...](http://groups.google.com/group/android-
developers/browse_thread/thread/a6de0a8d755915c/417af37a54d4f669?lnk=gst&q=droid#417af37a54d4f669)

------
ww520
I've started developing a side project for Android. My experience is very
positive so far. (I'll do a Show/Ask HN when the app is done.)

The tools and SDK are pretty good. I mainly use the command line tools and
Emacs. That setup works great.

The API and UI framework are fairly well-thought out. I like the
Activity/View/Intent constructs, encouraging modularity and failure recovery.

The graphic API are well-designed, with good separation and combination of
concepts and functionality. There are a lot of built-in supports for graphics,
like bitmap manipulation and transparency support. Support OpenGL.

The emulator is pretty good. The CPU and memory profilers (profiler!) are
excellent.

The choice of using Java is excellent. Since Android is kind of an embedded
device, I want the compiler to catch most of the silly mistakes before running
the app on it.

Things that could be better:

\- The audio APIs are kind of weak and buggy.

\- The XML layout can be a trail-and-error process. Interface Builder would be
nice.

\- The build-deploy-run cycle can be long. Should have a mode that doesn't
require re-installing the whole package for every build.

\- Giving a free Android phone to every developer would definitely help.

~~~
astrange
> Since Android is kind of an embedded device, I want the compiler to catch
> most of the silly mistakes before running the app on it.

Sorry, but what do the two clauses in this sentence have to do with each
other? Do you mean as opposed to writing all the apps in Python?

~~~
ww520
Everyone is comfortable with different language. I prefer statically typed
languages because I have been burnt by my silly mistakes before. Compilers
that help me in catching my mistakes go a long way. Note that I do use
scripting languages but those tend to be short and throw-away-able codes. If
the Android SDK requires a dynamic type language, I would have to write a lot
of boiler plate unit tests to catch my mistakes. That's just my programming
style, might not applicable to others.

Android being a semi-embedded device implies that application deployment is
more difficult compared to web apps, where the developer can upgrade anytime
he wants. That puts pressure on getting things right with fewer release
iterations.

I don't mean to start a language war. I just want to give a data point on what
works for me.

------
starnix17
On a more positive note, does this mean he is working on Facebook's Android
app?

If so, that's great, it's really _really_ terrible.

~~~
ydant
Have you used it recently? It's really improved over the last couple of
updates.

It still randomly opens my browser instead of doing things in the app, but
it's added a lot of features that brought it a lot closer to the iPhone one.

~~~
kefs
All I ask is that they fix this one simple issue for us devs..

[http://stackoverflow.com/questions/3077289/facebook-
android-...](http://stackoverflow.com/questions/3077289/facebook-android-
intent)

~~~
ydant
Well, judging by the amount of progress on the application recently, I imagine
they would be receptive to fixing it. Assuming someone has pointed the issue
out to them.

I haven't tried to implement any intents targeting their application.

------
soljin2000
Any one from facebook has some balls to be throwing stones. They are the
owners of one of the wackiest APIs known to man and a site design so bad there
are browser plugins specifically to fix it.

------
aantix
Having never developed for the mobile phone space, do any of the 3rd party
developer tools hold any promise for abstracting out some of these
complexities? Has anyone used Rhodes? <http://rhomobile.com/products/rhodes/>

------
sliverstorm
I don't know if this has been discussed before, but... since when are tweets
news?

------
carlrice
I must be the only one who absolutely loves Android, its fragmentation, its
stupid little quirks and the fact its written in Java. Then again I am not a
traditional software engineer / CS grad.

Edit: and he is such a cry baby! :)

------
ergo98
Reading his comments, he sounds like many developers when faced with tools
they aren't accustomed to using languages they aren't competent at: Instead of
acknowledging confusion and ignorance (in the polite way of saying it), turn
it into criticisms of the externals.

Look at virtually everyone new to JavaScript and web development as a great
example of this. Even brilliant minds, when first introduced to the
surprisingly powerful JavaScript, post diatribes of dislike for it.

For instance consider-

"A bit surprised how many hoops I have to jump through to do asynchronous HTTP
on Android. NSURLConnection+delegate was so easy."

So how does one do asynchronous HTTP on Android?

[http://stackoverflow.com/questions/828280/is-there-an-
accept...](http://stackoverflow.com/questions/828280/is-there-an-accepted-
best-practice-on-making-asynchronous-http-requests-in-androi)

Is that hard? What hoops are there? It is extraordinarily straightforward, and
is built such that you are essentially the commander and chief of a
centralized asynchronous mechanism. But yes, if you look for it to be exactly
like you've done it before, it might seem Byzantine.

Android has a tremendous number of quirks and imperfections, but I see no
reason why Joe Hewitt's opinion is of any significance.

~~~
joehewitt
I never said it was "hard", just that I was surprised that the simple task of
"get me this URL" required me to work with some abstract classes for "async
tasks". Strikes me as overengineering. The networking classes could easily
encapsulate the threading stuff and let me just stay on the UI thread, as
every other networking library I've ever worked with has done.

I've found other places in the Android SDK when, rather than simply using
callbacks to encapsulate asynchronous work, I'm required to deal with the
threads myself (see GLSurfaceView). You can accuse me of being "confused and
ignorant" but I feel I am making a valid critique of the API design.

~~~
ergo98
>You can accuse me of being "confused and ignorant"

It isn't an accusation or an insult: Every developer on the planet has
recurring periods where they are confused and ignorant. I can't make any such
a claim in this case, but can only point out that such public displays often
grow from such temporary roots.

However yes I cede a thousandfold that Android has an endless array of quirks
and nuances that seem...non-optimal. Parts of the API show their Google
lineage, while other parts draw from the Java norm. And on the "quirksmode"
thing, couldn't agree more.

It was the "Android Tools Are Horrendous, OS Is Hideous" bit that caught my
eye: I can't imagine someone seriously developing for something they consider
hideous, with horrendous tools, especially when they have shown themselves to
be principled.

~~~
joehewitt
I am obviously expecting that in a few years time Android will suck much less,
or I wouldn't bother investing time in it.

------
drivebyacct2
He doesn't like Eclipse and he'd prefer to write Objective-C instead of Java?
Uh...

~~~
astrange
"Uh…" what? You didn't actually remember to make a statement, I think.

------
ericz
Android SDK is horrendously overengineered.

------
barrydahlberg
Just ordered my phone yesterday so I guess I'll find out for myself soon!

------
mahmud
_"He's not crazy about writing in the programming language Apple prefers,
either. Basically, it looks like there's no pleasing this guy."_

Well, medical doctors are not crazy about McDonalds _or_ Burger King, guess
there is no pleasing them divas, eh?

------
ajaimk
I agree with the guy but he has seriously lost the right to talk because of
piece of crap that is the FB iPhone app.

