Synchroner Http-Request mit einem asynchronem Client

[Forumsgast]

Hallo,

ich beschäftige mich zurzeit mit Titanium-Mobile. Der Titanium-Httpclient unterstützt leider nur den asynchronem Modus (es gibt zwar einen Parameter in der Methode open für async = false, aber dieser funktioniert nicht).

Nun suche ich nach einem (möglichst generischen) Lösungsansatz um einen synchronen Http-Request mit einem asynchronen Httpclient auszuführen. Ich möchte also mehrere Http-Request nacheinander aufrufen, so in der Art:

function getRemoteData() {
	var a = httpRequest_1();
	if(a == 'wasAuchImmer') {
		httpRequest_2();
	}
}

Momentan könnte ich zwar die Methode httpRequest_2() direkt in der onload-methode von httpRequest_2() platzieren. Das finde ich allerdings suboptimal, da ich httpRequest_1() nicht grundsätzlich mit httpReqest_2() fest verdrahten will.

Vielleicht hat ha jemand eine bessere Idee.

vg
jack

[Gast]

Wieso willst Du einen synchronen Request ausführen?

und, wieso machste dass niht komplett selbst in js ?

http://codegods.de/2008/08/28/synchr...ts-javascript/

[Forumsgast]

@moma: In Titanium gibt es kein XHR Objekt sondern eben nur den HttpClient (mit ähnlichem Interface)

(es gibt zwar einen Parameter in der Methode open für async = false, aber dieser funktioniert nicht).

Hast du dafür eine Quelle außer dass du es nicht hinbekommen hast? Ich habe zwar nur mal mit Titanium Desktop gearbeitet aber dort funktionierten synchrone Requests durchaus - kann sein dass du dazu etwas andere Funktionen aufrufen musst aber das sollte herauszufinden sein.

[Forumsgast]

da ich httpRequest_1() nicht grundsätzlich mit httpReqest_2() fest verdrahten will.

Musst Du ja nicht. Kann man ja auch dynamisch machen. Wenn ich

do1();
do2(); 

notiere, ist das grundlegend auch erst mal fest verdrahtet.

[Forumsgast]

@fab
das steht bereits in diversen Postings:
http://developer.appcelerator.com/qu...ous-httpclient
http://developer.appcelerator.com/qu...ient-sync-mode

Wie gesagt, es ist auch ein Parameter dafür vorgesehen (zumindest für iOS):

http://docs.appcelerator.com/titaniu...nt-method-open

@nikosch

Musst Du ja nicht.

und wies soll ich es dann sonst machen?


vg
jack

[Forumsgast]

Momentan könnte ich zwar die Methode httpRequest_2() direkt in der onload-methode von httpRequest_2() platzieren.

so. Allerdings in der ready-Methode.

[Forumsgast]

We only provide asynchronous access. Given the slow speed of connections, the UI would hang and cause the OS to throw up the kill or wait dialog.

Das macht Sinn. Da frage ich mich, warum du trotzdem unbedingt synchrone Requests machen willst... zwei Requests nacheinander durchführen ist asynchron kein Problem und auch elegant machbar, siehe nikosch.

[Forumsgast]

@nikosch
eine ready-methode gibt es bei dem Titanium-HttpClient nicht, es ist die onload-methode:

onload : Callback<Object>
Function to be called upon a successful response.

http://docs.appcelerator.com/titaniu...roperty-onload

@fab

...Da frage ich mich, warum du trotzdem unbedingt synchrone Requests machen willst...

Vielleicht brauche ich die Rückgabe vom ersten Request als Parameter für den zweiten Request. Deshalb nacheinander => synchron und nicht weil ich unbedingt synchrone Requests machen will?!

zwei Requests nacheinander durchführen ist asynchron kein Problem und auch elegant machbar, siehe nikosch.

also entweder synchron (nacheinander), oder eben asynchron (parallel). sorry, aber 'nacheinander asynchron' ist ein Widerspruch in sich - und nein es ist nicht wirklich elegant machbar (zumindest nicht so) - da man die Requests dafür fest miteinander verdrahten muss.

vg
jack

[Forumsgast]

da man die Requests dafür fest miteinander verdrahten muss.

Nein muss man nicht.

[Forumsgast]

also entweder synchron (nacheinander), oder eben asynchron (parallel). sorry, aber 'nacheinander asynchron' ist ein Widerspruch in sich

Das stimmt so nicht. Du musst dir das eher so vorstellen:
synchron = die Skript-Ausführung blockierend
asynchron = nicht-blockierend

Das bedeutet nicht totalen Kontrollverlust. Im Grunde hast du den richtigen Ansatz schon genannt:

die Methode httpRequest_2() direkt in der onload-methode von httpRequest_2() platzieren

Mit "fester Verdrahtung" hat das nichts zu tun.

[Forumsgast]

@fab

synchron = die Skript-Ausführung blockierend
asynchron = nicht-blockierend

Was anderes habe ich auch nicht behauptet.

hier habe ich mich leider vertippt :

httpRequest_2() direkt in der onload-methode von httpRequest_2() platzieren.

ich meinte natürlich
httpRequest_2() direkt in der onload-methode von httpRequest_1() platzieren.


@nikosch
ok, wie wäre es mit einem Beispiel, hier schon mal das Grundgerüst:

function request(method, url, callback, data)
{
    var xhr = Ti.Network.createHTTPClient(); 
    xhr.onload = function(e) {
        callback(e.responseText);
    }

    xhr.open(method,url);
    xhr.send(data);
}

// Request 1 holt Daten vom server 1 und schreib diese in app.data
function request_1() {
	request('GET','http://server1.xx', function(response) {
		app.data1 = response;
	});
}

// Request 2 sendet Daten von app.data1 an server 2 
function request_2() {
	request('GET','http://server2.xx', function(response) {
		app.data2 = response;
	}, app.data1);
}

vg
jack

[Forumsgast]

Da hast DU ja schon eine feste Abhängigkeit eingebaut, durch die Hintertür mit "app". Das würde ich überdenken...

Wenn ich auch mal darf (nur ein Ansatz für den nicht viel geändert werden muss, viele Wege führen nach Rom):

// Request 1 holt Daten vom server 1 und schreib diese in app.data
function request_1(callback) {
	request('GET','http://server1.xx', function(response) {
		app.data1 = response;
                callback(response);
	});
}

// Request 2 sendet Daten von app.data1 an server 2 
function request_2(input) {
	request('GET','http://server2.xx', function(response) {
		app.data2 = response;
	}, input);
}

request_1(request_2);

Ansonsten sind Promises noch ein interessantes Konzept für so etwas.

[Forumsgast]

function request(method, url, callback, data)
{
    var xhr = Ti.Network.createHTTPClient(); 
    xhr.onload = function(e) {
        callback(e.responseText);
    }

    xhr.open(method,url);
    xhr.send(data);
}

// Request 1 holt Daten vom server 1 und schreib diese in app.data
function request_1() {
    request('GET','http://server1.xx', function(response) {
        app.data1 = response;
        request_2();
    });
}

// Request 2 sendet Daten von app.data1 an server 2 
function request_2() {
    request('GET','http://server2.xx', function(response) {
        app.data2 = response;
    }, app.data1);
} 

[Forumsgast]

Vielen Dank für Eure Code-Beispiele. Vom Prinzip handelt es sich nach wie vor um die anfangs beschriebene Funktionsweise:

httpRequest_2() direkt in der onload-methode von httpRequest_1() platzieren.

Mit fest verdrahtet meinte ich eine Lösung wie die von Asterixus, also eine feste bzw. hardcodierte Abhängigkeit von request_2 in request_1. Die Lösung von fab ist schon mal deutlich flexibler, es gibt nur noch eine Abhängigkeit zu der Callback-Funktion und wenn man den Callback-Aufruf optional macht, dann ist auch diese Abhängigkeit sozusagen weg und request_1 ist wieder ganz der Alte Dann hätten wir tatsächlich sowas wie eine Reihenschaltung parallel laufender Prozesse.

// Request 1 holt Daten vom server 1 und schreib diese in app.data
function request_1(callback) {
	request('GET','http://server1.xx', function(response) {
		app.data1 = response;
                if(typeof callback === 'function') { 
                     callback(response);
                }
	});
}

vg
jack

[Forumsgast]

Letztlich müsstest DU erst beschreiben, was Du erreichen willst und wie flexibel das sein muss.