
IPhone Development: Android SDK from an iPhone Developer's Perspective - pauljonas
http://iphonedevelopment.blogspot.com/2010/03/android-sdk-from-iphone-developer.html
======
ajross
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.

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

~~~
orangecat
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.

------
martythemaniak
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 do in his example, I would do exactly that
- create the views I want/need, throw them in a list, then rotate/display them
in whatever order I needed.

Personally, I cannot get excited about iPhone development. While the UI
Builder truly is top notch, the whole thing seems geared towards building
great UIs to so people can consume content in a mobile-friendly way. Android
OTOH, while limited in UI, gives you the freedom to make whatever you want.
Sadly, the author hasn't discovered that and makes absolutely no mention of
things like Services, BroadcastReceivers or the other ways you can hook into
the system.

People may say that doesn't matter, but that's because they can't miss
something they've never had. My Android app is one of the top ones in it's
category and has no equivalent on the iPhone because it can't be written for
non-jailbroken ones. The one I am currently working also cannot be written for
the iPhone (whether it will be popular remains to be seen. Mostly, I just want
to finish it and use it myself)

~~~
joezydeco
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

~~~
glhaynes
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.

~~~
joezydeco
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.

~~~
glhaynes
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."

~~~
joezydeco
I certainly wouldn't embark on a long-term OSX/iPhone project without
mastering IB.

It's obvious that your UI is easier to modify and update using IB than hacking
it in and out of the view controller code.

Back to the original thread, I do give a little credit to Android to having
the option of UI editing done inside of Eclipse. It's not perfect, it's a
little hacky, but the concept of slapping down a UI element like a button,
naming it, and then having it automatically compile and show up in the editor
autocomplete is a powerful thing. The first time it happened it honestly was a
nice surprise.

------
gte910h
As a guy who runs an embedded development company, I have to say, Android is
pretty costly to do compared to the iPhone OS for any given amount of
functionality.

Like usual, the Java everywhere approach of it makes it pretty painful when
you have a config file error, as a full 1/3 of those are not really validated
with something that will tell you that you made an error.

The business case of "No reviewers" makes it a more predictable platform by
leaps and bounds over the iphone though. Having done multiple month projects
which apple than sat on for 7 weeks without approving or rejecting after
months of being "suggested" to add expensive features (such as in app
purchases), I can completely see it being better for companies doing
"questionable" things (for apple's overly controlling view of questionable),
but otherwise, it's a PAINFUL market, as even if you're the only person in a
space, there is likely a guy writing an open source version of your app which
he'll then release for free.

What I'd REALLY like to see is someone make a app layer that runs on top of
the formal API what was about 2x more consistent and 4x less "javay" in both
graphical layout and the amount of hand edited XML files you have to do. I'm
thinking about trying <http://phonegap.com/> and the
<http://code.google.com/p/android-scripting/> to see if they're better
alternatives than pure java for customers looking for android solutions.

Then again, android is _more powerful_ than the sandboxed version of the Apple
API that they let you use, but that power comes at a cost of a _great_
increase in complexity.

~~~
theBobMcCormick
Last I checked, PhoneGap apps don't use native OS controls, so your app never
quite looks right. Android scripting is fun to play with, but from what I can
tell it's a _looooooong_ way from something you could release an app with.
Appcelerator Titanium looks quite promising though.

------
glenra
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 easy, and the DRM is an absolute
nightmare, often preventing a project that worked yesterday from downloading
to the phone today for reasons that are mysterious and inexplicable even when
surrounded by official iPhone gurus willing to poke at it. ("try reinstalling
your provisioning certificates" is for iPhone developers what "try rebooting"
used to be for Windows users.)

So maybe Android would be just my thing.

Is it possible that having programmed for the Newton using Newton
Toolkit/NewtonScript spoils you for all other mobile development environments?

~~~
bensummers
I've just spent a couple of weeks putting together a simple iPhone app. While
I have the benefit of having written some Cocoa apps in the past, I really
didn't find it the nightmare that you described.

Of course, the DRM and signing up for the developer program is a complete
pain, but waiting and following instructions means it's only a minor
hindrance. Even if it's a big philosophical discomfort with the platform.

Maybe I need to work longer at it to discover all the pitfalls?

~~~
glenra
Having written Cocoa apps in the past probably makes a huge difference. They
did make the DRM work somewhat better later - I actually started _trying_ to
develop the instant they made the SDK available so initially I was one of a
huge number of people complaining about cryptic error messages and complex
instructions that didn't work at all. They later replaced it with messages
that were _sometimes_ helpful and instructions that _sometimes_ worked.

I tend to have a "knack" for breaking software - which is why I've done QA for
a lot of my career. It's clear there exist people who got the iPhone DRM to
work once and it just _kept working_ after that; I don't know how they managed
it or what if anything I did differently. As a workaround, I eventually got in
the habit of treating the iPhone SDK much the way people used to treat word
processors back in the day. That is: save often and make frequent backup
copies of the whole project. When your project stops working for some
mysterious reason, go back to the previous version that did work. In short, I
applied "cargo cult" programming techniques.

I did ultimately manage to put an app in the iPhone store but that experience
soured me on further iPhone development. Though I might try using Corona
sometime.

~~~
bensummers
That makes sense, a year or so of progress makes all the difference to a
development environment. And yes, knowing a bit of desktop Cocoa makes it much
easier to get into, but I didn't have much of a problem learning Cocoa once I
found Hillegass' book.

Corona looks interesting. I could make fun of the spelling mistake on their
home page though.

------
madpickle
Having developed multiple multi-threaded, sensor-, service-, and multimedia-
based Android applications, I think he is mostly right when he writes, "I
don't think you'll ever see the groundswell the way you have with the iPhone
SDK where people from all walks of life with no programming experience
developed a desire to learn to write software, but I do think that there will
eventually be a good market for Android apps and, therefore, for Android
developers."

I would be very hesitant to use a mobile platform that allowed neither
background services nor mounting as a drive (w/o risk of bricking the device).
Not to mention one that is closed source. But then my apps are targeted at
R&D, not mass market. For mass market apps, the iPhone probably has the
advantage.

------
technomancy
> Let me also put my biases right out front: I don't like Java.

You don't need to write Java to write Android apps.

~~~
theBobMcCormick
The only alternatives I've seen that look like they might be _potentially_
production ready are PhoneGap and Appcelerator Titanium. (both use
JavaScript). If you've found others I'd love hear about it. I like the Android
framework a _lot_ but I too am not a big fan of Java.

~~~
warfangle
As Scala compiles down to JVM bytecode, it's available for Android
development:

[http://www.ibm.com/developerworks/opensource/library/os-
ecli...](http://www.ibm.com/developerworks/opensource/library/os-eclipse-
scala/index.html?ca=dgr-lnxw07Android-
Scaladth-o&S_TACT=105AGX59&S_CMP=grlnxw07)

~~~
theBobMcCormick
Interesting! Thanks for the link! I'm gonna put that in my "must read more
about" list!

------
joecode
_It's like working with the evil offspring of GridBagLayout and XML_

That one had me laughing out loud. Ah.. Good ol' Java, I remember you. Anyway,
as an iPhone dev looking to branch out into Android, I found this piece
immensely useful, though I'm sure mileage may vary.

~~~
redcap
I really hate Java UI development so I'd love to know just how predominant
having do deal with shit like GridBag is in Android.

The author puts the case that doing interfaces in iPhone is easier, does
anyone else have anything to share on the matter?

------
pkulak
I'd love to also hear a comparison with WebOS. From what I can tell by a
cursory glance, that's a dream environment to develop for. Of course, Palm has
to put it on something with decent hardware...

------
starnix17
Heads up, if you're looking to try Android development on OS X, once you learn
the basics drop Eclipse and just use this TextMate bundle:
<http://www.onebitwonder.com/projects/android>

The only good thing about Eclipse (IMO) is the in-line error handling,
otherwise it's just overly bloated, slow, and clunky.

~~~
theBobMcCormick
That is one of the nice things about Android development. You dont' _need_ to
use Eclipse. I've done all my Android development so far with Emacs.

------
zyb09
meh ramblings.. Android's SDK uses Eclipse and I hate Eclipse with a passion,
therefore iPhone is better.

What kinda nonsense is that? I like your OpenGL Tutorials A LOT, but can't
take you seriously on that one.

------
michaelneale
I got the impression that they liked/used the Interface Builder on the iphone
SDK (the comment on the easy of making things pretty) - if that is the case
that is telling. I do no iphone dev, but I have some close friends who are
prolific and successful iphone devs, and they take a dim view of anyone who
thinks it is more than a toy (of course, maybe something else was meant? I
dunno - but yeah, GridBag+XML sounds horrid doesn't it).

I guess things like Charles Nutter's duby language (and other alternative JVM
langs) can really make a much more pleasant experience.

