In wich I rant about developing on Android

I concur. But it ain't beds of roses with iOS either, especially when you hit blocks with "private APIs", or wanting to do anything more than Apple allows you to. Basically, each platform has its quirks. The problem with Android is, it can afford to have more "tools" to building beautiful android apps.

The rant is a mixed bag:

The state of Android visual GUI editors? Much improved but that just moves them from abysmal to shameful.

Animation? General-purpose property animation, which debuted in Honeycomb is very powerful. LayoutTransition is less-general, but very convenient for transition animations.

Declarative UI in XML is the worst possible way to do it, except for every DSL that's been tried. If you prematurely proliferate different layout files for different configurations, you are screwed. There is no solution, except to convince your designers they will never get the pixel-perfect results they get on iOS. Maybe lie to them and tell them they get only three size variations and two density variation: Big tablet, small tablet, and handset, plus hi-res and medium-res.

It should be noted that the Android Tools get better with every release, and that it can display and edit XML you have created. I recommend watching this video about recently shipped and upcoming functionality https://www.youtube.com/watch?v=Erd2k6EKxCQ - if you only have a few seconds then watch 30 seconds starting at 22 minutes in.

Out of curiousity how do you handle "pixel perfect" layouts on iOS in the face of diversity (screen sizes, orientation, languages)? As a simple example German text is typically 25% larger than the equivalent English text.

One thing that amuses me while doing Android (Java) development is just how much of the code Eclipse writes for me. You just put in what you really want to type and then the various tools come in and "fix" it for you. This of course is an indication of just how much boilerplate there is.

I am currently prototyping a jar dependency solution that could help my workflow and looks similar to cocoapods, but on top of Maven and Android repository xmls.

See here:

https://gist.github.com/3603015

If you think that can be improved, add your comments to that gist.

And if you have a list of common used maven or android repos, just post them there, too.

Please help!

I prefer Android development to iOS, but some of his criticism are valid.

The Android SDK is a bit too Java-ish for my liking. I mean, yeah, it is written in Java, sure, but some Java libraries/frameworks are able to live in Java and still feel light. While the Android SDK isn't EJB-bad, there is too much unneeded abstraction in most of the SDK, IMO, a feature which I tend to associate strongly with Java in general.

On the IDE issue... while Eclipse's 'quick fix', logcat plugin and powerful intellisense features are awesome, the horrible bloat cancels out all of the nice features. I'm frankly amazed how slow it can run on a new i5 system when everything else flies on it and I'm constantly annoyed by the sloppy way it is integrated with the Android SDK code generation system resulting in a situation where a build can randomly fail and then work if you hit rebuild without changing anything. I've basically given up on using Eclipse as the primary editor and now develop my Android apps in Sublime Text 2 and use an ant-based command-line build solution. I highly recommend ant (over Maven which he mentions in the article) simply because the Android SDK is already very ant friendly. Chances are good that building your project will Just Work in ant, especially if your dependent libraries are properly using the Android SDK and available via custom library sites through the Android SDK Manager. Sublime Text 2 has a good logcat plugin available via Package Control. The only time I fall back to Eclipse is when I have to do on-device debugging.

GUI Editor: I don't use the Android one, I write XML by hand. Yes, the Android GUI editor isn't that great (though much better than it was before). This is at least partially related to the non-pixel-perfect layout issue. Writing a GUI editor that allows for fully reactive UIs is a much more difficult problem than one where the elements remain fixed. Having said that, the Android GUI editor could be a lot better.

The duplication of XML files is another issue I agree with. I actually like declarative XML for UIs. If Android had a good property binding system and it was integrated with the layout XMLs, you'd be able to have single XML files that could powerfully lay themselves out properly for different orientations and resolutions without having half a dozen different XML layouts for the same view. This is an area where Android should crib from Adobe Flex (or WPF, but avoid all the special DependencyProperty bloat) rather than iOS.

StackOverflow: He's sadly right here with one exception. User "CommonsWare" is a great resource. A lot of the other people who answer Android questions are clueless and will just lead you down paths of stupidity. I highly recommend just downloading the Android AOSP source code and if you have a question read through the base classes. It would be nice if the framework classes were simple enough that you didn't have to do this, but to understand how tabbed page adapters (as one example) really work, you basically have to dig into the Android code because there is a lot (too much, IMO) of "magic" that happens under the covers in many cases and it isn't good "magic" because if you don't know about some of it, it will bite you in the ass.

Pixel-perfect UIs just aren't possible when you're developing reactive/liquid layout apps. This isn't a failing of Android, it is just the reality of developing for a platform without a small set of fixed resolutions. Tell your designer to suck it up because outside of iOS, reactive designs are the future.

OP, your piece begs the question: "What are you going to do about it?"

Really sounds to me like you mostly dislike Java. Personally, I can't stand objective-C and very much prefer Java and developing on Android. Personal preferences, man.