open - ¿Por qué es UIWebView canGoBack=NO en iOS7?
uiwebview tutorial (4)
Después de cambiar la propiedad a referencia " strong ", mi problema desapareció.
antes de:
@property (nonatomic, weak) IBOutlet UIWebView *webView;
después de cambiar la propiedad a " strong ":
@property (nonatomic, strong) IBOutlet UIWebView *webView;
Estoy integrando este sitio web en mi aplicación de esta manera:
NSString *url = [NSString stringWithFormat:@"https://mobile.twitter.com/search?q=%@", @"@test OR #test"];
url = [url stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
[self.twitterWebView loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:url]]];
self.twitterWebView.scalesPageToFit = YES;
Y tengo 2 botones para ir y volver en este sitio web. estoy llamando
[self.twitterWebView goBack]; y
[self.twitterWebView goForward]; en consecuencia.
Esto funciona bien en iOS 6 pero en iOS 7, las propiedades canGoBack y canGoForward de mi vista web son NO y, por lo tanto, mis botones de atrás y de adelante no funcionan.
Como nota al margen, cuando la aplicación se instala la primera vez y la página se carga la primera vez, mis botones funcionan. Pero cuando vuelvo a ejecutar mi aplicación y cuando toco un enlace en el sitio web, la propiedad canGoBack de mi vista web comienza a regresar siempre NO.
¿Como puedo resolver esto?
EDITAR : Cargué una mini aplicación de prueba que demuestra mi problema. Puedes descargarlo desde aquí . Ejecute la aplicación en un simulador de iOS 7, asegúrese de que el botón Atrás funcione en la primera instalación de la aplicación. Luego salga, vuelva a ejecutar la aplicación y verá que dejará de funcionar.
Por cierto, el problema parece ser sobre el sitio móvil de Twitter. Puede probar con otra dirección de sitio web y ver eso.
Tuve este problema también en iOS 7. Lo que funcionó para mí fue mover el código "canGoBack" y el código "canGoForward" a shouldStartLoadWithRequest como se muestra a continuación. Antes, lo tenía en webViewDidFinishLoad, que funcionaba para iOS 6, pero no para iOS 7.
- (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:(NSURLRequest *)request
navigationType:(UIWebViewNavigationType)navigationType
{
if ([webView canGoBack])
{
[browserBackItem setEnabled:YES];
}
else
{
[browserBackItem setEnabled:NO];
}
if ([webView canGoForward])
{
[browserForwardItem setEnabled:YES];
}
else
{
[browserForwardItem setEnabled:NO];
}
return YES;
}
Tuve el mismo problema. Puedo resolverlo con los siguientes cambios.
Implementado un nuevo método updateButtons
- (void)updateButtons:(UIWebView*)theWebView {
if ([theWebView canGoBack])
{
self.backButton.enabled = YES;
}
else
{
self.backButton.enabled = NO;
}
if ([theWebView canGoForward])
{
self.forwardButton.enabled = YES;
}
else
{
self.forwardButton.enabled = NO;
}
}
Se agregó una llamada al método anterior en los eventos shouldStartLoadWithRequest, webViewDidFinishLoad, didFailLoadWithError .
Ahora viene la parte difícil. Después de realizar los cambios anteriores, los botones para avanzar y retroceder funcionan como se esperaba, excepto en un escenario. Cuando volvemos a la primera página presionando el botón Atrás, no se desactiva. Debido a que no activará ninguno de los eventos anteriores cuando la página se está cargando presionando el botón Atrás / Adelante. simplemente carga desde el caché.
He intentado muchos enfoques, pero solo uno que resolvió mi problema.
Se agregó un observador en WebHistoryItemChangedNotification.
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(webViewHistoryDidChange:)
name:@"WebHistoryItemChangedNotification"
object:nil];
Llamado el mismo método de botones de actualización en webViewHistoryDidChange.
- (void)webViewHistoryDidChange
{
[self updateButtons:self.webView];
}
Esto parece estar relacionado con la funcionalidad de "caché de la aplicación" de HTML5 . En el primer lanzamiento, el sitio no se almacena en caché y el UIWebView detecta correctamente si puede avanzar o retroceder. Tan pronto como se llena el caché, las nuevas instancias de UIWebView deciden que, incluso si el URL cambia (lo que se puede observar en el UIWebViewDelegate de webView:shouldStartLoadWithRequest:navigationType: , ya no es posible avanzar o retroceder. canGoForward y canGoBack devolverán NO y goForward y goBack no harán nada. Esto persiste en todos los reinicios de la aplicación, siempre que exista la memoria caché HTML5 para este sitio específico.
Tal vez este problema se limite a las aplicaciones web que modifican el identificador de Fragmento de la URL después de la marca hash a través de JavaScript. Y sí, el comportamiento de UIWebView en esta situación cambió entre iOS 6 e iOS 7.
Todavía no he encontrado una solución, y probablemente tengamos que esperar a que Apple solucione esto en iOS 7.1 o más.
Editar
Otras personas también tienen este problema:
Si está utilizando Application Cache y también administra estados mediante hash u otra técnica, el objeto de historial no conservará su historial de navegación, por lo tanto, history.back () nunca funcionará y history.length se mantendrá en 1 para siempre.
(de http://www.mobilexweb.com/blog/safari-ios7-html5-problems-apis-review )
Editar 2
Este problema existe en Safari 7.0 (9537.71, predeterminado en OS X 10.9 Mavericks) también. Sin embargo, la construcción nocturna más reciente de WebKit (r158339) parece funcionar correctamente. Es muy probable que solo sea cuestión de tiempo hasta que la solución llegue a una versión de iOS y OS X.
Editar 3
Este problema aún existe en iOS 7.1 y OS X 10.9.2.
Editar 4
¡Este error se ha solucionado en iOS 8 y Safari 7.1 (9537.85.10.17.1) para OS X!
Relacionado: