Подождите, пока HttpWebRequest.BeginGetResponse завершится в Windows Phone 7 - PullRequest
4 голосов
/ 28 октября 2010

Я пытаюсь использовать асинхронное HttpWebRequest в Silverlight для Windows Phone. Все работает отлично, пока я не доберусь до того места, где мне следует позвонить

private static ManualResetEvent allDone = new ManualResetEvent(false);
...
request.BeginGetResponse(new AsyncCallback(GetResponseCallback), request);
allDone.WaitOne();
Debug.WriteLine("All done!");

В GetResponseCallback:

private void GetResponseCallback(IAsyncResult asynchronousResult)
{
    try
    {
        request = (HttpWebRequest)asynchronousResult.AsyncState;
        response = (HttpWebResponse)request.EndGetResponse(asynchronousResult);
        allDone.Set();
    }
    catch (Exception e)
    {
        Debug.WriteLine("Got Exception in GetResponseCallback: " + e.Message);
    }
}

После звонка на allDone.WaitOne(); просто зависает ...

Любые предложения о том, почему?

Ответы [ 6 ]

3 голосов
/ 29 октября 2010

Это займет немного сдвиг в мышлении от блокировки / ожидания к мышлению в асинхронных терминах на платформе WP7.В результате пользователь всегда может взаимодействовать с пользовательским интерфейсом.

Переместите вызов к вашему коду завершения (в данном случае к записи) в ваш CompletedEventHandler и для любых обновлений пользовательского интерфейса маршаллируйте обратно в поток пользовательского интерфейса с

Dispatcher.BeginInvoke( () => { /* your UI update code */ } )

Если есть какие-либо элементы пользовательского интерфейса, с которыми не следует взаимодействовать во время выполнения асинхронной операции, эти элементы управления могут быть скрыты или отключены на время.

2 голосов
/ 29 октября 2010

Если честно, это не очень хорошая идея. Ожидание в основном потоке (UI) заблокирует телефон и создаст неотвечающий интерфейс. В долгосрочной перспективе будет лучше не бороться с асинхронным сетевым доступом в WP7 и Silverlight, местами код может быть более сложным, и в итоге у вас будет много методов, которые принимают обратные вызовы, но пользовательский интерфейс с большим количеством ответов лучше, чем запереть его.

var request = WebRequest.CreateHttp(uri);

request.BeginGetResponse(r =>
{
    var reponse = request.EndGetResponse(r);

    // Do things response here
}, null);

// Let the method end and not wait
1 голос
/ 19 сентября 2011

Также обратите внимание, что если ManualResetEvent никогда не происходит, этот вызов WaitOne никогда не вернется:

1 голос
/ 14 июня 2011

Кажется, это ограничение эмулятора.Я еще не пробовал это, но я считаю, что запуск этого на разблокированном эмуляторе wp7 должен помочьhttp://forum.xda -developers.com / showthread.php? P = 11148176 # post11148176

1 голос
/ 14 марта 2011

Я столкнулся с той же проблемой, но решен, когда я заменил образ WP7 на новый. Разблокированное изображение вызовет эту проблему.

0 голосов
/ 29 октября 2010

Вы, вероятно, хотите переместить allDone.Set() за пределы try..catch. В противном случае событие никогда не будет установлено, если есть исключение, и поток, запустивший асинхронную операцию, зависнет. То есть вы хотите написать:

try
{
    request = (HttpWebRequest)asynchronousResult.AsyncState;
    response = (HttpWebResponse)request.EndGetResponse(asynchronousResult);
}
catch (Exception e)
{
    Debug.WriteLine("Got Exception in GetResponseCallback: " + e.Message);
}

allDone.Set();
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...