7 ms·

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

49 points by pauljonas 17y ago

glenra 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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.
- elai 17y ago
  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.
pkulak 17y ago
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...
madpickle 17y ago
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.
gte910h 17y ago
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/ http://phonegap.com/ and the http://code.google.com/p/android-scripting/ 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 17y ago
  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.
martythemaniak 17y ago
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)
- pkulak 17y ago
  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.
  - nuclear_eclipse 17y ago
    Looking at his profile: http://phonalyzr.com/ http://phonalyzr.com/ For a few other examples of things you can't do on iPhone: http://www.twofortyfouram.com/product.html 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 http://slidescreenhome.com replaces the standard home screen with a completely different, and information-centric view. http://pandora.com 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.
ajross 17y ago
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 17y ago
  Is this an instance where it might be reasonable to create a 'powerful path' and a 'simple path' to support both needs?
  - orangecat 17y ago
    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.
- theBobMcCormick 17y ago
  Of course he thinks you don't need the extra power provided by intents. This is the same guy who thought it's a bad thing that the Nexus One has a better resolution than the iPhone. Unbiased he's not. It'll be interesting to see how he's gonna respond if the next gen iPhone has a higher resolution screen. :-)
technomancy 17y ago
> 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 17y ago
  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 17y ago
    As Scala compiles down to JVM bytecode, it's available for Android development: http://www.ibm.com/developerworks/opensource/library/os-eclipse-scala/index.html?ca=dgr-lnxw07Android-Scaladth-o&S_TACT=105AGX59&S_CMP=grlnxw07 http://www.ibm.com/developerworks/opensource/library/os-ecli...
    - theBobMcCormick 17y ago
      Interesting! Thanks for the link! I'm gonna put that in my "must read more about" list!
zyb09 17y ago
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.
starnix17 17y ago
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 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 17y ago
  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.
joecode 17y ago
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 17y ago
  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?
michaelneale 17y ago
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.

49 points by pauljonas 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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.
elai 17y ago
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.

pkulak 17y ago

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

madpickle 17y ago

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.

gte910h 17y ago

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/ http://phonegap.com/ and the http://code.google.com/p/android-scripting/ 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 17y ago
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.

martythemaniak 17y ago

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)

pkulak 17y ago
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.
- nuclear_eclipse 17y ago
  Looking at his profile: http://phonalyzr.com/ http://phonalyzr.com/ For a few other examples of things you can't do on iPhone: http://www.twofortyfouram.com/product.html 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 http://slidescreenhome.com replaces the standard home screen with a completely different, and information-centric view. http://pandora.com 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.

ajross 17y ago

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 17y ago
Is this an instance where it might be reasonable to create a 'powerful path' and a 'simple path' to support both needs?
- orangecat 17y ago
  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.
theBobMcCormick 17y ago
Of course he thinks you don't need the extra power provided by intents. This is the same guy who thought it's a bad thing that the Nexus One has a better resolution than the iPhone. Unbiased he's not. It'll be interesting to see how he's gonna respond if the next gen iPhone has a higher resolution screen. :-)

technomancy 17y ago

> 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 17y ago
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 17y ago
  As Scala compiles down to JVM bytecode, it's available for Android development: http://www.ibm.com/developerworks/opensource/library/os-eclipse-scala/index.html?ca=dgr-lnxw07Android-Scaladth-o&S_TACT=105AGX59&S_CMP=grlnxw07 http://www.ibm.com/developerworks/opensource/library/os-ecli...
  - theBobMcCormick 17y ago
    Interesting! Thanks for the link! I'm gonna put that in my "must read more about" list!

zyb09 17y ago

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.

starnix17 17y ago

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 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 17y ago
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.

joecode 17y ago

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 17y ago
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?

michaelneale 17y ago

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.