title: How to access Windows Phone 7 specific network type (e.g. EDGE, 3G, etc.) without opening a socket?
body: <p>As I understand, before the Mango SDK update (7.1), you were only able to access a rather broad network type via the property <code>NetworkInterface.NetworkInterfaceType</code>. This would return an enumeration like <code>Wireless80211</code>, <code>MobileBroadbandGSM</code>, or <code>MobileBroadbandCDMA</code>.</p>
  
  <p>After the release of the Mango SDK, we are now able to access the NetworkInterfaceSubtype via an open socket using a call similar to this: <code>socket.GetCurrentNetworkInterface();</code> A property of the returned object (<code>NetworkInterfaceInfo.InterfaceSubtype</code>) will give you more specific network information such as <code>Cellular_EDGE</code>, <code>Cellular_HSPA</code>, or <code>Cellular_EVDV</code>. This is the information I need.</p>
  
  <p>The most efficient way I have found to access this is to open an async host name resolution request and grab the information in the async callback function, such as below (borrowed from this post: <a href="https://stackoverflow.com/questions/5325627/how-can-i-check-for-3g-wifi-edge-cellular-networks-in-windows-phone-7">How can I check for 3G, wifi, EDGE, Cellular Networks in Windows Phone 7?</a>):</p>
  
  <pre><code>DeviceNetworkInformation.ResolveHostNameAsync(
          new DnsEndPoint("microsoft.com", 80), 
          new NameResolutionCallback(nrr =&gt;
              {
                  var info = nrr.NetworkInterface;
                  var subType = info.InterfaceSubtype;
              }), null);
  </code></pre>
  
  <p>What I'm looking for is a way to access this NetworkSubtype information without having to actually open a data connection. The reason I need a passive method for querying this information is that I need to know when the network type changes, but continually opening a data connection in a loop that queries this could potentially prevent that change from taking place.</p>
  
  <p>UPDATE 1: I have found through testing that, as Richard Szalay suggested, the <code>DeviceNetworkInformation.NetworkAvailabilityChanged</code> event does indeed fire when the handset switches network technologies (i.e. 3G to EDGE, or WiFi to HSPA), and you do have access to the <code>NetworkInterfaceSubtype</code>. I unfortunately have also found that when switching from WiFi to a cellular network technology (e.g. HSPA, EDGE) that the reported network subtype can often be inaccurate. For instance, if you switch from WiFi to HSPA, the event arguments may still report a connection to WiFi when it gets fired, and no second event is fired to report HSPA. You are thus given the wrong connection type. This unreliability may make using this trigger ultimately useless, but I am going to do some network testing (without WiFi) to see if this issue is confined to WiFi switching. I'm hoping that it's just an issue with the WiFi radio, and that cellular network switching is reported accurately. I'll update this when I know more.</p>
  
  <p>UPDATE 2: I have found through a lot of (driving around) testing that while the <code>DeviceNetworkInformation.NetworkAvailabilityChanged</code> event will get you the network changes, it does not seem possible to determine exactly what raises/triggers the event. For instance, if you're recording the network interface each time the event is triggered, you could end up with results like: HSPA, EDGE, EDGE, EDGE, GPRS, GPRS, HSPA. The event argument object has a variable named <code>NotificationType</code> that is supposed to tell you the reason it was triggered, but this is always set to <code>CharacteristicUpdate</code> in my tests, so I have no idea why it is being triggered multiple times for the same network type (e.g. EDGE, EDGE, EDGE). For my purposes, I am just recording the changes that have not already been recorded and ignoring the multiples. It is not ideal (and seems slightly less than trustworthy), but it's better than nothing, I suppose.</p>