"Android Tools Are Horrendous, OS Is Hideous," FB iPhone Dev Joe Hewitt Tweets(finance.yahoo.com)
finance.yahoo.com
"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
20 comments
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.
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.
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.
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 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)
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)
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.
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.
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.
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.
People always seem to ignore this.
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.
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.
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.
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.
-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.
- "[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.
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.
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.
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.
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.
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.
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..)
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.
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.
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.
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 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?
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?
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...
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...
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.
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.
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.
> 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?
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?
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 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.
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.
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.
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.
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-...
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.
I haven't tried to implement any intents targeting their application.
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.
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/
I don't know if this has been discussed before, but... since when are tweets news?
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! :)
Edit: and he is such a cry baby! :)
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.
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 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.
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.
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.
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.
I love that here on HN you frequently get comments from the original author or subject of the article.
Completely agree. I'm faced with the relatively simple task of accepting a self-signed certificate. The things that HttpClient is making me do ...
>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.
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.
I am obviously expecting that in a few years time Android will suck much less, or I wouldn't bother investing time in it.
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?
Are you new to the Internet?
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.
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.
That's how media works. I'd argue that some of the news stories that came out about him quitting over App Store policy were over-the-top hyperbole.
> 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).
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).
>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.
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.
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.
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.
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.
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.
He doesn't like Eclipse and he'd prefer to write Objective-C instead of Java? Uh...
"Uh…" what? You didn't actually remember to make a statement, I think.
Android SDK is horrendously overengineered.
Just ordered my phone yesterday so I guess I'll find out for myself soon!
"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?
Well, medical doctors are not crazy about McDonalds or Burger King, guess there is no pleasing them divas, eh?
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.
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 :)