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
I'd say, if you already have experience programming, go with what you know. If it's web based, get something that has a larger screen. If it's Java, go with those that have a Java OS.
Just me
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
Id be hesitant to lock you into a platform before you even get started. That said, developing for the iPhone is pretty darn easy, if you are ready to get going, you can get off to a real quick start on it.
Prediction: The real iPhone killer is going to be sex robots from Japan. Think about it.
You can get the phone in Canada RIGHT NOW, you don't have to hack it like an iPhone or beg someone in the USA to send you one like the G1, and it is completely open source so there is no stupid EULA's to get in the way.
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.
Doesn't Smart Home already have this kind of thing, only profesionally developed and tested? I was under the impression that they supported things that were flexible enough that you could do pretty much anything with it.
If you absolutely need to develope it yourself, how about making it web enabled. Then it could be accessed from any web enabled phone. You'd have to implement a certain amount of security of course, don't want some jackass next door turning your lights on and off during the middle of the night.
Not even a mention for Windows Mobile?
Not that I care either way (though my current phone is an HTC TyTn II), but interesting how quickly it fell in popularity over the last year.
A government is a body of people notably ungoverned - AC
If you make some basic assumptions about things like useable screen-size and a touchscreen, I'd think you're best served going with a web-based interface. With the latest generation of phone browsers, it's close enough to a normal web browsing that you can make something useable and extremely portable across different phone platforms. You gave only a cursory explanation of what your program would have to do, but it sounds like it wouldn't be terribly intensive, so a web based system seems to be very practical.
One time I threw a brick at a duck.
Seriously consider using either J2ME or Web-based content. You can never rely on any one thing, but standards like these should allow you to change target platforms more easily in the future when the company you've chosen to follow either busts or, more likely, drops one of the features you've relied upon and you have a large amount of rework ahead of you.
(My fantasies always revolved around the Palm, but that was the standard when those dreams began).
Leela: "Is all the work done by children?" Alien: "No, not the whipping."
The cool thing about developing for the iPhone is that you are *essentially* also developing for OS X. So its almost a twofer.
Visit Jonesblog and say hello.
...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.
Use Yahoo's Blueprint. The app will then be compatible with many phones. They also have an emulator so you don't need to buy prototyping phones. Or at least not as many. http://mobile.yahoo.com/developers/roadmap
I personally love the iphone, but if price is an issue that is definitely not the way to go. You have to pay for the phone, 2 year contract, and $99 for the sdk. I'd say android would be your best bet. It's going to be very popular soon.
I'd go web-based or Java, since many phones support it.
Think of the problems if you develop for a specific platform and it becomes obsolete. I imagine your home will be around for many years, but I doubt any interation of Android or the iPhone will be. Unless you plan to change around your programming when you get a new phone.
Anything that has strong ties to legacy software or hardware will be supported for a longer period of time. Look at user-base, ease of installation and repair, and of course, the track-record of the company...Apple would be a bad choice, I can see them switching things up without notice and all of a sudden you can't dim your lights.
You should target the iPhone and the various Blackberries as you can get both in Canada and they both have large installed bases.
You can't go wrong with MS
...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).
That way you can develop the web page first, then tailor a platform-specific app to your user base later on.
Apple's IPhone, Obj-C and you need an intel mac dev platform + Apple dev license. But if you got those yea it's pretty fun to dev on. Not really the same as the others though. RIM's Blackberry, supports generic j2me and has it's own incompatible java api too. Nokia's line (Symbian), supports generic j2me. Android phone we can get in Canada. java based but not the same as generic j2me. J2ME generic app. Preferred if you just want to make the app once and have it support the largest number of devices. (doesn't allow the really cool stuff though) Web-based UI. Never tried this since I only work on mobile games. The other dev handles WinMo though it seems pretty easy to work with. Also keep in mind that Verizon likes it's apps in BREW. And if you're going international, most support various versions of java. (often incompatible though)
I might be biased, as we've developed over seven web-based apps for iPhone + mobile and it seems to be the best solution. If you have the budget for several platforms, I'd next go with iPhone. Widespread Android adoption will be a slow process, and a little too exclusive (did I just say that, even though I'm an iPhone user?!? ha). Other platforms, unless your ecology currently has a wide adoption of some particular platform, aren't widespread enough, and there's plenty of iPhone adoption that's already happened/happening.
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
Thinkingman.com New Media
>
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
Except with many smartphones you aren't locked into a single point of sale. There are plenty of very good Windows Mobile applications that vendors sell directly to the consumer, for example.
For this purpose, I'd go dual interface, and not bother coding on the phone itself.
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.
SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
I recommend you just develop a web-based solution using Django. (Or any other web platform of your choice, but Django is the one I have used and I love it. Django makes it easy to do whatever I have needed to do, and I have done some unusual stuff with it.)
Then, you can use any phone with a decent web browser, plus you could use a PDA, a netbook, or anything else. You likely will live in the house for many years, and technology certainly will evolve... a simple web solution is pretty future-proof.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
use J2ME!
Its very powerfull
Its open, you can do whatever you want
Its easy to develop for
Its secure (well, more secure than the other players)
Its well supported and documented
It cover 95-99% of the market
All you need is a PC/Mac and a recent phone.
You can develop on Windows, OSX, Linux, *BSD, Solaris, etc.
The development tools are awesome
Waiting for Windows Mobile 7 myself before I start writing any code, but I think the advancements in .NET make it easy to write, though I'm not really sure how worthwhile on a whole.
I like Apple's applications, but it's a big fuss to get development rights, and it never touches an enterprise.
I guess it is something up to you, and your skillsets.
The price is always right if someone else is paying.
I'm starting my development on a rotary-dial Ma-Bell phone. Only sold in black. Infinite talk time, no limits on storage. Simple intuitive interface.
Every time you call tech support, a little kitten dies.
All phones come with sms, blackberries with email etc. No need to mess with browser navigation and logging in and sending a message is really easy.
Something like www.mobiledatanow.com or www.activexperts.com would work as they use messaging.
Consumer-grade crap is crap and it'll fail.
Get a real automation system and wire your house up properly. Hell, with what you're spending on your phone "solution", you could easily get some PLC controls and wire up your house so that it will last for the life of your house.
Here's some less-expensive stuff, but still of very good quality:
http://web4.automationdirect.com/adc/Home/Home
Of course, I'm just an EE that works in automation and control. What do I know?
---
ECHELON is a government program to find words like bomb, jihad, plutonium, assassinate, and anarchy.
I would chose a phone that I can develop for, without having to get on my hands and knees to beg permission to use their precious SDK. Self-respect, ya know.
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.
I can't imagine building an app like this that is almost guaranteed to change over time and then tying it to a particular mobile phone platform, which is also guaranteed to change over time.
If you do all your automation interface as a web application, then you can customize the UI using your favorite methodology for whatever browser is connected. A simple text based interface for older phones, all the way through to a rich interface for iphone-style phones that have full featured browsers.
~ The Fudge Report @ http://mywebpages.comcast.net/fudgereport/
Windows Mobile? That gets you many PDA's, in addition to mobile phones.
I use midpSSH (a j2me app) to control a number of bash scripts/command line programs for my media center computer from a non qwerty phone. The program allows commands to be saved into command lists, suits my needs, and let me sell my samsung blackjack (received for free from an AT&T upgrade) and downgrade to the slightly less ostentatious samsung a707 sync. It seems like you might want to write the code for the fun of it, but if you're looking for a quick solution, anything you can do from the command line can be done with this arrangement.
Don't do it if you ever expect to make money in the process.
For-profit software development is about as successful as being discovered in Hollywood. Millions of people out there trying to be rich and famous and only a limited few will ever make it. Write software because you are good at it and enjoy it. Don't expect to live off of it, let alone make your fortune like iD.
If you write it in J2ME, and stick to a relatively commonly used subset of J2ME, you'll be able to run it on any phone you might have that supports java. iPhone is a nice flavour of the month, but will you ALWAYS have an iPhone? If there's any chance of ever switching phones, suddenly all your objective C is useless. If you target J2ME, you'll be able to run it on any Blackberry or Nokia phone at least, and possibly Android as well (though admittedly I'm not too familiar with Android).
Write it once, run it anywhere. Makes sense, no?
You gave the answer yourself: use a web interface and any phone with a browser.
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.
Have you heard of Tridium? Their JACE box (sold though various OEMs - Honeywell, Siemens, JCI, etc., and authorized contractors) can take care of the control and the web UI very well. Then all you need is a handheld device with wi-fi to reach a web page for control functions.
bias alert: I work in commercial building automation controls and I am certified in the Niagara-AX Framework.
This is such a DUH discussion. I wonder if the guy asking this question even has the know-how to execute on this plan if he's asking this question in the first place. Web-based beats all for this one-off scenario.
Seth
$5 / month hosted VPS on linux = awesome!
Develop for the the Open Moko phone.
You will have control over the entire operation of the phone, and have the interface do exactly as you would like.
I used Hal 2000 almost 10 years ago, and it worked really well. I'm betting that it is refined even more for today. I had wished back then I could have developed a better tool, but now that you mention it, the cell phone would work great. I make my own small radio transmitter to send voice commands to the computer. You can also call the computer from a phone and give commands. Perhaps something that simply sends the voice from the phone to the computer would do? Now you're compatible with all phones much faster. www.homeautomatedliving.com
jsut athnoer menagiensls ltitle psrhae for you to dcoede. Why do we wtsae our tmie dnoig tihs?
J2ME is a fairly well defined language without the first version problems still inherent in the iphone market. It's also fairly wide-spread (except on the iphone) and you don't have to be tied to one carrier.
Those who are suggesting a web-based approach must have huge phones with high bandwidth. On my last 2 phones, using the web-browser (built-in or Opera mini) was just painful whereas the Java apps were easy to use (I've used GMail, Google maps and a Sudoku app).
My mind works like lightning. One brilliant flash and it is gone.
If you have good reasons to not develop a web app do Windows Mobile with .NET (good reasons, you care about the 'prettiness' of the UI, you care about bandwidth costs or speed, you care about unique or more usable controls - sure the web is cool but it still basically sucks on most mobile devices)
Assume you dont have a decent data plan in your area a Windows Mobile might be the best choice, you could then do the controls on your house easily through a direct dialup connection or through text messaging, etc. You could say that other platforms have this capacity but I'd argue you could do it faster in .NET
Fastest platform to develop for (assuming you have visual studio) .NET has an excellent set of libraries that can help you in this respect and Windows Mobile phones are the most accessible (accessible as in, choice of plan, provider, software, and hardware). .NET for mobile platform is very easily translated into a web application or into windows application, but its definately the platform that would be the most usable for you and you can draw on a development community that has been strong for over 5 years.
Also with the release of NVidia's new apex chip WM with get a real jump start that the mobile computing market needs.
I'd suggest developing for the Openmoko Neo Freerunner. It's an excellent platform!
I put together a rocking multi-room home entertainment set up for a fairly reasonable price that required no professional installation or wiring. And it's all controlled by my iPhone, but an iPod touch would work as well.
Here's my set up:
2 macMinis - one is your streaming media server one is for synching
1 airport extreme base station (N band wifi)
1 airport extreme base station (older b/g band wifi)
2 appleTV's (1 for each movie viewing room)
3 airportExpresses (1 for each audio only room)
1 drobo with 2x1TB HDs
1 iPhone
1 iRemote app (free from Apple Store)
With this setup, I have all machines sharing a single NAS device that holds over 200GBs of movies and music, plus TimeMachine backups. Each airport express allows plug and play audio streaming from iTunes. The appleTV does that as well, but provides the ability to watch movies from my iTunes library and control iTunes on my mini (or other machines)
So this gives you a multi-room audio and video network.
This can all be controlled over wifi via the iPhone with the iRemote app which is a free download from the iTunes App store.
The caveat is that at this time neither the iPhone or iPod touch support N band wifi. This is why I have two extreme base stations ... the iPhone only supports B/G right now, so you'll need to set a B/G base station in bridgemode connected via cat-5. If you set up only one in B/G/N, you can run into network degradation as slower B/G devices slow your home network, you really want N for the fast throughput.
Why have 2 mac Minis? That's my preference, one streams, one synchs the AppleTV units, there is a difference there and I'm sure you might have your own way of doing things. The streaming server also hosts a NiceCast ($40 from rogueAmoeba) audio stream from whatever is playing on that machines iTunes.
The drobo is my preference for a fast and easy NAS set up that can scale to 2+1TB, which is more space than I'll need for music+movies +file backups in the next couple years.
Of course this setup only controls the flow of iTunes media and active room units, other things like DVR/slingCast will have to go with a standard universal remote. For that, I strongly suggest Harmony remotes from Logitech. The 890 works quite well, and has RF support.
It's the granddaddy of PDA OS and it's making a comeback.
I said it's making a comeback, dammit.
Grr.
Terrorists can attack freedom, but only Congress can destroy it.
Granted I don't know about software development, but I thought that the way Java was supposed to work was develop once, and easily port to multiple platforms.
Build a bare-bones web app. Works on all phones and you can tweak it as your taste in phones change.
Horns are really just a broken halo.
Maybe I'm missing something obvious here, but who's going to be living in the house? I'd write the software for whatever that person uses. If there's not a specific person, then I'd write software based on the platform market share in your area.
Just ignore anything else! Don't waste time learning new APIs, etc. Expensive and annoying proprietary platforms, and I'm an iPhone developer (i.e. if you're not already developing for it, and you're not doing something like 3D graphics, forget it, it's time-expensive).
Thinkingman.com New Media
I have to decide on a mobile phone to develop for ... What would you choose if you had to go with one?
Why not pick the one that's a decent phone?
(or browser, or camera, or whatever the hell else you're going to use it for)
Hopefully you'll be using the results of what you've developed for longer than you spend developing it. If not, I think that you've missed the point of "automation".
I work in a small company that develops for all of the above, plus Windows Mobile. For ease of internet connectivity, I would definitely go with Windows Mobile over anything else.
I just finished writing an app for the iPhone which had to upload files. Before that I ported an app from J2ME to Blackberry that had to download data, and have since ported that to Windows Mobile as well. The support for Windows Mobile is enormously more extensive than that for iPhone, and definitely has more kinks worked out. Some of the errors I run in to on the iPhone are obviously glaring bugs in the framework. However, since so few people have developed apps using Objective C and the apple framework as compared to generic C++ for Windows Mobile, there aren't any solutions or workarounds yet.
Also, the iPhone framework is somewhat restrictive on what you can do, compared to Windows Mobile, or even some J2ME devices.
Internet connectivity with the Blackberry is confusing on several levels, and good luck if you want to do anything besides HTTP.
If you're looking for power, go Windows Mobile (some new HTC device). It's by far the easiest platform I've worked with so far to debug on, and like I said, I've worked with J2ME, iPhone, Blackberry, and Windows Mobile. (Just starting on Android, so no suggestions there as yet. From what I've heard, it's api looks a lot like the iPhone).
--Edward Dassmesser
Hang a crap phone off the back of your computer, and send/receive SMS through it. That's relatively simple to do. Then, you can carry a phone that you actually like instead of one that's easy to develop for. And you get to boast that your house has a command-line interface. :)
It isn't that much harder to get your home PC to send you MMS, should you want to see what's going on.
Nokia N800/N810 are Linux-based. They run a lite-gui called Maemo which is cross platform and GTK-compatible (i think).
Or just develop a web-app optimized for a few different screen sizes.
The issue that most folks miss is the "sometimes connected" nature that your app needs to deal with. If you are writing apps for businesses, much of the data should be cached local and uploads can wait until you have connectivity. Being out of service shouldn't stop the worker from moving on to the next task. Push the data later when you're back in coverage. The BlackBerry API knows about this stuff. I was responsible for deploying 20k blackberries with custom apps on them. The corp architects said to do a web interface so it could be reused inside the company too. They missed that about 10K of those users were in rural locations with spotty data coverage. The app was worthless for them. We had to implement a blackberry specific app that grabbed data for future jobs and cached data captured while on the job for later transmission.
Don't design around a any phone that is on the market today. design around some standard interface. the you program whatever phone is popular this month to use that interface.
Solid and reliable, if a bit lacking in features.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
Windows Home Server has nice add-ins and applications for houses wih automations. And there are add-ons to expose these to Windows Mobile devices. The two together ends up with a fairly interesting proposition.
Is html / wml with a web server backend.
Apple users are well-trained to pay premium for everything, from the iphone accessories to the software applications.
I'd go for the well-paying techno-lusting, in-love-with their device user base.
While the bberry is highly addictive, it's used almost exclusively for the simple tasks of email/calendar/phone.
May I interest you in developing a $10,000 application which will display a message saying "I am filthy rich and you are my bitch!" on said device?
Good luck!
Isn't this like designing a car based on what sound system the customer might own?
If your product is "the next big thing", the phone makers will adapt to you.
As for which phone you should start with to get established, do you believe /. is the place you will find most of your initial adopting customers? Survey them. Know your clientele.
You can get the phone in Canada RIGHT NOW, you don't have to hack it like an iPhone or beg someone in the USA to send you one like the G1, and it is completely open source so there is no stupid EULA's to get in the way.
You know, in some ways that phone is real appealing... Particularly the whole "hackable" aspect. In other ways it looks like complete garbage, at both the hardware and software levels... I have trouble these days getting past the lack of a keyboard. I mean, I was a Palm fan until they decided to stop meaningfully improving the OS, so I'm down with pen computing - but I've also been using a Treo 650 for a couple years now, and I use that built-in keyboard all the time. I hate the idea of being without that.
I would be all over the G1, personally - except I hate the idea of a mobile device that doesn't allow you to develop and install native code. I don't like the idea of a Linux system that can't run "bash", or run the same software I run on my Linux machine at home... And I don't like the whole idea of my phone having to waste cycles converting one instruction set to another. I've had enough of that on the Treo with PACE.
Of course I recognize the benefits of a virtual environment for sandboxing, and of an API that's really designed for phone use... But to me the point of running Linux on a device is to be able to do Linuxy things with it...
All this is almost enough to make me turn to Windows Mobile - it doesn't require everything to go through an emulation layer like Android does, its operating software is a lot more mature than OpenMoko, you can get decent hardware for it (sliding keyboards, etc.)... Basically, it's still more of a "portable computer" system adapted to work as a phone (like PalmOS on the Treo) rather than "high-functionality phone" system like Android...
Why they gotta make this so hard? Android looks great except the whole "Linux appeal" is negated by the fact that you apparently can't actually get at it...
Bow-ties are cool.
Depends a bit on how compilicated the software will be. If it's very simple and a slow interface is not a problem, WAP + server-side PHP would be nice and the customers could choose any phone that supports WAP and GPRS (or whatever 3rd generation tech is used in the US) - which is practicaly any new phone in the market.
If you want to write the bulk software to run on the phone, I'd say Nokia's Symbian S60 line on Java, C/C++ or Python is a very good choice. It seems the C++ they use is a bit non-standard, but they also support Java ME which is much easier to learn. And Python.
Nokia has a pretty clean company portfolio, their SDK is based on Eclipse and all the relevant APIs are open, seem to be well-documented and full with developers manuals and code examples. forum.nokia.com is their the developer's site. Personally I have never developed mobile software, but I know some people who do mobile game development, and at least their employers seem to prefer Nokia S60. S60 has a very extensive range of phones, including touch-screen phones, and there's also a free emulator available. Sounds good, but I have no first-hands experience what so ever.
You should develop for the platform that has the most application sales, and overwhelmingly that is currently the iPhone. So if your goal is to make money, look at the phone that truly has people buying software.
In other ways it looks like complete garbage, at both the hardware and software levels...
I have a friend who has one, and is pretty enthusiastic about it from a conceptual level, but he basically says it's currently entirely unsuitable for using as an actual phone now. Which is kind of unfortunate.
Go client-server.
Set up a server that controls everything. Use existing solutions, home made stuff, whatever to control the actual thing.
Use your mobile phone to talk to this server, that way if u decide to abandon your existing "new" phone to a futuristic space gadget, you can still control your A/C from space !!
Why not develop something HTTP based, so you would be able to access it from any paltform with a browser?
The only question I would ask is: Where is the money right now? So who out there is making money with phone apps? In the future the Android might be a game changer but for now, if you are making money which platform did you develop for?
I'd avoid the iPhone primarily because of Apples want of full control, approval, distribution etc. and you are limited to one (that is not that popular in the big scheme of things) system.
If possible stick with basic java mobile and you are open to a much wider range of phones with limited restrictions.
Avoid closed systems if maximum distribution and profit is required!
You guys didn't read the question. He's not asking which platform has the largest installed base or anything like that. He's asking the best way to scratch a personal itch.
The iPhone SDK running on a OS X Leopard machine beats the development platform of those other phones hands down. The only drawback is if you =don't= want to distribute through the apps store, or Apple rejects your app, you have to buy the commercial developer's license so you can get your own signing key. But you don't have to pay anything (nada) until after you've got your application completed and running in the emulator. Then it's $99 to submit to Apple, or $299 to sign and distribute yourself.
And, at https://developer.apple.com/iphone are video tutorials, reference libraries, sample code, how to's, tools, etc.
Make it easy on yourself.
Web based is the way to go. With home automation or any interface to physical objects if you make it externally accessible you better have secure code. SQL injection may be dropping tables in a more literal sense when your house floods and your first floor meets the basement.
Why is Windows Mobile missing in that list?
PS my desktop runs linux, no fanboy.
Hivemind harvest in progress..
and a the current Android phone requires the same 2 year contract.
Personally, If I was in this situation I would develop a web based version for use with the Iphone, Ipod Touch, Symbian(?), and Android devices. They all have nice web friendly browsers and it would not cost anything to develop for them. In addition, I would also provide a Windows Mobile version for certain phones. WM is pretty straight forward, especially with VB.NET and would hardly take any time to develop for. If you already have the web based version setup, you could have the WM application use HTTP and not have to worry about sockets and protocols and all that jazz.
Keep in mind though, developing for the iphone will always only be available on the iPhone and Ipod Touch, not to mention the fact that you have to put it in their app store. With android, even though only one device is currently available, many phones will be coming out with the Android OS on it, giving your customers more of a choice, and from my experience, customers like choice :)
I'd go with a web based system and integrate zone minder in as a security camera system to have a single application for everything. You could also include a Tivo Control or a media center like XBMC. Web based also gives you flexibility as more and more devices include built in browsers. You could control your house from a Wii or pull up a web page on the screen on your internet refrigerator.
A web based system is OK, but you really lose out by not being able to use native features and the user having to work through whatever UI the phone browser presents.
A native phone app can also be more responsive than a web based app which will incur some latency, even if all on the same WiFi network...
If you're going to all the trouble to make a fancy automation system why wouldn't you go to the extra effort to make the control app the best possible app you could have?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I would suggest using an Android based phone, as you are not limited to hardware (eventually there will be more options than the G1). A web based UI would also be plausible by using the phone's browser as you mentioned, though this may leave you vulnerable to "house-hackers" (I had to :) ).
I've been playing around with Blackberry development and, I have to say, it's nice and easy. Simple, powerful, and well documented API, easy to develop and deploy, and a huge installed base. Best of all, you control your applications destiny, not another vendor.
Anthony Papillion
Advanced Data Concepts, Inc.
"Quality Custom Software and IT Services"
I've developed for both Blackberry and Windows Mobile. You can develop for both platforms for free, and do not even have to sign applications. With Blackberry you do have to sign your application to use certain Java classes deemed "secure". It costs $100 for a license allowing unlimited signing. However, you can do full J2ME (plus some BB APIs) for free. Blackberry UI, processing speed and graphics capability is very, very poor. I have recently been experimenting to push Blackberry graphically, and have hit nothing but dead-ends (for example, the native display is 16 bit RGB-565, but all APIs to push raw image data are 32 bit ARGB 8888, so a very slow conversion is done by the system). However if you stick to API-supported rendering (basic font rendering, blitting with alpha channel, simple drawing primitives) then you can do quite a bit with good performance. Just don't expect to be able to do your own bitmap-level rendering in realtime (like rotozoom, bumpmapping, texture mapping, etc). All development must be done in Java.
Windows Mobile offers a ton of CPU power and RAM (I've ported both Quake I & II for example). Devices are available with 3D accelerated GPUs, touchscreens, VGA-resolution displays, CF, SD, Wifi and Bluetooth (all in a single device even). So as far as raw options in hardware capability and form-factor, Windows Mobile gives you the most choice. If your app will do some really heavy lifting graphically then Windows Mobile is the better choice. You can develop in the widest variety of languages for this platform - C, C++, C#, Java, ARM assembly, Pocket C, and Visual Basic (just to name some off the top of my head). With both iPhone and Blackberry you are restricted to a single language.
As far as iPhone goes, I've not delved there at all. Things I've heard that concern me are a non-standard programming language, restrictive distribution policy, and whether or not you can simply write and build an app and stick it on your own phone or not without having to sign it or otherwise register it with Apple.
Better known as 318230.
why the fuck are retards tagging every mobile with openmoko, and acting like it's going to be the next big thing?
I have some news for you fucks, it's out already and it flopped. it will NEVER be a big thing. you'll be lucky if it becomes a small thing. right now it's on course to go down in history as a dismal failure
I don't know about everyone else here, but from reading TFOP, it looks like he's working for a housing developer trying to build a house that can be controlled from the client's phone (it's not clear whether they are building for a specific client or attempting to sell, but it's irrelevant). As such, the iPhone (or iPod Touch) is the worst possible platform, as the idea is clearly to provide a specific application for one client, and Apple's distribution methods simply do not allow for it. A web-based interface is surely the best, as the client then doesn't need to buy a specific phone, but I would in the near future recommend Android from a moral standpoint, to try and support it and help kick Apple's dominance (which is stupid).
Linux based and programmable and no fees :)
Oops..was I supposed to push that button?
Our company develops mobile applications for all of the target platforms you mentioned in your post except for Android.
My recommendation is to develop in Java, not because I like the language (I don't) but because it's possible to architect mobile applications so they can easily be ported to Blackberry OS, Symbian, and I assume Android. The important thing is to build your domain model and services so they'll run on the lowest-spec J2ME profile you'll be deploying on. That way most of the app will be built from a common set of libraries and the only differentiation is in the views and controllers which will obviously be different across platforms.
At the moment we're getting more requests for iPhone apps and while the SDK is nice (hate the app store, though) we end up re-writing a lot of Java code in Objective-C which is no fun. Whatever libraries you write for the iPhone will be essentially useless outside of Apple's tiny universe. Bear in mind that Nokia will ship over 400M Symbian phones this year to Apple's 10M.
When you're doing bespoke development for a target of a mobile phone the cost of developing the software far outweighs the cost of the hardware.
People being people will mean the users first impression of your software will be the hardware. So just pick the one that the end user likes the most for its other features.
threadeds blog
Well, everyone has said Iphone. It has accelorometer, gps, touch screen, easy to use store. I have heard that in Canada, it is prohibitively expensive to use for anything worthwhile. Blackberrys have a huge install base but there is the marketing issue. I personally am going to try my hand at android. I know, the new G1 is not available in Canada yet, but either it will be or you can pretty much bet that another phone using Android will be soon. Most, if not all the big names have announced they will be introducing a phone based on it. Google has the marketplace and they have said they won't interfere (you don't need Mr. Jobs to personally rub your app all over his body and proclaim it doesn't itch!). There is also that little thing about dev costs. The SDK is free, a community is beginning to appear for support, and oh, did I forget to mention the OS is open source?... For the future, I would thing that Android might be an interesting choice. Java is pretty straight forward, or I have seen a little C++ used on it. not sure where that will go but I have seen it. You can even use the FREE emulator at code.google.
"Computers are a lot like Air Conditioners" "They both work great until you start opening Windows"
I actually own one, and I'm pretty enthusiastic about on a practical level. Orrery, the star-map application is fun, Duke 3d, the whole "make a quick application with python + gtk (or e, or qt, it's all there), and if I were to repurpose a phone, there really is no point in using anything else.
Pro tip: For home automation, ReMoko may be half of what you need already.
If your friend is having a hard time using it may I suggest the FDOM (fat and dirty openmoko) image? It's got alot of applications pre-installed, plus some hacks to make it more "daily phone" worthy.
Shut up you morons. Go where the masses are. Nokia.
It all depends on what you want to do. If you are fine with a web service, go with that. If you need to be able to hack the phone to pieces, go with Symbian or Linux. If you want to create Apple looking applications, play by their rules and drink their cool aid with one sales channel only, go with apple. Finally for a Web++ experience, use Symbians webruntime for the 5th Ed. You can extend whatever you need with QT if necessary and the js is already extended with PIM, Messaging and other fun things.
Sorry about the repost, forgot to preview and put up that unreadable wall of text...
I think you just invented something there. Congratulations- you're the Phil Spector of the literary world!
(Just try to avoid the gun freak and alleged murder tendencies in 40 years time please...)
home automation is of limited value past a programmable thermostat
The programmable home thermostats I've seen can only control the furnace and the air conditioner. Because they cannot control the windows, they cannot help enforce a home climate control policy that includes opening all the windows when the outdoor temperature is in some range and then closing them at all other times.
Even better, you don't need to buy the actual hardware; get XCode
XCode alone costs $599.00 plus shipping and tax unless you already have a recent Mac.
Why are you people talking about app stores, when he's doing something that will be sold to people who are getting their house wired by the exactly same organization that will deliver the app?
If I were you, I'd go with web-based interface + J2ME for extendent interface (some video streaming, eye-candy, etc.).
I don't know much about this, ... and never really developed phone apps, ... I'm curious as much as anything.
... a QT platform for phones? ... and, you can compile it for windows mobile right? and it's owned by nokia so presumably there will be nokia devices running it, right? and it runs on the openmoko too, doesn't it? and I imagine it should run on various other mobile devices / netbooks / tablets like the asus eee pc and the nokia n800.
... maybe it's more complicated than I'm making this sound... no one else seems to be mentioning it, .. so what have I got wrong?
... and then just potentially get a couple of other devices for free... as opposed to developing for windows mobile using .net, and never having much possibility of portability?
there's that QTopia,
I've never used qtopia,
I mean, my impression is you could right it in qtopia but be "targeting" windows mobile,
I'm sure there are far more windows mobile devices out there than there are iphones, regardless of the recent popularity of the iphone. does a home-buyer want to be required to be a mac-guy? aside from web-based, my impression is that something writen in qt / qtopia would run on the largest number of devices.
iPhone and Android are different in that they provide a consistent, well designed interface on all phones (of course iphone is just one) and a online store to buy/download apps. These two facts lead to a superior user experience.
With Java/Windows you have carrier branded interfaces that are inconsistent and your app is not truly integrated into the phone software. Also all the JavaME apps I've seen are sluggish and the pain of using them exceeds their value. I had a windows mobile device for a year and it was anything but stable. My wife has a RIM curve that reboots and I know others who are frustrated with their windows mobile devices.
I think Android will be a hit. I understand it is very well designed, and all apps run as first class citizens. It should be relatively painless to port a JavaMe app to Android but I suspect they will have no shortage of excellent applications. And eventually we will see more phones.
Another possibility is to implement this using text messaging in addition to whichever phone you decide on, since text messaging works almost exactly the same on pretty much every phone out there. E.g. text "lights" to get the status of your lights, and text "lights off" to turn them off. You could also set it up so that you get text alerts to your phone when something you're monitoring in your house changes. The other good thing about text messaging is that you can validate based on phone number, rather than relying on the security of a password on a web browser (think house key vs. house keypad).
You can set up something like this for free literally in minutes using the phone number DOTCOM (368266), which lets you send and receive text messages to and from every internet domain name ad-free (just drop an index.cmrl file on your webserver). See:
http://dotgo.com/publishers
and
http://www.dotgo.com/support/documentation/doc0001.1.0/html-1/
(Disclaimer: I'm a co-founder of DOTGO)
It seems people are forgetting this poor soul is Canadian and didn't say he was selling the app. I'm using an HTC Touch on the Bell network, I pay $7 a month for unlimited internet and the phone is free on a 3 year contract. This is a great option for keeping your costs down. As stated previously above Windows Mobile is really simple to get your applications on. If you do web I suggest a different browser, but there are some really strong ones on the market from Opera, Skyfire and Netfront. You could always make a simply mobile page which pocketIE could produce quickly, so there are a lot of options. The point is, to use a low-cost, low distribution solution, a WinMo Phone from Bell is likely your best bet at the moment.
Go LonTalk and use an i.Lon. Don't waste your time with X10 or zigbee bs. Use an FTT10 comm hardwired between all of your nodes and the i.Lon as a web interface. It's cheap and quick a d will work with any phone or pc
If you go with a web based app.... use a WURFL library + DB to discover phone capabilities. It's a really easy library/class you can get for PHP, JAVA and .Net
WURFL on Sourceforge
Basically it runs a User Agent detection routine on the phone and does a look-up in a DB table which contains all known capabilities (dimensions, video codec support, html support, image support, etc.) and returns an object that you can use to turn on or off features in the web app.
A fool throws a stone into a well and a thousand sages can not remove it.
Depends on what you are coding for. If as you say, you are developing for our own benefit to control your home automation, you'd be better off using Android as you'll have more freedom to innovate and be able to code as needed at a lower level.
If you want to sell it, the iPhone is probably the better of the two, as long as you can live with the limitations.
I've done a fair amount of coding with the iPhone, and while it is nice to develop for, I constantly chafe at lacking/bad functionality/APIs that I know I could do a better job of if the platform were more open.
To extend the question a bit....I want to develop an application to encrypt and authenticate calls via an external PKI system. Do any of these phones have APIs suitable for accessing the voice stream? OpenMoko seems the only obvious choice.
perl -e 'print $i=pack(c5, (41*2), sqrt(7056), (unpack(c,H)-2), oct(115), 10);'
Apple surpassed RIM only on new sales to new customers. Not in sales to their existing market base.
It would be a mistake to start development for Apple's phones as they use objective c which I think is not as poratable as J2ME.
BlackBerry development uses J2ME APIs and RIM proprietory APIs. It would be alot easier to build apps that work on diff RIM devices and other devices with a JVM than to get locked into obj c.
RIM just announced they will have a store front and improved stuff for developers.
The only reasone ppl even think to develop for the iPhone SDK is because the phones look slick and all the teenybops want one.
Don't be fooled by the glitz.
If you want to go onto the same path as the top 5 phone manufacturers, J2ME is the best choice for the phones currently on the market, as well as the ones currently being developed. If you are uncertain on the actual required JSR's, or need hardware dependencies not supported with the available JSR's, Symbian S60 should be your choice.
It depends on what you want to develop, but if you were in india, I would have suggested you to go Nokia symbian based as it is the defacto standard for smart phones in India. But web interface is limiting, but definitely more flexible.
What "serious callers only" said, plus you seem to imply that they would NEVER test on an iPhone. The point being that you could develop and test on cheaper devices with no contract AND on an iPhone or two.
Secondarily, the Touch opens up the market to people that might find that application useful, but are locked into contracts with other carriers like Verizon, or who like their crackberry, or whatever.
Heck, I looked into getting a Touch simply to run the multitouch trackpad applications on an iMac.
Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
Check out Lagotek, they have ready built this.
Go for the phone your frickin' customers use.
~~~~~ BigLig2? You mean there's another one of me?
I actually own one, and I'm pretty enthusiastic about on a practical level. Orrery, the star-map application is fun, Duke 3d...
I was wondering how this would be possible on a device with no keys... It seemed accelerometers + touchsceen was the only possibility... I was gonna ask but got curious and looked it up... Sure enough, accelerometers + touchscreen. I can't help but think how much nicer it'd be to play games on the thing if they'd just included a handful of hardware keys... even just a 5 way navigator and a couple buttons next to it would be dandy...
This is what tears me up about the Freerunner. I got into Palms and such because I wanted a portable computer - something I could use to tinker in Scheme or Python or whatever at random times... Openmoko's software environment is great for that - but the hardware's not great for anything apart from pure pen apps. (If I'm gonna be hacking around in Python, a keyboard would be very helpful...)
Bow-ties are cool.
For the purpose you describe - strictly personal use - J2ME has all the advantages. It's pretty easy to develop for, has very good tooling (have a look at NetBeans), good documentation & a lot of books about it, and it will work on pretty much any phone you might have now or buy in the future.
if you're rich enough to do all of this you can spring for a contractor that will set it up for you. honestly, the google phone (android base) would be the most capable, but might be beyond you. an intricate setup like this requires more than a google and a random forum question. hire someone to set it up for you AND show you how to use it.
GPS support in a Web browser via a standard navigator.geolocation API is in a W3C Editor's draft http://dev.w3.org/geo/api/spec-source.html , and implemented in latest Firefox code or the Geode plug-in (with appropriate user privacy controls).
And people are talking about standard browser access to accelerometer and camera.
Don't bet against the browsers.
=S
iPhone requires a mac to develop your apps on (which you probably already know).
Some MIDP phones can install via a cable connection, but most dont. Also, you will most likely need to digitally sign your application to even get it on the phone.
The easiest phones I've worked with are DoJa phones (DoCoMo Java by NTT - it's similar to MIDP). Once you write a DoJa app you simply uploaded it to any web site and it can be downloaded to any phone - without signing or the requirement to be certified. There are quite a few overseas DoJa models, but I don't think they are that popular (I work with the Japanese ones).
I run a small site about developing for mobiles - most of the content is DoJa. You can find it at http:\\mobiledevlab.com
Good luck!
web based if you building these house for other people, you'l serverly limit them if you use any one brand. though i'm not sure about connecting gps to the phone and the web page. think garage doors opening as you arive home and lights coming on before you reach the door.
"You are still innocent until proven guilty. What's changed is what they do to innocent people." by notnAP (846325)
I would recommend this. It has gps, wifi, bluetooth, runs linux, you can get qtextended for it, or just plain debian. It uses sim cards and will work with Rogers and Fido. The sdk is free, will run on windows, linux or mac. All royalty free. And will run any linux software.