UIWebView shouldStartLoadWithRequest solo se llamó una vez?

Question

En mi aplicación de iPhone, tengo un UIWebView donde estoy cargando un html local. Todo funciona bien, pero ahora quiero poder manejar enlaces locales (a notas al pie): cuando hago clic en un enlace local, quiero poder saltar a la nota al pie de página referida por él, y luego poder volver .

<a href="#tofootnote">jump to footnote</a> 

manejé esto añadiendo mi código para shouldStartLoadWithRequest e interceptar clics de enlace locales; cuando se hace clic en un enlace local, trabajo mi magia (ocultar algunos elementos de la interfaz de usuario, agregar un botón de retroceso, etc.); al hacer clic en el botón Atrás, vuelvo a la ubicación original en el documento html.

El problema es que al hacer clic UNA VEZ MÁS en el enlace ya no se invoca shouldStartLoadWithRequest. Es decir, el código siguiente:

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType { 
NSLog(@"foo bar"); 
return YES; 
} 

sólo muestra "foo bar" ONCE (en realidad, dos veces - la primera vez que estoy cargando inicialmente el documento), pero sólo una vez después, independientemente del número de veces que' m haciendo clic en el enlace local

Entonces, a menos que alguien tenga una mejor explicación, supongo que UIWebView almacena en caché el documento o enlace o algo así y ya no llama al manejador después de la llamada inicial; Si este es el caso, ¿cómo puedo borrar esta caché interna? (sin volver a cargar el documento)

Answer 1

La única solución que he encontrado para este problema es reemplazar todas las anclas de "#anchor" a algo que se considera una URL, como "| ancla". De esta manera UIWebView pensará que es un enlace real e intentará la solicitud cuando se haga clic. Obviamente, esta solución solo funcionará si maneja todos los clics usted mismo y, por lo tanto, puede interpretar los anclajes modificados. Puedo entender el motivo del comportamiento de UIWebView, pero es bastante frustrante. El delegado realmente necesita mensajes para hacer coincidir los controladores onclick, etc.

Answer 2

Intente 'tocar' la etiqueta del anclaje (asígnela a sí misma). Mi hipótesis es que hará que el DOM se actualice, lo que hace que vuelva a verificar el enlace. ¡No lo he probado, es solo una idea!

Answer 3

Esto parece estar sucediendo para mí también cuando uso un onclick = "window.location.hash = ...; return false;" en lugar de capturar el clic.

Si me desplazo un poco o hago clic en otro delimitador, puedo usar el enlace nuevamente.

Answer 4

NSURLRequest * request = [petición NSURLRequestWithURL: fileURL cachePolocy: NSURLRequestReloadIgnoringLocalCacheData timeoutInterval: 60.0];

[webView loadRequest: request];

Answer 5

Si su están cargando el contenido utilizando la loadHTMLString, como:

[webView loadHTMLString:htmlString baseURL:[[NSBundle mainBundle] bundleURL]]; 

Entonces parece ser suficiente sólo para recargar la html-cadena. Al hacer clic en el ancla, (de nuevo) llamará a su gancho de delegado.

Answer 6

Un truco que encontré cuando me encontré con este problema usando jquery mobile incrustó cambios en la página fue agregar un número al azar en el hash. De esta manera iOS parece pensar que es una nueva solicitud:

//set location hash to path 
set: function(path) { 
    path += "&" + Math.random(); 
    location.hash = path; 
}, 

Esto debería funcionar ajustando dinámicamente el camino a través de un evento onclick también.

Answer 7

Puedo solucionar este problema estableciendo window.location en un ancla ficticia después de manipular la válida.

- (BOOL)webView:(UIWebView *)aWebView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType { 
    if ([[request URL] fragment]) { 
     if ([[[request URL] fragment] isEqualToString:@"__DUMMY_ANCHOR"]) 
      return NO; 

     // Do your custom handling of the anchor here 

     // Change the location to a non-existent anchor 
     [aWebView stringByEvaluatingJavaScriptFromString:@"window.location='#__DUMMY_ANCHOR'"]; 

     return NO; 
    } 
} 

Answer 8

Una variación en el código (operativo) de Ben Dolman anterior. "Restablece" el caché de UIWebView con los dos enlaces ficticios para que los enlaces posteriores sigan llamando al método. Primero guarda el enlace interno, o fragmento en un NSString llamado savedFragment. Luego le dice a UIWebview que cargue el primer enlace ficticio #pageX y luego otro #pageY. Finalmente, toma el FragmentoSalvo y lo usa para construir el número de página, que luego se usa en un método separado para desplazar el UIWebview a la ubicación correcta.

- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request navigationType:(UIWebViewNavigationType)navigationType { 


    if ([[request URL] fragment]) { //check if fragment exists (treat as internal link) 

     NSString *fragment = [[request URL] fragment]; 

     //If the fragment is neither "pageX" nor "pageY", treat as an internal link in the PDF 
     if (![fragment isEqualToString:@"pageX"] && 
      ![fragment isEqualToString:@"pageY"]) { 

      savedFragment = fragment; //hold the fragment in savedFragment (NSString) 
      [pdfWebView stringByEvaluatingJavaScriptFromString:@"window.location='#pageX'"]; //load UIWebView with first dummy link 

     } else if ([fragment isEqualToString:@"pageX"]) { 

      [pdfWebView stringByEvaluatingJavaScriptFromString:@"window.location='#pageY'"]; //load UIWebView with second dummy link 

     } else { 

      NSString *pageString = [savedFragment stringByReplacingOccurrencesOfString:@"page" withString:@""]; //grab the page from savedFragment 
      int page = [pageString intValue]; 
      [self scrollWebViewToPage:page-1]; //scroll to page (seperate method) 
     } 

     return NO; //do not load any of the dummy links 

    } else { 

     return YES; //first load of PDF into UIWebView should be allowed 
    } 

}