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

Mobile Device Ramblings

Since my days of writing code for embedded systems in the early 90’s I’ve always had a soft spot for mobile devices.  My first experience writing code for mobile devices was a floating point library I created for the Palm OS for a time tracking application, this was a small C library, nice concept but I just don’t think it reached the fullest potential, next was in 1998 with my first HPC or Handheld PC running some early version of Windows CE, with a fold out keyboard and a of low resolution LCD black and gray display.  At the time we used embedded VB to write applications; it was fairly painful to write anything but the smallest applications, these devices never really took off.  Next was a collection of “smart-phones” with PDA like functionality, some had development kits but again these were very painful and you really couldn’t do too much other than manage lists and appointments.  Then around 2001 the world was changing for mobile devices with a new technology called WAP or wireless application protocol, the idea here was really cool, define your application in a set of XML documents using the WAP standard and it would run on any device that supported a WAP browser.  Well I learned the technology, built a few proof of concepts systems, but in the end this technology just didn’t turn into anything real.  An interesting side note on this is that although WAP seemed and still seems like a great idea, most phone or mobile device that people do “web-stuff” these days really have a full feature browser built in so all the experience learning WAP probably provides less than significant value today. 

Fast forward to 2003, hardware is really coming of age and cellular technology is starting to provide solutions for wireless wide area networks that are usable.  These are built into phone and cards that fit in your computer that act as modems as well as a new hybrid technology called the “Smart Phones” that not only provide voice service, but a platform for developing non-trivial applications.  So now we have devices that have decent computing power as well as some sort of connectivity.  With PDA’s up to this point some sort of external connectivity was required to synchronize data, now we have a device that can not only access web sites via built on browser functionality, but when networks are available they can synchronize data with the server to keep their data fresh.  I’m not really so much a Microsoft Bigot, but that is where the majority of my experience is so I can speak to that.  With the release of Windows Pocket PC 2003 and Pocket PC 2003 Second Edition and the Compact Framework we started to have a good platform where it made sense to develop business applications on a mobile application (this was possible before, but using tools like eVC++ and Embedded visual basic, the eVC++ probably really good at creating small, yet industrial strength PPC apps and Embedded VB…well lets just not talk about it…) 

So although the Compact Frameworks application was definitely a 1.0 release it did provide the basis to build real applications, in addition if you needed a non-trivial data store, SQL Server CE was an excellent solution, although it’s footprint was small in relative terms, it wasn’t really all that small and with limited amount of RAM on the device it wasn’t always the best solution.  With the release of the .NET framework 2.0 came the Compact Frameworks 2.0 and around that time Windows Mobile 5.0.  The compact framework 2.0 was much “tighter” than the 1.0 release but to develop a real world class application you still needed to get down and dirty and do a lot of tricks to get it to do the things you want.  I’m confident with the next major release, this will become a fairly mature product at the same time the mobile operating systems based upon Windows CE.  In addition each year the devices provide more capability in terms of built in RAM, display resolution and processing speed.  Finally bandwidth provided by mobile carrier is increasing with each year so it looks like these devices are coming of age where it makes sense to seriously start putting business application onto these devices…

Saying that…

Let’s discuss a little bit about what type of application is a good candidate to build on a mobile device and what type isn’t....

What is a good candidate for a Pocket PC application?  A good candidate for an application is one for users that have a really busy schedule that require work to be performed at many different locations.  As good as a user interface is on a mobile device, the capabilities that are on a more robust set of hardware such as a laptop just aren’t present.  In addition the information that can be conveyed to the user is also fairly limiting.  Leaving out the obvious solution of calendaring/scheduling an excellent application for a mobile device is email.  With this type of application you really don’t have to perform many steps, lookup significant data, you just really want to exchange a little bit of information back and forth as efficiently and quickly as possible, you want to do it efficiently in that you don’t spend 2 minutes or even 15 seconds using the application, you want to do it quickly in that if you get an email, you would like to respond within a short amount of time (like 5 minutes).  Yes this could be done with a phone call, but if you are in the middle of a task, you may need to spend an extra 2 minutes completing it before you want the interruption of doing your end of the communications, by that time the original person has moved on and you may be interrupting them.  I guess you would almost call this a vehicle for asynchronous communications.  So now let’s think in terms of a busy remote worker with many tasks to be performed at multiple locations.  What can we do to empower these types of worker with the information they need and the capability to provide real time feedback to some sort of coordinator?  Well it depends, if the system would need something like...where they need to be and when they need to be there and their schedule doesn’t change that much, I guess they could just print out their schedule in the morning (or synchronize with a server in the morning) and that would be adequate.  There are two or three areas where building an application may make sense: 

• They need more than just the schedule, this could be any detailed instructions of what they need to do, any past work that has already been performed, contact information etc...
• When they perform the work (drop off a package, pick up a vehicle or similar, some central coordinator needs to know about it.  3) 
• Once they begin their day, their schedule may need to be flexible. 

So now revisiting the idea of an asynchronous vehicle for communications we can start thinking in terms of good candidates for mobile applications…well not yet, the other thing we need to think about is the capability of the device for interacting with users (at least until we can take voice interactions to the next level).  Right now a 2x3” screen with a stylus just isn’t the right answer for all but a certain class of applications.  I recently developed an application for a IT dispatching system that this is a great fit, but for someone like me that needs to have multiple and sophisticated "conversations" with technology it just isn’t all that efficient.  So the answer for determining the right cutoff for a mobile application might be the volume, length and the sophistication of the conversation between the user and the application.  So for a delivery driver where they could do a lookup of on a map, get directions, drop the package off, possibly get a signature, send that information about the coordinator, we have many small non-sophisticated conversations with a device.  For a developer fixing bugs, let’s say they fix 5-6 bugs a day, their conversation may be extensive if they enter notes but the key factor here is once they open their device get to where they need it is probably quicker to just do this on their desktop.  In addition the developer probably will enter some notes, until we come up with a reliable voice solution this will never be perceived as simple on a device.

-ec