Android vs iOS: A Developer's Perspective • Hacker News Board

Re: Android vs iOS: A Developer's Perspective

#71

Post by mxcl » Wed, Dec 08, 2010, 10:36 AM UTC

BenoitEssiambre wrote: post #31

rgbrgb wrote: post #18

Earlier quoted context omitted.

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

Grab Xcode 4. It's still beta and buggy but it's all one window and is pretty good IMO.

There's keyboard shortcuts for spaces. And CMD` to switch between windows in apps.

OS X isn't perfect, I switched from KDE 5 years ago. Eventually you start noticing all the little touches that mean it is—really—light years ahead of Linux desktop options.

It does have a lot of little "Apple" touches though that you'll just have to take with a LOL.

Re: Android vs iOS: A Developer's Perspective

#72

Post by rmc » Wed, Dec 08, 2010, 11:02 AM UTC

Sounds like Google are trying the "Developers Developers Developers" stragegy from Microsoft.

Re: Android vs iOS: A Developer's Perspective

#73

Post by radishmouse » Wed, Dec 08, 2010, 11:57 AM UTC

BenoitEssiambre wrote: post #31

rgbrgb wrote: post #18

Earlier quoted context omitted.

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

I've got a few tips that might make your experience a little better. Option 3 below will be particularly helpful for accessing the documentation more easily.

Option 1: Re-map your Expose´ keys. I mouse (tablet, actually) right handed, so I use the following shortcuts that I can access them quickly with non-mouse hand:

F1 - All Applications

F2 - All Windows

F3 - Desktop

F4 - Spaces

This allows me to use Expose´/Spaces via keyboard in tandem with the mouse. While technically two steps, it feels more like a single, coordinated step to me.

I use XCode in the Condensed (not All-in-One) layout, which results in lots of small windows. I hit F2 (or F1 if I've secluded XCode to a single Space), then either:

- mouse over the various windows and press the space bar to see a zoomed-in view of that window. Then, click the one you want to bring into focus.

- press an arrow key to highlight a window, press space to see a zoomed-in view, press arrow keys as necessary, and then either press F2 again (or click the left mouse button) to exit Expose´.

Option 2: Press Cmd + Shift + D. This will bring up the "Open Quickly" dialog box. Start typing the name of the file you need to open or bring into focus.

Option 3: Use shortcuts to go immediately to the definition of a class/method/protocol/etc., toggle between .h/.m files, or open the documentation to whatever's under the mouse.

- Press Cmd key then double click a class name (or method name or whatever). This immediately opens a window to the definition.

- Press Cmd + Option + Up Arrow to toggle between .h and .m files for a class

- Press Option then double click a class/method/etc. name to open the documentation in a floating window.

- Press Cmd + Option then double click a class/method/etc. name to open the documentation in the XCode documentation window.

Mac OS X is littered with these kinds of accelerated interface shortcuts. I wish I could point you to a good, consolidated guide; but I have yet to find one on the web. Several of them can be found in the opening chapters of Aaron Hillegass' Cocoa programming books.

Re: Android vs iOS: A Developer's Perspective

#74

Post by Tichy » Wed, Dec 08, 2010, 12:53 PM UTC

"even now when I show Whereoscope on Android to iPhone users, I need to explain the basics of navigating an Android phone to them before they can use it."

I just can't let this stand. I have an iPod Touch and an Android, and I struggle a lot with the iPod Touch. Even making the MP3 player (iTunes?) do what I want is a challenge, and that is a native Apple app. I also had a lot of problems with iPad apps when I tried the iPad of a friend. The lack of a back button is a problem if the browser pushes you into some other app (YouTube or Maps), for example.

I could go on and claim that Android usability is so much better than iPhone (which I personally feel it is). But lets just assume that this guy is used to the iPhone and hence can cope with it better than with Android.

Also, if his users struggle with his app on Android, it is probably his fault. What is stopping him from giving it the same interface as the iPhone version? iPhone has one button, Android has 4. So it should be possible to use the same interface on Android, assigning one button to behave like the iPhone button.

Btw, you don't actually have to use Eclipse for Android development. You can do everything with the command line, and hence integrate the development environment (simulator, build script) into any editing environment you want. I am not sure if the same is possible for XCode, but I don't think it is. If XCode does Java, you could probably even use XCode for Android development.

Re: Android vs iOS: A Developer's Perspective

#75

Post by allenp » Wed, Dec 08, 2010, 1:09 PM UTC

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'll add this because it has happened to me - sometimes you're in all in one mode and you still don't see your code, just the file name that you selected at the top of the window - this is because there is a horizontal divider that is pulled all the way to the bottom of the window. Look for 1 little dot at the bottom of the window in the center, if you drag that up you'll be able to see your code again.

Re: Android vs iOS: A Developer's Perspective

#76

Post by SeanLuke » Wed, Dec 08, 2010, 1:32 PM UTC

rimantas wrote: post #69

chunkbot wrote: post #27

Earlier quoted context omitted.

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

How about compared to retain/release/autorelease?

?? I admit the last time I really coded in Obj-C was for NeXTSTEP. But back then init ultimately called malloc, and release ultimately called free. In any case, yes, a good GC can be faster as it takes advantage of cache effects.

Re: Android vs iOS: A Developer's Perspective

#77

Post by SeanLuke » Wed, Dec 08, 2010, 1:39 PM UTC

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 love Obj-C dearly. But Obj-C's reference counting scheme is, and always has been, much more cognitive load than a GC. In Java the above would be roughly:

    public myObject(Number aNumber) {
        someField = new SomeObject();
        someOtherField = aNumber;
        }

...and that's it. No dealloc, no forgetting to release, no forgetting to retain objects you hold onto, no trying to figure out how to handle cyclic references (or indeed if certain references are cyclic at all). Just set it and forget it.

Re: Android vs iOS: A Developer's Perspective

#78

Post by chunkbot » Wed, Dec 08, 2010, 3:50 PM UTC

rimantas wrote: post #69

chunkbot wrote: post #27

Earlier quoted context omitted.

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

How about compared to retain/release/autorelease?

I upvoted you, but I was mostly just quoting the jwz article from 1998.

Re: Android vs iOS: A Developer's Perspective

#79

Post by wankerrific » Wed, Dec 08, 2010, 5:13 PM UTC

mickdj wrote: post #19

pkaler wrote: post #14

Earlier quoted context omitted.

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

I'm not sure I agree with the blog post then. The Android docs certainly do not detail this kind of information either.

In fact, I've found the docs for Android to be of the "broad but shallow" variety. That is they cover everything (thanks to Javadoc) but they don't necessarily provide usage guides on the various APIs.

My opinion on Android development vs. iPhone is:

a. GC is convenient

b. The developer docs on Android are not nearly as good as Apple's

c. XCode (while not perfect) is less buggy than Eclipse for basic development activities. Eclipse just gets in the way most of the time and can't keep up with my typing speed which is really frustrating.

d. I like ObjC's dynamism a lot more than Java. This is a personal preference.

e. Its nice to be able to peer into the OS source on Android as the definitive answer for API questions but I suppose if the docs were better you wouldn't need to do that.

f. The Android APIs are full of pattern inconsistencies with their implementation on the whole compared to UIKit which make them more difficult to learn.

g. UI Layout on Android is abysmal compared to using Interface Builder.

i. Again - this is more of a Java thing, but Android lacks the ability to do conditional compilation. You have to go through build system/scripting gymnastics to get what you would get from a simple #IF statement in C.

Re: Android vs iOS: A Developer's Perspective

#80

Post by mblakele » Wed, Dec 08, 2010, 5:47 PM UTC

BenoitEssiambre wrote: post #31

rgbrgb wrote: post #18

Earlier quoted context omitted.

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

Another tip: ctrl-shift-d brings up the "File > Open Quickly" dialog, where you can type the name of a file into a filtered list (eclipse also has something like this). So instead of finding the right window, just bring up whatever file you need via the keyboard. I find this faster than using the mouse or cmd-`.

Another shortcut I used frequently is cmd-shift-e. This toggles "View > Zoom Editor" so that I can see more code.