Accessing Windows Live Services from Windows Mobile Devices & Other Smart Client Systems

Jim -

Hi, this is Larry from today's broadcast. I'm the one who asked the question about how to tell if your Pocket PC has an internet connection, and how to programmatically make an internet connection if the device is not connected.

I'm going to split this query into two posts. The first post will focus on how to determine programmatically if your device is connected to the internet.

Yes, you are correct, there's a great deal you can do with the Microsoft.WindowsMobile.Status.SystemState class. I've spent a couple of hours playing with this. If SystemState.ConnectionsCount is greater than zero, then you PROBABLY have an internet connection. If SystemState.CradlePresent is true or if SystemState.ConnectionsDesktopCount is greater than zero, then you probably have an internet connection via ActiveSync. If SystemState.ConnectionsNetworkCount is greater than zero, then you probably have an internet connection via wi-fi. There are a bunch of properties that will tell you if you probably have an internet connection over a phone connection, such as ConnectionsModemCount > 0 or PhoneActiveDataCall == true.

(other potentially useful SystemState properties: PhoneSignalStrength to tell you if you have a good enough signal to establish an internet connection over the phone modem, PhoneRadioPresent to see if you're dealing with a Pocket PC phone device, PhoneRadioOff to see if the Pocket PC phone is turned on or off, ConnectionsModemDescription to see if your modem connection is a Broadband connection)

If anyone listening wants to play with the SystemState class, there's a sample project in the WindowsMobile 5.0 SDK called NotificationBrokerViewer that seems to display every SystemState property.

You can use the negative of these properties with some certainty. For example, if SystemState.ConnectionsCount == 0, then you're not connected to the internet. However, there does not appear to be any way to make certain that you DO have an internet connection. These methods only tell you that you have a network connection of one variety or another. There seems to be no way to tell if there's internet behind these connections.

For example, if I turn off my cable modem at home, I can cradle my device or make a wi-fi connection to the device, and the SystemState properties noted above will all indicate a connection. I imagine that the same holds true for the modem internet connections -- if I connect to the Verizon EVDO network, but Verizon's internet is somehow not working, I doubt that the SystemState properties will pick this up. (Unfortunately, Verizon was not willing to shut down the network so I could confirm this.)

So, I think there's no way to determine programmatically that your device is connected to the internet. I don't think this is a problem with the SystemState class -- I think this probably represents the best connection information available to the Pocket PC.

So, Jim ... what do YOU do about this when you develop systems for production? It seems that you'd need to deal with this -- somehow trap the inevitable errors when connections cannot be made. I'd appreciate your comments and discussion here.

Larry

Jim -

Before I get into my second post ...

... during today's presentation, I thought I understood you to wish that VisualStudio would automatically insert appropriate "using" statements when we add various classes to our code. For example, I think you did something like type in a reference to an XmlDocument, and then ask why VisualStudio couldn't add the "using System.Xml" reference for us.

I may have misunderstood, but I THINK that's what you were asking for. If so, Visual Studio has already addressed this. Say you begin typing in a reference to an XmlDocument, and you notice that intellisense is not recognizing your reference. Right-click on the reference. If you're missing the appropriate "using" statement, the pop-up menu will contain a Resolve option. Put your cursor over this option, and you're given the ability to choose "using System.Xml;". Choose this, and the "using" statement is automatically added for you -- without your having to navigate to the top of the page and then find your way back.

I think this is way cool.

Again, I may have misunderstood what you were wishing for ...

Larry

Jim -

Finally. I asked how to programmatically connect a Pocket PC to the internet (assuming that no connection presently exists), and you asked me to post to you here.

Here's what I've figured out.

First, there's a sample project in the Windows Mobile SDK called cmhelper that addresses this problem in part. Unfortunately, it's written in C++, and I'm not very good at deciphering C++. cmhelper shows some ways to access the Connection Manager API, which is about as complex and nasty an API as I can imagine. The cmhelper program WILL try to connect a Pocket PC phone to the internet, using a phone data call. There seems to be a great deal of additional power within the Connection Manager that's not addressed in cmhelper, but the last thing I want to do is to get lost in a multi-month project to figure out this API. It would take me long enough just to duplicate what cmhelper can do, using P/Invokes in C#. (By the way, I've searched high and low on the internet, figuring that SOMEONE would have posted how to P/Invoke this API. No luck.)

Second, the OpenNETCF people address the Connection Manager API in their Smart Device Framework Extensions (SDFEs). I've resisted this product in the past -- it's another dll to worry about (unsigned to boot), and if anything goes wrong with my project, Microsoft is quick to blame third party dlls. Also, the documentation for the SDFEs is really sparse -- if they've managed to address the power that seems to be inherent in the Connection Manager API, it's not evident from the handful of lines of code posted in their documentation. But my main objection to the SDFEs is that they don't presently work very well. I can use them to make the same kind of data call that cmhelper will make, but the property in the SDFEs that's supposed to sense an existing connection is not working.

The ideal dream system would look at all possible available internet connections, and make the best possible connection. One would assume that an ActiveSync internet pass-through would be best in most circumstances, and that wi-fi would usually be superior to whatever's available in a modem data call. I've never seen a programmatic way to initiate a wi-fi connection, if one has not already been made by a user.

So again ... I ask you as a professional programmer. What are you (and people like you) doing in real world applications? Do you rely on the user to initiate the internet connection from outside of your program? Do you make this connection for the user, and if so, how?

Larry

Larry;

Regarding my statement yesterday about "wishing that Visual Studio would provide an option to insert the required using statements for a type" - you didn't misunderstand me. :-) I really didn't know that such an option existed - if I did know I certainly don't remember knowing. :-)

I appreciate you taking the time to post that such an option does exist. That'll be a huge timesaver for me, especially during presentations where I type so much code on the fly.

Thanks!!
Jim

P.S. I'll reply to your other posts shortly.

Larry;

You raise many good points; I'll post the answers as I have time today (just a little unexpectedly busy today) but I will get to them all.

All of the notifications in SystemState do refer to network connectivity which, as you point out, does not ensure Internet connectivity. In terms of determining whether I have actual internet connectivity I basically use a small routine that attempts to reach an expected endpoint; in other words before doing the "real" work that relies on Internet connectivity, I try something simple within a try/catch block.

By way of an example, in scenarios where I need to perform Merge Replication or RDA synchronization, I use an HttpWebRequest to do an HTTP GET to the MergeRep/RDA ISAPI DLL and check to see that I get the expected string back. So I do something like this...

bool IsConnected()
{
bool connected = false;
const string url = @"http://<servername>/advworksmobile/sqlcesa30.dll";
const string expectedResponse = "SQL Server Mobile Server Agent 3.0";

try
{
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(url);
request.Method = "GET";
HttpWebResponse response = request.GetResponse();
Stream responseStream = response.GetResponseStream();
StreamReader reader = new StreamReader(responseStream);
string responseString = reader.ReadToEnd()
connected = responseString == expectedResponse;
}
catch (...)
{
....
}
finally
{
// Close things
}

return connected;
}

This is the technique that I and many other folks I know use to determine if we have actually connectivity. I like this technique also because it allows you to determine if your desired endpoint is actually reachable.

I'll hit your Part 2 questions shortly.

- Jim

As an aside…

For people who want to dig into to the full set of features offered by the State and Notifications Broker API, I'm finishing up a 3-part whitepaper series on MSDN dedicated to State and Notifications Broker API. You may be asking how one can get a 3-part out of that API but it is incredibly powerful with many more capabilities then many people realize. All 3 parts cover both native and managed code.

Part 1 is on the basics
Part 2 is on conditional notifications, batch notifications, persistent notifications (notifications that will auto-start an app)
Part 3 is on creating your own custom notifications and the issues related to notifications & threading

Part 1 is at http://msdn2.microsoft.com/en-us/library/aa456240.aspx
Part 2 is stuck in publishing hell. It's been done for several months but the publishers are having issues (not related to the paper) that are holding things up. I'm told it'll be out there w/in the next week; I'll post the URL when available.
Part 3 is currently in writing but should be completed shortly.

Jim -

Thanks for your great reply on my part I. Actually, I can imagine combining the HTTPWebRequest technique you've discussed with the SystemState technique you recommended earlier, to give the user an idea WHY they're not able to make a connection.

If you've ever supported Pocket PC users in the field, you've probably dealt with the frustration of trying to figure out why a given user suddenly is unable to connect. Usually, I get a voice mail message telling me that my server is down, and it can take hours just to get the user to realize that the server is fine, but (for example) there's no internet behind his wi-fi connection.

So with the combined techniques, you could present the user with better information. If, for example, SystemState tells you that the user is connected via wi-fi, but you can't HTTPWebRequest your server, and you can't HTTPWebRequest Google either, then the chances are pretty good that there's no internet behind the user's wi-fi connection.

Larry

Larry;

I'm sorry but I've just been swamped and haven't had a chance to dig into the connection issue.

I did want to offer a suggestion on something that you may find helpful. I know that you mentioned concerns about installing the OpenNETCF assemblies but have you considered viewing/using their source code. You can download the source code for all versions of the SDF up through v1.4.

The link for the SDF downloads is http://opennetcf.org/PermaLink.aspx?guid=3a013afd-791e-45ef-802a-4c1dbe1cfef9
Just click on the "Download Smart Device Framework v1.4 Binaries and/or Source Here" link and then download the SDF v1.4 source.

I'd suggest pulling down that source code and taking a look at ConnectionManager.cs in the OpenNETCF.Net subfolder. I think there's a good chance that you'll find some very helpful information in there.

Please let me know if that helps. If not let me know, I'll dig into things a bit more.

-Jim

Thanks, Jim. That's a good suggestion.