Which Phone To Develop For? 344
Rob MacKenzie writes "I have to decide on a mobile phone to develop for. We're building a house with some automation built in, and we want the mobile phone to be able to control certain aspects of it, and retrieve information on what's going on in the house. Our choices are the usual suspects: Apple's IPhone, RIM's Blackberry, Nokia's line (Symbian), any Android phone we can get in Canada, J2ME generic app, or a Web-based UI we would interact with in the phone's browser. What would you choose if you had to go with one? Which exact model? We will be buying a few to develop for, so price is a bit of an issue."
Definitely Web-Based (Score:5, Interesting)
If you design your system with a web-based system, you can even go ahead and add other types of device into the mix while still properly supporting a phone. Something that works with the aging Nokia 770's web interface, or even the newer 810 would work just fine with an iPhone, or any flavor of Windows Mobile.
In my personal experience, the iPhone would be a great platform for something like this - though the cost of entry isn't so great. However, the iPod Touch would do just as well unless you really need to have cellular access to things from long distances. The Mobile Safari interface is nice and clean, and the "Sliding" paradigm used in a lot of interfaces for it seems to be quite user-friendly and not too tough to work with.
Windows Mobile might be good for development of a standard application, and Windows Mobile devices are a dime a dozen these days if you don't mind going back a few versions. Unfortunately, the underlying OS is.. Windows Mobile.
Unless you want to learn a new API (Score:5, Interesting)
Personally, having developed for Windows Mobile and the iPhone, my inclination would be to instead create a web-based UI.
The reason is simple: first, the web is pretty universal. You can (in theory) use it from almost any device with a web browser.
Second, it's going to be a lot easier to quickly prototype the control software than a custom client/server architecture with a custom protocol, which you'd get with nearly any mobile device.
And third, if you switch to a new brand of phone, you're not completely hosed; the worst thing that will happen are a few web page tweaks.
Web-based, then iPhone, then nothing. (Score:2, Interesting)
But again, the Web is your best bet. It is the only one that will work on all your phones. Otherwise, it's the iPhone because all your base will belong to us. Mwahahahaha!
Here's an interesting article on the advantages of mobile AJAX, that I enjoyed reading: http://mobiforge.com/developing/story/getting-started-with-mobile-ajax [mobiforge.com]
WAP & TAP (Score:5, Interesting)
WAP (a cut-down version of HTML) works on all small-format web browsers, and should be your *high end* phone interface. But also, you should have a secondary interface, based on a voice modem, that is audio/keypress, and which would work with all phones hands down full stop.
Re:Go with what makes you comfortable (Score:3, Interesting)
The devilish thing is that mobile phones today are as the personal computers were before the IBM PC and MS-DOS appeared on the market.
Not that it was the best product that took over then, and we are still waiting for the 'killer phone'.
Apple could have taken that path if they were more open but from the perspective of a developer they are a locked-up dead end.
The phones that I think are the ones that's easiest to develop for are the Windows Mobile phones (horrible thought), but I haven't seen the Android yet, so I can't say it's better.
As for Symbian - I suspect that only Nokia will run that and that it eventually will die.
SonyEricsson is today targeting the Microsoft track, so they will essentially be diminished to a software shell and styled HTC phones.
Since you're buying more than one (Score:3, Interesting)
Buy a G1. It has the best tools (Eclipse) and the cheapest development costs ($25, and that's only if you want to distribute in the Android Market).
Blackberry is free unless you want to access certain APIs that require signing, then it's a one-shot $100. Their development environment is somewhat primitive, but you can use Eclipse and command-line tools as well.
iPhone, of course, requires a yearly $99, and they can reject you or your applications. You'd better like Objective-C and Xcode.
Series 60 (Nokia) is a PITA to develop for, though with them moving over to Qt that will get better. But don't expect their phones to be upgradeable.
Windows Mobile is easy to develop for, but Visual Studio will cost you.
bash & ssh (Score:3, Interesting)
Go with what you know (Score:3, Interesting)
My advice is, developing for mobile phones is generally more fiddly than for most platforms. Eg if you're used to developing J2EE/J2SE, J2ME is going to be familiar but irritatingly different.
The low hanging fruit is definitely the iPhone. I tried to develop for it. I failed. Here are my personal pros and cons:
Pro:
Great API exposing all the unique functionality quite well.
Good quality documentation, when you can find it. (See below)
That functionality itself is great too.
Easy to develop free apps and getting them into the iTunes application store is actually pretty reasonable and easy.
Cons
Objective C. I really just don't like it. REALLY don't like it. As a Java developer, it has some niggles that set my teeth on edge.
The development environment. If you're used to Eclipse for instance, you might not like XCode. I didn't.
Documentation on slightly deeper subjects is not always easy to find. I was sometimes left scratching my head at strange behaviour that seemed undocumented, with no recourse to investigation other than Google. This is poor.
Buying an iPhone is not cheap, specially with the contract. Guess you could get away with an iPod Touch for most functionality.
YMMV. I decided to use someone else's apps, who was already developing something close to what I wanted to do anyway. Pity, but it just wasn't worth the pain to me.
Re:Lots to consider... (Score:3, Interesting)
The BlackBerry-specific API exists because J2ME has traditionally been far too limited and incapable for what they want to do with the platform.
That being said, I just came from the BlackBerry Developer Conference and have an interesting tidbit to share...
Whenever they were implementing some new feature, whenever possible, they did it based on a JSR, and not their own home-grown API. Seriously, the presentations were littered with references to JSRs.
Re:Openmoko Freerunner (Score:4, Interesting)
I don't know, I'd prefer to develop for a phone that people are using.
Developing for the iPhone or J2ME means at least you have quite a large installed base for selling your software.
Re:I'd go iPhone: (Score:3, Interesting)
Well, now, I wouldn't say that.
Looking at the smartphone platforms, iPhone doesn't support J2ME. Android doesn't natively support J2ME, though some folk are working on a J2ME compatibility layer. Windows Mobile supports J2ME, I think, but you have to believe that Microsoft would really rather you build apps using .NET. Only Blackberry and Symbian might consider J2ME strategic, and who knows what Symbian will do after their overhaul.
J2ME is in somewhat better shape on feature phones (things wimpier than smartphones), insofar as there is no aggressive competitor...yet. I predict Android will head to feature phones.
So, J2ME is a widespread option, but there are definitely chinks in the armor.
Why would you pick the iPhone? (Score:2, Interesting)
Re:I'd go iPhone: (Score:3, Interesting)
That's why he said to develop on the iPod Touch.
Actually, he said "You can target the iPod touch as well as the iPhone" -- and how many of the other toys (GPS, etc) are available on the touch as well?
But it doesn't exist on *every* other phone. One of the huge advantages of targeting the iPhone is that you are guaranteed to have a specific feature set that you can rely on.
That is, it's one of the huge advantages of targeting one specific machine.
That's like claiming Apple's homogeneous hardware is a good reason to target Mac instead of PC. Leaving aside the possibility that you might want to actually avoid vendor lock-in, and be able to choose a different manufacturer... If you really want to use exactly one line of computers, you can just buy a Dell.
Or, put another way: Take each J2ME phone individually. You've got tens, probably hundreds of possible targets to choose from, and it's probably trivial to port between them. Or you could go with the iPhone, which you can't even develop for in the same language.
J2ME ain't that great to develop for, because you have no idea what sort of hardware you're targeting.
Again: Why not? Pick one. Keep in mind, this is for a single person.
Non-tech-savvy consumers don't like trying to figure out which software they can run, or which software will run well.
...and I'll stop you right there. Non-tech-savvy consumers don't build home automation suites, and then write custom software to run on their phone to control it.
Regardless, most services come with some sort of store in which you can buy (or download free) software which has been tested on your phone. My current $1 phone can download from something called EasyEDGE. Android has an App Store, just like the iPhone.
Some types of apps so far have been completely safe, and only a few have been outright rejected.
That's a bit like saying "It's OK to have a dictator who can rape me anytime. I don't think he's gay, so my ass is safe..."
One: You don't know that.
Two: It's absurd that you should be asked to give away that right in the first place.
There's a lot of non-tech-savvy people who would never consider ever getting any other smartphone that would love to have an iPhone.
I'm not sure about that. I would guess a lot of tech-savvy people already have a "smartphone" of sorts, one which is ready to run J2ME apps. They didn't set out to buy a smartphone, and they certainly didn't pay hundreds of dollars (plus a contract!) for it. They just picked up whatever came free with a contract.