What's the quickest mobile platform to create a Bluetooth application on?

Question

Most of the time I write code for embedded modules or small programs on my computer to analyze data that said code generates. Now I've been asked to prototype a mobile application to analyze/display that data instead. I have no (6-year old CS101) experience with either of the popular languages (Obj-C/Java?), let alone with any of the APIs/libraries available on the 4-5 popular mobile OSs, so I'm more or less at square one.

Adapting the embedded hardware to talk to a phone is fairly straightforward, just add a Bluetooth module that I can configure to emulate a serial port (using SPP profile), but I don't know where to start on the other side.

What sort of mobile OS/device should I target for ease/speed of developing a Bluetooth serial port profile (SPP) application from having equal (no) experience on them all?

BlackBerry

• Everyone has one around here (except me), so this is where I'm being nudged towards unless there are significant obstacles or another is vastly better (faster)
• Smaller community
• Lots of dev-blogs moan about poor SDK/tools
• "BlackBerry devices have limited support for SPP." (PDF, p. 9)

Android

• Very few phones around here.
• API makes it seem very straightforward to look for devices and connect to them.
• Large dev community, (many more examples to peruse).

WM6

• I have a (bad) WM6.5 phone.
• Smaller community
• Phones can have various stacks (MS, Widcomm), which are not interoperable, some don't support SPP, and I don't know what my phone (HTC Ozone) has...

iOS

• Don't have/never used a Mac, iPhones only marginally popular around my organization.
• Large dev community
• Can only connect to approved Bluetooth devices(?) Kills that option dead if I read it right.

Some portable framework (Appcelerator, PhoneGap)

• Seems impossible as they can't get at the Bluetooth.

Answer 1

Just a quick note that my library 32feet.NET for Windows Mobile (and desktop) supports both Microsoft and Widcomm stacks.

Answer 2

I am not sure what the target audience for your application is, but if it is an in house or limited deployment application and you just want to get a feel for how this might work on a mobile device, it might be worth simply using an existing application to transfer a CSV file over bluetooth from your embedded device to a mobile phone you would like to evaluate, and then another existing application to analyze the received CSV file.

There are bluetooth file transfer applications available for Android and Windows Mobile at a minimum and I think it is possible on blackberry also (but not officially for non jail broken iPhone yet as far as I am aware).

There are also applcitaions to view and edit csv files on these platforms (e.g google 'Android spreadsheet csv' and you will find links for Android ones).

Doing this manually will likely be pretty painful if you are doing it repeatedly but it will let you get a feel for how it might work, and maybe help with the 'look and feel' part of the decision on which phone platform to use (which you may find you are a lot more opinionated on after using several different phone types!)

A slightly more left field approach might be to build a WiFi access point into your embedded machine if this is possible (and I realise it probably is not...) and file share or even have a simple http server built in to provide the data. The latter would allow you use any phone with WiFi and a decent browser.

Answer 3

If you're sold on Bluetooth as the communications channel, and you're only criteria is time to a working prototype:

• Best Choice: Windows Mobile
• Runner Up: Android

Why?

1. iOS can be eliminated immediately. Bluetooth communication can only be achieved with an iOS approved accessory, which you can't build or buy unless you are in the MFi developer program. A standard SPP-capable embedded radio module won't do the trick (the MFi NDA prohibits me from saying any more than that).

2. I have never done Bluetooth development on the BlackBerry platform, so I don't have much to contribute here with experience, but my impression is their support is based more on the J2ME JSR implementation than anything platform specific, so you might get flakey results.

3. Android has good support for RFCOMM (where SPP lives) in Android 2.1+. Getting connected with a small module and streaming data is fairly simple, and the examples help a lot. There is one trick, though, which resides in finding the UDID that is published for the SPP service on the embedded device. The Android API doesn't do a great job (not matter how many bug reports I file) of heping you discover this value. I had to find out what it was by other means and hard-code it into applications to get things running (more on that if you're still interested).

4. Windows Mobile is the winner because you can get around Bluetooth altogether in your code, but still use it. WinMo has a Control Panel for setting up Bluetooth devices, so you can turn on your embedded radio, pair with it, connect, and attach the SPP profile to a COM port...all from the control panel. Then you can use C# and .NET to write your application and connect to your device using the SerialPort class, because it's just another COM port. This keeps you out of the WinMo Bluetooth API (which is low-level C++) or a 3rd party driver like 32Feet.Net (which isn't a bad driver).

Hope that helps. I tried to condense it down more.