Comment by foobarbazetc | Hacker News Reader

Comment by foobarbazetc | Hacker News Reader

Parent Full thread

Why? Developing for Android is a pain in the arse, especially once you're done and testing in the field.

There are hundreds of devices, all different, all with their own bugs and all running different versions of the OS to deal with. This is J2ME all over again.

That doesn't mean it's impossible, it just means it takes longer. It also means you need to go out and buy a tonne of development/testing phones.

All of the above might be okay for people with money and/or investment, but makes it difficult for small developers. Let's not even begin to talk about the Android Market, supported seller/buyer countries, currency display, return policies, etc, etc.

Compare that to iOS -- Apple rolls out an update to the OS, it works on all devices, and they're all identical. There's far less testing required (version N, N-1), and far less hardware investment too. You pop your app up on the App Store and it all 'just works'. That's what Steve is talking about -- integration vs fragmentation.

Yeah, fortunately this is not how software works in practice. The best example is probably the PC market, which is fragmented to such a degree that the hardware permutations are uncountable -- and yet Windows, Linux, other major operating systems and applications all manage to deliver stable, consistent user experiences. The situation with Android is parallel: lots of different hardware, but basically still a "write once, run everywhere" environment. (Everywhere being any phone with a legit Android environment.) Similarly to when you're developing on a PC, you occasionally need to know something about the specific hardware or version you're running against, but more often than not, you just code, and it just works.

Mobile is a different ball game. To start with, while hardware is more varied it's also got far more standardised input hardware - there's a keyboard and there's a mouse and you can rely on that being the primary input.

On Android there will be a touch screen, but it's size, resolution and accuracy will vary. There may be buttons but their quantity and makeup will vary.

The second factor is that you cannot get away with bad UI as much as you can on the desktop. On the desktop it's frustrating but survivable, on mobile it's a death knell.

It'd be more accurate to call it write once, run poorly everywhere.

Edit: insert irony about shocking mis-post blunder due to an interface quirk of my Android phone here.

I suspect that it's more realistic to compare Android development to PC development, say 5 or 10 years ago than now. When I was developing games 10-12 years ago there was a staggering array of different displays, processor speeds, internet connection speeds, colour depths etc etc, whereas now on pretty much any PC you'll have true colour, decent display, decent connection etc. I suspect that game developers still have to wrestle with capability differences more than the rest of us, but for "normal" applications any PC is good enough these days. Windows and the related drivers are also much more stable and consistent now. I don't think Android is there yet, but I suppose it will be within a couple of years.

Disclaimer: I've never written an Android app.

Do you have an app in the Marketplace?

I'm a developer for a very large Android app that touches more system components than most and we have no place in code where we check for OS version and exactly 3 places where we check for a very specific (bad) phone.

"pop your app up on the App Store" -- after going through Apple's gate. In the Marketplace, we deploy on our schedule, not Apple's.

What's the bad phone?

Developing and testing on Android wouldn't be so bad if the damn emulator was actually usable. AVDs sound great in theory, but useless in reality. A hobbyist can't afford to buy a couple of dozen phones to test out an app. No wonder Android Market is full of comments about apps not working...

Reply on news.ycombinator.com