[evinfinite]

Just a point that needs clarification: how is any of this comment relevant to the points raised in the OP? That is, how does this help against the fact that Android has:

* A much more complex set of (good!) abstractions that are poorly documented;

* and, if I might add alongside the OP, requires a much higher workload in terms of code length and complexity, debugging, device configuration management and tools for what seems to be a much lower payoff?

I have a successful iOS app out, and I tried to rearchitect it in a manageable way to port it on Android. What I found out is:

* The code would be roughly twice as much as the iOS version.

* A proper UI effort would require roughly 2.5x work than the iOS version, as I need to prep up a flexible layout that will work on phones (the buckets 'small' to 'large'), and then another for tablets (actually up to two: 'xlarge' and Honeycomb, which may require some rethinking to accommodate the new action bar). Contrast this to two, fixed-size layouts for the iOS version.

* I already have a path for implementing backgrounding on iOS and it requires minimal change to account for services not available while backgrounded; otherwise, code is exactly the same. On Android, I would have to plan for it from the beginning and set up very poorly documented IBinder stuff to have my Activities talk to a background Service.

* The general unwillingness of Android users in the face of paid apps, and a use model that does not lend itself easily to the insertion of ads, would make my (more costly) effort go unpaid.

I must admit I have never used resources other than developer.android.com and Google, and the latter didn't help me as much as (as little as) developer.android.com did. There might be an excellent book on all of this, but I haven't bought any — any recommendations are welcome.

[nextparadigms]

There are several good Android books out there, you can Google for top 5 Android books. A lot recommend a subscription to this site where you also get these 3 books in that price:

http://commonsware.com/books

And you can try these sites for code snippets on anything:

http://www.anddev.org/

http://www.androidsnippets.com/

[hahainternet]

Could you give me an example of exactly why the claims you've made are true?

Why would your app need twice as much code? Why is using the Android ui designer so much harder than iOS's equiv?

What is so undocumented about IBinder? It's basic IPC?

I would really like to hear reasons, not abbreviations.

[tolmasky]

Although not having used Android specifically, I can easily see the UI designer being poor compared to iOS's. I still have yet to see anything as good as Interface Builder for any other platform, and I think a lot of it just boils down to the fact that when IB was designed it was actually considered to be "the right way" to make pieces of your app from the beginning, as opposed to something bolted on later. Making a nib less app is really hard in Cocoa. A lot of stuff in Cocoa/Touch just makes more sense from a UI builder perspective than a hand-coded perspective. The new constraints API which is absolutely awesome is a good example of this for desktop Cocoa, and the storyboarding stuff is a good example for Cocoa Touch.

[koko775]

Moreover, Interface Builder's file format is quite literally a serialized version of the class constructed at runtime, as configured in Interface Builder. What can be done in IB can also be done in code, which is more than I can say for Android's xml.

[hahainternet]

What do you mean it's more than you can say? Android's system is precisely the same. To build an Activity you set up and extend Views using the ViewGroup function 'addview'

http://developer.android.com/reference/android/view/ViewGrou...

I actually use this to inflate a series of layouts, and then to arrange them inside an existing layout dynamically.

[koko775]

No, there are methods and settings that can be set via code that cannot be set via the XML, and vice-versa - I'm not talking about mixing them together. Yes, they are the same classes. No, they are not created and instantiated and configured in exactly the same fashion; there are occasionally differences.

[hahainternet]

Such as? I don't mean to carry on an endless comment thread but I don't quite understand what you're talking about.

[koko775]

Agreed on all counts. As for the backgrounding stuff, though, don't worry too much, as with a local binder, services become little more than classes running in the background. The ickiness from all that AIDL stuff I've found to not be particularly necessary, as you won't have other applications needing to access your service, typically. Exporting content providers to other apps doesn't seem to be particularly useful, anyways, unless you're Facebook or OEM, where apps might reasonably expect to find the content provider or service they're looking for.

[wallflower]

> On Android, I would have to plan for it from the beginning and set up very poorly documented IBinder stuff to have my Activities talk to a background Service.

An Android developer grows up once they have to deal with Activities going poof.

To be fair, services and content providers enable widgets. Widgets are a differentiator.