Live data from Hacker News

IPhone Development: Android SDK from an iPhone Developer's Perspective

iphonedevelopment.blogspot.com

11–20 of 34 posts

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#11
FTA: Indeed. Intents are powerful. The problem is that they give you power that you don't need the vast majority of the time in the vast majority of applications.

This is silly, and tells me the author didn't think past the SDK. The Intent framework is what allows me to take a photo with the regular camera app (the one that pops up when I press the shutter button) and select "Facebook" from the "Share" menu. The Facebook app hooks up automatically. The iPhone app has to have its own "take photo" gadget, otherwise you end up having to browse through your photos trying to find the one you just took. This kind of integration is everywhere in Android.

That said, some of the other complaints are spot on. It's absolutely true that the amount of "dumb XML boilerplate" in Android is too high, and there are a bunch of tasks and states that can only be accessed through static configuration, and not managed dynamically by the app. Likewise the application lifecycle (which is inherently more complicated on Android because of the ability to run in the background) is more complicated than it needs to be, and frankly poorly documented. On the whole it's an OK framework; it's not great.

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#12

His example of how Android is worse than iPhone is quite inaccurate. Activities in Android do not correspond to UIViews in iPhone - they're supposed to be self-contained and somewhat independent units of execution (UI units in this case). The fact that Intents are so limited demands pretty loose coupling and makes developing larger applications easier (and your code more modular). If I wanted to do what he wants to d…

Maybe I'm in the minority, but I find UIBuilder to be awful. Unintuitive and almost impossible to grok without some prior experience or handholding. For my first "hello world" apps I wound up coding the views entirely by hand and skipping the .xib

I can understand this. Interface Builder is designed to transparently map to the underlying Cocoa calls. It doesn't introduce any new abstractions that aren't already present in Cocoa.

While this is a great feature for reasoning about your xibs, it can probably seem unnecessarily confusing to someone new to Cocoa.

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#13
post #9

His example of how Android is worse than iPhone is quite inaccurate. Activities in Android do not correspond to UIViews in iPhone - they're supposed to be self-contained and somewhat independent units of execution (UI units in this case). The fact that Intents are so limited demands pretty loose coupling and makes developing larger applications easier (and your code more modular). If I wanted to do what he wants to d…

What's the app of yours that can't be built on the iPhone? It would just be nice to know for an example of what you're talking about.

Looking at his profile: http://phonalyzr.com/

For a few other examples of things you can't do on iPhone:

http://www.twofortyfouram.com/product.html allows a background service to change phone settings dependent on conditions like your current location, time of day, or battery level.

http://slidescreenhome.com replaces the standard home screen with a completely different, and information-centric view.

http://pandora.com is the most obvious example, or any media player application far that matter, for when you want to listen to something other than your mp3 library while using your phone.

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#14
post #2

I haven't looked at Android yet but my experience with Objective C and the iPhone SDK is exactly the opposite of his - I found everything about iPhone development painful. As far as I could tell, Objective C does not work the way my brain does. The Interface Builder does not seem well integrated or make interface design "a joy" - it felt like more a hindrance than a help. The SDK does not make simple or common tasks…

Provisioning is annoying but once you get used to it and setup, it doesn't take that much time. Interface builder doesn't have obvious documentation at first, but once you get used to it it's very quick to work with.

I find the iphone sdk rather obtuse in working with arrays & dictionaries, slicing and dicing strings around and parsing XML with.

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#15
post #11

FTA: Indeed. Intents are powerful. The problem is that they give you power that you don't need the vast majority of the time in the vast majority of applications. This is silly, and tells me the author didn't think past the SDK. The Intent framework is what allows me to take a photo with the regular camera app (the one that pops up when I press the shutter button) and select "Facebook" from the "Share" menu. The Face…

Is this an instance where it might be reasonable to create a 'powerful path' and a 'simple path' to support both needs?

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#17

Earlier quoted context omitted.

Maybe I'm in the minority, but I find UIBuilder to be awful. Unintuitive and almost impossible to grok without some prior experience or handholding. For my first "hello world" apps I wound up coding the views entirely by hand and skipping the .xib

This is commonly said by people new to Interface Builder. I don't recall hearing of a long-time Apple / NeXT dev or major app that didn't use it, though.

So why hasn't IB gotten the same amount of improvements and attention as the rest of the toolchain? XCode has come a long way, as have the compilers and instruments.

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#19
post #15
post #11

FTA: Indeed. Intents are powerful. The problem is that they give you power that you don't need the vast majority of the time in the vast majority of applications. This is silly, and tells me the author didn't think past the SDK. The Intent framework is what allows me to take a photo with the regular camera app (the one that pops up when I press the shutter button) and select "Facebook" from the "Share" menu. The Face…

Is this an instance where it might be reasonable to create a 'powerful path' and a 'simple path' to support both needs?

Yes, and there's already a reasonably simple path. If you just want to switch to a new screen (say, an "about" view) and don't need to be notified when it exits, you just add the new Activity in AndroidManifest.xml, create a NewActivity class, and call "startActivity(new Intent(this, NewActivity.class))". The extra steps he describes are only relevant if you need to pass in additional data, or get a callback when it exits, and you'd need extra code to handle that for the iPhone as well.

Re: IPhone Development: Android SDK from an iPhone Developer's Perspective

#20

Earlier quoted context omitted.

This is commonly said by people new to Interface Builder. I don't recall hearing of a long-time Apple / NeXT dev or major app that didn't use it, though.

So why hasn't IB gotten the same amount of improvements and attention as the rest of the toolchain? XCode has come a long way, as have the compilers and instruments.

Oh I don't disagree with you that IB can be annoying, and to a part-time Mac programmer like myself, not as intuitive as I wish. I only meant that the full-timers generally seem to like IB (warts and all), or, even if they don't like it, they still nearly universally use it instead of doing all their layout in code.

The same scenario has repeated itself for many years: a newbie gets annoyed at IB and says "I'm just gonna do it all in code!" and all the graybeards say "ur doin it rong."

Post reply on HN