 |
|||||||||
|
|||||||||
|
|
In the beginning (relatively speaking), there was PalmOS. This was the main vehicle through which application developers created mobile applications. This was due in large part to the fact that PalmOS pretty much dominated the PDA market and was really the first pioneer of the PDA+phone combination (remember when all your friends snickered at you derisively when they got their Palm VII device? ... or maybe that was just my friends.... ).
Now we've got a much broader market, with a lot more options. This is a good thing, because programming for PalmOS sucked. Now we've got mobile devices that run a mobile version of the .NET Framework that can even run a mobile version of SQL Server for the desktop. We've got the iPhone SDK, which is basically a mobile version of Cocoa - making Cocoa/Mac programmers feel right at home when building apps on this device. You've got an elite closed system of RIM application developers. Then you've got people writing mobile web applications with Ajax that work on small footprint devices. And now you've also got the imminent arrival of devices running Android, a Java+XML development environment.
So just how do you figure out whether you should be spending your time, your money, and potentially a lot of risk, on a given mobile development environment? In this blog post I'm taking a look at some of the mobile dev environments and what I think the pros and cons are, and who I think should be taking advantage of those environments.
As of yet, Android is still unproven and unreleased. We've seen demos of Android running on a few devices, and a lot of really fascinating marketing shpew... but nobody has actually gone out to a store and bought an Android device, downloaded an Android application, and run it. As a result, we really don't know what this ecosystem is going to look like. The development environment for Android is Java with templated UI based on XML that borrows a lot of inspiration from declarative UI programming patterns. Everything in the Android space is currently under a rosey umbrella of the "green grass" effect... A lot of people are banking on Android to solve all their problems, regardless of how realistic that assumption might be.
Analysis: Don't spend a dime on Android development that you can't afford to write off as an experimental loss. Obviously if you've got people paying you to write Android apps then you're safe, but if you're thinking about venturing into these uncharted waters and you don't have the capital to throw at it, I'd say avoid it.
Obviously the iPhone is a phenomenon. It's been ridiculously successful and, in typical Apple fashion, they have managed to take a device that had singular geek appeal and make it appealing to the general public. Even if they don't own one, pretty much every person on the planet who isn't a luddite and hasn't been living under a rock for the past couple of years knows what an iPhone is and has seen the commercials. The development environment is a slimmed down sandboxed version of Cocoa, so Mac/Objective-C developers should feel immediately at home building iPhone applications. The SDK has been getting progressively better as more features are added to the core phone/iPod touch OS. The App Store is quite possibly one of the single best mobile application deployment channels ever. That said, there are some downsides. Recently, people have been up in arms because Apple seems to be exercising arbitrary authority over the rejection process where the application might overlap functionality that Apple already provides. Also, Apple has banned other applications for questionable network use even though the authors felt as though they were complying with the network regs outlined by the SDK agreement.
Analysis: If you are positive that your idea can't possibly be rejected by Apple, and you can build your application cheaply, then this is a no-brainer you should be jumping all over this potential gold mine of a platform. However, there is a risk that you could spend a crapload of money on building your application only to have it rejected by Apple during the final stages... so that's a risk you need to weigh before beginning the project (possibly talk to an Evangelist to gauge whether they think your app might get rejected or not). If you are building an app as a hobbyist, in your spare time, or to tinker - you couldn't possibly ask for a better platform to get visiblity for your effort and hard work. Also, keep in mind that there are currently a lot of enterprises that don't allow the iPhone to be used by their employees for security concerns... so keep that in mind and do a cross-check on your intended audience before you start building, or you could end up building a killer app that everyone wants and no one can use. Another possible downside - lack of community. Good luck finding public answers to your problems. The NDA for the iPhone SDK has been hindering everyone from tinkerers and hobbyists to full-on commercial application developers and even authors who have been trying to help developers learn this platform. It doesn't look like Apple is going to lift the restrictions on the NDA anytime soon, so if you want to get into this platform, you'd better enjoy being a self-taught lonely programmer.
The .NET Compact Framework has a remarkably wide install base. It basically shows up (or can be installed) on any Windows Mobile device. Devices that can run the CF include everything from small cell phones that only have numeric keypads to full PDA-type phones with slide out haptic keyboards all the way to niche devices like in-car entertainment/navigation console systems. Who knows, I'm sure there is a refridgerator out there that might be running a version of the .NET CF. Obviously the development environment for the CF is the .NET Framework, so if you've been building desktop and/or server apps using C#, you should be able to jump right onto building mobile applications for CF-carrying devices. You get what is arguably one of the best IDEs available in the industry, a flaming truckload of community where most problems you might encounter have already probably been solved and discussed on blogs or forums.
Analysis: If you are building an application that you want to deploy in an enterprise, you can probably find no better mobile platform/SDK combination. Windows Mobile devices are everywhere, and if you walk around a corporation anywhere in the world, you're going to find a truckload of people walking around with WM devices or Blackberries. Even corporations where people are using Blackberries also probably have complementary coverage for WM and exchange-based devices. The deployment channel for hobbyists and shareware type developers is rough and ugly, but WM devices are not closed, and anybody can plug a device in and install software on them (unlike iPhones). The open-ness of this platform is a huge advantage to commercial and hobbyist developers alike. Even if you're planning on building your app on one of the other platforms, you should consider building a port for this platform as well because of the huge target audience, corporate/enterprise acceptance, rich tooling, and massive public community/support.
Most people feel that this is the most risk-free approach. Rather than building an application that targets a specific device or specific OS/platform, people will build web applications that can be viewed from mobile web browsers. The problem with this approach is that, unless you're using an iPhone, most mobile web browsers suck, so you have to try your damndest to overcome the limitation of the browser chrome through which your application is viewed. Also, many mobile platforms have strict JavaScript limitations (including the iPhone), which can inhibit Ajax apps or cause unanticipated side-effects.
Analysis: If you want little to no risk, and the functionality you want to expose can be done in a low-fidelity small-form-factor "lowest common denominator" type format, then you should consider the Web / AJAX approach. Another downside to this approach is that you rely on the speed and quality of the mobile device's connection. Users automatically associate bad experiences with the application they were using at the time, so your app may be the undeserving recipient of customer ire when their 3G connection starts to suck ass and your app appears to stop responding to Ajaxy requests.
To summarize, I am currently of the mindset that Android should be considered a wait and see technology. The iPhone SDK sports the best mobile application deployment and purchasing channel on the market, but can be problematic for enterprises and apps requiring high levels of security. Also, there is some risk in building an app that might be rejected. The .NET Compact Framework is a tried and true, proven mobile development framework that provides a relatively easy way to build apps for Windows Mobile devices. It takes some effort to make your Windows Mobile apps look decent (out of the box CF apps look like ass), but you get the benefits of a huge community, re-use of your C#/.NET skills, great tools and more. Ajax apps are relatively risk-free, but you need a good, live internet connection to use them and they often can't compensate for crappy displays and/or small form factors.
There's a single question to answer to solve this problem : which platform
are your target customers running ?
Yes, that's obvious. The goal of my post was to address the question when
you don't have a platform requirement dictated by your existing or
potential customers.
Looks like Qtopia just became Qt Extended, and I expect will become
something of a platform now that Nokia owns Trolltech. They are moving
towards GPL with it.
With an AJAX approach, another concern should be browser performance (and
indirectly, battery life - although I don't think anyone would develop a
web/Ajax app you'd run for a long time).
I am not a techy. I have however, came up with an idea which I believe
would synchronize well with the I phone 3.0 SDK. I am in the need of a
seasoned SDK developer who would be willing to work with me on
developement.
