On Seven Inches

Tim Bray has a year-end blog post up that's worth a read. In case you don't know, Tim Bray is Google's Android Evangelist. As you might expect from someone who would take that job, he's as enthusiastic about the Android platform as I am about iOS. Although his perspective colors his view (as does mine), his analysis is usually pretty good.

He's got one assertion in this most recent post, however, that doesn't seem to ring true to my ear.

Apple will totally do a 7" device. Anyone who’s spent quality time reading books or playing games on the Galaxy Tab knows; there’s a great big hole in the ecosystem that needs something bigger than a handset but that still fits in one hand and you can use for four hours in a row sitting up. This argument is over.

John Gruber seems similarly skeptical, opining yesterday that:

The problem is that it’s nice, for certain tasks, to be able to hold a tablet in one hand, but you can’t do that with the current iPad. I think Bray’s mistake is assuming that using a 7-inch display is the only way to solve that problem.

The argument is far from over, and it's silly to even make the assertion. I have, within arm's reach, the very 7" tablet Tim refers to - a Samsung Galaxy Tab. I have spent quality time with the Tab, and think I definitely count as part of the set known as "anyone", yet I don't see this glaring hole that Tim thinks is so obvious. Personally, I found the Tab awkward for text reading, though part of that is due to Android's abysmal text rendering engine. The only way the Tab is better than the iPad for reading is that it's lighter and more portable. As for games, I'll admit that the Tab's form factor is pretty much ideal for driving games. All other types of games I've tried, it's either no better or worse than the iPad and, of course, there's no comparison in the selection of available games yet.

The Tab is a 16:9 tablet running Android 2.2. For watching 16:9 video content like movies and HD television shows, the end result is that you get roughly the same size image video as you do on the iPad in a package that's lighter and easier to hold, which sounds like a winner, right? There are downsides, however. The smaller form factor means less room for batteries and thus shorter battery life. The energy requirements for a 7" tablet are not considerably less than those of a 10" device, but there's a lot less room for batteries. As a result, while battery life is almost never an issue on my iPad, it's often one on the Tab. If you've seen the inside of an iPad, you know that most of the heft of the iPad comes from batteries. Apple made the design decision that they'd rather have a slightly heavier device that could run all day long on a single charge with normal usage. Based on sales and reviews, I think it's safe to say that was a good decision.

Batteries are getting more efficient every year, as are processors, so at some point, a 7" device with iPad-like battery life is completely feasible, however when that happens, a 10" device will have even better battery life. But battery life is far from the only downside to this form factor.

With the exception of video, some types of games (e.g. car driving games), and likely a handful of other tasks, the smaller form factor is simply not as good as the iPad for most things you'd want to do. It sits in an uncomfortable middle ground between phone-size devices and 10" tablets like the iPad and the… well, like the iPad. The Tab does nothing considerably better than either an iPhone or an iPad. It's "as good" at a handful of tasks.

What it boils down to is that the main advantage of the 7" form factor is that it's easier to carry around with you and is lighter to hold. I'm just unconvinced that's enough of a reason to make a 7" iPad inevitable.

Personally, If I were going to buy something to fit between my iPhone 4 and my iPad, I'd buy a Kindle, and recent sales numbers seem to indicate that many people are making that choice. The Kindle does less than the Tab, but it's even lighter and it does do something better than the iPad, iPhone, and Tab: it's a better ebook reader. It gets great battery life, it's easy on your eyes, has nice text, it's easy to carry, can be held comfortably in one hand, and it's much, much cheaper.

When Apple introduced the iPad, it looked like it was going to compete, and probably kill, the burgeoning ebook reader market. Instead, it pushed those special-purpose devices into a lower price bracket where they no longer compete directly with the iPad. Looking at how the sales numbers have jumped recently, the iPad may just be the best thing that ever happened to the Kindle. The Kindle and Nook are almost down into the "impulse buy" category, and as a result, they're selling like hotcakes, often to people who already own iPads.

But where does a seven inch tablet fit into the market? What would compel someone who owns an iPad to buy one, or would compel someone to buy one instead of an iPad? There isn't really a huge unmet demand for this product to fill. There's no pressing, burning need that would cause people to buy yet another device. A seven inch tablet has to compete with products that are already on the market and that are well-established. It can't compete with the Kindle on price, size, weight, or as an ebook reader. It's not noticeably cheaper than the iPad, yet has shorter batter life. It doesn't do anything that the iPad or iPhone can't. It's only compelling advantages are that it's lighter and smaller. Well, for a small segment of the market, it has another advantage: it's not from Apple.

The Galaxy Tab has been selling pretty well, but it's got novelty working for it, and it's really the only viable non-Apple tablet on the market right now. That will not be the case for long, however. The way the iPad has sold, you can expect every computer hardware manufacturer to try to claim a piece of the tablet market. Microsoft has already announced that, for them, CES would be about "slates" yet again this year (oh, boy!).

For seven inch tablets to gain traction in the long run, they will have to provide a compelling advantage over the iPad, the iPhone, and the Kindle. If they're not going to compete on price, maybe there's some feature or ability where seven inch tablets can distinguish themselves and establish a long-term foothold, but I haven't thought of it yet, and apparently neither have the current tablet manufacturers like Samsung.

The only way Apple will release a 7" tablet is if they think of some compelling reason for such a product to exist. It's possible that the reason would be price - making a more affordable and smaller iPad available to people who can't afford a $500+ device but want something bigger than an iPod touch. That's not impossible given Apple's drive for competitive pricing in their consumer products the last few years, but it's far from a foregone conclusion.

Experts == Idiots?

It's sad, really, the state of technology journalism. But you knew that, already. I should know to enough ignore link-baiting crappy journalism, especially those that do little more than republish some company's press release. Most days, I do.

Not today, though.

Computerworld posted an article with this headline today: Devs bet big on Android over Apple's iOS.

Wow, really? That seems surprising. What could possibly justify such a claim? Some proof that developers are leaving iOS in droves? Some new data about the Android Marketplace is actually making decent money for a substantial portion of Android developers? No, though it is encouraging to see that the Marketplace opened up to 13 new countries today. Still another 60 or so to go, but it's a step in the right direction. But that fact's not even mentioned in this article.

So what justifies such a grandiose claim? A survey of Appcelerator Titanium developers commissioned by Appcelerator. Now, if you don't know, Appcelerator Titanium is a cross-platform framework that allows you to develop an app once and generate applications for multiple paltforms: iOS, Android, Linux, Mac OS, and Windows.

Leaving aside my personal opinions about cross-platform tools, the article has already strayed from the headline. Devs? Well, sure, they're devs, but they're not representative of devs in general as the headline would imply. They're developers who have specifically chosen one option, and it's an option that doesn't tie them to a platform at all. We're talking about a group of people that have already shown their willingness to hedge their bets and who aren't about to take the risk of hitching their wagon to a single platform.

It's an inherently skewed sample. If you ran that same survey past 15,000 dedicated iOS developers, or dedicated Android or Blackberry or .Net developers, you'd get drastically different results.

In other words, this survey has no value whatsoever except to Accelerator. To them, it's perhaps useful for helping them decide where to devote their resources in the future to keep their clients happy.

But for the world at large? Worthless.

Oh, and what constitutes "betting big" in the context of the article? Well, it's not actually addressed, but their idea of "betting big" doesn't seem to match mine. There's nothing about investments, or exclusive agreements, or anything else that involves any sort of risk whatsoever. Developers were just asked things like "how interested are you in a platform X". The "betting" didn't involve monetary investments, or time investments. These developers did nothing more than state an opinion. An anonymous opinion. Oh… those crazy rebels.

Well, I'm "betting big" that the author of this post is a hack and his soi-disant "expert" is fucking clueless.

Let's face it, nobody knows for sure where the mobile market is headed, and being a Titanium Dev doesn't make your opinion any more informed or valuable than anyone else's. Personally, I suspect Android will continue to grow in market share unless Windows Phone 7 is better than great or else Microsoft manages to one-up Google's relationship with Verizon. But, any way you cut it, this is not a replay of the PC battles. There are too many companies still in the game and who have the potential to grow market share, profit share, or whatever other metric by which you want to judge.

Despite what you may read, there is no clear market leader. Nokia is still in the lead based on total handsets, Blackberry is still in the lead based on smartphone handsets sold, Apple is kicking ass in the profits department, and Android is doing gangbusters in new sales unit, if you lump all the 100+ models of Android phones together and count free phones as sales. Plus, the market is still growing. Apple, for example, didn't increase their market share at all year over year, but they increased their units sold considerably.

Understandably, many people are counting Microsoft out of the mobile game, but I'm not. Though I'm no fan of their technology stack or their approach to business, I think the sheer size of Microsoft's advertising budget, their Enterprise-savvy sales force, and the enormous pool of existing .Net developer talent they can draw on gives them an opportunity for huge inroads. They may not capitalize on it, but it's certainly there and counting Microsoft out of the wireless market would be as foolish as counting Apple out of the game 12 years ago was. And over at HP, lots of money and time is being invested into the Pre platform, which has not been a huge commercial success, but got pretty good grades with many developers who worked with it.

The game's afoot. It's going to be fun to watch, but if you are truly a betting person, this is what you might call a high-risk scenario.

App Licensing

For all those people telling me that Google's App Licensing would put a definitive stop to piracy on Android and that Apple should implement something similar, all I can say is: I told you you were wrong and here's proof, and it didn't take even as long as I said it would.

I understand Google has to address piracy because it's a bit of a black eye for the platform. They need third party developers, and a lot of third party developers are gun-shy about developing for a platform with a reputation for rampant piracy. Although the iPhone has its own problems with piracy, it's on a completely different scale. The closed nature of the platform is actually an advantage for third party developers, much the way gaming consoles are. Sure, Apple's protection scheme has been compromised and any App posted to the app store can be pirated easily. But, because only people who Jailbreak their phones can actually install the hacked software, and Jailbreaking a phone can cause problems with future updates from Apple, there's built-in damage control.

It also helps that you can buy App Store apps in every country where you can legally buy an iPhone. On Android, you can only buy apps in 13 countries, meaning people in other countries either have to do without paid apps, or have to pirate. There's built-in incentive in that system for people who might be perfectly willing to pay for an app to go pirate it. Google would get more for their piracy-battling dollar by expanding the paid markets than by implementing more hare-brained licensing schemes that won't ever make a dent in piracy.

I don't envy Tim Bray's task of having to try and reassure Android developers that this crack isn't a problem. Of course it's a problem. It's a problem the media industries have been fighting with since the dawn of digital content. The RIAA, MPAA, and media companies have invested millions, maybe even billions of dollars into various schemes that have failed to make much of a dent in piracy.

For those who think this App Licensing can ever work, you (much like the media industry) fail to grasp the inherent technical flaw with any kind of DRM. With DRM, you have to provide the legal purchaser with the content and with the key to unlock that content. No matter how sophisticated the stuff in-between, no matter how complex the lock, a sufficiently technically knowledgeable person who has the content and the key to unlocking it can find a way to free the content from its protection. On Android, once you've freed the content from its DRM, you can distribute it to anybody because of the ability to sideload applications. So on most Android phones right now, once a single copy of a program has been hacked, it's just as easy to pirate as it was without App Licensing.

With software, finding the balance between making it inconvenient to pirate (because you can't make it impossible) without overly inconveniencing your customers is hard. It's easier on a closed platform. That's not to say there aren't downsides to a closed platform — of course there are — but this is one of the clear advantages for third party developers. Truth be told, you simply can not stop the dedicated pirate, but a closed platform does deter the bulk of the pirates who can be diverted into paying customers by making it inconvenient. Best of all, it does it without affecting the legal purchasers, unlike most DRM.

When it comes down to it, the most effective way to stop piracy is to make it easy and convenient for as many people to buy content legally as is possible and to price it fairly. This is something Google clearly doesn't get, or else you'd be able to buy paid apps everywhere you can buy an Android phone.

App Licensing

Google took an interesting step recently by adding a service called App Licensing to the Android SDK. I haven't looked at it in detail, but the gist of it is that it's a license validation system for third party apps. It allows third party apps to check with the Android Marketplace to see if it's authorized to run on the particular device. To simplify it beyond recognition: It's sort of like Steam for Android Apps.

This is a bit of a double-edged sword for Google, though. Steam-style online authentication isn't exactly warmly embraced by the proponents of "open" systems, but given how easy it is to pirate applications downloaded from the Android Marketplace (and then return them for a refund!), it's probably a necessary step to attract developers to the platform. Google has to at least look like they're trying to stop the rampant piracy.

But here's the thing: With an open source OS, I can think of a dozen different ways to try and circumvent something like this, and I'm hardly a 1337 hacker. Google can add complexity and make it harder to circumvent, but if someone with the right skills has full access and control over the hardware and software, you can't stop them from getting around any kind of licensing authentication scheme you create. It's like DRM. Within a few months (at most), there'll be an exploit or hack to allow pirated Marketplace apps that use App Licensing to be run without a license. I can almost guarantee it. Google can keep changing the process to fight the pirates, but it's a losing battle, and likely would entail a lot of inconvenience to developers in the process.

This is one area where a closed system has advantages. For us iPhone developers, only about 10% of our potential audience can possibly pirate our apps because pirating requires jailbreaking. That 10% is the starting point. The most it can be. Jailbraking is a quid pro quo, so 90% of our potential market can't, won't, or wouldn't know how to pirate an app. But the real number is even smaller than that. Not everybody who jailbreaks their phone pirates apps - there are other valid reasons to jailbreak (so I'm told, I've never been tempted myself) - and I know people who have jailbroken their phones who are ethical and wouldn't consider pirating an app.

There's no doubt that there are advantages to "open" systems, but there are also disadvantages. In this particular case, one of the most major drawbacks of "open" doesn't hurt Google or the Wireless providers, it hurts third party developers. If that wasn't true, Google wouldn't be devoting engineering hours to try and stop it with 'app licensing'.

Life as an iPhone Dev has it's problems, no doubt. When you have an app sitting in review for months, the way Briefs has been, when you get rejected on seemingly arbitrary or inconsistent grounds, or when you can't implement something that would benefit your users because of a term in the license agreement, it sucks. But, when all is said and done, a good app on the App Store properly promoted can make enough money for a development team to live on. Until that can be said about the "open" Android Marketplace, I simply can't buy into the "open is better" mantra.

If a curated platform offers a better user experience and allows third party developers to actually make money, I just don't see "curated" as a dirty word, no matter how many times Google's Android Evangelist tweets it.

Ahh… the Sweet Smell of "Open"

I bet owners of Droid X phones are thrilled to have such an "open" phone. Man, I was just so off-base when I discussed Android and the practical reality of openness in a world controlled by wireless providers. Oh, wait… no I wasn't.

via several people on Twitter

The Illusion of Open

Today, on Twitter, I've been having some back and forth with John Wilker, one of the founders of the 360|iDev Conferences about Android and the concept of "openness". The discussion really helped to clarify some of my thoughts on the matter (thanks, John!).

Now, I've been somewhat harsh on Android at times, but the things I'm harsh about are details and personal programming platform preferences. It's actually a pretty good platform with a huge amount of potential. It now appears to have reached the critical mass needed to really propel it forward, and I do have high hopes that it will keep moving forward, getting better, and pressuring Apple to do even more amazing things than they would have otherwise done.

Yesterday, Google IO ended, and it was clear from the tone of the conference that Google is planning to put up some fierce competition to Apple on several fronts, and that's good. A lot of Google's pitch was focused on this idea of "openness" - that Google's stuff is inherently more "open" (except, of course, the stuff they make money from, but that's a whole separate topic) and therefore better for the user. Tim Bray, Google's Android Evangelist, went off on a rather enthusiastic but somewhat silly Twitter rant a few days ago about openness and the "curated experience" of the iPhone. It's clear that Google sees "openness" as a competitive advantage over Apple and has made it their battle cry in the mobile space.

But, not too long ago, Google announced that it was ending direct sales of their phone, the Nexus One.

Here's the reality of the Android situation now: if you buy an Android phone, it will most likely be locked down by your carrier, possibly also with some features disabled. Or, to use Tim Bray's term, the reality is that most Android phones that get bought are a "curated experience".

In some places, some carriers will sell unlocked phones, but for a great many people, if you want an open Android phone, you will be required to buy one from a carrier and jailbreak it, which is likely a violation of your subscriber agreement. If you don't jailbreak it, you may not get future Android updates. If you buy an Android phone and don't jailbreak it, you might spend the entire life of your phone using the Android version that shipped on it. Your vendor could even charge you a ridiculous monthly fee for the upgrade, something that at least Verizon has considered doing. Even if your carrier does provide updates for free and regularly, there will be a delay as the vendor and provider add all their customizations and restrictions on top of the official Android release.

For the vast majority of people who will buy Android phones, "open" is an illusion because now that Google has abandoned their direct sales model, Android firmly puts the final decision making power for the overall experience of the phone back into the hands of the traditional carrier/vendor relationship that ruled the space before the iPhone came out. Apple, unlike other phone vendors, is capable of going toe-to-toe with the carriers and is willing to do so to fight for a better user experience. That's why we don't have AT&T branding all over our iPhones. That's why we don't have the mandatory 15-second spiel before voicemail that Verizon users have to suffer through. Apple is at least an equal partner with the carriers who sell their phones. Most of the other phone vendors, to put it bluntly, are the carriers' bitches.

Does Android have some nice features that the iPhone doesn't? Absolutely. Is Android improving? No doubt about it and on a regular basis to boot. But, by putting the real power back in the hand of the carriers and their vendor partners, the user experience is never going to be as important in the decision making process as it is for the iPhone. Even if the Android team manages to make the overall experience better than the iPhone (which I consider unlikely, but possible), the carriers will almost certainly screw it up with their ham-handed customizations and restrictions.

If you're going to have a curated experience, isn't it better to at least have one where the curator is making their decisions primarily around the quality of your experience?

Unless Google resumes direct sales or puts licensing limitations on the carriers to prevent them from locking down Android phones, "open" will be just another empty marketing slogan. And I suspect that's what it will be. Google doesn't really care about the user experience, they just want to keep making money on their proprietary, non-open advertising in the mobile space the way they have on the web, and the more Android phones that are out there, the more phones that will be getting Google Ads. Hell, Google even discussed the possibility of unblockable ads at Google IO!

Right. Nothing screams "open" like unblockable advertisements served using proprietary algorithms based on personal data that's been collected about what you do online.

Ad Hoc Distribution, Android vs. iPhone

I've spent a fair few words on this blog discussing my perception of the Android SDK. To sum it all up simply, my overall opinion is that programming for the Android SDK is good, but nowhere near as good, nor as fun, as programming for iPhone SDK. Although Android has some places where it shines, there are relatively few where it outshines the iPhone SDK.

There is one, however. One where the experience is worlds better in the Android camp: ad hoc distribution.

When you do contract programming, ad hoc distribution is a big part of your life. A lot of people who hire others to write software aren't programmers themselves, so we have to have a way to get the applications we develop to our client for their review and for testing. On the iPhone, we have to go through this relatively convoluted process where we create an ad hoc distribution certificate then create an ad hoc provisioning profile that ties the application to certain, specific devices based on a unique identifier called a UDID. The client then has to install the provisioning profile on their phone, and then install the app.

When it works, it's not too terrible. It's a bit of a pain in the ass, but it's not too awfully time-consuming.

The problem is when it doesn't work. When a client reports that an app won't install, trying to remotely figure out why can be really tedious and time-consuming and the process creates a negative impression of the platform in the eyes of the client. And there are many reasons it can go wrong, and it does go wrong way too often in my experience. If the application bundle gets changed in any way, code signing fails and the app won't launch. If the provisioning profile doesn't get installed properly, installation of the app fails. Often, when the problem is finally fixed, we have no idea what we did that fixed it.

And we developers are left holding the bag. We're left spending hours and sometimes even days trying to get the app working on the client's device. Usually, that time we spend figuring out what the hell is going on is unbillable. When a client isn't a programmer, especially when a client isn't particularly tech-savvy, the whole process can be extraordinarily painful and frustrating both for us and for our clients. On top of that, we're limited to 100 devices that we can even do this process with. With several models of iPhone and iPod Touch, plus the iPad and the fact that most developers have multiple clients in the course of a year, we have the added hassle of having to manage our devices so we don't exceed our limit.

On Android? I drop the compiled app into my Dropbox folder and e-mail the client the URL to it. I instruct them to tap the link from their phone. That's it. It just works. No hassles, no worries. There's a one-time instruction I have to give them that involves tapping a checkbox in their phone's settings to allow third-party apps, but after that, it's just the URL. The user still has control of whether it gets installed, so it's relatively safe, but there's no provisioning profile, no iTunes requirement, no worries about the application getting corrupted or accidentally changed in transit. No angry customer calls or e-mails.

In most ways, I wish Android was more like the iPhone. In this way, I really, really wish the iPhone was more like Android. This whole process lacks the polish and ease of use that I ordinarily associate with Apple products, and after two years of developer complaints, it has improved a bit, but not nearly enough.

A Short Android SDK Follow-Up

Something interesting has happened since I posted my thoughts on the Android SDK. Two interesting things, actually. Both were e-mails from people who work on the Android SDK, one from Google and another from Motorola.

Despite the fact that I was quite critical of several aspects of the Android SDK in that post, neither e-mail attempted to argue with me. Neither took an adversarial approach at all. Both basically thanked me for my opinion and asked me for more information so they could improve Android and address those things I criticized in my post.

It may seem like a small thing, but those two e-mails impressed the hell out of me. Regardless of language or preferred design patterns or any of the other million things that we developers love to argue about over a pint of beer, one of the true marks of a good developer is the ability to take criticism without getting defensive combined with a true desire to make your products the best they can be. Reaching out to somebody who has criticized a product you work on is not an easy thing to do.

So, I felt it was only fair to point this out here because I think it bodes really, really well for Android's future. I think we'll see great things out of Android as it matures. I don't think those things will change my personal desire to work with Android as my primary platform, but that's simply because I don't like Java anywhere near as much as I like Objective-C, but I'm definitely not going to bet against Android doing well.

Android SDK from an iPhone Developer's Perspective

I've already given my opinion on the Nexus One hardware. Now it's time to look at the programming side of things. It's time for my opinion of the Android SDK.

Let me start by stating the obvious, because I know a few people will forget this: I'm about to state my own personal and very subjective opinions about the Android SDK. That opinion may differ from yours, and that's okay. Really. It is. The Earth will continue to spin even if you think I'm 100% wrong.

Let me also put my biases right out front: I don't like Java. I've actually been using Java longer than Objective-C and have actually logged more hours and made more money using Java than I have with Objective-C, but from the moment I read Object-Oriented Programming and the Objective-C Language back in 1997 or 1998, I felt like Java was doing many things wrong. Every step in Java's evolution has reinforced and strengthened that feeling. The approach used in NextSTEP (which evolved into Cocoa and then Cocoa Touch) matches my way of thinking. I believe in the approach. I like the approach and the language so much, in fact, that I took a substantial cut in income to be able to work with it full time. So, based on that, you should be able to see that Android's already got one strike against it from my point of view.

I've been intentionally putting off writing this blog post, however, because I didn't want to do what I've seen a lot of people do with the iPhone SDK and Xcode, which is to write a blog post about how it doesn't work the way I expect it to, and therefore it's bad. Given that I already have quite a bit of experience with the language and IDE and have now had several weeks with the Android SDK, I feel like I can give an opinion that's not just me complaining that it's not what I already know and like, though the fact that it does many things in a way I don't like is certainly a factor in my opinion.

So, after spending a few weeks with Android, what do I think?

It's actually not bad. It's a fairly capable SDK. It has most of what you'd need and, being based on Java, there's an awful lot of code and libraries you can draw upon. The design of the SDK is a little inconsistent (just like the Android user experience, actually). There are parts that are almost as close of a copy of the iPhone SDK are very similar in design and feel to the iPhone, and there are parts that seem downright alien¹.

There definitely is a lack of consistency in the design when compared to the iPhone SDK. Different parts of the Android SDK feel like they were written by completely different teams that didn't necessarily communicate or even agree on the best way to do things. There are some small inconsistencies in the iPhone SDK, but there are strong guiding principles and dominant design patterns throughout the iPhone SDK that don't have any counterpart in the Android SDK. The overall effect is that Android is a little chaotic and disjointed, but still competent.

Android also has a difficult task in that it's designed to run on such a broad range of hardware and you can developed on a broad range of operating systems and hardware. Google has actually done quite an admirable job given how much harder the problem is when you don't have limited hardware options, all of which you control.

One of the ways they've dealt with this is in the design of the emulator. You can configure the emulator to simulate different hardware with different features and different screen sizes, and you can have multiple virtual devices setup. This means you can test your app on a "virtual Nexus One", then switch to a new virtual device and test on a "virtual Motorola Droid". Working with the emulator is smooth, but not as smooth of an experience as the iPhone Simulator. For example, when you launch an app in the emulator, the emulator doesn't become the front-most application, and the emulator doesn't unlock automatically. But, the experience is still quite decent, especially in light of the additional challenges presented by it being an open platform.

Running on the device worked well, too. Surprisingly well, in fact. Again, it's not quite as smooth of an experience as running on the iPhone. There were little annoyances, such as when you run a program on the device, the phone doesn't wake up or unlock the way the iPhone does. But, overall, it works pretty well and without the hassle of provisioning profiles or developer certificates.

I found debugging to be somewhat painful on Android, but that may just be that I know GDB so much better than JDB/ADB (the Android Debugging Bridge) and I also know Xcode's debugging features much better than Eclipse's.

Although you don't have to use Eclipse to program for Android, it does seem to be the default choice. At least, it seemed like the choice with the fewest obstacles when I was getting everything setup. Eclipse has really good integration with the Android SDK and tools. Running and debugging on the device or on the emulator are a piece of cake, and there are even tools for pushing data to the running virtual device such as location data.

But I hate Eclipse with a passion. It completely and totally doesn't jive with the way I think or work. I find the UI inscrutable and its performance on the Mac is less than stellar. If I were going to be doing a lot of Android development, I would probably invest some time in finding an alternative IDE with good Android integration, or just work with TextMate and the command-line.

I do feel like I can code any application I need using Android. Making it look nice can be a challenge, and I spend a lot more time referencing documentation than I ever did with the iPhone SDK. Knowing one part of the Android SDK doesn't necessarily give you any clues about how another part works and even being an experienced Java developer doesn't give you that much of an advantage in that respect.

Designing views in the Android SDK is one of the areas that I can say without equivocation is worse than the iPhone in every single respect. Android's approach to creating views has absolutely no redeeming value whatsoever. Designing your interface on the iPhone is easy. It's fun. It's intuitive. On Android, it's fucking hell. It's like working with the evil offspring of GridBagLayout and XML. It's utterly horrid. But, Java has never done UI well and has never made it particularly fun so I can't say I was surprised by this, though it did exceed my expectations by being even worse than I thought humanly possible. The whole process is counter-intuitive and time-consuming, and that's just to make something that functions. It's even more time-consuming and painful to make a UI that doesn't look like ass.

But, that's the only area so far in Android that I've found really horrible. Overall, it's a capable SDK. What it's not, however (at least for me), is fun. It's completely missing any fun factor whatsoever. The SDK doesn't get out of my way when I want to create. It's a constant obstacle. Not a big or insurmountable obstacle, but a constant one. The iPhone SDK, on the other hand, is quite fun. Once I understood its approach to doing things, it became quite easy to forget about the SDK and just create my apps.

I've been trying to figure out exactly what the difference is; what it is that makes one fun for me and the other not, and I think I've got it. The Android SDK generally fails to follow one design principle that Apple does pretty damn well, which is:

Make the stuff you do all the time easy.

As a result, on Android, things you almost never do seem to be just about equally hard and time consuming as those that you do all the time.

Case in point: Because of the relatively small screen size, one of the things you do all the time in mobile apps is switch in new screens of data. On the iPhone, we accomplish that like so:

1. Create an instance of the view controller class for the view we want to show
2. Set properties on that view controller to provide it with the data it needs to function
3. Present the view controller's view by adding it to the view hierarchy, pushing it onto a navigation controller's stack, or presenting it modally, each of which typically requires a single line of code

Now, on Android, it's not quite so straightforward.

1. Add an entry for the Activity (which is similar to UIViewController, but not exactly the same) to your application's Android Manifest to let Android know the class can be launched
2. Create an Intent based on the Activity's class
3. Make sure that any data you want to pass to the other Activity is serializable or in the shape of raw datatypes
4. Push the information you want to pass to the other Activity as an "extra" to the Intent, serializing those that are objects
5. Start the Activity
6. In the Activity class, override onActivityResult and retrieve the extras you need, deserializing those that aren't native datatypes.
7. In the Activity override the onCreate() method to specify the view to be used (and don't even get me started on designing views in Android...)

In reality, the two lists above don't do justice to the difference in effort. This is a task that becomes second nature for the iPhone developer because it's intuitive, and thankfully so. This is the kind of three or four line chunks of code you begin to write without even thinking about it. On Android, the stuff you need to do to accomplish the same task is scattered throughout your project files and the process is not likely to ever become second nature or easy.

Now, people who love Android will argue that Intents are powerful - more powerful than the iPhone's approach because Intents can be used to let other programs and the OS leverage functionality from your program.

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. And they do that at the expense of making something you need to do all the time more involved and more complex than it should be (and, therefore, more likely to contain bugs). It's indiscriminate complexity, which is not a virtue. As OpenDoc and CyberDog will gladly attest, seemingly good concepts do not always make for good implementations or user experiences, and the iPhone hasn't suffered much for its lack of a way to share functionality between applications.

To me, much of the Android SDK (pretty much the parts that weren't heavily influenced by the iPhone SDK) seem to be over-engineered. Much of the Android SDK features complexity seemingly for complexity's sake. Fifteen years ago, I would have loved it because I was in my over-engineering macho-programmer phase² and that complexity and the theoretical power it gave me would have seemed really cool.

Today, it just makes me shake my head and think Google's engineers should stop showing off how smart they think they are and start writing elegant code that's exactly as complex as it needs to be. They should be designing their SDK's architecture with an awareness of the fact that that not all tasks are created equal, and simplicity is, at times, the absolute best choice.

But, despite my feelings about Android's elegance, it absolutely is a decent mobile SDK. There's a lot of functionality in there, and an awful lot of libraries and sample code that you can draw on to avoid re-inventing the wheel in your applications.

I don't see myself ever doing Android work full time. I don't see myself ever actively looking for Android SDK work that's not part and parcel of a larger project that includes an iPhone application. But, bottom line, it's not bad. It is, at times, inelegant, unnecessarily complex, and convoluted, but it's young and it still has the potential to grow into a great SDK.

Will Android take off? Probably. There are a lot of Android phones coming to the market. Phone and wireless companies love free OSes because they increase their profit margins. And, once enough people start to own Android phones, people will really start writing apps for Android phones. 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'm happy to leave that market to others.

---

1 My apologies. My original wording here could have been read to imply that the Android team copied the iPhone SDK, which really wasn't my intent. I meant to say that some parts have a very similar feel and use design patterns commonly used in the iPhone SDK. It's quite obvious if you've spent any time with the Android SDK, that they are doing their own thing and are not just copying the iPhone
2 Every programmer goes through this phase if they stick with programming long enough. If you've been programming for a while and don't think you went through it, there's a very good chance you're still in it.

Nexus One from an iPhone Developer's Perspective

Okay, this article has been a long time in the coming. THe delay is partially because I've just been crazy busy, but it's also because I wanted to spend enough time with the Nexus One and Android so that I wasn't judging them purely on what I was already accustomed to. I think that I've spent enough time with them now to be able to do that. Not only has it been several weeks, but when I was in the U.K. for NSConference, I had only my Nexus One most of the time because I didn't want to incur AT&T's incredibly high data roaming rates. As a result, I got a real feel for what it's like to use the Nexus One as my main phone.

In this posting, I'll talk about the device from my perspective as a user. My thoughts on the Android SDK as a developer will come in a future installment, hopefully in the not-too-distant future.

Let me state that I tried to be as objective as I was capable of being, but this is in no way an unbiased or objective report. These are my subjective impressions, which is to say that they are the subjective impressions of somebody who has used and developed for iPhones for nearly two years, who teaches workshop on developing for the iPhone, and who has written books on the topic. While I tried to be fair, it should come as no surprise that I believe in Apple's approach to both hardware and software, so caveat emptor.

Hardware

The Nexus One hardware is so close to being a home run that it's painful to have to bash it around a little bit. But, it misses in a few really major ways. If Google and HTC can solve a handful of annoyances, the Nexus Two could be pure awesome from a hardware perspective. I can't honestly bestow that adjective on the Nexus One, however, because these few flaws were enough to make me want to throw the damn phone at the wall. Hard. Repeatedly.

First, the good. The phone feels really nice in your hand. It feels like a quality piece of hardware. Not chintzy or cheap like the Motorola Droid or most cell phones. It feels solid and very much like the iPhone. The first impression was very good.

The screen is vivid and high-resolution and looks really, really nice… that is, as long as you are indoors. Outside on a sunny day, the OLED screen is almost completely unusable. That's kind of a big deal for a phone. I applaud HTC for pushing OLED technology forward, and I can see it being a great technology today for devices that require mostly indoor use, but this is a phone, and as such, I need to be able to use the damn thing outside.

The touch screen is noticeably less precise and sensitive than the iPhone's. It really makes you appreciate the iPhone's touch screen, which is something I think most of us take for granted since we've had so few points of comparison. The Nexus One's isn't horrible, but it's also not great. Mis-taps are far more common and the finger tracking isn't nearly as accurate. How much of this is the hardware and how much is the averaging algorithm used to determine where the touch registers, I have no idea.

One real issue I have with all of the Android phones is the four hardware buttons they all have: back, menu, home, and search. Three of the four shouldn't be there. Coming from Google, I can understand the emphasis on search, but it simply doesn't belong in a hardware button. I don't need to search while I'm playing a game, for example. Likewise, the menu button isn't applicable in all situations, nor is the back button. Of the four, only the home button really needs to be a hardware button, and it's not a coincidence that Apple made that exact design choice. You have a touch-screen, for crying out loud. Anything that's context sensitive rather than universal, should be contained in an on-screen control, not a hardware button. Search, back and menu are not universal. Home, power, volume - those you might need at any time and should be hardware.

To make matters worse, the sensors on the Nexus One for the four hardware buttons is not exactly aligned with the silkscreened icons. You have to tap noticeably above the button to get it to register. That was very frustrating for me until someone (from Google nonetheless) pointed out the mis-alignment. Up until then, I consistently had to hit the buttons three or four times to get it to register.

But even worse than that, the home button on the Nexus One is right below the fracking space bar on the portrait keyboard. Combine that with the not-completely-precise touch screen, and you have a UX disaster. I can't tell you how many times I've been typing and ended up leaving my application due to accidentally hitting the home button. Leaving an application mid-sentence is hardly a good user experience.

The Nexus One also has a Blackberry-style scroll ball. It serves no purpose whatsoever. You can use it for navigation on Android's home screen, and in some table views, but it's never necessary (touch screen, remember?) and never offers a better experience than the touch screen. I've seen the argument that it could be used for games. Well, I tried a few games that supported the trackball. It sucks as a game controller. It sucks in general. It should never have been put into production. For the most part, you can just ignore it, but you can't help but to wonder what the thought process was that led to this completely superfluous control being included.

The final issue I have on the hardware side is minor, but the SIM card can't be removed or inserted without taking the battery out, which means you have to re-boot. And, on the Nexus One, rebooting takes quite a long, long time. Most people won't need to do this very often (if ever), but as I had to do it several times, I really came to appreciate the location of the iPhone's SIM card slot and the fact that the SIM card can be hot swapped.

When it comes down to it, the Nexus One gets it about 90% right. Unfortunately, it's that last 10% that really seals the deal for most non-geek consumers, and the Nexus One just doesn't have it.

But the Nexus One does have a few advantages over the iPhone. Unfortunately, most of these advantages will only appeal to geeks and not the larger consumer base. For one thing, it has a faster processor and a much higher resolution screen. The faster processor isn't all that obvious in day-to-day use, however, because Android 2.1 doesn't seem to leverage the GPU for most OS-level tasks. Things like table scrolling (for example) are often skippy, which is just inexcusably bad engineering given the 1Ghz chip and powerful GPU inside. That big screen is also partially responsible. The Nexus One has an awful lot more pixels to push than the iPhone, and the end result is that it simply can't do as much work per second as the half-year older iPhone 3Gs, though a firmware update might be able to rectify that, at least for games specifically written to take advantage of the GPU.

The higher resolution screen makes text and drawn elements look a touch smoother and less jaggy, but there's a high price for something most people won't notice. I could see a difference when placed side-by-side next to my iPhone, but the Nexus One's screen didn't jump out at me as that much noticeably better than the iPhone's screen, and even when placed side-by-side, the difference wasn't earth-shattering. Besides that, having all those extra pixels to display text smoothly is rather a waste given that text on the Android's quite simply looks like ass.

The iPhone's 150 ppi screen has a higher-resolution that the vast, vast majority of LED or CRT devices ever created. I don't know of a single person who ever looked at the iPhone's 150 ppi screen and said "if only I needed a more powerful magnifying glass to see the jaggies". The Nexus One's screen seems like a pure case of trying to compete on specs without regard to whether there was any need for a better spec. In other words, a solution looking for a problem. After all this time with the Nexus One's "better" screen, I don't find my iPhone to be at all lacking in that regard.

"Because you can" is rarely a good reason for including a feature.

I do like the ability to mount the device to gain access to its contents, but most people won't care about that, and for the average user, not having tight integration with iTunes and iPhoto makes this phone that much less accessible.

The last hardware feature I'll mention is the haptics, which I'm ambivalent about. The Nexus One issues a little shiver when you touch certain onscreen controls. Most of the places where I appreciated having it was due to some other design flaw that the haptics compensated for, such as the misaligned hardware button sensors. It's kind of a neat feature, but I don't miss it on my iPhone. If it could be designed to tell you specifically which button was pressed instead o just that some button was pressed, I could see it as being a very useful feature, but as it is, it really doesn't add much value.

Software

The Neuxs One shipped with Android 2.1. As far as I know, it was the first and so far is still the only phone to ship with this version of the operating system. When I first got the phone, the most noticeable aggravation for me was the lack of multi-touch gestures such as pinch-in and swipe in the delivered applications like the browser. An update has since added these gestures, and it helps some. Not enough, but some.

As I mentioned earlier in the hardware section, one big shortcoming of the Nexus One is the fact that it doesn't seem to leverage the full processing power available to it very effectively. The hardware in the Nexus One is capable of doing amazing things, yet everyday tasks like scrolling are still often jumpy and unimpressive looking. Games written to use the GPU (presumably using OpenGL ES) seem to be better in this regard, so it's not that the hardware isn't up to the task (based on specs, it's quite impressive actually), it's just that the operating system isn't taking full advantage of the hardware.

Android's home screen can be configured in a much greater variety of ways than the iPhone's. In addition to application icons, you can also add "widgets" for searching the web, reading headlines, or discovering the weather. Third party developers can also develop additional widgets. Not a bad idea, and it reminds me of Mac OS X's dashboard. The implementation isn't as polished as I'm accustomed to with Apple products, however. The shipped widgets lack a uniform aesthetic and some of them are just ugly (Analog Clock, I'm looking at you!). With a little nicer execution, this could be a really great feature, but it left me unimpressed.

One of the small things that really bothered me on the Android is the lack of scroll bounce. I always thought it was silly eye-candy on the iPhone when you scrolled to the end of a list and it went a little past the end and bounced back. But you know what? That's powerful visual feedback. You know that you're at the end of the list. On the Android, when I came back into an application with a scroll list, I often didn't know if the phone was frozen or if I was just already the top or bottom of the list. This is especially important in apps like Twitter apps where the contents of the list may have changed since last use. That scroll bounce is part of that last 10% I was talking about, and the Android software doesn't have it either, for the most part.

"Multitasking" is one of the much lauded benefits of Android over the iPhone. Of course, it's not really multitasking. Everybody except most "tech pundits" knows that the iPhone's Mach kernel supports full preemptive multitasking and also knows that at any given moment there are somewhere on the order of twenty daemons and other processes running on a stock (non-jailbroken) iPhone.

What people mean when they misuse this term is the ability to run more than one GUI application at a time, the way we do on our regular computers. And the Android certainly allows this. Only, it's not really a point in Android's favor. When you hit the home button, the previous application keeps running, which means it keeps eating memory, keeps using processor cycles, and keeps eating battery. To truly quit most applications requires a multi-step navigation that is neither intuitive nor well-documented. The ability to have more than one GUI application at a time on a device with such a small screen isn't as important as some make it out to be, since you can't actually interact with more than one a time.

In the early days, I was a big proponent of having Apple add the ability to run multiple apps to the iPhone OS, but I've come to change my mind on that. I think most people don't need it and Android's implementation only confirms it. Yes, the app keeps running, so when I go back to it, it doesn't have to relaunch. But, if the app were designed to go back where I left it and launched quickly, the end result would be exactly the same, only without the wasted processor cycles and battery time, not to mention the confusion about which apps are currently running. Most people don't want to ever see a process monitor or to even know what one is.

To the extent that there may be a need to have more than one GUI app going at a time, it's also a non-trivial problem to solve. Oh, the technical problem has long-since been solved, but the user experience issues around presenting multiple GUI applications on a small screen have not yet been adequately resolved. Android's solution is simply bad. If Apple does offer a solution to allow more than one GUI application at a time, I'm sure it will be much better, but given the choice between having only one GUI app running and Android's system of keeping everything running, I'd rather have only one app running.

This post has gotten longer than I intended, so I'm going to finish off with just a general statement. Basically, when it comes right down to it, most of the delivered applications on Android just aren't as good as the apps that come on the iPhone. The differences are minor and often subtle, but they make a big difference in the user experience.

To give one example: setting an alarm. Both Android and the iPhone have the ability to set alarms and act as an alarm clock, buzzing and playing a sound at a given time. The day of my flight home from the U.K., I set alarms on both devices (I'm paranoid bout missing flights). It took me quite literally three to four times as long to configure and enable the alarms on the Nexus One as it did on the iPhone. Add that extra time by the number of tasks you do on your phone in a given day, and it can add up to a considerable amount of time.

To make matters worse, on the Nexus One, if you snooze an alarm, there's no obvious way to prevent it from going off again at the end of the snooze interval. You can turn off the alarm, but the snoozed alarm still goes off after the interval (in my case, while in the shower). On the iPhone, if you go manually turn off the snoozed alarm, you never hear it, which is as it should be.

Conclusion

Overall, it's just a general lack of attention to detail that defines the differences between the iPhone and the Nexus One, and that lack of attention to detail exists on both the hardware and software side. The Nexus One isn't a bad phone by any stretch of the imagination. Had it come out three years ago, it would have been revolutionary. But you do have to train yourself to Android's idiosyncrasies much more so than the iPhone. If you've never owned or used an iPhone, you'll probably find the Nexus One to be a very adequate device and will assume that the minor annoyances are just part of owning a smart phone. If you've owned an iPhone for any length of time, you'll likely feel, as I do, that it's a rather half-baked device with some good ideas but generally weak execution.

Then, the question becomes, are the other advantages, such as it being a truly (mostly) open platform or being able to not use AT&T as your mobile provider important enough to you to justify using a less-polished device. Certainly, the answer for some will be "yes". For me, it's a resounding no. I would never willingly choose the Nexus One over my iPhone for daily use, nor would I recommend it to someone who didn't explicitly state that avoiding AT&T or using an open platform was among their top priorities.

But, if the iPhone is not an option for one reason or another, the Nexus One is definitely a most adequate phone. I'd gladly recommend it over any currently available Blackberry, Windows Mobile, or Palm smartphone.

Coming Soon… One Week with Android

Don't worry, I have no intention of leaving the iPhone SDK as my main programming platform or the iPhone as my primary phone, but in the interest of being an informed fanboy, I've been using a Nexus One this week, and I've been porting some small apps to Android. I'll write up my observations and thoughts about both the phone and the SDK this weekend.