¿La diferencia entre shouldoverrideurlloading y shouldinterceptrequest?
Cualquier persona por favor dígame la diferencia entre los métodos public WebResourceResponse shouldInterceptRequest (WebView view, WebResourceRequest request) y public boolean shouldOverrideUrlLoading(WebView view, String url) .
Estoy creando una aplicación de Android en la que una cadena se obtiene como la respuesta de un evento de clic en mi WebView . Quiero almacenar esta cadena y mostrar it.I vio ambos de estos shouldOverrideUrlLoading intentó usar shouldOverrideUrlLoading que devuelve la URL de redireccionamiento Cuando he comprobado con la creación de una aplicación de ejemplo utilizando google.com como la url que cargué en mi WebView y WebView clic en un menú.
¿Podría alguien por favor decirme la diferencia entre ambos métodos y cuál debo usar?
La implementación de Android WebKit permite al desarrollador modificar un WebView a través de la clase android.webkit.WebSettings como
- Soporte para JavaScript,
- Soporte para Plugins,
- Acceso al sistema de archivos,
- Inspección de recursos, etc.
En la inspección de recursos , es posible inspeccionar las solicitudes de contenido y / o recursos mediante la sustitución de métodos shouldOverrideUrlLoading y shouldInterceptRequest .
Pero por encima de dos métodos se utilizan con fines diferentes, como
1. shouldOverrideUrlLoading se llama cuando una nueva página está a punto de ser abierta, mientras que shouldInterceptRequest se llama cada vez que se carga un recurso como un archivo css, un archivo js, etc.
2.Si un usuario solicita interactivamente un recurso desde una WebView, es posible mediante el uso del método shouldOverrideUrlLoading de la clase WebViewClient para interceptar la solicitud. El código de ejemplo se presenta a continuación. Fuente
private class MyWebViewClient extends WebViewClient { @Override public boolean shouldOverrideUrlLoading(WebView view, String url) { if (Uri.parse(url).getHost().equals("www.google.com")) { return true; } return false; } }
El método da a la aplicación host la oportunidad de hacerse cargo del control cuando una nueva URL está a punto de cargarse en la WebView actual. Un valor devuelto de true significa que la aplicación host maneja la URL, mientras que return false significa que el WebView actual maneja la URL. El código anterior evita que los recursos se carguen desde el host "www.google.com".
Sin embargo, el método no intercepta la carga de recursos desde dentro, como desde un atributo IFRAME o src dentro de una etiqueta HTML o SCRIPT, por ejemplo. Además XmlHttpRequests también no sería interceptado. Para interceptar estas solicitudes puede hacer uso del método WebInterceptRequest de shouldInterceptRequest . El código de ejemplo se presenta a continuación.
@Override public WebResourceResponse shouldInterceptRequest(final WebView view, String url) { if (url.contains(".js")) { return getWebResourceResponseFromString(); } else { return super.shouldInterceptRequest(view, url); } } private WebResourceResponse getWebResourceResponseFromString() { return getUtf8EncodedWebResourceResponse(new StringBufferInputStream("alert('!NO!')")); } private WebResourceResponse getUtf8EncodedWebResourceResponse(InputStream data) { return new WebResourceResponse("text/css", "UTF-8", data); }
El método notifica a la aplicación host de una solicitud de recurso y permite que la aplicación devuelva los datos. Si el valor devuelto es nulo, WebView continuará cargando el recurso como de costumbre. De lo contrario, se utilizará la respuesta de retorno y los datos. El código anterior intercepta las solicitudes de recursos JavaScript (.js) y devuelve una alerta en lugar del recurso solicitado.
Vea más en: WebViewClient shouldOverrideUrlLoading y shouldInterceptRequest
Trate de entender de esta manera, espero que esto le ayudará a resolver su problema.
Public WebResourceResponse shouldInterceptRequest (vista WebView, URL de cadena)
Added in API level 11 This method was deprecated in API level 21. Use shouldInterceptRequest(WebView, WebResourceRequest) instead. Notify the host application of a resource request and allow the application to return the data. If the return value is null, the WebView will continue to load the resource as usual. Otherwise, the return response and data will be used. NOTE: This method is called on a thread other than the UI thread so clients should exercise caution when accessing private data or the view system. Parameters view The WebView that is requesting the resource. url The raw url of the resource. Returns A WebResourceResponse containing the response information or null if the WebView should load the resource itself.
Public boolean shouldOverrideUrlLoading (vista de WebView, URL de cadena)
Added in API level 1 Give the host application a chance to take over the control when a new url is about to be loaded in the current WebView. If WebViewClient is not provided, by default WebView will ask Activity Manager to choose the proper handler for the url. If WebViewClient is provided, return true means the host application handles the url, while return false means the current WebView handles the url. This method is not called for requests using the POST "method". Parameters view The WebView that is initiating the callback. url The url to be loaded. Returns True if the host application wants to leave the current WebView and handle the url itself, otherwise return false.
Ref: http://developer.android.com/reference/android/webkit/WebViewClient.html
Creo que shouldOverrideUrlLoading se invoca cuando se está cargando una nueva página en la vista web, por ejemplo, cuando haces tu inicial:
webview.loadUrl( "file:///android_asset/web/index.html" );
YOur shouldOverrideUrlLoading se invocará, y se volverá a invocar si el usuario hace clic en un enlace para navegar a una nueva página.
ShouldInterceptRequest debe ser llamado para todas las solicitudes realizadas dentro de la página actual, por ejemplo. Cuando HTML importar fuentes veo shouldInterceptRequest ser llamado, o cuando el webView intenta cargar imágenes en mi página se llama (pero no estoy viendo que llamó a las solicitudes de ajax, así que todavía estoy un poco confundido).