Как я понимаю, до обновления Mango SDK (7.1) вы имели доступ только к довольно широкому типу сети через свойство NetworkInterface.NetworkInterfaceType
.Это вернуло бы перечисление типа Wireless80211
, MobileBroadbandGSM
или MobileBroadbandCDMA
.
. После выпуска Mango SDK мы теперь можем получить доступ к NetworkInterfaceSubtype через открытый сокет, используя вызов, аналогичныйthis: socket.GetCurrentNetworkInterface();
Свойство возвращаемого объекта (NetworkInterfaceInfo.InterfaceSubtype
) предоставит вам более конкретную информацию о сети, такую как Cellular_EDGE
, Cellular_HSPA
или Cellular_EVDV
.Это информация, которая мне нужна.
Наиболее эффективный способ, который я нашел для доступа к этому, - это открыть запрос разрешения имени асинхронного хоста и получить информацию в функции асинхронного обратного вызова, как показано ниже (заимствовано из этого поста).: Как я могу проверить наличие 3G, wifi, EDGE, сотовых сетей в Windows Phone 7? ):
DeviceNetworkInformation.ResolveHostNameAsync(
new DnsEndPoint("microsoft.com", 80),
new NameResolutionCallback(nrr =>
{
var info = nrr.NetworkInterface;
var subType = info.InterfaceSubtype;
}), null);
Мне нужен способ доступа к этой информации NetworkSubtypeбез необходимости фактически открывать соединение для передачи данных.Причина, по которой мне нужен пассивный метод для запроса этой информации, заключается в том, что мне нужно знать, когда тип сети изменяется, но постоянное открытие подключения к данным в цикле, который запрашивает это, потенциально может предотвратить это изменение.
ОБНОВЛЕНИЕ 1: в ходе тестирования я обнаружил, что, как предположил Ричард Сзалай, событие DeviceNetworkInformation.NetworkAvailabilityChanged
действительно срабатывает, когда трубка переключает сетевые технологии (например, 3G на EDGE или WiFi на HSPA), и у вас есть доступ к NetworkInterfaceSubtype
.К сожалению, я также обнаружил, что при переключении с Wi-Fi на технологию сотовой сети (например, HSPA, EDGE) указанный подтип сети часто может быть неточным.Например, если вы переключаетесь с WiFi на HSPA, аргументы события могут по-прежнему сообщать о подключении к WiFi, когда оно срабатывает, и второе событие не отправляется, чтобы сообщить о HSPA.Таким образом, вы получили неправильный тип соединения.Эта ненадежность может сделать использование этого триггера в конечном счете бесполезным, но я собираюсь провести некоторое тестирование сети (без WiFi), чтобы выяснить, не связана ли эта проблема с переключением WiFi.Я надеюсь, что это просто проблема с радио WiFi, и что о коммутации сотовой сети сообщается точно.Я обновлю это, когда узнаю больше.
ОБНОВЛЕНИЕ 2: в ходе многочисленных (разъезжающих) испытаний я обнаружил, что хотя событие DeviceNetworkInformation.NetworkAvailabilityChanged
приведет к изменениям в сети, это не представляется возможнымточно определить, что вызывает / запускает событие.Например, если вы записываете сетевой интерфейс каждый раз, когда происходит событие, вы можете получить такие результаты, как: HSPA, EDGE, EDGE, EDGE, GPRS, GPRS, HSPA.У объекта аргумента события есть переменная с именем NotificationType
, которая должна сообщать вам причину, по которой она была запущена, но в моих тестах она всегда устанавливается на CharacteristicUpdate
, поэтому я понятия не имею, почему она вызывается несколько раз длятот же тип сети (например, EDGE, EDGE, EDGE).Для моих целей я просто записываю изменения, которые еще не были записаны, и игнорирую множители.Он не идеален (и кажется немного менее заслуживающим доверия), но лучше, чем ничего, я полагаю.