"Android Tools Are Horrendous, OS Is Hideous," FB iPhone Dev Joe Hewitt Tweets
finance.yahoo.com
finance.yahoo.com
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 :)
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.
People always seem to ignore this.
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.
It's that they can't sell easily so are instead giving away their product, effectively flooding the market with free goods.
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.
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.
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)
- "[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.
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.
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.
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.
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.
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.
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?
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...
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.
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?
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.
If so, that's great, it's really _really_ terrible.
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.
http://stackoverflow.com/questions/3077289/facebook-android-...
I haven't tried to implement any intents targeting their application.
Edit: and he is such a cry baby! :)
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.
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.
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.
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.
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.
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).
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.
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.
Well, medical doctors are not crazy about McDonalds or Burger King, guess there is no pleasing them divas, eh?