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

51–60 of 85 posts

Re: Android vs iOS: A Developer's Perspective

#51

Post by pkulak »

I think it's easier to do simple things on iOS and easier to do complex things on Android. I built a simple iOS app a while ago and was amazed at how easy it was. I didn't customize a thing and kept it all looking exactly how the built in libraries made it look. It was just a matter of throwing some things into interface builder and wiring them up. Then I wanted to do the same thing in Android and was immediately baffled by this crazy HTML-like language that would never work quite right and was horribly verbose.

Now, however, my company is developing an iOS app, and we're following screens given to us by a designer. I think I wouldn't mind that layout language now...

Re: Android vs iOS: A Developer's Perspective

#53

Post by binaryfinery »

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…

I've written memory managers used in console games for the N64 (4Mb), PS2 (32Mb) and a complete memory tracking system for Unreal Engine 3 on XBox360 (OMG 512Mb).

I use MonoTouch for iOS development. Why? Because I can build complex object graphs without having to maintain, in my head or in external documentation, the acyclic version of the graph. In a GC language I can create graphs that are happily cyclic, and have every reason to be, and yet have them deallocated when the application nulls the last reference.

In a reference counted system that desires cyclic pointers, one or more of those pointers have to be chosen as non-reference-incrementing pointers - and likewise one must remember not to release them either.

Memory management in Objective-C (without GC) is no effort provided one is making applications with simple object interactions, such as the plethora of tree-based hierarchies. Reference counting is great for that.

So it could be that the OP is lazy, or it could be that they have experience with problems that you do not. If you believe that OP actually requires a lesson on the basic rules of reference counted memory management (since thats what you provided) then I suggest that you are underestimating the experience of your detractors, which in turn leads me to believe that you are overestimating yours.

Re: Android vs iOS: A Developer's Perspective

#54

Post by varikin »

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…

Memory management is Obj-C has issues. The documentation is spotty at explaining how to property handle it, or maybe it is an issue with the organization of the documentation cause I can't always find what I need, but I know it is there. When I started, I keep hearing the general rule of thumb, "if you don't alloc/init it, you don't need to release it." Except no one mentioned you have release properties. I never alloc/init them. Along with that, difference between an ivar and property is poorly documented. The fact that "aField = x" is different than "self.aField = x" and can mess up memory management was lost on me.

My problem with the documentation, as I said before is mostly organization. Along with that, some of these concepts are defined in ways that only make sense if you already know the language and framework.

After a couple projects and code reviews, I think I understand it now. It is not that we are lazy for not understanding or liking it; it is that it isn't intuitive or simple like GC.

Re: Android vs iOS: A Developer's Perspective

#55

Post by binaryfinery »

I have to say that developing on Android after having worked on iPhone is a bit like waking up from a vivid nightmare

Can I plug MonoTouch here then? I just ported a native app to MT. It is approx two seconds slower to load - which I do think is a big deal - but the productivity benefits ( = new features) vastly outweighs that drawback.

Re: Android vs iOS: A Developer's Perspective

#56

Post by tres »

chc wrote: post #25
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…

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

I don't disagree with the premise that memory management requires more work; however, the tools and utilities that Apple now provides to hunt down memory issues makes it more tedious than difficult.

Re: Android vs iOS: A Developer's Perspective

#57

Post by CountSessine »

metachor wrote: post #34
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…

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.

I wish I could vote you up more than once. Not using all-in-one layout in XCode is Considered Harmful. This is even more important than binding Open Quickly to CMD-O or some other quick key shortcut.

Re: Android vs iOS: A Developer's Perspective

#58

Post by jamesg »

binaryfinery wrote: post #53
jawngee wrote: post #45

Earlier quoted context omitted.

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…

I've written memory managers used in console games for the N64 (4Mb), PS2 (32Mb) and a complete memory tracking system for Unreal Engine 3 on XBox360 (OMG 512Mb). I use MonoTouch for iOS development. Why? Because I can build complex object graphs without having to maintain, in my head or in external documentation, the acyclic version of the graph. In a GC language I can create graphs that are happily cyclic, and have…

This is very well put. Much more insightful than my glib comments below. Thanks dude!

Re: Android vs iOS: A Developer's Perspective

#59

Post by jinushaun »

makeramen wrote: post #4

I 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).

I can't be the only one that hates Android's documentation. It's nothing more than a list of methods and properties. Thanks for nothing, Google, I can use Eclipse's code completion for that. The Android docs have never helped me once. I've always had to rely on web searches when seeking help.

The iOS docs, on the other hand, is rich and full of example code, example usage and programming guides. There's a lot of hand holding, which is great. Android's SDK is definitely simpler and makes more sense than the iOS SDK "out of the box", but I feel like Apple provides enough documentation on important classes like UITableView and UINavigationController.

However, iOS is strongly MVC, so I can understand how a newbie can feel a little lost with all the ViewControllers and various project templates. (Which one do I use? How do I use Navigation Controllers without starting a Navigation Controller project template? Etc...) A "Hello world" example in iOS creates a lot more files than an Android one.

Re: Android vs iOS: A Developer's Perspective

#60

Post by HectorRamos »

varikin wrote: post #54
jawngee wrote: post #45

Earlier quoted context omitted.

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…

Memory management is Obj-C has issues. The documentation is spotty at explaining how to property handle it, or maybe it is an issue with the organization of the documentation cause I can't always find what I need, but I know it is there. When I started, I keep hearing the general rule of thumb, "if you don't alloc/init it, you don't need to release it." Except no one mentioned you have release properties. I never all…

If your property is defined as retain in your header, you are claiming ownership for it and so it needs to be released in your dealloc method.

This is covered in the basic Memory Management doc http://developer.apple.com/library/mac/#documentation/Cocoa/...

Post reply on HN