Slashdot Mirror
Which Phone To Develop For?
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."
You can target the iPod touch as well as the iPhone, and can develop on the iPod touch as well as the iPhone ($220 development platforms with no per-month cost).
You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas
You have a large installed base thats still growing rapidly.
And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.
Test your net with Netalyzr
That way you can control things with or without the phone. Give it a simple interface and then you can use any phone or device with the web page.
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.
My own pointless vanity vintage computing page
Technology is becoming agnostic.
Build a 'phone' ready web page and stop worrying which device will connect to it.
The Kruger Dunning explains most post on
Why not develop it for Windows Mobile? It doesn't have as many restrictions as an iPhone or blackberry, is well established, is widely available, and has a good sdk.
Though, I will say that the most flexibility would probably be from a web-based app. Then you wouldn't be limited to a phone. However, it wouldn't be too difficult to make something that could work both on Windows Mobile and desktop Windows.
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.
...and the "easiest" solution is to go the web route. You can determine, based on the browser identifier, what is connecting to your web server and adjust the CSS accordingly. In our app, for example, I use a CSS library from Google Code to make the app look like an iPhone app when I detect it's an iPhone. I use a different CSS file when it's anything Blackberry.
Your server, therefore, is what should be the controller. I'm assuming you want to connect somehow to things like the air conditioning, lights, etc. The web server can invoke a CGI program, as an example, which talks to whatever serial lines are necessary to control said equipment.
Even better, you don't need to buy the actual hardware; get XCode and you get an iPhone simulator. Likewise, RIM has a simulator for every freaking model of every phone they've ever released (as well as for the different carriers).
Total cost to you should be zip for development purposes.
...but how long will any mobile phone technology last? Will you find yourself having to re-do it all every 5 years as phone/carrier makers obsolete what you developed for?
Web based makes sense since you could possibly transition to some other technology, or, more likely, a mobile device's web access will only get better making it in-place upgradable for a long time.
Building your software to target a specific phone technology just seems terribly shortsighted for something like a house.
(IMHO, the real answer is "none" -- home automation is of limited value past a programmable thermostat and ultimately an albatross of shit that doesn't work and is expensive and time-consuming to fix. Its frightfully expensive to maintain ordinary systems like windows, gutters, and roofs, let alone a whole complex automation system).
>
You have a large installed base thats still growing rapidly.
A good fraction of said installed base has money to spend. All of them have a track record of being separated from their money with only moderate effort.
And separating other people from their money is the primary motivation for going into any business.
Those who can make you believe absurdities can make you commit atrocities. - Voltaire
Plus, if you are already a .NET developer, the learning curve is almost nil. The number of phones is still large (and, if coded right, is just a recompile to run on things like netbooks and MIDs)......and you can make a desktop version, too.
Layne