"Android Tools Are Horrendous, OS Is Hideous," FB iPhone Dev Joe Hewitt Tweets

http://finance.yahoo.com/news/Android-Tools-Are-Horrendous-siliconalley-175763215.html?x=0&.v=1

by siglesias • 16 years ago

50 56 16 years ago

finance.yahoo.com

gte910h3• 16 years ago

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.

listic• 16 years ago

Is there any indication that Google might change the Android release model when faced with competition? Maybe in 3.0 or 4.0? If they maintain their development speed, they may release Android 4.0 in about the same time with competitors' next major release.

gte910h3• 16 years ago

I don't think they can due to licencing issues, although they could offer an optional service which would GREATLY help.

cma• 16 years ago

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.

m0nastic2• 16 years ago

Just wanted to point out that while "Android" does in fact let you install apps from any source, many Android phones (for example virtually all of the ones offered by ATT) do not actually allow installing non-market apps. And as this is something that any carrier or vendor can implement, I wouldn't be surprised to see more of it in the future. (Much like how even though 2.2 supports tethering, so far handset manufacturers/carriers have been disabling that support on their 2.2 rollouts)

People always seem to ignore this.

danilocampos• 16 years ago

That's true.

But it doesn't matter. It's a bit like opening a make-your-own-pizza Pizza Parlor and thinking that point of differentiation matters against the power of say, Papa John's. Yeah, maybe Papa John's doesn't cater to a niche of pizza enthusiasts who really want direct control of the mundane elements of configuring and baking the pizza. Maybe they're leaving a bit of money on the table there.

Doesn't matter. They know the majority of the market wants pizza twenty minutes ago, they want it delivered to wherever they are, and they don't want to give it anymore thought than that. No problem -- Papa John's builds an infrastructure that can address this problem well, and screw the artisans. So they'll battle it out with Domino's and Pizza Hut and make a good chunk of money.

Apple has a funnel that is greased like a pig. They don't care that a few nerds can't sideload their dingus through an alternative whatsit. Most people are being served through their absurdly convenient ecosystem.

Consumer: Solid core of a few thousand truly excellent apps, plus decent games > Reasonable discovery experience > Convenient payment with existing account.

Developer: Write for (mostly) one device configuration > Get into a crowded store filled with a bunch of people who can buy in seconds without touching their credit card.

It's easy. Android does. not. have. this. And until it does, very few incentives will exist to create outstanding Android applications. As usual, Google has gone off half-cocked without making sure their product does what it should. They need to fix this, or we're all stuck with only one decent mass market for mobile apps, controlled by Apple.

Someone needs to step up and actually compete with Apple on the things that matter, otherwise the standard never moves forward for devs or users, and that sucks.

gte910h3• 16 years ago

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.

Zak• 16 years ago

I think as Android becomes more established as the standard smartphone OS, Google will be able to exert more influence on carriers and manufacturers by withholding the Google apps and Market when certain conditions are not met. I hope that Google uses this influence to encourage the production of devices that are easy to get software updates for, and lacking customizations that the user can't remove or turn off.

As for Java, it is my impression that most JVM languages can be used on Android, though dynamic languages suffer a bit on startup time. Scala seems like a good option here.

zsouthboy• 16 years ago

>Google will be able to exert more influence on carriers and manufacturers by withholding the Google apps and Market when certain conditions are not met.

Google already does this. Android is free for anyone to use, but if you want the Market and the Google branded Apps, you have to go through a round of certification. The process is testing for compatibility, among other things.

(This is the reason we keep seeing cheap Android tablets pop up without the Market application installed - they haven't gone through the process.)

Most carrier/OEM customization of Android is at the UI level. As a developer, it's understandable to not have all the different devices with different capabilities, but if you code as recommended and don't make assumptions about what the user has / doesn't have available, your application will work pretty much anywhere that the Market is installed.

Null Pointer Exceptions don't happen because the phone's OEM or carrier changed something - they happen because the code went ahead and assumed something worked correctly that did not.

(NPEs are the most common reason I've personally seen applications crash on my own devices, I have no data to support an assertion that that is the main cause of Force Closes, however)

JunkDNA• 16 years ago

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?

briancooley3• 16 years ago

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...

carlrice2• 16 years ago

In 2.2 and higher there is an integrated crash reporter into the system. For 2.1 and lower I have a crude catch all error handler that sends the cause of the crash, app and os versions, handset model and carrier, etc. Using this method, some custom ROMs and two phones I can fix roughly 95% of the errors without actually having the device or user with me to debug.

starnix17• 16 years ago

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.

ydant2• 16 years ago

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• 16 years ago

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

http://stackoverflow.com/questions/3077289/facebook-android-...

ericz• 16 years ago

Android SDK is horrendously overengineered.

carlrice2• 16 years ago

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! :)

andreyf• 16 years ago

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.

aantix• 16 years ago

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/

dpcan• 16 years ago

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 :)

ergo984• 16 years ago

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...

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.

timcederman• 16 years ago

I actually found reading through his tweets that a lot were valid criticisms. I'm disappointed that there is such a "fanboy" divide on Apple vs Android. Why can't we acknowledge there are pros and cons of both and accept that different things bother people differently?

maukdaddy• 16 years ago

Are you new to the Internet?

ergo984• 16 years ago

There are absolutely pros and cons of both. There is no question about it. However Joe is being used as a pawn with people quoting over his over-the-top hyperbole like "Android tools are horrendous, OS is hideous". That isn't a "pro and con" point.

I somewhat sense that Joe is perhaps still fighting his evangelical battle about the Apple thing (note that I'm not taking his Tweets as ultra serious, and I picture some jocular hyperbole, even if some net reporter takes it as statements of concrete truth), and it's like Android is his abused rebound mate, used as a prop to try to strike back. Like he's trying to aggrandize how extraordinary his suffering is to announce the depth of his principle.

quux• 16 years ago

I've been writing code on android for almost a year now have even made modifications to some of the tools and android itself to meet our needs, and I totally agree with all of his complaints.

joehewitt2• 16 years ago

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.

chunkbot• 16 years ago

I love that here on HN you frequently get comments from the original author or subject of the article.

ergo984• 16 years ago

>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.

dminor• 16 years ago

AsyncTask does encapsulate the threading stuff though.

The HTTP APIs aren't Android specific - they're just the standard Java API and Apache's HttpClient. I suppose Google could create another API on top of these APIs (and all the other ancient and poorly designed Java APIs), but since Java's "callbacks" are objects with methods you override, you aren't really saving yourself much.

tejaswiy• 16 years ago

Completely agree. I'm faced with the relatively simple task of accepting a self-signed certificate. The things that HttpClient is making me do ...

masklinn• 16 years ago

> Is that hard?

No, but he never said it was hard.

> What hoops are there?

it's not built into the HTTP request process, even though async HTTP is what you want... basically always. With the example, for every single type of request you have to create a new class. If you generalize the thing a bit, you only have to write an anonymous class every time.

He's comparing that to NSURLConnection where 3 out of the 4 constructors (well technically 1 constructor and 2 initializers) are asynchronous and simply take a request and a delegate (total: one line).

ergo984• 16 years ago

>it's not built into the HTTP request process, even though async HTTP is what you want... basically always

In the Android world that simply isn't the case, and thread-oriented (as opposed to evented) development is the most common strategy, which is why the calls are synchronous -- you toss off a thread to do some web service calls, processing the request and updating the UI.

Regardless, a universal HttpAsyncTask class, with an oncomplete delegate, is a trivial undertaking (there is no need to create one for every unique call). Should there be one in the stock library? Maybe. The lack of one by default is indicative of the fundamentally different general approaches however. Not better or worse, just different.

weaksauce• 16 years ago

I agree that the way you show is easy. Could he have been doing it in some other fashion that is not that straightforward and assumed that it was the only way to do it? Probably. Was he jumping the gun by saying that there were too many hoops. Definitely.

joe_the_user• 16 years ago

Yes,

This is a common pattern. But it's a pattern that includes very good developers.

That's because just about all tools and environments today are "awful", are unintuitive and overly complex and it's actually useful to vent and then get your understanding of the situation under control. Then you can move on to producing something useful.

No one has yet produced tools and environments that seem in sane except to those who are used to them and adapted to their compromises. Good developers don't silently accept the excuses but stay frustrated on some level - it's an incentive to produce better stuff. Obviously, you still do want to channel this frustration into reasonably moderate and useful directions.

mahmud• 16 years ago

"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?

ben1040• 16 years ago

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.

barrydahlberg• 16 years ago

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

martythemaniak• 16 years ago

-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.

briancooley3• 16 years ago

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.

drivebyacct22• 16 years ago

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.

briancooley3• 16 years ago

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.

m0nastic2• 16 years ago

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• 16 years ago

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..)

sliverstorm• 16 years ago

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

drivebyacct22• 16 years ago

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

astrange2• 16 years ago

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

ajaimk• 16 years ago

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.

soljin2000• 16 years ago

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.

ww5202• 16 years ago

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.

astrange2• 16 years ago

> 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?

ww5202• 16 years ago

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.

"Android Tools Are Horrendous, OS Is Hideous," FB iPhone Dev Joe Hewitt Tweets

Related Stories