2010-05-29 14 views
8

Im mehrere Dinge von einer Webseite in einem UIWebView zurück zu meinem iPhone App über die should Methode des UIWebView zu passieren versucht.Auslösen should mit mehreren window.location.href rufen

Grundsätzlich meine Webseite ruft window.location.href = "Befehl: // foo = bar" und ich bin in der Lage, dass in meiner App kein Problem abzufangen. Nun, wenn ich eine Schleife erstellen und mehrere window.location.href-Aufrufe gleichzeitig ausführen, dann wird shouldStartLoadWithRequest nur einmal aufgerufen und der Aufruf, den es erhält, ist das allerletzte fire von window.location.href am Ende der Schleife.

Die gleiche Sache mit der Webansicht für Android geschieht, nur die letzte window.location.href wird verarbeitet.

+0

Ich fand eine clevere Lösung. Erstellen Sie dynamisch einen iframe für jeden Befehl und setzen Sie seinen src auf "command: // foo = bar", Sie können dies mehrfach in einer Schleife auslösen und sustartStartLoadWithRequest wird jedes Mal aufgerufen! Jetzt zu studieren, wie man das optimiert. Ich denke nicht, dass es gut wäre, Tausende von Iframes zu erstellen (obwohl sie versteckt sind). Irgendwelche Vorschläge dazu? – AlBeebe

+0

Ich würde versuchen, jeden Standort Anruf auch zu optimieren. Wenn Sie nur 60 Anrufe pro Minute senden können, stellen Sie sicher, dass Sie jeden Anruf mit genügend Abfragevars und Fragmenten blockieren, um mehrere Befehle pro Anruf zu verarbeiten. Vielleicht möchten Sie auch wkWebView: http://shipster.com/wkwebkit/ es automatisiert einen Großteil dieses Prozesses und ist zuverlässiger. – newshorts

Antwort

39
iFrame = document.createElement("IFRAME"); 
iFrame.setAttribute("src", "command://foo=bar"); 
document.body.appendChild(iFrame); 
iFrame.parentNode.removeChild(iFrame); 
iFrame = null; 

So schafft dies einen Iframe, setzt seine Quelle auf einen Befehl im Versuch, an die App übergeben, dann, sobald sein, um den Körper should beigefügten aufgerufen wird, dann entfernen wir den iframe aus dem Körper, und setze es auf null, um den Speicher freizugeben.

ich diese auch auf einem Android-webview getestet shouldOverrideUrlLoading mit und es funktionierte auch richtig!

+3

Diese Lösung ist schrecklich hässlich, aber es scheint die am wenigsten abscheulich hässliche Lösung zu sein. Es scheint, dass Javascript "optimiert", indem window.location-Aufrufe ignoriert werden, die anschließend durch andere window.location-Aufrufe ersetzt werden. Danke, dass du mich vor einer sehr schmerzhaften Debugging-Sitzung gerettet hast! – Arkaaito

+0

@Arkaaito +1 für die hässlich hässlich, stimme ich völlig – AlBeebe

+4

Ich möchte nachverfolgen, seit ich diese vor 2 Jahren gepostet. Ich schrieb eine Android- und iPhone-App, die im Grunde eine in eine native App eingebettete Webansicht war. Ich benutzte diese Lösung, so dass ich von der Webansicht zur nativen App kommunizieren konnte und es funktionierte einwandfrei seit 2 Jahren. Ich hatte über 500k + Downloads meiner App. – AlBeebe

0

Nein, url Wechsel des iframe wird shouldOverrideUrlLoading nicht auslösen, zumindest nicht in Android 2.2.

3

Ich schlug dieses Problem auch und hier ist meine Lösung, die für mich funktioniert. Alle meine JavaScript-Funktionen verwenden diese Funktion __js2oc (msg) Daten zu übergeben und Veranstaltungen zu Objective-C über should: P. S. Ersetzen Sie "command:" durch den von Ihnen verwendeten "appname:" - Trigger.

/* iPhone JS2Objective-C bridge interface */ 
var __js2oc_wait = 300; // min delay between calls in milliseconds 
var __prev_t = 0; 
function __js2oc(m) { 
    // It's a VERY NARROW Bridge so traffic must be throttled 
    var __now = new Date(); 
    var __curr_t = __now.getTime(); 
    var __diff_t = __curr_t - __prev_t; 
    if (__diff_t > __js2oc_wait) { 
    __prev_t = __curr_t; 
    window.location.href = "command:" + m; 
    } else { 
    __prev_t = __curr_t + __js2oc_wait - __diff_t; 
    setTimeout(function() { 
     window.location.href = "command:" + m; 
    }, (__js2oc_wait - __diff_t)); 
    } 
} 
Verwandte Themen