WebViewClient onReceivedError veraltet, neue Version erkennt nicht alle Fehler
Lesezeit: 3 Minuten
Martin Epsz
Im Android-SDK 23 onReceivedError(WebView view, int errorCode, String description, String failingUrl) wurde verworfen und durch ersetzt onReceivedError(WebView view, WebResourceRequest request, WebResourceError error). Wenn ich mein Telefon jedoch in den Flugzeugmodus versetze und eine URL in mein WebView lade, wird nur die veraltete Version der Methode aufgerufen.
onReceivedHttpError (WebView view, WebResourceRequest request, WebResourceResponse errorResponse) ist auch nicht nützlich, da es nur Fehler über 500 erkennt und ich einen 109-Statuscode erhalte.
Gibt es eine nicht veraltete Methode, um zu erkennen, dass mein WebView nicht geladen werden konnte?
Stellen Sie sicher, dass Sie mit Android SDK 23 testen
– Karan
25. September 2015 um 11:36 Uhr
@KaranMer, das ist schon so.
– Martin Epsz
25. September 2015 um 14:26 Uhr
Läuft auf dem mobilen Gerät, auf dem Sie testen, tatsächlich Android Marshmallow (API 23)? Selbst wenn Sie Ihre App auf dem API 23 SDK entwickeln, die App dann aber auf Android Lollipop ausführen, erhalten Sie immer noch das „alte“ onReceivedError, weil es die Funktion des Betriebssystems ist, nicht eines SDK. Außerdem ist der “Fehlercode 109” (ich denke, das ist net::ERR_ADDRESS_UNREACHABLE) kein HTTP-Fehlercode, sondern der Fehlercode von Chrome. onReceivedHttpError wird nur für die vom Server per HTTP empfangenen Fehler aufgerufen. Wenn sich das Gerät im Flugmodus befindet, kann es unmöglich eine Antwort von einem Server erhalten.
– Michail Naganow
26. September 2015 um 1:02 Uhr
@MikhailNaganov das ist hilfreich. Wenn Sie das als Antwort posten, werde ich es akzeptieren.
– Martin Epsz
26. September 2015 um 20:36 Uhr
Die Lösung besteht also darin, beide Methoden im Client zu überschreiben und zu erwarten, dass das Betriebssystem bestimmt, welche aufgerufen wird, denke ich.
– Richard Le Mesurier
31. August 2016 um 13:23 Uhr
xdevs23
Sie könnten auch Folgendes tun:
@SuppressWarnings("deprecation")
@Override
public void onReceivedError(WebView view, int errorCode, String description, String failingUrl) {
// Handle the error
}
@TargetApi(android.os.Build.VERSION_CODES.M)
@Override
public void onReceivedError(WebView view, WebResourceRequest req, WebResourceError rerr) {
// Redirect to deprecated method, so you can use it in all SDK versions
onReceivedError(view, rerr.getErrorCode(), rerr.getDescription().toString(), req.getUrl().toString());
}
Stellen Sie sicher, dass Sie importieren android.annotation.TargetApi
das funktioniert! 30.11.2015 , auf Android 4x, mit neuestem SDK für 5x
– jmp
30. November 2015 um 19:16 Uhr
Bitte beachten Sie, dass der neue SDK 23-Callback für jede Ressource (Iframe, Bild usw.) aufgerufen wird, die nicht geladen werden konnte, nicht nur für die Hauptseite … daher muss Ihre Behandlung von Fehlern möglicherweise entsprechend geändert werden.
– k2col
19. April 2016 um 6:30 Uhr
@ShahidSarwar Das ist falsch! Das Problem, das Sie hatten, hat in keiner Weise mit dem in dieser Frage besprochenen Code zu tun. Das onReceivedSslError Rückruf und was du da gemacht hast, ist ein ganz anderes Thema.
– kräh
20. Februar 2017 um 15:30 Uhr
@ShahidSarwar hat versucht zu veröffentlichen und es wurde veröffentlicht, was nun?
– Lalit Poptani
5. Juli 2017 um 12:24 Uhr
@ShahidSarwar: Entschuldigung, der Link, den Sie hier geteilt haben, ist ein anderes Thema und hat in diesem Zusammenhang keine Relevanz. Die Person, die dort die Frage gestellt hat, hat ‘handler.proceed()’ verwendet; blind auf den ‘onReceivedSslError’-Callback. Deshalb hat Google es abgelehnt, und ich bin auch einmal auf die gleiche Situation gestoßen. Wie auch immer, die Antwort hier von xdevs23 ist zumindest vorerst die beste.
– Midhu
4. August 2017 um 4:16 Uhr
Bitte beachten Sie, dass das mobile Gerät, auf dem Sie testen, tatsächlich Android Marshmallow (API 23) ausführen muss. Selbst wenn Sie Ihre App auf dem API 23 SDK entwickeln, die App dann aber auf Android Lollipop ausführen, erhalten Sie immer noch das „alte“ onReceivedErrorweil es die Funktion des Betriebssystems ist, nicht eines SDK.
Auch der “Fehlercode 109” (ich denke, das ist net::ERR_ADDRESS_UNREACHABLE) ist kein HTTP-Fehlercode, sondern der Fehlercode von Chrome. onReceivedHttpError wird nur für die vom Server per HTTP empfangenen Fehler aufgerufen. Wenn sich das Gerät im Flugmodus befindet, kann es unmöglich eine Antwort von einem Server erhalten.
Wie kann das die Antwort sein? Es gibt nicht die Lösung
– Kasnady
2. September 2017 um 8:46 Uhr
Die Lösung besteht darin, ein Gerät mit >=23 zu verwenden
– MDjava
8. November 2018 um 5:12 Uhr
11596000cookie-checkWebViewClient onReceivedError veraltet, neue Version erkennt nicht alle Fehleryes
Stellen Sie sicher, dass Sie mit Android SDK 23 testen
– Karan
25. September 2015 um 11:36 Uhr
@KaranMer, das ist schon so.
– Martin Epsz
25. September 2015 um 14:26 Uhr
Läuft auf dem mobilen Gerät, auf dem Sie testen, tatsächlich Android Marshmallow (API 23)? Selbst wenn Sie Ihre App auf dem API 23 SDK entwickeln, die App dann aber auf Android Lollipop ausführen, erhalten Sie immer noch das „alte“
onReceivedError
, weil es die Funktion des Betriebssystems ist, nicht eines SDK. Außerdem ist der “Fehlercode 109” (ich denke, das ist net::ERR_ADDRESS_UNREACHABLE) kein HTTP-Fehlercode, sondern der Fehlercode von Chrome.onReceivedHttpError
wird nur für die vom Server per HTTP empfangenen Fehler aufgerufen. Wenn sich das Gerät im Flugmodus befindet, kann es unmöglich eine Antwort von einem Server erhalten.– Michail Naganow
26. September 2015 um 1:02 Uhr
@MikhailNaganov das ist hilfreich. Wenn Sie das als Antwort posten, werde ich es akzeptieren.
– Martin Epsz
26. September 2015 um 20:36 Uhr
Die Lösung besteht also darin, beide Methoden im Client zu überschreiben und zu erwarten, dass das Betriebssystem bestimmt, welche aufgerufen wird, denke ich.
– Richard Le Mesurier
31. August 2016 um 13:23 Uhr