Although polling a webservice is possible, do you know of another method to push changes to a mobile client except using the exchange server mail transport?
+3
A:
Back when I worked in the Microsoft Dynamics Mobile team (until January 2009) there was no other built-in way to do this on .NET CF other than through the Exchange Server Mail Transport.
However, one of my colleagues did a spike where the mobile client openened a HTTP connection to the service and kept it open, whereby the service had an open channel on which it could push.
AFAIK, this is basically what the Exchange Server Mail Transport does. IIRC, he got it working alright, but I'll tweet him and see if I can get him to chime in.
Mark Seemann
2010-01-07 10:55:46
A:
Here are some options for use in an internal network:
- MSQM
- TcpListener
For option 1 youd need to install another piece of infrastructure, but you gain a standard API and protocol.
For the second option you have to implement your own protocol.
Both option only work in a closed environment!
Louis Haußknecht
2010-01-07 12:34:04
@downvoter, what is wrong with my answer?
Louis Haußknecht
2010-01-08 07:28:10
+3
A:
As Mark Seemann worte: I once did a POC of a client notification system for .NET CF when I was in the Microsoft Dynamics Mobile team.
At the time I didn't find any Out-Of-The-Box solutions that could do this and I didn't want to piggyback on the Exchange Server connection since the intended users didn't have a AD account and most certanly didn't use the exchange server. So I was in the same situation as you are now. I started searching for possible solutions...
I realised that the server coudn't connect to the client since the IP address of this constantly changes (going from 3G to WiFi, loosing connection, etc). The clinent had to connect to the server. Furthermore I found that most networks allows HTTP connections but not always custom TCP connections over custom ports.
I used "Comet" to do long-held http requests from client (.NET CF) to server (IIS) and pushed the notifications to the client using this connection. If the client got a timeout before a notification was given it would simply make a new request.
On the serverside I used a combnation of an AsyncHttpHandler and wait threads that checked for messages to the connected clients every sec. It is important to use a AsyncHttpHandler or you'll block the IIS server.
The POC worked well and it proved to be a reliable solution. There are some drawbacks to this: if you are not careful you'll drain the battery quite quickly.
Unfortunately there are simply too many lines of code involved for me to post the code here, but if you like you are more that welcome to contact me and I'll e-mail you my POC.
Tim
2010-01-07 18:58:27