Forgot your password?
typodupeerror
Programming Cellphones IT Technology

Which Phone To Develop For? 344

Posted by kdawson
from the building-a-house-around-it dept.
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."
This discussion has been archived. No new comments can be posted.

Which Phone To Develop For?

Comments Filter:
  • I'd go iPhone: (Score:5, Insightful)

    by nweaver (113078) on Friday October 24, 2008 @04:19PM (#25503365) Homepage

    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.

    • Re:I'd go iPhone: (Score:5, Insightful)

      by geekoid (135745) <`moc.oohay' `ta' `dnaltropnidad'> on Friday October 24, 2008 @04:22PM (#25503431) Homepage Journal

      "And apple takes only a 30"

      Only?

      • by jcr (53032)

        Comparable to any other software distributor.

        -jcr

        • by dreamchaser (49529) on Friday October 24, 2008 @04:39PM (#25503691) Homepage Journal

          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.

          • by SQLGuru (980662) on Friday October 24, 2008 @05:02PM (#25503931) Journal

            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

          • by droopycom (470921) on Friday October 24, 2008 @06:30PM (#25504873)

            I do not have an iPhone, Windows Mobile Smart Phone, or Blackberry. I have a Nokia phone, and in the past i had a Motorola phone with Java.

            The thing is, as a user, I dont know where to shop for Windows Mobile apps or Symbian Apps. The only app i ever downloaded was google maps on my Razor.
            On the other hand, I do know where to shop for iPhone apps.

            I'm sure there are thousands of places to buy or get mobile apps for the other platforms, but the thing is nobody is really promoting them to the consumers.

            Apple is promoting its App Store directly to consumers, so if I was a developer trying to make money by selling to consumers, I would probably choose Apple.

            But Microsoft, RIM and Symbian probably offer have better services and tools for developers (such as no stupid NDAs). If I wanted to make money by selling mobile enterprise apps, I might consider RIM or Microsoft instead, and target my advertising directly to potential customers.

        • by geekoid (135745)

          That depends a lot.
          I don't know of any off the shelf software distributor that take 30%.

          • Re:I'd go iPhone: (Score:4, Informative)

            by lysergic.acid (845423) on Friday October 24, 2008 @10:46PM (#25506651) Homepage

            well, Android Market takes 30% as well. according to Google [blogspot.com], developers are required to pay a one time $25 application fee when they register, after which they're free to upload their applications without any need for validation or approval. so instead of having to go through Apple's block box approval process, quality control will be implemented through a collaborative filtering system (user ratings) similar to Mozilla's extensions library.

            it's been stated that developers will receive 70% of the revenue from each purchase, so that's inline with Apple's 30% service fee. though apparently Google doesn't receive any of the money made from Android Market:

            developers will get 70% of the revenue from each purchase; the remaining amount goes to carriers and billing settlement fees--Google does not take a percentage. We believe this revenue model creates a fair and positive experience for users, developers, and carriers.

            so again it looks like the cellphone carriers are trying to get their grubby little fingers on other people's money solely on the basis that they control the proprietary cellular networks the public depends on. well, at least it's good that Google is encouraging innovation and opening the platform to independent developers.

            with the collective weight of the Open Handset Alliance [wikipedia.org] (which is composed of pretty much all of the major players in the mobile phone/smart devices industry) behind the Android platform, it has a good chance over overtaking Windows Mobile and dominating the mobile devices market. i mean, Android has pretty much vertical as well as horizontal integration. they've got all the major mobile carriers, software developers, handset manufacturers, semiconductor manufacturers, and handset manufacturers. the only big names companies that aren't behind Android are Apple, Microsoft, and Verizon. personally, i don't think they stand much of a chance against the OHA.

            Apple gets their iPhone processor/chipset from Samsung and Marvell, both of who are now member of the OHA. and HTC, a major Taiwanese ODM that develops many popular Windows Mobile-based carrier-rebranded handsets has also joined the OHA. we know that their recently released T-Mobile G1/HTC Dream's Qualcomm MSM7201A processors (shared by the Palm Trio Pro) supports Android, so it's likely that other Qualcomm MSM line processors will also run Android. and it's reported that the HTC Vogue/Touch (Vodafone VDA Touch, Okta Touch, O2 XDA Nova, T-Mobile MDA Touch) can also run Android on is TI OMAP 850 processor. so chances are, other handsets based on the OMAP line will also support Android.

            in fact, _all_ of HTC's smartphones [wikipedia.org], which represent a major segement of Windows Mobile handsets, use CPUs designed by other OHA members, including Texas Instruments, Intel, Samsung, Marvell, and Qualcomm. and if the one of HTC's Windows Mobile-based devices already runs Android, then the rest may will likely follow.

            and a look at other Windows Mobile Smartphones [mobile-sg.com] shows that they all pretty much run on the same TI, Intel, Marvell, Qualcomm CPUs. so it seems these OHA members produce the vast majority (if not all) the CPUs used in mobile devices--or at least those currently running Windows Mobile. under these circumstances, i would not be surprised at all if Android starts supporting replacing Windows Mobile as the dominant mobile operating system.

      • Re:I'd go iPhone: (Score:4, Insightful)

        by FreeBSD evangelist (873412) on Friday October 24, 2008 @07:42PM (#25505499)

        Considering that they are taking care of all the billing, credit card processing, accounting and running the distribution/download site, yeah. I'd call that "only".

      • Re: (Score:3, Insightful)

        "And apple takes only a 30"

        Only?

        He covered that with the bit about the 'nice distribution system'. Apple's training their customers to pay for apps. The real question is: Despite the 30% cut, would a developer still make more money? The amount Apple makes is immaterial.

      • Re: (Score:3, Insightful)

        by Sentry21 (8183)

        Only, including the cost of development tools, distribution, credit card processing, bandwidth, etc.

        You write your app and upload it, and then Apple sends you a cheque. Sounds like a pretty damn good deal to me.

      • Re:I'd go iPhone: (Score:5, Insightful)

        by EXMSFT (935404) on Friday October 24, 2008 @09:41PM (#25506347)
        You're kidding, right? Apple gives you a complete retail channel with a storefront and an end-to-end transaction that is brain-dead easy for the consumer, and leaves nearly nothing for the ISV to do besides make software, sign agreements, and "pay rent". You'd lose nearly as much if not more to a brick and mortar big-box store if you were wholesaling to them - and then you have to set up an entire retail channel - which ain't easy. People keep underestimating the value that Apple gives in this deal.
    • Re:I'd go iPhone: (Score:5, Insightful)

      by SanityInAnarchy (655584) <ninja@slaphack.com> on Friday October 24, 2008 @04:25PM (#25503471) Journal

      You're practically self-parodying here...

      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).

      Excluding, of course, the per-month AT&T contract.

      You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas

      All of which exist on other phones.

      You have a large installed base thats still growing rapidly.

      vs, say, J2ME, which has a huge install base that shows no signs of collapsing.

      And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.

      "Only" 30%? And they can pull the plug on your app any time they want.

      All you've managed to do so far is to show that it could work, not why it's better than anything else.

      • I think he's being sarcastic but hey that's just the way I took it.
      • Re: (Score:3, Insightful)

        by Anonymous Coward

        Excluding, of course, the per-month AT&T contract.

        That's why he said to develop on the iPod Touch. You don't need a contract with AT&T for that, and it can do everything the iPhone can (except it doesn't have a microphone).

        All of which exist on other phones.

        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.

        vs, say, J2ME, which has a huge install base that shows no signs of collapsing.

        J2ME ain't that great to develop for, because you have no idea what sort of hardware you're targeting. Of course, it totally depends on what sort of applicat

        • Re: (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

      • Re:I'd go iPhone: (Score:5, Insightful)

        by bjackson1 (953136) on Friday October 24, 2008 @05:27PM (#25504233)

        You're practically self-parodying here...

        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).

        Excluding, of course, the per-month AT&T contract.

        You have some very interesting features (accelerometer, GPS, camera) which make for some particularly interesting ideas

        All of which exist on other phones.

        You have a large installed base thats still growing rapidly.

        vs, say, J2ME, which has a huge install base that shows no signs of collapsing.

        And apple takes only a 30% cut of revenue, in exchange for a nice distribution mechanism.

        "Only" 30%? And they can pull the plug on your app any time they want.

        All you've managed to do so far is to show that it could work, not why it's better than anything else.

        Excluding, of course, the per-month AT&T contract.

        Yep, last time I used my iPod Touch I had to pay AT&T. Learn to read, please. You have some good points about J2ME, but spouting off non-sense doesn't help.

      • Re: (Score:3, Interesting)

        by mmurphy000 (556983)

        vs, say, J2ME, which has a huge install base that shows no signs of collapsing.

        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 overha

    • Re: (Score:2, Informative)

      by Anonymous Coward

      A little unclear from your post if you are trying to sell an application or if this is for your own house that you are building.

      If you want to sell an application, Apple provides a great distribution mechanism albeit a currently buggy suite of tools to get your application onto the store.

      If it's for personal use, they also provide an ad hoc means for loading applications on specific devices without having to post it to the application store.

      Something to keep in mind is that if you want to develop on the iPh

    • Re:I'd go iPhone: (Score:4, Informative)

      by alexj33 (968322) on Friday October 24, 2008 @04:33PM (#25503611)
      You've got a nice long road ahead of you if you target the iPhone.
      http://www.gizmodo.com.au/2008/09/how_apple_picks_which_apps_make_it_to_the_app_store-2.html [gizmodo.com.au]

      That is, unless it's a flashlight too.
    • by AliasMarlowe (1042386) on Friday October 24, 2008 @04:39PM (#25503689) Journal

      >

      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.

    • by JimDaGeek (983925)
      Thank you Apple Employee. That was a great ad for your products. :-)

      Those "Interesting" features don't do anything for this topic. Accelerometer? Would this developer shake the IPhone to turn on a light? Silly and not a natural program feature. GPS? Would this developer use GPS to automate something in the house? Not likely. Camera? That is not unique to the IPhone, so no points there.

      Only 30%? Your freaking kidding right? So I spend tons of time and money to design, develop, debug, etc an
  • 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.
    • Re: (Score:3, Interesting)

      by Z00L00K (682162)

      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 ye

  • web based (Score:5, Insightful)

    by thetoadwarrior (1268702) on Friday October 24, 2008 @04:19PM (#25503377) Homepage
    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.
    • by Kamokazi (1080091)

      Agree on the web-based. Make it work with most mobile browsers, and it can also work from a desktop. Hell it could even run from standard (or non-standard, rather) phones with simple browsers if it's friendly enough.

      And fooey on you for excluding Windows Mobile...I know hating Microsoft is the popular thing to do around here, but you should give credit where it's due. It's the best OS Microsoft has ever made. Which isn't saying much, but I like it because it has the best variety of apps and flexibility

      • I have a Windows mobile phone as spare and it's not the worst OS ever. It definitely has issues that's for sure and its game support is rubbish.

        That said Windows Mobile wouldn't be a bad idea except for that it still limits you. If someone wanted to use MS then do a .net web app. People in general aren't that keen on Windows Mobile on their phone so picking an unpopular OS would limit your choice in phones....unless you do it in Java but then it's not really developing for Windows Mobile.
  • Definitely Web-Based (Score:5, Interesting)

    by TellarHK (159748) <tellarhk.hotmail@com> on Friday October 24, 2008 @04:20PM (#25503391) Homepage Journal

    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.

    • by swb (14022) on Friday October 24, 2008 @04:31PM (#25503577)

      ...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).

      • by vux984 (928602) on Friday October 24, 2008 @04:49PM (#25503779)

        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.

        I'd teir it. A web service tier that does all the actual work. A web based front end, lowest common denominator UI for any device including a laptop, it uses the web service to get things actually done.

        Then you can just build a phone UI directly against the web service for any device you want a more 'slick mobile application' for than accessing it via the web.

  • by geekoid (135745) <`moc.oohay' `ta' `dnaltropnidad'> on Friday October 24, 2008 @04:21PM (#25503399) Homepage Journal

    Technology is becoming agnostic.
    Build a 'phone' ready web page and stop worrying which device will connect to it.

  • Web Based (Score:3, Insightful)

    by Gat0r30y (957941) on Friday October 24, 2008 @04:21PM (#25503413) Homepage Journal
    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.
    • by Lumpy (12016)

      It's easy to write for. Not easy to get your app to where people can buy it. I know of 2 guys that cant get their apps approved for sale.

      it's the one and only reason I hate the iphone.

    • Writing for Android is pretty darn easier.
  • Windows Mobile? (Score:5, Informative)

    by Flyskippy1 (625890) on Friday October 24, 2008 @04:22PM (#25503427) Homepage

    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.

    • by Bert64 (520050)

      Trouble with developing for windows mobile is that you end up with apps that only run on windows mobile...
      If you develop for the unofficial iphone sdk you can create portable apps, same with other unix and java based phones.

    • by Arterion (941661)

      Yeah, I was really wondering why it wasn't listed as one of the "obvious choices", considering it's probably the most open platform.

      I definitely agree on the web-based app part. You can target the browser for whatever phone you end up dealing with -- and it wouldn't be too hard to write it for multiple different phone browsers, by just changing some of the presentation code.

  • by w3woody (44457) on Friday October 24, 2008 @04:22PM (#25503439) Homepage

    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.

    • by chaim79 (898507)
      Also, you can setup your web server with device-specific includes, now you can have CSS one way for the iPhone, another for the blackberry, another for a laptop, etc. Updating to a new device would be as simple as updating the includes and tweaking the CSS. Using this method you would be developing for just about all devices at once! A user could use several devices to check/update/etc all with very little support effort on your part.
  • 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

  • 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.

  • 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 practic

  • J2ME or Web (Score:4, Insightful)

    by jaminJay (1198469) on Friday October 24, 2008 @04:24PM (#25503465) Homepage

    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).

  • iPhone and OS X (Score:5, Insightful)

    by BWJones (18351) * on Friday October 24, 2008 @04:26PM (#25503487) Homepage Journal

    The cool thing about developing for the iPhone is that you are *essentially* also developing for OS X. So its almost a twofer.

  • by wandazulu (265281) on Friday October 24, 2008 @04:27PM (#25503505)

    ...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.

  • 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

  • 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 happ
  • WAP & TAP (Score:5, Interesting)

    by Marxist Hacker 42 (638312) * <seebert42@gmail.com> on Friday October 24, 2008 @04:47PM (#25503745) Homepage Journal
    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.
  • I recommend you just develop a web-based solution using Django [djangoproject.com]. (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

  • by Beardo the Bearded (321478) on Friday October 24, 2008 @04:58PM (#25503879)

    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 [automationdirect.com]

    Of course, I'm just an EE that works in automation and control. What do I know?

  • by 0xdeadbeef (28836) on Friday October 24, 2008 @05:00PM (#25503911) Homepage Journal

    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.

    • by Octorian (14086)

      The BlackBerry code signing key is now only $20.

      They're also serious about a new Eclipse plug-in, which is far more capable now in its second beta, with full build and debugging/profiling integration. (Seriously, no one actually uses their provided IDE)

      Also, BlackBerry is a very open platform to develop for, in that you don't need anyone's permission to distribute your apps, and have a lot of power in what you can do on the device.

      I just attended the BlackBerry Developer Conference earlier this week, and t

  • bash & ssh (Score:3, Interesting)

    by ngworekara (1027704) on Friday October 24, 2008 @05:02PM (#25503925)
    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.

  • by Drasil (580067) on Friday October 24, 2008 @05:13PM (#25504059)
    You gave the answer yourself: use a web interface and any phone with a browser.
  • by Fross (83754) on Friday October 24, 2008 @05:14PM (#25504069) Homepage

    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.

  • 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
  • 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 HD

    • by rainer_d (115765)

      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

      In other words: turn your house into the biggest microwave in the whole neighborhood.

  • PalmOS (Score:4, Funny)

    by RomulusNR (29439) on Friday October 24, 2008 @05:49PM (#25504453) Homepage

    It's the granddaddy of PDA OS and it's making a comeback.

    I said it's making a comeback, dammit.

    Grr.

  • by Heembo (916647) on Friday October 24, 2008 @05:54PM (#25504509) Journal

    Build a bare-bones web app. Works on all phones and you can tweak it as your taste in phones change.

  • 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".

  • 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.

  • by ChrisA90278 (905188) on Friday October 24, 2008 @06:09PM (#25504651)

    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.

  • by John Hasler (414242) on Friday October 24, 2008 @06:11PM (#25504683) Homepage

    Solid and reliable, if a bit lacking in features.

  • 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.

  • by aaandre (526056) on Friday October 24, 2008 @06:14PM (#25504707)

    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!

  • Nokia, or 100% WAP (Score:2, Insightful)

    by hydrofix (1253498)

    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,

  • by Dan East (318230) on Friday October 24, 2008 @10:51PM (#25506683) Homepage Journal

    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.

    • Re: (Score:3, Informative)

      by phantomfive (622387)

      Things I've heard that concern me are a non-standard programming language,

      Non-standard programming language? Come on, if learning a new language puts you off, then you really need to work on your programming skills. What is a 'standard' programming language, anyway? C#? Objective C is 100% backwards compatible with C, and will take you an afternoon to learn. Your much bigger problem will be figuring out the API, since it is significantly bigger.

"You need tender loving care once a week - so that I can slap you into shape." - Ellyn Mustard

Working...