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

21–30 of 85 posts

Re: Android vs iOS: A Developer's Perspective

#21

Post by rbritton »

rimantas wrote: post #11
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…

If they do ever introduce it, I sincerely hope it is completely optional. On my iPad app, I run with such tight memory constraints while dealing with large image files that it has to be freed up when I tell it to or I'm likely to get killed by the memory watchdog.

Re: Android vs iOS: A Developer's Perspective

#22

Post by rbritton »

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…

The lack of a decent simulator also affects web apps. I downloaded the SDK and installed it in hopes of using it to test mobile versions of sites. It's rather difficult to test when it can take ten minutes to fully load and render a page!

Re: Android vs iOS: A Developer's Perspective

#23

Post by Locke1689 »

kbutler wrote: post #16
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…

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

Actually, my research was simulating a different hardware architecture and the patch I have is for hardware-assisted virtualization under arbitrary hardware architectures. It does have to recompile the code, but the TCG does a pretty good job of that. The virtualization target can do a lot better by keeping TCG in mind while structuring its binary execution, which may be one thing that they don't try to do in Android.

Re: Android vs iOS: A Developer's Perspective

#24

Post by protomyth »

rbritton wrote: post #21
rimantas wrote: post #11

Earlier quoted context omitted.

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…

If they do ever introduce it, I sincerely hope it is completely optional. On my iPad app, I run with such tight memory constraints while dealing with large image files that it has to be freed up when I tell it to or I'm likely to get killed by the memory watchdog.

I would expect it would be if they follow the pattern from OS X. I do wonder what the breakdown in new OS X apps between GC and retain/release.

Re: Android vs iOS: A Developer's Perspective

#25

Post by chc »

rimantas wrote: post #11
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…

Older iPhone models cannot run the current OS anyway.

And manual memory management is not a showstopper, but to say it's "not that complicated and does not add much overhead" is just wrong. It's conceptually simple, but the devil is in the details. I would bet that if you took a poll of all Cocoa programmers who have been working in the field since — well, pick any date you think qualifies as "out of the initial phase" — and ask them how many of their programs have done correct memory management without debugging, you will get an answer of 0.

Re: Android vs iOS: A Developer's Perspective

#27

Post by chunkbot »

rimantas wrote: post #11
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…

I treat memory as a resource too precious to be left to the mercy of programmers. In any application, a good garbage collector can be more efficient than malloc/free or new/delete.

http://www.jwz.org/doc/gc.html

Re: Android vs iOS: A Developer's Perspective

#28

Post by chunkbot »

rbritton wrote: post #21
rimantas wrote: post #11

Earlier quoted context omitted.

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…

If they do ever introduce it, I sincerely hope it is completely optional. On my iPad app, I run with such tight memory constraints while dealing with large image files that it has to be freed up when I tell it to or I'm likely to get killed by the memory watchdog.

The existence of a garbage collector doesn't mean that the programmer has to play a totally hands-off role in the allocation of objects; as with any coding, there are usually a few bottlenecks that deserve special care. A system with a good GC will provide opportunities to tune; for example, to make hints to the GC about lifetime and locality and so on.

http://www.jwz.org/doc/gc.html

Re: Android vs iOS: A Developer's Perspective

#29

Post by jawngee »

I'm stumped why memory management is so hard for developers, to the point I have to raise an eyebrow every time I read it. Are you seriously that lazy?

The docs about it are fairly straight forward:

http://developer.apple.com/library/mac/#documentation/Cocoa/...

Instruments makes it exceedingly simple to track down leaks.

While the iPhone 4 could probably handle a GC in most cases, the iPad less capable.

XCode is a personal preference.

I dunno, the time I've spent with Android, and A/B'ing respective apps, Android has almost always "felt" slower. I get that's totally subjective, but that's been my impression. For example, Angry Birds on the Galaxy Tab versus Angry Birds on the iPad are no where near the same experiences. The Galaxy Tab is jerky and slow, while the iPad is smooth.

I still don't get why memory management is so hard for you though.

Post reply on HN