A few days of programming on iOS and Android illustrates a vast difference.

Counterpoint: I just began developing my first Android app a few days ago, a turn-based strategy game. I've only had an Android device for a month or so so the platform is relatively new to me, and I didn't even know Java (although, to be fair, I knew C# fairly well a couple years ago, which is arguably the same thing plus type inference.) In a few days, with relatively few problems, I was able to build an app and I'll be releasing it in various markets soon (once I stop polishing and let it go, which is hard for me to do.)<p>I found the experience to be straightforward and intuitive. I was able to find tutorials for any task I couldn't figure out myself and the API documentation is perfectly adequate. Working with images and settings files are two areas where I was very pleasantly surprised at just how easy it was.<p>There were some minor frustrations. The Android emulator fought me a little so I started just debugging on my actual device. Debugging certain problems can be difficult, Eclipse can cause headaches and throw random nonexistent exceptions, etc. but overall I think you've vastly overstated the difficulty level of jumping into Android development. "The depth of knowledge of in design patterns required is so great..." It's really not. With almost no experience with Java or Android, I've put together a working app in a few days that, in my opinion at least, is pretty good, and that works on various mobile devices with different resolutions and capabilities.<p>Some other things I'm happy with about the Android platform: the SDK is free, Android is open source, you're very unrestricted with regards to what your app can do, and Android Market developer accounts cost a one time fee of $25 instead of $100 a year.

Screw it, I'm psyched! It's a great time to be a mobile developer! I was going to write a whole response regarding iOS vs Android until I realized the debate is like religion or politics. Currently both platforms are great and only getting better with each iteration. I'm developing for both platforms and loving it. Just in the latest iterations look at what we can do.<p>iOS * AirPlay - My phone will be my gaming console and media center, genius! * iCloud - Good, no more transferring files back and forth. * CoreImage &#38; AVFoundation - 30 lines of code to add video editing and filters to my application, sounds good! * GLKit - High-level 3D libraries for a game developer noob like me. I'm in! * TwitterAuth - I'm still going to integrate FB authentication but this is cool too.<p>Android * Ice Cream Sandwich - No more fragmentation. Unifies hundreds of devices (not just phones). Brand new UI library. I can't wait! * ADK - My home, car, and toaster will soon be at my mobile command while giving me status updates. This is so awesome! I foresee Android powered cleaning robots in the future. * Face-tracking - So my phone can recognize me and focus in on my face and voice automatically. This sounds like fun. * USB Host - I can plug anything USB into my Android phone. Hot damn!

Android is not a toy, you can easily see it's an improvement over traditional mobile, and it highly influenced by the web.<p>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 &#38; Swing apps, feel the burn .. then do Android.<p>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.<p>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.

"For example, to correctly implement asynchronous HTTP requests is an entirely different challenge in iOS and Android. On iOS you use the built in libraries, and if your user happens to change applications during the request, you can be sure you have up to 30 seconds, usually more, to complete whatever actions need done before termination. On android, you must implement the `android.app.Service` API for all your important web calls. The app can be killed at any time, and you must retain your arguments, and retry the call in case it happens to die."<p>Except... no, you don't. :/<p>The first sentence of the documentation on Service: "A Service is an application component representing either an application's desire to perform a longer-running operation while not interacting with the user or to supply functionality for other applications to use."<p>Do you need to do either of those things? If you say no, then don't use Service.<p><a href="http://developer.android.com/reference/android/app/Service.html" rel="nofollow">http://developer.android.com/reference/android/app/Service.h...</a><p>In the Processes and Threads documentation: <a href="http://developer.android.com/guide/topics/fundamentals/processes-and-threads.html" rel="nofollow">http://developer.android.com/guide/topics/fundamentals/proce...</a><p>It describes how when the user leaves the activity in a process, it goes in the background. It doesn't kill the process. You can continue doing networking. You don't need a Service to have background threads in your process. (In fact again from the Service documentation, a Service is not a thread at all.)<p>Just continue doing your work, and if the system needs your RAM for other processes, it will kill your process, but otherwise you can continue downloading in the background.<p>This is exactly how for example the web browser, and any app using a WebView, works.<p>This is similar in many ways to iOS. Not surprising, iOS seems um inspired in its multitasking design by Android.

Well you're new to Android so things seem weird at first. It's all a matter of picking up the underlying concepts. To be fair ObjC and Cocoa looks for most Java devs like voodoo, but once you get it it becomes easier, too.

I mostly agree with the blog post. It is perhaps too hard to make proper app in Android, but all those abstractions are powerful, imho. Consider quick search/suggestions. If done properly, then you can plug your implementation also to system-wide search with just some config changes (and user permission, of course). Sure, content providers seem far too difficult (search dictionary example in dev docs), but then you can reuse them for your list activity or quick search or access them from another app.

My problem with Android development is that, being a non-Java developer, I never knew when to use the Android SDK or the Java SDK or the Apache stuff for certain tasks. For example, networking. Googling online for solutions, I don't know if any of the Java code I find is Android compatible.

I would love to see some scripting language in Android AND iOS which is <i>Officially</i> supported. Something like Python,Ruby or JavaScript which will make app development much easier.<p>Hey Google, Give us a nice scripting langauge. Pretty Please?

This guy it seems trying to say that Android's APIs were developed by (talented) engineers for engineers (skilled programmers) on the go, while Apple just adopted mature libraries from OSX which are providing set of hight-level abstractions and APIs understandable by any mediocre coder (the way of 'easy/cool' java/php frameworks).<p>But one should remember that too high-level APIs and abstractions has its cost in terms of performance and bloatedness of required runtime (J2EE/Spring/Hibernate way) especially on resource-limited (lack of FPU, etc) platforms.

The only thing I know for sure is it took me about 4 hours to write a concept Android app that used an existing app the market (barcode scanner) which I could interact with via intents. It was free and I can install the APK on devices without using the market. I don't really know what more I could ask for.<p>Well that's not true, the other thing I know for sure is Objective C makes me dry heave.

So of all the things which might be singled out as "over-engineered" in the Android developer kit, he singles out the mechanism of _message passing_ as worthy of the propeller beanie?<p>That's confusing to me. Message passing is one of the simplest actionable metaphors we have in the world of programming. I'm new to android development, but they seemed pretty straightforward to me.

I worked on an Android app for about 2 months together with some experienced Android developers. Most things, like displaying dialogs, storing things to the Db, etc. worked quite well and I really came to like intents. However, I completely agree with the authors criticism of the implementation of asynchronous calls. We implemented in app purchase functionality for our app and it was a huge pain. Google provides lots of documentation around this. However it's very convoluted and looking at their example IAP app makes you wonder if they had some contest going on to achieve the highest number Gang of 4 design patterns per lines of code. That massively distracted from what the example was supposed to teach you. We ended up spending around 2 weeks to get a solidly tested implementation of IAP working and get all edge cases covered. My main complaint about this is, that we weren't doing anything fancy and 99% of the code we had to write was not specific to our application. Something that just takes our vendor information and one callback for the success case and one for the error case would have totally done the job. I am sure there are hundreds of dev teams out there writing the exact same code as we did. Many of those probably are not testing their code or even just copying Google's example, without understanding what's going on. This is a huge waste of everyone's resources and will probably lead to many buggy apps. I understand that Google wants to allow for the flexibility to cover 99.9% of all use cases. However, they could still have offered a simple library method for the 99% case and have allowed the other 1% to write their own thing. Now everyone has to write their own solution. I hope someone will open source their IAP solution. If not, I actually might do it, since it's just crazy right now.

There are other ways to do it: <a href="http://android.xamarin.com/" rel="nofollow">http://android.xamarin.com/</a>

Maybe I am going off on a tangent here, but... why not just use an AsyncTask with a synchronous HTTP petition inside? I am a novice in the Android SDK, but it just seems easier.

Counterpoint, and like I said on the original post: Within a few days of programming Android I had published a few apps. You just need the App-titude, and the attitude as they say. I'm on day 60 and have done 65 Android apps thus far. Perhaps my live-coding video that was up last week would help? <a href="http://www.youtube.com/watch?v=x8bu8nNUZSY&#38;feature=channel_video_title" rel="nofollow">http://www.youtube.com/watch?v=x8bu8nNUZSY&#38;feature=chann...</a>

Haven't tried programming Android, but not crazy about objective c. But Apple's documentation is stellar and easy to access.

For higher abstraction layer on Android, there's Corona SDK and other similar tools.

Wouldn't it be better though if we did not have to rely on either apple or google for mobile programming? How about extending trusty old HTML to provide low level Apis for mobile devices? Phone gap does it and it's already proving valuable. As mobile bandwidth is becoming more stable it makes more sense to quit the app store madness and embrace the wild open web as the only app platform. In principle I do not see why there isn't a set of mobile browser extensions already; i suspect that both google and apple will use their platforms as a tool to lock in developers to their own strategies.

Java APIs are not designed to "just work" but rather to "eventually work with anything".

Then again you won't find such names in iOS SDK <a href="https://plus.google.com/101253020771610439991/posts/YKKyGFdq2MT" rel="nofollow">https://plus.google.com/101253020771610439991/posts/YKKyGFdq...</a><p>:)

WTF? This guy is an idiot.<p>I make iOS and Android applications for a living. It is ridiculous to have to create a service to make a few HTTP calls. For that, Android/Java provides various threading classes so that you can keep multi-threaded code nice and neat.<p>With iOS, out of the box, you get NSURL and its family. You have to setup callbacks in your class and you have to keep track of your http calls per class by using things like action=whatever. What a pain. ASIHTTPRequest makes things much easier.<p>Ugh, this just makes me mad. Why would people listen to shitty developers? Why are you spreading this ignorance?<p>Objective-C is a giant paint, with opaque types. Having to remember what class you've put into a dict can get messy.<p>I have to work with both frameworks every day, and Android is the better framework BY FAR.