Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android vs iOS: A Developer's Perspective

whereoscope.wordpress.com

Post reply on HN
Print view View original

11–20 of 85 posts

Re: Android vs iOS: A Developer's Perspective

#11

Post by rimantas »

archgrove wrote: post #5

I totally agree with some of the points: iOS should really receive the same garbage collector that OS X has had for years, and the provisioning certificate nonsense is, well, nonsense. iOS really does need a side loading mechanism. That you need a Mac to develop on is, I suppose, a negative - you can get going with Android on almost anything. However, I can't say I've ever had any problem with Apple's documentation:…

Garbage collection on OS X appeared in Leopard with Objective-C 2.0—later than iPhone, but before iPhone SDK. Older models are still around and even iPad has less memory than iPhone 4 so it is not unreasonable to treat it as resource too precious to be left ar the mercy of GC. On the other hand, manual management is not that complicated and does not add much overhead in programming except the initial phase of getting used to it.

Re: Android vs iOS: A Developer's Perspective

#12

Post by alex_c »

I found that matches my experience fairly well.

I haven't found Apple's documentation to be significantly worse than Android. Parts of the documentation are sparse at best (the Cocoa layer is great, lower-level stuff less so), but overall both systems have good documentation.

Fully agree about Apple's certificates - it feels like I have to spend an hour or two every few weeks trying to figure out some provisioning profile problem. By now I think I've gone through almost every possible thing that could go wrong with them, so it's a lot faster to fix, but it was incredibly frustrating at first. Apple automated some of that through XCode a few releases back, but that stopped working after a few months and I haven't been able to get it to work again - back to doing everything by hand.

Also fully agree about the Android emulator.

All in all, the two platforms are very close in terms of difficulty - they each have different downsides. I'm a lot more familiar with the iPhone, so Android development goes a bit slower, but I suspect with similar amounts of experience there shouldn't be a significant difference in development time.

Re: Android vs iOS: A Developer's Perspective

#13

Post by jamesg »

Locke1689 wrote: post #10
ericd wrote: post #6

The shoddy state of the simulator really irks me on Android - it's really necessary that it works well, because there are so many different models of phone. The Android version of my app apparently has a crash-on-startup bug on a single type of Android phone (Droid X), shows up as windowed in others, and works just great on the Nexus/Droid I've tried it on. I can't test on all that physical hardware, though, and the…

I actually have a pretty massive patch for QEMU sitting in a computer somewhere (with a pretty massive bug) so I know QEMU pretty well. QEMU is actually very fast if used correctly. Android is not using QEMU correctly. I'm not really sure what they're doing wrong but if I can virtualize a VMM which then virtualizes another OS and the interaction is essentially real-time, basic ARM and Java should not be out of the pe…

QEMU is a truly awesome piece of code. Everything Fabrice Bellard does is incredible.

You could well be right that they're not using it correctly -- that sounds entirely plausible. I guess my point was more that, whatever the cause, the net effect of it is that the Apple Simulator is unrealistically fast, and the Android Emulator is unrealistically slow. Neither really encourage great development if you rely on them.

Re: Android vs iOS: A Developer's Perspective

#14

Post by pkaler »

mickdj wrote: post #9
archgrove wrote: post #5

I totally agree with some of the points: iOS should really receive the same garbage collector that OS X has had for years, and the provisioning certificate nonsense is, well, nonsense. iOS really does need a side loading mechanism. That you need a Mac to develop on is, I suppose, a negative - you can get going with Android on almost anything. However, I can't say I've ever had any problem with Apple's documentation:…

Clarification: We don't use any private API's on iOS, James' comments were with respect to what we do with location and networking. Apple's documentation is great for most visual elements, but CLLocation* in particular has quite flawed documentation.

Where are the flaws in CoreLocation or the documentation? CLLocationManager is instantiated like any other NSObject. CLLocationManagerDelegate returns asynchronous results like any other protocol in Cocoa/CocoaTouch. CLLocation, CLHeading, CLRegion are about as close as you're going to get to get to C-style POD structs in Objective-C.

The documentation is all here and the API is about straight forward as it is going to get. http://developer.apple.com/library/ios/#documentation/CoreLo...

Re: Android vs iOS: A Developer's Perspective

#15

Post by Locke1689 »

jamesg wrote: post #13
Locke1689 wrote: post #10

Earlier quoted context omitted.

I actually have a pretty massive patch for QEMU sitting in a computer somewhere (with a pretty massive bug) so I know QEMU pretty well. QEMU is actually very fast if used correctly. Android is not using QEMU correctly. I'm not really sure what they're doing wrong but if I can virtualize a VMM which then virtualizes another OS and the interaction is essentially real-time, basic ARM and Java should not be out of the pe…

QEMU is a truly awesome piece of code. Everything Fabrice Bellard does is incredible. You could well be right that they're not using it correctly -- that sounds entirely plausible. I guess my point was more that, whatever the cause, the net effect of it is that the Apple Simulator is unrealistically fast, and the Android Emulator is unrealistically slow. Neither really encourage great development if you rely on them.

Agreed -- I just wanted to defend QEMU (and my own work, by extension) for a moment.

Also, code can always be made to go slower so I'm not sure if "unrealistically fast" is as bad a "unrealistically slow."

Re: Android vs iOS: A Developer's Perspective

#16

Post by kbutler »

Locke1689 wrote: post #10
ericd wrote: post #6

The shoddy state of the simulator really irks me on Android - it's really necessary that it works well, because there are so many different models of phone. The Android version of my app apparently has a crash-on-startup bug on a single type of Android phone (Droid X), shows up as windowed in others, and works just great on the Nexus/Droid I've tried it on. I can't test on all that physical hardware, though, and the…

I actually have a pretty massive patch for QEMU sitting in a computer somewhere (with a pretty massive bug) so I know QEMU pretty well. QEMU is actually very fast if used correctly. Android is not using QEMU correctly. I'm not really sure what they're doing wrong but if I can virtualize a VMM which then virtualizes another OS and the interaction is essentially real-time, basic ARM and Java should not be out of the pe…

It's actually much easier to "virtualize another OS" than to virtualize a hardware platform (and associated OS).

If you are running guest code that matches your host architecture, QEMU can run the code natively. If you are running foreign code (e.g., ARM on an Intel host), it has to dynamically recompile the code, which will hurt performance.

kb

Re: Android vs iOS: A Developer's Perspective

#17

Post by kellysutton »

ericd wrote: post #6

The shoddy state of the simulator really irks me on Android - it's really necessary that it works well, because there are so many different models of phone. The Android version of my app apparently has a crash-on-startup bug on a single type of Android phone (Droid X), shows up as windowed in others, and works just great on the Nexus/Droid I've tried it on. I can't test on all that physical hardware, though, and the…

I can second this one thousand times. I developed the blip.tv Android app. It runs well on the Samsung Galaxy S phones, but crashes on startup on _all_ other Android devices. No clue why.

Re: Android vs iOS: A Developer's Perspective

#18

Post by rgbrgb »

archgrove wrote: post #5

I totally agree with some of the points: iOS should really receive the same garbage collector that OS X has had for years, and the provisioning certificate nonsense is, well, nonsense. iOS really does need a side loading mechanism. That you need a Mac to develop on is, I suppose, a negative - you can get going with Android on almost anything. However, I can't say I've ever had any problem with Apple's documentation:…

Agreed. I had the exact opposite reaction when I started doing some Android dev after coming from iPhone.

I find Xcode to be at least 80,000 times better than Eclipse (memory usage, UI, interface builder, speed, general bugginess).

I also REALLY like Apple's docs and the ease of integrating C code (no NDK!) when you need to do something like real-time audio.

My only really big complaint is the certificate signing process which can be a real pain.

I mean, I can totally see why Android might feel better or more familiar to a Java programmer though.

Re: Android vs iOS: A Developer's Perspective

#19

Post by mickdj »

pkaler wrote: post #14
mickdj wrote: post #9

Earlier quoted context omitted.

Clarification: We don't use any private API's on iOS, James' comments were with respect to what we do with location and networking. Apple's documentation is great for most visual elements, but CLLocation* in particular has quite flawed documentation.

Where are the flaws in CoreLocation or the documentation? CLLocationManager is instantiated like any other NSObject. CLLocationManagerDelegate returns asynchronous results like any other protocol in Cocoa/CocoaTouch. CLLocation, CLHeading, CLRegion are about as close as you're going to get to get to C-style POD structs in Objective-C. The documentation is all here and the API is about straight forward as it is going…

I don't want to veer O/T, but that's not the hard stuff in CLLocation.

There's a lot that could be discussed, but as one example: optimizing for battery conservation requires knowing which radios are currently powered up.

iOS makes its own decision as to which of the 3 styles of location service to engage, based on the desiredAccuracy and distanceFilter values.

However the WiFi/GPS radio have different costs for runtime and warmup, so this API doesn't help when you are attempting to optimize for all 3 of: Accuracy, Timeliness, Battery conservation

Furthermore, the accessible battery percentage in UIDevice.batteryLevel is only reported to the nearest 5%, which is not granular enough to be of use in real-time server-based tweaking.

Re: Android vs iOS: A Developer's Perspective

#20

Post by jamesg »

rgbrgb wrote: post #18
archgrove wrote: post #5

I totally agree with some of the points: iOS should really receive the same garbage collector that OS X has had for years, and the provisioning certificate nonsense is, well, nonsense. iOS really does need a side loading mechanism. That you need a Mac to develop on is, I suppose, a negative - you can get going with Android on almost anything. However, I can't say I've ever had any problem with Apple's documentation:…

Agreed. I had the exact opposite reaction when I started doing some Android dev after coming from iPhone. I find Xcode to be at least 80,000 times better than Eclipse (memory usage, UI, interface builder, speed, general bugginess). I also REALLY like Apple's docs and the ease of integrating C code (no NDK!) when you need to do something like real-time audio. My only really big complaint is the certificate signing pro…

I'll make just one refutation to this: I am not a Java programmer :)

I had to learn Java specifically for this project. Python is my preferred hammer for most nails, but not an option on mobile. I've also been a professional C programmer before, wreaking havoc in the kernel. I've got opinions on Objective-C, but that's a subject that deserves a whole separate post.

Post reply on HN