Android vs iOS: A Developer's Perspective
whereoscope.wordpress.com
Android vs iOS: A Developer's Perspective
1–10 of 85 posts
Re: Android vs iOS: A Developer's Perspective
#2Stopped reading after the blatant display of apostrophe usage misunderstanding and unnecessary insertion of recent popular culture reference in the article. That is to say, after the first 3 words.
Re: Android vs iOS: A Developer's Perspective
#3Stopped reading after the blatant display of apostrophe usage misunderstanding and unnecessary insertion of recent popular culture reference in the article. That is to say, after the first 3 words.
I was tempted to, as well. But it’s at least a marginally interesting piece, summarizing ups and downs of developing for both platforms. (And I think he used the word “inception” literally.)
Re: Android vs iOS: A Developer's Perspective
#4I totally agree with his arguments. Learning Android development has been a breeze with the great documentation and ease of deployment developers. You just have to put up with all the other non-technical aspects of things (fragmentation, uglier UI, etc).
Re: Android vs iOS: A Developer's Perspective
#5I 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: It's clear, well written, generally entirely correct. I must confess, I've never spent "weeks devising and performing increasingly peculiar experiments to figure out how to get iOS to do what [I] want", any more than on any platform. If he's complaining that iOS has private APIs then, well, I'm quite sure Android does as well - private just means "not guaranteed to exist in the same form on an upcoming release". If he's claiming that Android's "openness" allows him to see deep inside the OS to make design decisions, rather than relying on the documentation, then I'd suggest that's a mad development strategy (unless one likes rewriting when new OS releases come out).
The point about the simulator seems to be that Android's is so bad, you have to use the phone. I can't really see that as a plus, as one could do exactly the same thing on iPhone, except that iOS has a working simulation environment for when you want it.
The remaining points, about the initial user experience and development environment are entirely subjective, so one can't really comment either way. His point that developing for Android seems to be "easier" than iPhone runs contrary to my experiences, but what one man finds easy, another might find hard.
Re: Android vs iOS: A Developer's Perspective
#6The 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 emulator is slow enough that it's nearly useless - various background services on the virtual machine complain about timing out when starting it up.
The fragmentation of that market doesn't seem worth dealing with for the amount of activity on the marketplace.
Re: Android vs iOS: A Developer's Perspective
#7An interesting perspective. It really seems like from the programmer's point of view, Android has found a nice sweet spot in productivity - a nice, comfortable, garbage collected but CPU-slow programming environment to do all of your 'OnClick' programming, and then the NDK and C/C++ for when CPU time matters.
iOS puts you in the C/C++/ObjC world for just about everything, unless you want to slog through Javascript. It's been rumoured that Apple is working on a version of MacRuby for iOS - this can't come fast enough.
Re: Android vs iOS: A Developer's Perspective
#8Stopped reading after the blatant display of apostrophe usage misunderstanding and unnecessary insertion of recent popular culture reference in the article. That is to say, after the first 3 words.
I was tempted to, as well. But it’s at least a marginally interesting piece, summarizing ups and downs of developing for both platforms. (And I think he used the word “inception” literally.)
The inception link was just a bit of fun :)
Thanks for your comments, and the typo in that first sentence was pretty bad. Sorry about that. I've ceded the grammatical highground for the foreseeable future with that gaffe.
Re: Android vs iOS: A Developer's Perspective
#9I 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.
Re: Android vs iOS: A Developer's Perspective
#10The 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 performance target.
P.S. If you think QEMU is slow, don't even think about Bochs.