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.

Read more »

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.

Read more »

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.

Read more »

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

Read more »

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.

Read more »

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.

Read more »

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.

Read more »

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.

Read more »

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.

Read more »

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.

Read more »

SmartPhone Comparison

I found this comparison of the current generation of smart phones to be interesting. Droid is shaping up to be a heck of a phone. I don't think it's going to pull a lot of people away from the iPhone, but I think it will do well and will probably be the biggest boost for the Android platform to date.

Are there really 10,000 applications on the Android Market now? I'm somewhat surprised that it's that high. I think even if that number's true (Googling finds me a lot of people regurgitating this same estimate from an unofficial source, but I can't find an authoritative source for the actual number of apps in the store), that comparison doesn't really represent the true differential between the App Store and the Android Market. Not even 1% of the applications in the Android Market have been downloaded over 250,000 times (including free ones!), and less than a quarter of them have even been downloaded even 5,000 times. By App Store standards, almost every app in the Android Market is a failure, including the best selling paid apps. That will change, but it hasn't yet and it's definitely a factor in comparing the phones. The App Store is, to put it simply, far more than 10x better than the Android Market.

My concerns about Droid's battery life don't appear to be true if the numbers in this comparison chart are accurate. Although the standby time for the Droid is noticeably shorter than the iPhone, the talk time is greater by a comparable margin. I'm also wondering if these are manufacturer's claims, or real world results. I'm especially curious to see how the Android's battery holds up when playing games or video on that big, beautiful screen. I really wish I could get my hands on one of these for a few weeks. Actually, at some point, I may buy a developer phone just to try and do a real comparison of the platforms from a developer's perspective and also to see if there are any good procedures for developing apps for both platforms simultaneously. I probably won't do that until I'm sure Android has secured the #2 spot, though, and the Android Market starts showing more commercial potential.

One thing I've heard from a few people, and the videos I've seen seem to support it, is that Droid's use of hardware acceleration is really inconsistent. Certain things like video must be leveraging the GPU to work as well as they do, but many other aspect of the UI don't seem to use it at all, which means things like scrolling or zooming often seem sluggish, at least compared to the experience on the iPhone. It's a subtle thing, but the iPhone's ubiquitous ability to leverage hardware acceleration really is a big deal, and one that's not often mentioned in phone comparisons.

Also, I'm hearing mixed things about multitouch on the Droid. The best I can figure is that it does support multitouch, but doesn't make very extensive use of it. It seems to be at least the case that the default browser doesn't support multi-touch gestures like pinch-zoom, which I would find annoying. If anyone can clarify this for me, I'll be happy to correct the post with the right information.

Other than the bigger screen, the iPhone and Droid are surprisingly comparable. In a way, that's bad, though. I'm not sure that having a higher-resolution screen (which I've heard looks nice, but isn't really noticeable unless you put the screens next to each other) and a higher-megapixel camera is enough. I was kind of hoping that Android would kick the iPhone's ass in a few more categories, because that would be a great motivator for Apple. If the Droid is really trying to be an "iPhone Killer", it won't be enough to be as good as the iPhone. But, the smartphone space is big and growing, and the Droid doesn't have to be an iPhone Killer to succeed. It certainly looks to be better than what Palm is offering, or any of the Windows Mobile devices that are available.

I will admit that Droid does look to be a pretty darn nice piece of hardware. If Motorola were willing to invest some time and resources into making Android's interface more intuitive and less designed-by-committee and also was willing to throw some resources at implementing system-wide use of that big GPU they've got in the phone, they could have a real winner on their hands. They've got the hardware in place to challenge the iPhone, but it looks like they're still falling short on software. Even though they are falling less short than others, Software is still king, and until they get that right, they're going to continue to be bridesmaids, and never the bride.

One row in this chart that I want to niggle with a bit with is the multitasking row. First of all, the iPhone does have muli-tasking. It has a very good preemptive multitasking kernel very similar to the one in our Macs. The ability to use it just isn't exposed to third-party developers through the SDK. And, that's not necessarily a bad thing.

In the early days of the iPhone SDK, I was one of the loudest proponents of adding multitasking and background tasks to the iPhone SDK. There are whole classes of applications that would become possible if Apple did, and that's all I was concerned about as a developer. But, you know what? Now that I've spent twenty months with the SDK and know more about the current state of embedded hardware, I've come to realize Apple was right on this call. The time isn't quite right yet. The tradeoff is such that you are doing most of your customers a disservice if you allow multiple applications to run. I've seen multitasking on the HTC Hero, the Palm Pre, and on a few models of Windows Mobile phones, and having multiple background apps running can really kill your performance and your battery life.

Sure, you can just quit those apps if performance suffers, right. Yeah, if you're reading this blog, sure. But the iPhone isn't a device targeted only or even primarily at tech-savvy people like developer. I'm reminded of when I would sit down at a certain family member's computer and he would have every application he had opened since he last booted his computer. It never occurred to him to quit programs he wasn't using. I suspect that there are more people like this family member than like you and me in the pool of potential customers. On a modern computer with virtual memory, who cares if there's a bunch of unused applications open, since they don't really have much of an impact. But on a phone? It still matters.

At some point in the near future, it will make sense on phones, too. But for now, given the hardware limitations, more people will have a better experience if they don't let developers write background processes or let users have more than one app running at a time. Battery life will be longer in real world use, performance will be better, and there are relatively few applications that can't get by without this ability.

Frankly, I'll be honest. I hope Droid fails for a completely selfish reason. I want to see Verizon get the iPhone. Of all the cell phone companies I've used, they were the least obnoxious and had the best service. If they got the iPhone, I'd go back to them in a heartbeat, even if I had to pay a termination fee to cancel my AT&T contract. At present, I just don't see the Droid betting better by enough to lure me away from the iPhone as either a consumer or a developer.

Ah, enough Saturday night rambling. I've got to go finish Chapter 10 which needs to be finished by the end of the day tomorrow.

Read more »

Droid Looks Nice

Here's a breif article on Droid with some nice pictures. The keyboard doesn't appeal to me, but to people who want a physical keyboard, this should have a lot of appeal, since they've put a decent-size keyboard on a phone that's almost as thin as the iPhone. I'd really like to check one of these out. I honestly do not think it's an iPhone Killer. To be that, the Android 2.0 OS would have to take a quantum leap forward in usability. It wouldn't be enough to become as-good or even a little better than the iPhone. To become an iPhone killer, a phone has to be significantly better than the iPhone. On the hardware side, though, there's some stuff that looks great on paper.

The screen has a much higher resolution than existing iPhones at 854x480 pixels. I'm curious about this item, though. It's one of those things that we geeks like to salivate over. Look at all those extra pixels! But, I wonder how much of a difference that will make to the end user and what the tradeoff will be. That's a very high PPI. It might be one of those things where they've pumped up the resolution to have a better spec for advertising purposes, but that having the extra resolution doesn't offer much real benefit to the user.

Plus, it seems like it would have to be more of a drain on the battery than a lower-resolution screen. That's an awful lot more pixels to push (roughly 300% of the iPhone), which means much more work for the GPU, which also means a drain on the battery. The iPhone's 320x480 screen already has a higher PPI than most computer screens, so I'm curious if the higher-resolution screen is really a good idea in practice, or if it's just geek-pr0n for people who get off on having better specs than their neighbor, sort of like the MHz processor wars a few years back when Intel started increasing clock speed by reducing the amount of work done per cycle because the clock speed had become the main marketing point for processors.

I'm not saying that's the case. I don't have access to a Droid so don't have the ability to form an opinion of the Droid. This is all just conjecture at this point. I'm curious, though: Do most people's eyes need significantly more than 150 points per inch, when each point is capable of displaying a range of millions of colors.

If I had to predict, I'd guess that the difference as far as the end-user is concerned will be very little. Fonts and images will be drawn a tiny bit smoother. But, I also predict that it will have an impact on battery life and game performance because there are so many more pixels to push.

But I could definitely be wrong. I would actually love to be wrong this time. If they've really managed to make a significantly better screen without sacrificing battery life or performance, it would be a truly awesome thing, especially if they can combine it with a version of Android that, to the end-user, is nearly as good as the iPhone. I can't think of anything that would push Apple more than having someone nipping at their heels with something that is truly better than the iPhone in some respects and as good (or nearly so) in all others. My fear, however, is that this resolution touting is just another case of trying to compete with the iPhone based on a feature list or spec sheets. If you try to compete on either of those, it shows that you completely fail to grasp what it is that makes the iPhone so popular and indicates that you aren't yet capable of producing an iPhone competitor, let alone an iPhone killer.

I have my fingers crossed that the Droid will live up to the hype, but I'm not betting any money on it.

Read more »

The Nook

For whatever reason, Amazon's Kindle has never really appealed to me. Though I read a fair amount, and am not opposed to the idea of an e-reader, I've just never had any techno-lust for it. It's not because of the DRM, though I'd rather they didn't have it. It's just that it's not that exciting. It's basically a one-trick pony. No matter how thin they make it, or how many books it can hold, it will only every serve the very limited purposes of reading books and doing some light web browsing. Boring. I can do both of those things on my phone, albeit on less than an ideal screen size, or on my laptop.

Today, Barnes & Noble announced their competitor, the Nook. The Nook is based on Android. Now, people who read this blog know that my opinion of Android is that it's not as good as the iPhone in most respects, both from the point of view of a consumer and from the point of view of a developer. Obviously, that's subjective, but it's my honest opinion of where things stand right now.

However, I see the Nook as possibly a game changer for Android, much more so than the much-touted Verizon Droid, which might be a good phone, but it doesn't strike me as a game changer as much as being a not-totally-horrible-like-the-Voyager ersatz iPhone for people unwilling to switch to AT&T. I'm not quite ready to say it IS a game changer, but it definitely could be. It's a book reader that can be more. It's a tablet device that can be programmed. It's bigger than a phone, but still portable. This device, in my opinion, is every so much more techno-lustworthy than the Kindle. It also raises the bar for Android. Here's a whole new audience of devices that will be able to buy Android apps.

Of course, we'll have to see how it actually performs and how people like it. But assuming it delivers on its promises, then I'd say that Android just pulled out a tiny bit from the pack and its odds are looking better. There's a long ways to go in the race, but this could be a turning point. This could be the thing Android needs to achieve critical mass for their App Store, which is the one thing that they absolutely must have if they're ever going to challenge the iPhone's dominance.

I can't wait to see where this goes from here, and I can't wait for Apple to introduce some kind of new iPhone OS device, whether it's a tablet, or something completely new. I don't have any idea what Apple is going to do, but I'm sure they are not going to stand still.

Read more »

A Look at Android Development

I stumbled across this article on Android development today, and it was a very interesting read. The author gave a very balanced look at the Android platform, saying what he thought was good and bad. It reads like a very honest assessment. I didn't detect any obvious spin.

The one area where I don't agree with the author is his statement on Android's Intent/Activity model. This post claims that Android is "a big step ahead of the current iPhone programming model", but I can't help but to be reminded of OpenDoc and CyberDog. This idea of getting "away from monolithic, isolated applications" is not new; it's been floating around at least since the 1990s. If you look at theoretical, rather than practical implementations, it probably goes back much further than that, even.

Yet, here we are in 2009 still using monolithic applications.

Oh, wait, no we aren't. Not really.

When I write an iPhone application, much of the functionality I'm using wasn't written by me and isn't part of my application. It's part of a framework that's already on the phone. I think time has shown that the content-focused (or, intent-focused, if you will) way of dividing up code is problematic at best. It's great in theory, but problematic in practice.

In the example in the blog posting, how do I know if that barcode application is installed? What do I do if it's not? This approach opens up a huge number of problems with testing, installation, and development that offset any of the gains you get from not having code duplicated. The problems of Intent/activity are even more pronounced on an open platform like Android where the user has a lot of flexibility in terms of how they configure it and what they install on it.

This concept also just doesn't really fit the mobile application model that well. The iPhone isn't a general-purpose computer, and neither is an Android phone. If you look at the general population of consumers using smart phones, the way they use the phone the vast majority of the time really doesn't lend itself to this concept at all. They use and expect small applications to serve a defined, finite purpose.

If you're building megalithic applications for a smart phone, you're (quite simply) doing it wrong, and if you're not, you're not going to get all that much benefit from Intent/Activity, and you are going to pay a price in added complexity in the development process and the install process, not to mention greatly increasing the likelihood of problems for your customers.

That's not to say that the iPhone couldn't use some improvement in the inter-application communication arena. We currently have the ability to register application URLs, but it's a one-way trip. I can launch a barcode application, but I can't tell the barcode program to send me anything back unless I control both applications. In reality, I'm not sure how big of a limitation this really is, however. Most of the time, we're not going to want to rely on another application's functionality to handle an important application task unless the other app is one we wrote and have control over. If that's the case, then we have access to the source code and can included the functionality in the app and make it self-contained, greatly reducing the chance that our customers will have problems and get mad at us.

Read more »

The best new software for your PDA/Smartphone

Here is a short review of software to help make practicing medicine a little easier.

Includes a review of device characteristics:

Android,Apple,BlackBerry,Palm,Symbian,Windows, memory issues, input methods, WiFi, 3G and EHR integration.

Includes products from:

AAP,AAFP,ACP,Epocrates,Johns Hopkins, Merck,Skyscape, UpToDate. SV

Medical Economics Article

Modern Medicine Podcast

Related Article: Consumer Health Applications for the iPhone/iPod Touch

Read more »