[mahmud]

Android is not a toy, you can easily see it's an improvement over traditional mobile, and it highly influenced by the web.

I fought Android until I decided to throw my entire weight behind Java and settled on it as a platform. Don't fight it: learn Java proper, do a few SWT & Swing apps, feel the burn .. then do Android.

You can ignore the abstractions and just "draw up" your application with Eclipse, inside one giant activity, but you would be doing yourself a disservice.

I told myself "Java sucks, it's bloated, it's big, yada yada yada. Just man up and learn it; no sense in bitching about what you don't know" :-) Glad I did. It gets work done.

[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.

[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.

[andymoe]

I'd love to hear a good java book recomendation. Is there a K&R kind of book for java?

I also have to say that maybe iOS is bit easier to get started with but have the author come talk to me after doing ten or twenty apps wrangling core data, list view, sprites, physics engines, universal apps and mixing c c++ and objectice-c and tell me that rabbit hole is not pretty damn deep.

[mahmud]

Hortsman & Cornell's, two volume "Core Java 1.2". I only read the first.

Gosling's "The Java Programming Language".

And Josh Bloch's "Effective Java".

After that, Java Concurrency in Practice.

Langr's "Agile Java" is good for just that.

Bloch, Goetz, and Doug Lea have each written excellent books on java concurrency.

That's just about all the java books I would want to recommend. Many j-books are trash.

[rkalla]

+1

Effective Java is a must-read once you understand Java. It points out what is magic and what is not. What takes up processing time and what doesn't.

It pulls the sheet back on the abstractions and shows you how everything works and what you should be aware of.

Doug Lea is a brilliant developer in the concurrency space. With his Executor framework that went into (Java 5?) he suddenly made threaded programming as easy as possible to get right.

[RodgerTheGreat]

Don't forget Java Puzzlers, also by Bloch: http://www.javapuzzlers.com/ Not only is it a fun read, but it delves very deeply into case studies of the dark corners of the Java language.

[andymoe]

Awesome. Thanks so much for the recommendations everyone.

[rattab]

I don't know how relevant it is for mobile development but I'd recommend Effective Java by Joshua Bloch (http://www.amazon.com/Effective-Java-2nd-Joshua-Bloch/dp/032...). It's essentially the equivalent of Effective C++ for Java and it does a good job of explaining how to properly use the language. It also contains quite a few general programming advises which are applicable to other languages. Just keep in mind that it assumes that you already know the language and have a bit of experience under your belt.

[cema]

Also, consider The Well Grounded Java Developer which is now in Manning's Early Access Program (http://www.manning.com/evans/).

[aerique]

Since I recall you being a Common Lisp enthousiast: do you see, for example, ECL ever becoming a viable alternative for making Android apps?

I've been exploring iOS using Objective-C and I'm about half-way done with my first real app for the Appstore and I can't wait to try and rewrite it using ECL once it is done.

Otherwise it will probably be Unity for me since my main interest is games and game-like apps. I really don't have the time to become and expert in each and every differing mobile platform.

[mahmud]

I didn't look into any "alternative" ways of doing things. I tried to port ABCL to Android, but for my current needs, the standard-way is good enough, at least then I can hire help and focus on what matters, instead of doing everything myself.

Our Android apps are all on the galaxy tablet, we plan to roll out a deployment of 50 devices by year's end.