[sehugg]

Good feedback. Makes some good points; the pixel-perfect layout vs. flow layout is a very significant difference. We've done a similar bullet-point writeup: http://voxilate.blogspot.com/2010/11/ios-and-android-odd-dev...

One major pain point is dealing with fragmentation. Of course iOS is no stranger to this, but it seems Apple does a better job preserving backwards compatibility. On Android there are wholesale API changes between 1.x and 2.x, and apparently Honeycomb revamps the entire Activity UI framework. Yuck.

[ikhare]

I haven't researched Honeycomb in detail, but current apps work just fine on Honeycomb as long as you say in your manifest that you support large screens. Bump for example, works just fine on the Xoom without any custom work (obviously we haven't optimize for the tablet form factor yet though).

I don't think I agree with the entire UI framework being revamped. Can you point me to something specific?

The Android framework engineers also try often to introduce features that get back ported to older version. A good example of this is the concept of Fragments that was introduce in Honeycomb but has been back ported all the way to 1.5 (I believe).

[sehugg]

Yep, by "revamped" I meant Fragments. From Reto Meier's blog: http://blog.radioactiveyak.com/2011/02/strategies-for-honeyc...

Apparently the new Fragments API will be (is?) available on pre-Honeycomb devices as a static library, and I'm guessing there will be some compatibility with the 'legacy' Activity API in Honeycomb. Still I'm guessing there will be rough edges and unexpected incompatibilities, as there are between 1.x and 2.x versions.

[ikhare]

With Bump 2.0 we decided to throw out 1.x. We are only supporting Android 2.0 and up, 1.x is small enough that it doesn't matter for us anymore. This way we can focus on making the app that works better with a smaller number of differences to deal with.

That said, yes, there are definitely rough edges in 1.x to 2.x, hopefully less so to 3.x. I think only time will tell as things surface in communities like Stack Overflow.

[mks]

We have got into minor issues with Honeycomb - the new selection/copy/paste in the text areas took our app by surprise. The other thing was TAB key events that don't get fired from the Honeycomb keyboard even if tab is inserted to the text correctly. However these are probably edge cases.

My biggest gripe is that Honeycomb emulator is dead slow, so testing anything on it without a real device is really painful.

[GeneralMaximus]

This is because the Android emulator is a real emulator emulating an ARM instruction set on your x86 box (it uses QEMU), whereas the iPhone Simulator is a proper port of CocoaTouch to Mac OS X.

I think both of them suck. The Android emulator is slow and the iPhone Simulator is inaccurate[1].

Here's an effort to port Android to x86: http://www.android-x86.org. I see a a 100% x86 Android emulator running on VMWare in the near future. Tasty :)

--

[1] For example, the iPhone Simulator lets you use NSFileManager to create files and directories inside your app bundle. This does not work on the actual device. I ran into this during a demo :|

[ikhare]

Interesting, I'll keep that in mind if/when I get to deeper Honeycomb development.

As for the emulator, Android is notorious for it's terribly slow emulators. I've basically stopped using them and only use actual hardware to test on. The emulator is good for surfacing race conditions that only show up on super slow devices tough :-)

[ksolanki]

As someone who has developed exclusively on Android, this article seems like an interesting read, especially because it is written by someone who has programmed in iOS before moving to Android ("porting" iPhone app to Android). I wonder if the take would be different when I/someone move(s) to iOS from Android.

I agree that fragmentation is one big pain point of Android. It needs to be considered even between different device manufacturers, not just API changes, when it comes to things like the camera preview. UI responsiveness is another factor that is a disadvantage in Android, which has to be considered explicitly while developing.

[ikhare]

I didn't mention it in the article, but I did Android programming before I did iOS. I was doing Android programming before the iPhone SDK came out in 2008. When the iOS SDK came out, I moved to the platform that had real users and phones. Android didn't have actual phones until late 2008.

I don't remember much of my feelings of the platforms from those early days because I was in a frenzied coding mode trying to release the first few apps in the App Store. But I do remember being frustrated by the lack of something like a GridView in iOS.