Voor communicatie maakt de Windows Phone 7 (WP7) gebruik van Asynchrone communicatie. Dit betekend voor WP7 ontwikkeling dat je een functie aan roept die buiten de standaard line valt.

WP7 kan meerdere taken tegelijk uitvoeren maar werkt binnen een taak liniare.

Dit betekent voor asyncrone communicatie dat het na de aangeroepen code wordt uitgevoerd. Het probleem is dan ook dat de data die je dan terug stuurt buiten de functie scoop valt.

Je zou dit op 2 manier kunnen opvangen om het toch binnen een functie te kunnen gebruiken. 1 een timer maken die controleren of de asynchrone communicatie geslaagd is of door de communicatie functie aan te laten roepen.

Ik heb beide manieren gebruikt. Om te beginnen met de timer.

[Code van timer]

Ik vond zelf hier een klein nadeel aan hangen door dat je uit einderlijk een probleem had dat je in een andere thread zit te werken als je ook doet met asyncrone communicatie, beide hebben het probleem dat ze niet kunnen communiceren met de normaal thread.

Om hier uit de normale thread aan te spreken heb je een Dispatcher nodig.

Dispatcher.BeginInvoke( () => {
// This code is on the UI thread.
});

Ik moet bekennen dat ik heel dit deel niet echt tot in de puntjes begrijpt.

Vorige week stond het probleem “Hoe data op te halen via GET” via me huidige Communicatie functie.
Na een beetje zoeken blijkt dat je via een HttpRequest geen GET kan op kan vragen omdat deze funciet een Body verlangd. Dus als je er een GET mee stuurd krijg je de melding terug dat de Method niet klopt. Oke Dan de vraag hoe je dan een GET kan opvragen. Heel makkelijk, je maakt gebruik van een WebClient die kan wel werken met GET.

// Nieuwe WebClient aanmaken
WebClient request = new WebClient();
// Header aan de WebClient toevoegen
// Dit kan fout zijn
// Huidige situatie = [Sessie_ID]:[Sessie-code]
request.Headers[headerM] = headerV;

//request.DownloadStringAsync(uri);
//request.DownloadStringCompleted += new DownloadStringCompletedEventHandler(getStreamComplete);
request.OpenReadAsync(uri);
request.OpenReadCompleted += new OpenReadCompletedEventHandler(getStreamComplete);

Oke die werkt, ik krijg geen melding dat de Method verkeerd is. Nu geeft hij gelijk terug dat de link niet goed is, want hij krijgt geen data terug. Het volgende probleem. Hoe krijg je de link er goed in met Header.

System.Net.WebException: The remote server returned an error: NotFound. ---> System.Net.WebException: The remote server returned an error: NotFound.
at System.Net.Browser.ClientHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.Browser.ClientHttpWebRequest.<>c__DisplayClass2.b__1(Object sendState)
at System.Net.Browser.AsyncHelper.<>c__DisplayClass4.b__0(Object sendState)
at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)


oke de volgende link moet werken “https://api.sense-os.nl/sensors?page=0&details=full” heb de link nu 3 keer getest. Dus het probleem zal bij de Header of bij de sessie_id liggen. Alleen de sessie_id moet in de header komen.
Dus de 2 volgende problemen word de sessie goed in de Header geplaatst en of is de sessie wel werkbaar.

Het probleem is nu opgelost:
Het probleem zat zo als ik vermoede in de Header. Ik had een paar spel fouten er in gemaakt.
De Goede oplossing is:

// Dit geeft de waarde aan die de sessie heeft, zonder het voorvoegsel van sessie_id.
String strAlter = Communicatie.SessionHandler.sessionHandler.Substring(15, 27);
request.Headers["X-SESSION_ID"] = strAlter;


Ben je je code aan het opschonen die ik net gemaakt heb blijkt er in het eind product een fout te staan dat een probleem geeft.
Ik had er voor namelijk om te testen in de code een standaard link gezet om te testen. Deze link had ik met het opschonen er uit gehaald omdat ik er een regel er boven de volgende tekst had:
// Maken van de uri string
String baseUri = "http://api.sense-os.nl/";
Uri uri = new Uri(baseUri + requestUri);

Helaas bleek er geen “http” te staan maar https. wat weer tot het oude frustrerende probleem kwam. terwijl ik later hoorde dat de server wel “https” aan zou moet kunnen.

Maar dit deel is voor nu afgesloten nu naar het omzetten van json in iets begrijpelijks.