Live data from Hacker News

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

finance.yahoo.com

41–50 of 57 posts

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

#41

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.

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

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

#42
post #12

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 surprisi…

> 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 constr…

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

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

#44
post #39
post #14

Earlier quoted context omitted.

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.

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.

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.

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

#45
post #12

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 surprisi…

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, rathe…

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.

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

#46

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 wi…

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.

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.

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

#47
post #16
post #2

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…

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 f…

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

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

#48

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.

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.

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

#49
post #12

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 surprisi…

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.

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

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

Post reply on HN