Hacker News Reader

> you start jumping into the rabbit hole when you start getting into server API integration and doing processing off the main thread (AsyncTask, IntentService, Service, unit tests lions tigers oh my)

Yes, the first thing to learn is concurrent programming in Java, and Android's classes that simplify it.

Then learn about components - everything that implements the ComponentCallbacks interface - and how lifecycles work. If you skip over this you are doomed.

Then learn how to keep your data model in a ContentProvider.

After that, you are through most of what is different and that might be strange.

(OP here.) I agree with you on most points, but I don't know how you'd write a graphical game without dealing with asynchronous operations. For example, this app uses an extended SurfaceView (uses its own thread to draw), timers to handle move animation, and AsyncTasks to perform computer AI turns and implement a hack that makes Toasts last longer. Otherwise the UI would be clunky and give a "not responding" message whenever it wasn't your turn.

I would say that graphical games are a step above the simple "standalone app" you mention.

I apologize. I may have rushed to judgement. I didn't get a chance to check out your game, will do. Games are definitely not a simple standalone app.

I stand by my assertion that non-trivial app development on Android can be harder than on iOS. For example, take a look at the Google Music app source (an example of a complex app) and see if you can understand how it was designed and why it was implemented in such a way. I can't claim to fully understand it.

http://android.git.kernel.org/?p=platform/packages/apps/Musi...

> AsyncTasks to perform computer AI turns and implement a hack that makes Toasts last longer

I'm curious why you did not use a FrameLayout to overlay a Toast-like message on top of your SurfaceView game board.

I certainly could've done that. I liked Toasts, found that you couldn't extend their duration beyond 3.5 seconds, Google'd the problem and found a hack to extend them. Either approach would've worked fine.

Maybe eight months of experience isn't enough to judge it fairly, but I think Cocoa's almost mystical reputation is somewhat inflated. If you compare Cocoa Touch to Cocoa on the Mac you can see that Cocoa Touch is a much cleaner, simpler and more consistent version of Cocoa. There is still room for improvement.

It's a testament to the skills of the original authors of Objective-C that a 1989 technology is still competitive in 2011, but we've learned a lot about language and UI framework design since then.

Why is _Android_ development relatively easy? Well, for one thing, the territory is well trodden. ... _Java_ masters have been able to switch to _Android_ and tell people/show people how to code properly. ... _Java_ has been around for a while.

Goes both ways, no? Not that your comment is without merit but this bit just struck me as really odd.

Java isn't the most flexible language. Java is notorious for having over-engineered frameworks and APIs (J2EE). There is lots of unavoidable copy and paste. The newer things that make Java look more modern, lithe and Ruby-like like Spring/Hibernate - don't work well within the power/memory limitations of a mobile device.

And, more importantly, the market isn't just there for Android apps. Not as many people want to code Android. I hate to say it but some of the projects I've been involved on - Android was a "checklist" item - as on 'We're on Android now, too'. I only know a handful of full-time Android developers, but I know many, many people who have quit their jobs and have gone full-time iPhone (contract/product).

It's important to distinguish Java the language from Java the framework-encrusted "enterprise" tool. Java as a language isn't so bad. Objective-C and Java each have their own strengths and weaknesses. For example, my Java code dealing with collections is much cleaner than comparable code in Obj-C because I don't have manually box & unbox primitives with incredibly verbose messages.

The JVM also gives you alternatives. Currently none of the non-Java JVM languages is great for Android but Jetbrains' Kotlin project is looking very promising: http://blog.jetbrains.com/kotlin/

> Java is notorious for having over-engineered frameworks

You've got to separate Java the language from all the other stuff. You aren't going to use J2EE for Android so how does that affect you? Java may not be the most elegant language but neither is Objective-C without warts.

> And, more importantly, the market isn't just there for Android apps.

Now you are just moving the discussion.. this is not what the OP was talking about nor was it the point of this discussion.

The OP's thesis was about how Android development is easy. I countered that with the strong personal opinion that once you get into more complicated apps that it gets harder. I believe it gets harder because there are less resources (for example, if you compare the Apple developer docs with Google's Android docs - you would be hard pressed to say that the quality and quantity of Google's docs are more).

Apple clearly had the lead on developer mindshare because of the success of the App Store. Google is catching up but the reality is you can make a living off iOS easier than Android. You could do both but going from CoreData to ContentProviders in one day might make your head queasy.

Speaking of J2EE, I would love to have Spring or Hibernate ORM. I've tested the various Android ORMs and they do not yet seem to be 1.0.

> AsyncTask, IntentService, Service, unit tests...

Maybe I'm off-base here, but I think that if you understand the abstract concepts behind these on another platform (say GNU/Linux development with Qt or GTK) then it's simply a matter of translating your understanding of the concepts into the new platform's way of doing it. This is what a CS degree is meant to teach you (i.e. in my degree program, they never taught any programming languages -- only concepts in the abstract). Learning Services, ContentProviders, AsyncTask, etc. was really not bad at all and as you said, the SDK has gotten drastically better over the years.

It's not just coding.

The challenge is two parts: 1) creating an app that does what you want and does not ANR 2) creating an app that looks good and responds well. I stress that the 2nd part is what the users notice the most - they don't care about your well-designed network processor logic if it takes too long or lacks the shine and polish of an iOS equivalent app.

I'm not saying it is easy to polish an app on iOS. We've spent months polishing an iOS app to client satisfaction. The thing about Android is that clients are willing to accept less polish.

In my experience, the difference between Android and iOS for me is "How?" for the former versus "Is this even possible?" for the later.

Yes, iOS is friendlier to newbies, but Android is more flexible and allows pretty much anything you can think of. More complexity is the drawback of having more flexibility, but after learning the platform it isn't really that bad (as the article says, with which I agree).