Overview of Device Messaging Over the Internet

The .NET Compact Framework has made programming for Windows Mobile based devices easier than ever and extremely similar to programming with .NET targeting a desktop. Still, there are numerous minute differences between the two that can lead to unexpected and unwanted situations. This posting will go over one of the major differences between the desktop and mobile platforms: Internet messaging.

The Problems with Devices

There are many near certainties when you program targeting computers running the .NET Framework. Your internet connection won't be immediately cut if you receive a phone call (unless you're using a dial-up modem). Barring an unreliable power grid, your computer will most likely not have to worry about running out of batteries while transmitting data. The OS virtually never gets into a state where it's forced to kill processes to continue operating. Last but not least, it's not really be possible to accidently drop your server into the toilet or accidently leave it on your seat after lunch. When you start talking about mobile devices however, all of these possibilities become reality.

 

Pitfalls with Device Addressability

It's not easy to find a mobile device over the internet. Why? Because it's mobile. Device Addressability becomes a big issue, since when moving between access points on a wireless network the device's IP address is liable to change without warning. This problem is coupled with the fact that the mobile device could be in an area without service or have been shut off to conserve battery. Being able to communicate with the device through the cellular network, or with SMS text-messages is one option when communication is possible, but is potentially costly depending on the volume of traffic. Due to this, it is currently unrealistic to assume that a server can easily get in touch with a mobile device.

 

The Request/Reply

With this being the case, the simple answer is just doing internet communication with requests initiated by the device. WCF with the .NET Compact Framework takes this into account for the default bindings and only supporting request/reply channels in .NET Compact Framework 2.0. This solves most of the aforementioned problems about device addressability, and allows the device to initiate communication when it's capable of handling the data. On the other hand, this introduces various other problems related to caching, timeliness of data, and reliability.

 

Store and Forward Messaging

In response to some of this, the .NET Compact Framework team developed Store and Forward Messaging for the .NET Compact Framework 3.5. This feature addresses some of the problems with caching by using some of the built in functionality of Windows Mobile. Utilizing ActiveSync's Always Up-To-Date, (more info on how that works here), it is now possible for data to get pushed to devices instead of pulling with requests. Also, since there already is an inbox and outbox associated with the Exchange mailbox, caching of the information is handled without additional work. While this enables scenarios that were not possible with the .NET Compact Framework 2.0, there still remains the issue with reliability, which I shall discuss in an upcoming blog posting.

 

Where to go from here?

• Design your applications around these constraints and common failure cases.
• For some Compact WCF HelloWorld examples and more background on Store and Forward Messaging, read Mark Prentice's blog here.
• For more information on the support of WCF for mobile devices, read Andrew Arnott's blog post here.