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.
If you’re sold on Bluetooth as the communications channel, and you’re only criteria is time to a working prototype:
Why?
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).
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.
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).
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.