I've got a couple mobile projects that need to provide communications services to a centralized server.  Over the past year or so, I've been getting to know WCF a little better and the more I learn, the more I think this is the one by far that in all the latest Microsoft technologies, that you should invest your time in learning.  Saying that, it would seem logical to think about using WCF as the technology to communicate on our mobile devices.  I'm not sure the answer is clear to me yet on this one.

First, what do I LOVE about WCF, if I had to sum it up, I would say three things,

1. The formality of defining and implementing contacts for our communications
2. The ability to configure and for the most part not worry about the transport details when coding your service
3. The ability to do duplex messaging, I still need to spend some time to see how this works under the hood from a scalability implication, but the concept in general seems powerful.

Saying that, we can make the following assumptions about the current state of mobile devices and applications:

1. In most cases the device is going to be a client on the client/server side of the equation
2. Our computing horsepower just isn't the same
3. Based upon my experience in both worlds (desktop/web AND mobile devices) I would say you can crank out 3-5 lines of desktop/web code in the same time it takes to get one line of mobile code into production
4. Code on mobile devices can't easily be updated so it really has to be right the first time
5. As good as our mobile platforms are these days, there are still a few quirks that are beyond our control and device specific

Therefore, most of the benefits of going with WCF really aren't that great in a mobile device.  And if a technology really doesn't provide much value, it may make more sense to keep it simplest technology with the fewest moving parts.  I think as with anything new, one needs to implement and analyze the results.  As I mentioned earlier, I don't have answers here yet, but wanted to start capturing thoughts.

-ec

MEDC 2007 - Day 1

Actually the first day was yesterday with MIX, I went over there with high-hopes of watching another great key-note by Scott Guthrie, I made the trip from the Monte Carlo to the Venetian early that morning, got registered and headed up to the meeting room.  I was greeted by a not-so-friendly security guard saying the MIX sticker on my badge wouldn't let me onto the fourth floor...guess there was something in the fine print, oh well.  I came back that afternoon and went to a couple great sessions, one on identity, it really seems like OpenID is really going to merit a series investment in time over the coming months.  The other conference I went to was on security with AJAX enabled applications.  This was a great session as a refresher/reminder that building a secure application really needs to be started from day one and built into the architecture, at least its much easier that way.  Overall the $395 I paid to add MIX to the MEDC conference was well worth it

The conference started out with a bang with the Key Note by Robbie Bach the president of Microsoft’s Entertainment & Devices Division.  He made a great case for developing software as a service and one of the biggest clients for those services is going to be mobile devices.  I also so some great demos on another one of the things I love to work on in my spare time (what's that?) Home Automation.  I really need to look at some of the latest developments in this area starting with Microsoft's Home Server.

Key points on what I took away from today's sessions

• Microsoft/Verisign finally came up with a "sane" way of signing mobile CAB files for WM 5.0.  Before you had to sign all your files, send them to Verisign, let them do their thing, get those files back.  Package them into a CAB and send it back up to them to sign the completed package.  What a pain in the ass, no real way to automate.  Just introduced this week, you can just start sending up the CAB file and it only costs one signing event!  Now it seems reasonable to sign the files...
• There is now an applications out there called fakeGPS.  I have a project coming up in May where I need to report on GPS data from a device, I'm looking forward to digging into this technology.
• According to Microsoft, WM6.0 and the Compact Frameworks are 100% back-wards compatible.  I have a fairly large WM5.0 application I've developed so I'll put this through the test, I really hope this is the case!
• On WM6.0 devices the Compact Frameworks 2.0 SP2 and SQL Server Compact edition are baked into the ROM...nice!
• On the large WM5.0 application I developed there is a good chunk of the code that deals with one handed operation on a Pocket PC type device (read not smart phone) I always thought this was a real hack...it was nice to see the Microsoft presenters give a demo of how to do this (and their implementation was really even more of a hack ;) ). 
• In Windows Mobile there is an event that I can subscribe to (something like Connection Status Changed) this will be fired when the connection via cell phone changes.  As part of my mobile application based upon a schedule I check the server for changes...kind of messy and probably wasteful the easy solution here would be to use an SMS message to kick of replication, yet this isn't that great either.  What I'm thinking about is that I'll build some sort of registration type service where the device can register with the server it's IP address as the connection status changes, then the server could make a TCP/IP call to the device to initiate replication (or maybe just send changes)
• New terminology for WM6.0 (Don't shoot the messenger)
  • Smartphone (no touch pad) - Now called "Windows Mobile Standard"
  • Pocket PC Phone - Now called "Windows Mobile Professional"
  • PDA's (no phone) - Now called "Windows Mobile Classic"

Overall this was a great day...picked up lot's of tips & tricks and validated all my design considerations over the past year.

-ec

NiVek J.D.'s Maiden Voyage

Everything came together today for NiVek's J.D.'s official first journey.  NiVek J.D. is a remote control tractor purchased from Target that was converted over to be controlled via a small on-board computer programmed in Java.  The same basic board I used for NiVek I was used for this "robot".

This robot has two cool features not on NiVek I.  The first is it has a GPS module purchased from Parallax.  The second and which I think is really exciting is it using a Windows Mobile device as a "Repeater" that allows for communications from the NiVek embedded computer to a a PC.  This design is based upon software components that are part of WiMo or Windows Mobile Robot, you really need to check out that site!  This consists of some kewl software components that are made up of a Compact Framework 2.0 application that runs on Windows Mobile and a collection of services that run under Microsoft's Robotics Studio.

NiVek J.D.'s Hardware

Basically the radio was just ripped out of the existing remote control tractor and and the motors were connected to the NiVek embedded computer.  As with the "original" WiMo, the Windows Mobile device was mounted on a servo with a CD-ROM.  The original WiMo used a SmartPhone not a Pocket PC so that probably worked out a little better, it's nice to be able to pan the camera however with my driving skills (smacking into walls) one of these days, I'm pretty sure the CD-ROM is going to end up in pieces ;-).  I need to re-think that part of the design.

NiVeK J.D.'s Maiden Voyage (well at least one of the first few)

50,000ft System Overview

• The actual robot itself is controlled by an embedded computer based upon a small PIC processor with some additional components that allow it to be programmed in Java with 32K RAM & ROM this was purchased from Parallax and is called a Javelin Stamp.  (See this post for more information)
• The embedded computer has a BlueTooth transceiver module that allows it to communicate with a Windows Mobile Device.
• The Windows Mobile Device has a Compact Frameworks 2.0 application running code available from the WiMo Bot web site.
• The Windows Mobile WiMo application communicates with the robot via BlueTooth.  It also has the ability to listen on a socket for connections from a remote application.  Since this is a Windows Mobile device (in my case a phone), it will not only work while it's connected via a local LAN via WiFi, but it can also communicate via the GPRS radio and be a sort of "repeater" that will allow it to communicate to a host controller program anywhere it has cellular reception, just think about this...this is very kewl!  A nice feature is on the opening screen shot of WiMo it tells you the IP address of the device.
  
• On the PC side you have a set of Microsoft Robotics Studio services.  When these services first start you will be greeted by a dialog that will allow you to enter the IP address of the remote Windows Mobile device.
  
• Once you press "Connect" (and the software gods are shining on you) you should establish a connection from your PC to the WiMo application.
• At this point a couple of additional forms will show up from the MSRS services.  The one in the upper left is displaying console messages from MSRS (Microsoft Robotics Studio).  This is a great way to see what's actually going on with your services. 
• The one in the upper right is from a service that came with WiMo (with the addition of buttons to control the motors).  Another really cool built in feature with WiMo is the ability to use the camera on your Windows Mobile device to send pictures back from your robot.  This from also sends messages to the core WiMo communications MSRS service to pass those to the WiMo device application.  These messages allow for control of the robot from the PC.
• The dialog in the bottom is an additional MSRS service that was built that subscribes the the TextMessageReceived event from the core WiMo service. 
  • The NiVek embedded computer spits out GPS readings every second (probably need to change this so it only sends when the location changes). 
  • This gets sent from NiVek to the the WiMo software on the device with a simple <stx><etx> binary protocol.  The WiMo software turns it into a simple text message. 
  • For our GPS WiMo constructs a simple text message "GPS: #Sats=4 Lat=28.4.042 Long=82.42.5522". 
  • This text message is sent over the wire from the Windows Mobile application to the WimoComm MSRS service. 
  • The WiMo MSRS service picks up the text message and finds any services that subscribe to this type of incoming event.
  • The GPS Point plotter MSRS service subscribes to these messages so it takes those readings and plots the on the crude dialog you see below.  The challenge here is that for a robot this size of NiVek J.D. if it moves 50ft that's a long distance, and the resolution on the GPS module I purchased just doesn't seem to be all that accurate.

Finally one last picture of you host at the controls!

Looks like my day job is going to be busy over the next few weeks with DevConnections and MEDC but I hope to sneak in a few hours every once in a while to push this effort forward!

Can anyone figure out what NiVek stands for?

- ec