Coding Blues

Some of you may know that I'm currently working on a pet project which will eventually enable me to control my PDA from my mobile phone over a Bluetooth link. I've hit a bit of a dead end, so I thought now might be good time to blog my current progress.

The project was originally split into three parts:

1. Bluetooth Communications

The two options here were either to use the BT stack natively, or just use its COM port profile transparently. The former was more flexible, neater and potentially more functional (like being able to receive a call via your headphones), but unfortunately you have to pay to use the Widcomm Stack SDK. The latter would be easier to program around, easier to get working, and most importantly free. And so I picked that to use. It was a trivial exercise in the end.

2. Creating an "AT Engine"

SonyEricsson are great. Most people consider Nokia to be the innovators in the mobile phone industry, but I've always disagreed with that. But I digress. SE have, since the T68, provided a way for external devices to create relatively rich user interfaces on their phones by posting of AT commands over a serial link. The first innovative use of this feature was seen in Christersson's PCControl application for Windows, which effectively allowed you to run applications on and move the mouse of your desktop via your mobile phone. Actually it was this software which inspired me to create a similar application for the Pocket PC.

There isn't much information on the web on how to create these UIs though. The main source of information was via a reference PDF published by SE outlining the 100+ AT commands that you can use. Since PCControl was pretty much what I wanted to emulate I decided that it would be easier to snoop on the COM port that it used and just regurgitate what I found there. Another problem I faced was that, since the phone was effectively stateless, any UI would need to be synchronised with whatever was controlling it.

What I've ended up with is a fully event driven state machine which a host can use to create a stateful UI on an SE phone. Handset key presses (and releases) are raised as windows events, as are the state changes themselves. The engine is also platform independent so will also work on a desktop platform.

3. Interacting with client applications, specifically Windows Media Player Mobile

So now that I had a way of displaying a UI on the phone and being notified of button presses, what I needed was a way to map these to the relevant application functions (play, stop rewind etc). This is the bit that I'm currently stuck on.

I heard that Windows Media Player 9 Mobile has no real automation facility, but that WMP10M did in the form of a control. Luckily (or so I thought) Dell had released a firmware update that gave me WMP10M, which was great seeing as many other manufacturers were not doing the same.

After installing the update and completing the previous parts of the project, I discovered that there weren't actually any examples or tutorials on how to use this control in the Pocket PC (in C++ let alone C#!). What I did find was that someone had actually written a usable .NETCF automation class for WMP9M! So ironically if I had stuck with the previous version I would be finished by now. Hurmph.

So now I'm spending a great deal of time figuring out which Windows Messages that I can send to manipulate WMP10M (with little luck so far), or waiting for someone to figure out how to use the WMP10M control via .NETCF. Till then, I have a pretty good sample app (for both PPC and Windows XP) which demonstrates the AT Engine if anyone wants to give it a bash.