[KirinDave]

This is a complaint about Mobile in general, not Android. People bitch about fragmentation (and it is a bit painful), but in the regard of "everyone has their own UX on top of the system default" iOS is in exactly as bad a boat, if not worse. Some of the most popular iOS apps take their UX off in crazy directions (a common example: Tweetbot).

Look closely though. You'll notice the ActionBar is extremely prevalent in these. The ActionBar is actually one of those few Android teachable moments; I wish Apple did this as well, as consistently, or as themably. I've used a lot of these apps (and I am sad to not see Pattrn up there!) and it's very much the case that they have a fairly consistent set of "touch semantics" that screenshots don't reveal. E.g., Tap upper right corner to configure; long press for edit; swipe horizontally to navigate; long press on text fields to engage c/p editor bar.

For better or worse, Android's toolkits offer a lot more guidance to the programmer on "the right way" than Apple's do (a great example of this that bleeds into UI is how Android has a ton of Loader patterns and iOS doesn't have anything nearly so sophisticated in its core lib). So in some respects, Android is actually slightly better off; the bigger toolkit means you get some superior consistency. The recent iterations (and backported support) framework strongly encourages you to do things like support long presses and swipe navigation and backpane navigation.

[rimantas]

Maybe you know something about Android, but I doubt you know as much about iOS.

[KirinDave]

I have written iOS apps (although never public published) and taken classes in iOS development. I am much more of a novice at Android development, but have written a complete (albeit simple, un-networked appliance) app. I've focused more on Android recently because that platform is evolving quickly.

So let's just pretent this isn't a shitty genetic fallacy post and address your challenge head on, "Back up your example and prove to me Android's APIs give more guidance than Android's in how to do ______." I specifically mentioned the Loader pattern.

Compare: Google's Loader pattern: http://developer.android.com/reference/android/content/Loade...

A concrete and common example, doing an async task: http://developer.android.com/reference/android/content/Async...

Compare this to the equivalent API for doing async task usage in iOS: http://developer.apple.com/library/ios/#documentation/Perfor...

In iOS There is no concept of a "Loader", so the community has come up with stuff like AsyncUIImageView and friends (code here: https://github.com/nicklockwood/AsyncImageView) which still doesn't entirely solve the problem, because solving the problem takes a lot of framework support.

Sadly, fragmentation is at play again in this; and many Android developers don't use Loaders because they're intimidated or confused or can't use them for their entire panoply of supported devices; so there are a fair share of Android apps that do not use them. You can usually catch this if you change orientation and see things reload from scratch.

Given the rapidly increasing velocity of deployment of 4.0 devices, I think this issue with framework fragmentation is transient.