Ich portiere Code aus dem vollständigen .NET-Framework in die WP7-Version und es kommt zu einem Problem mit synchronen vs asynchronen Aufrufen.
%Vor%Der Antwortstring wird dann in eine Liste von Objekten zerlegt, die von der Methode zurückgegeben wird.
Das Problem, das ich habe, ist, dass es keinen Weg gibt, den Anruf in Silverlight / WP7 synchron zu machen. Wenn ich einen Rückruf verwende, erhalte ich die Antwort in einer anderen Funktion und kann sie nicht von der ursprünglichen Funktion zurückgeben. Gibt es eine Möglichkeit, den Anruf entweder synchron zu tätigen oder von der CallBack-Funktion zurück zu der Methode zu gelangen, die den asynchronen Anruf ausgelöst hat?
Sie müssen sich das Problem anders überlegen. Damit sich asynchrone Dinge synchron "anfühlen", ist es am einfachsten, den Code so umzuformulieren, dass er den Fortsetzungsmodus " verwendet ".
Anstatt eine Funktion aufzurufen, die einen Wert zurückgibt, und Sie diesen Wert dann verarbeiten, rufen Sie eine Funktion auf und übergeben eine anonyme Funktion als einen Delegaten an es. Die aufgerufene Funktion ruft dann den Delegaten auf und übergibt die Zeichenfolge.
Hier ist ein Beispiel, das anonyme Funktionen und Lambdas verwendet:
%Vor%Dies ist die eine Hälfte der Lösung. Der nächste Teil ist, dies tatsächlich zu nennen. Stellen Sie sich vor, Sie hätten eine ICommand-Instanz oder ein einfacheres Button-Click-Event, das diese Funktion aufrufen und "die Zeichenfolge abrufen" müsste. Anstatt "die Zeichenfolge abzurufen", rufen Sie diese Funktion auf und stellen eine Callback-Methode bereit (die eine Schließung darstellt).
%Vor%Hier ist ein wirklich guter Artikel, der das Konzept weiter erklärt: Ссылка
Ich schlage zuerst vor, dass Sie versuchen, sich mit async vertraut zu machen, aber wenn Sie wirklich einen asynchronen Aufruf in einen synchronen Aufruf konvertieren möchten, können Sie ManualResetEvent verwenden, um das gewünschte Ergebnis zu erzielen.
Hier ist ein kurzes Beispiel für die Verwendung:
%Vor% Jetzt wird der Code in der Zeile _event.WaitOne(); blockiert, bis _event.Set(); aufgerufen wird.
Viel Glück!
Es ist besser, dies asynchron zu tun, damit der Benutzer weiterhin mit dem Gerät interagieren kann.
Ich vermute, der Grund, warum Sie dies wollten, besteht darin, zu verhindern, dass der Benutzer mit bestimmten Steuerelementen interagiert, bis Ihre Anfrage abgeschlossen ist.
Die akzeptierte Möglichkeit, dies zu erreichen, ist das Ausblenden oder Deaktivieren von UI-Elementen, mit denen während der Anfrageverarbeitung nicht interagiert werden sollte.
Tags und Links silverlight multithreading windows-phone-7 asynchronous