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.
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. :-)
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.
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)
I'm right there with you in that minority. I think using previous Apple tools had led me to expect the interface should be "discoverable" and it wasn't. UIBuilder is, if anything, user-hostile. Plus the XCode integration is really poor.
The iPhoneRant blog reflected my experience pretty well with posts like this:
Quotes: "Programming the iPhone means managing a hodgepodge of view and view controllers and nav controllers and where the hell was I? It really doesn't allow your brain to just think about what the software is supposed to do. The fact that no one's come out with a good source to teach this stuff is very telling--it's unteachable. You have to slog through it, and when you get it to work, you're done. You can't necessarily explain how you got there or why it works. And it doesn't lend itself to being teachable, which is a good reason all the books on iPhone programming stink."
"The XCode environment is flaky and shit-filled. Little things add up, like the fact that you can't just select a file in the top frame and save it with command-S. No, you get a beep. Can't do that. You have to CLICK IN THE LOWER WINDOW, on the code, and then hit save. Because, otherwise you might save a few clicks and make things easy and intuitive."
I've actually got an App in the store. When I started I figured I'd do this silly little thing as a proof-of-concept and then go on to more ambitious ideas but I gave up because iPhone programming was just so unpleasant I couldn't bring myself to do it anymore.
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."
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
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...
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.
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.
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.