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

41–50 of 85 posts

Re: Android vs iOS: A Developer's Perspective

#41

Post by jamesg »

pkaler wrote: post #33
mickdj wrote: post #19

Earlier quoted context omitted.

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 runt…

There's a lot that could be discussed... There isn't a whole lot to be discussed. iOS minimizes battery usage based on how close cell towers are, type of cell tower, altitude, Wifi spots database, state of GPS almanac, hardware/driver combination, etc like a any good OS/kernel (including Android) should. The App sets CLLocationAccuracy to kCLLocationAccuracyBest, kCLLocationAccuracyNearestTenMeters, kCLLocationAccura…

So, I will say that I bundled documentation and "openness" into one box, which I probably shouldn't have. The connection is that absented of the "openness" we were really looking for, we sought documentation to describe what's going on. That said...

CoreLocation is a good abstraction. However, its primitives for specifying what trade-offs you are willing to make in acquiring a location are, well, primitive.

A couple of random examples:

- CoreLocation doesn't tell you the source of the location sample (GPS, WiFi, etc). It gives you an estimate of accuracy. Of note, it doesn't give you a measure of the accuracy of the accuracy. This is of import as we have seen examples where the data is off by a whole hemisphere -- I'm not kidding! I understand that exposing these details is kind of "ugly", but obscuring it is removing signals that we could use to figure out the reliability of the data, and what techniques we might be able to use to "clean" the data. I am willing to concede that CL is a good API for general use, but when you're building consumer products, that doesn't cut it. The guy in New York who was reported as being in Antarctica (again, seriously), doesn't really care that the iPhone doesn't provide us the tools to fix that, he just wants it to work (and he's no longer a user).

- Related to the first point, but separate: the implementation of the algorithm for seeking to the desired accuracy is a black box. This makes it really easy to use for basic stuff, but you really don't have any way of knowing the result, in milliwatts, of passing in a given value to that argument. There are ways to mitigate this (which we've had to explore), and we can experiment to learn what the drain is, approximately, but hiding that information has obstructed our development process. Consider also that CL doesn't allow me to specify how long I am willing to wait to get the location fix at the desired accuracy. It does not let me set a budget in milliwatts for a location fix. I realise that Android doesn't provide those exact abstractions, but the tools it does provide make it easier (by which I mean "possible") for me to build them myself.

I also don't think you've successfully made the argument that the OS will know better than us. It's a generic tool, which makes some assumptions. It will have made compromises that don't necessarily work for us. It will not perform optimally for every use case. Going back to something I said before, it seems to optimise for getting to the desired accuracy quickly. For background location tracking apps like ours, that is not a priority. Power is. Neither CoreLocation's abstraction nor documentation provide for this use-case.

Re: Android vs iOS: A Developer's Perspective

#42

Post by statictype »

jawngee wrote: post #38
orangecat wrote: post #35

Earlier quoted context omitted.

And don't get me started on those lazy kids and their assemblers. I mean, how hard is it to remember a few dozen opcode hex values? Less snarkily: Developer resources are not infinite. Time spent futzing with memory management in non-performance-critical areas is time not spent improving performance where it actually matters, adding features, or improving the user interface. For example, Angry Birds on the Galaxy Tab…

I wasn't talking about the Nexus One, I was talking about the iPad vs the Galaxy Tab. And I didn't say that GC was what was slowing down Angry Birds, I was talking about subjective relative performance between Android and iOS. The point of my criticism is that memory management in objective-c doesn't take any extra time beyond overloading dealloc and writing a few more retains and releases for 90% of all cases. It's…

memory management in objective-c doesn't take any extra time beyond overloading dealloc and writing a few more retains and releases for 90% of all cases

It's the other 10% where the memory leaks that bring down your app come from.

Re: Android vs iOS: A Developer's Perspective

#43

Post by HectorRamos »

orangecat wrote: post #35
jawngee wrote: post #29

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 p…

And don't get me started on those lazy kids and their assemblers. I mean, how hard is it to remember a few dozen opcode hex values? Less snarkily: Developer resources are not infinite. Time spent futzing with memory management in non-performance-critical areas is time not spent improving performance where it actually matters, adding features, or improving the user interface. For example, Angry Birds on the Galaxy Tab…

This isn't rocket science. The linked document takes all of 10 minutes to read and understand. If that is not enough, there are three years worth of WWDC sessions on memory management available on iTunes U (this year's are even free!). It's something as basic as learning a new language's if/else structure.

For reference, I'm a five year Java dev who has now been doing iOS dev for two years, and had no problem switching from GC to manual memory management.

Re: Android vs iOS: A Developer's Perspective

#44

Post by rquesada »

One point that the article doesn't mention is the iPhone Simulator, is a simulator: it simulates the iPhone environment.

Simulators have both good and not so good points. On the one hand they are pretty fast, since they use "host" code and "host" APIs. On the other hand, since they use "host" API, you can't rely 100% on them.

For example, the iPhone Simulator simulates the iOS OpenGL ES API using Mac OpenGL API. While developing cocos2d for iPhone I found many differences between the Simulator and the Device. But in spite of that, I still suggest developing mostly everything on the Simulator, and every now and then to try the app on the device both to test the performance and "reality".

Re: Android vs iOS: A Developer's Perspective

#45

Post by jawngee »

orangecat wrote: post #35
jawngee wrote: post #29

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 p…

And don't get me started on those lazy kids and their assemblers. I mean, how hard is it to remember a few dozen opcode hex values? Less snarkily: Developer resources are not infinite. Time spent futzing with memory management in non-performance-critical areas is time not spent improving performance where it actually matters, adding features, or improving the user interface. For example, Angry Birds on the Galaxy Tab…

How is the most ignorant comment in this thread voted up?

First of all, he offers no evidence that memory management in objective-c is resource or effort intensive. He can't, because it's not. This is not hard:

    -(id)initWithSomeNumber:(NSNumber *)aNumber {
        ...
        someField=[[SomeObject alloc] init];
        someOtherField=[aNumber copy];  // or retain, your call.
        ...
    }

    -(void)dealloc {
        [someField release];
        [someOtherField release];
        [super dealloc];
    }
How is that hard exactly? There are only 4 rules you need to follow for memory management in Objective-C/Cocoa/CocoaTouch:

* If you use a convenience method, eg [NSString stringWithFormat:...] you don't own it, so don't release it.

* If you use alloc, copy or new, you own it, so release it.

* Implement dealloc to release fields you own.

* Never invoke dealloc directly.

I mean you can be as snarky as you want dude, I write Cocoa apps all day long (as well as web apps and mobile apps) and I can tell you and the original poster, are either idiots or lazy. I'm going to go with lazy.

Re: Android vs iOS: A Developer's Perspective

#46

Post by frio »

raquo wrote: post #37
BenoitEssiambre wrote: post #31

Earlier quoted context omitted.

I have a question. I asked this to a few mac users and haven't received a good answer. How the hell do you get xcode (or other programs, but xcode is particularly bad) not to end up being a big piles of small windows you can't access effectively because they don't have a dock icon? The only way I found, was to long-click on the xcode dock icon which after a while splatters small versions of the windows everywhere, th…

Well, there's Cmd + ~ hotkey for switching windows of active apps in 10.6, and it can be added using some small app in 10.5

It existed off the bat in 10.5 :).

Re: Android vs iOS: A Developer's Perspective

#47

Post by jamesg »

jawngee wrote: post #45
orangecat wrote: post #35

Earlier quoted context omitted.

And don't get me started on those lazy kids and their assemblers. I mean, how hard is it to remember a few dozen opcode hex values? Less snarkily: Developer resources are not infinite. Time spent futzing with memory management in non-performance-critical areas is time not spent improving performance where it actually matters, adding features, or improving the user interface. For example, Angry Birds on the Galaxy Tab…

How is the most ignorant comment in this thread voted up? First of all, he offers no evidence that memory management in objective-c is resource or effort intensive. He can't, because it's not. This is not hard: -(id)initWithSomeNumber:(NSNumber *)aNumber { ... someField=[[SomeObject alloc] init]; someOtherField=[aNumber copy]; // or retain, your call. ... } -(void)dealloc { [someField release]; [someOtherField releas…

It's totally about laziness! But that's what computers are all about -- I could store printed versions of all of my documents in a filing cabinet, and go and manually sort them every time I needed a different ordering, but I'm lazy! I use a database!

I just don't see why laziness should be restricted to users. Developers are lazy too.

You're right that there are only 4 rules (or more or less depending on your formulation), but I don't care. I'd rather take the time to have another martini. Or, y'know, implement features that make my users happy.

And it definitely gets harder when there are more moving parts. You're right that the rules are simple, but the execution of those rules gets more complex as you add more components, more threads, remoting, etc. I never said it was impossible, or up there with Fermat's Last Theorem or anything like that. Just that this is work the computer could be doing for me. I want to be lazy, but Apple won't let me.

Re: Android vs iOS: A Developer's Perspective

#48

Post by maxawaytoolong »

The provisioning in iOS is truly awful. However, in the XCode4 beta this has been greatly improved. You just click on a couple buttons within XCode itself, and everything gets automagically set up.

I've heard that it still causes problems if you're trying to clear out old profiles, but Apple seems to have been trying to provide a good fix to the worst part of iOS development.

Re: Android vs iOS: A Developer's Perspective

#49

Post by jcoby »

BenoitEssiambre wrote: post #40
jamesg wrote: post #32

Earlier quoted context omitted.

Don't know on the first one, but you can use ctrl + cursor keys to move between spaces. Fairly sure that's the default, but if not, it can be setup in preferences for Spaces.

It doesn't seem to be the default but I guess I can find out how to set it up. I still think you should get a mouse based one click interface though.

Ctl+1 through 9 switches spaces directly. If you enable the spaces menu bar in system preferences, you can click on the icon and choose which space to switch to (in snow leopard at least).

Re: Android vs iOS: A Developer's Perspective

#50

Post by losvedir »

BenoitEssiambre wrote: post #39
metachor wrote: post #34

Earlier quoted context omitted.

To use XCode in a single window, switch it to the All-in-One layout in the preferences: http://iphonedevelopment.blogspot.com/2009/03/xcode-single-w... Also, in any OS X application with multiple windows you can use Command-` (i.e. Command + backtick key) to switch between windows of the active application.

All-in-One is kinda nice. It seems it should be the default. It still doesn't make the documentation window of any use though. I guess it has a little less chance of being hidden under a pile of other windows now. Command+backtick doesn't seem to do anything on my mac.

Strange that Cmd-backtick doesn't work for you. Try this: Open up System Preferences, select "Keyboard", change to the "Keyboard Shortcuts" tab, and highlight "Keyboard & Text Input" on the left. Is the "Move focus to next window in application" box checked? What's its shortcut?

Also, long-clicking on the dock icon just activates Expose for Application Windows. I have it set-up to activate upon mousing to the top right corner and really like it. You don't have to wait for the delay of clicking and holding on the dock, though you'll still have to scan for the correct window.

Post reply on HN