2012-05-09 19 views
7

Tengo una interfaz de sitio web/control Asp.Net 4.0 que usa un panel de actualización y algunos botones. El panel de actualización está conectado a un temporizador que se ejecuta cada 5 segundos, lo que provoca una devolución de datos parcial. Los botones alterna algunos ajustes y luego obliga a una actualización del panel de actualización a través de una llamada similar a esto:ASP.NET La devolución de datos de Ajax se detiene de repente en IPhone/IPad

var prm = Sys.WebForms.PageRequestManager.getInstance(); 
prm._doPostBack('<%= UpdatePanel.ClientID %>', ''); 
return true; 

El sitio funciona bien en IE/Firefox y en los dispositivos móviles de Safari (iPhone/iPad), pero en el móvil dispositivos la devolución de datos al azar y silenciosamente deja de funcionar. Me imagino que puede tener que ver con el ahorro de baterías y que safari cierra la devolución de datos parcial cuando está inactiva. El problema es que cuando el usuario regresa al sitio, la devolución de datos se cierra por completo y ni el temporizador ni los botones vuelven a generar devoluciones. (He monitoreado el tráfico de red en el servidor para verificar esto). Ni siquiera cuando el usuario actualiza el sitio web (varias veces) vuelve a funcionar la devolución de datos parcial. Simplemente deja de publicar datos en el servidor. Entonces, de repente y sin ningún motivo en particular, la devolución de datos comienza a funcionar de nuevo. El tiempo de inactividad suele ser de hasta 10 minutos, lo que hace que mi sitio web sea completamente inútil para este propósito.

Dado que transcurre tanto tiempo antes de que la devolución de datos vuelva a comenzar, me pregunto si hay alguna configuración en el lado del cliente o en IIS para jugar.

El sitio web se ejecutará solo en los dispositivos de mis clientes, no es público, por lo que si hay alguna configuración para jugar con el cliente estoy dispuesto a hacerlo.

Estoy realmente confundido acerca de esto y no he encontrado una manera de desencadenar el "error", simplemente sucede a veces. Cualquier consejo y consejo son muy apreciados.


Actualización:

añadido algunas manejo de errores y tengo (no siempre) recibir el siguiente mensaje cuando la devolución de datos falla:

La página está realizando una devolución de datos asincrónica pero el ScriptManager. La propiedad SupportParialRendering está establecida en false. Asegúrese de que la propiedad esté configurada como verdadera durante la devolución de datos.

Odly suficientemente esta propiedad es obviamente cierto para el dispositivo en primera instancia, de lo contrario la devolución de datos nunca funcionaría, que no es el caso.


Actualización 2: encontrado el blog folloing sugiriendo cambiar el BrowserCap puesta en web.config. Intentando esto ahora. Informará de nuevo. Otras sugerencias son muy bienvenidas. ASP.NET 4 BrowserCaps (or: what were they thinking?)

Lo anterior deshabilita javascript en safari mobile en modo de pantalla completa (se ejecuta desde la pantalla de inicio). El siguiente artículo sugiere una solución a este problema. Gotcha: iPad versus ASP.NET

Respuesta

6

Los hallazgos en "actualización 2" en mi pregunta resuelven el problema. Al parecer, los AgentesDeUsuario Safari ocasionalmente reconocidos como Mozilla 0.0, como se identifica en la siguiente entrada en el blog: ASP.NET 4 BrowserCaps (or: what were they thinking?):

El primer WTF es que el marco .NET en realidad una excepción si se detecta una devolución de datos asincrónica desde un navegador que, de acuerdo a BrowserCaps no admite la devolución de datos asincrónica.Es como si pensaran que saben mejor quién es capaz de aceptar devoluciones de datos asíncronas incluso con una abrumadora evidencia de lo contrario ...

La siguiente WTF fue sustancialmente más difícil de encontrar. ¿Por qué Safari UserAgents se reconoce ocasionalmente como Mozilla 0.0 y por qué nunca pude reproducir el problema incluso cuando uso una cadena UserAgent que acabo de copiar de una excepción?

La respuesta está en

<browserCaps userAgentCacheKeyLength="64" />

El ajuste predeterminado para la caché longitud de la clave de agente de usuario es tomar los primeros 64 caracteres de la cadena user-agent. ...

Y al final de la página:

Ajuste del userAgentCacheKeyLength a 256 resuelto el problema, a pesar de que todavía hay cadenas de agente de usuario por ahí que están identificados como Mozilla 0.0. Al menos ahora es consistente.

lo tanto, poner en <browserCaps userAgentCacheKeyLength="256" /> Web.Config resuelve el problema.


Esto, desafortunadamente, provoca otro problema cuando el navegador Safari se utiliza en el modo de pantalla completa (enlace guardado en la pantalla de inicio). En modo de pantalla completa, Safari utiliza una cadena de agente de usuario HTTP diferente, y ASP.NET ya no reconoce el navegador como Safari, sino que lo reconoce como un navegador genérico sin capacidades y, por ejemplo, JavaScript y JQuery dejará de funcionar. El se elabora adicionalmente en Gotcha: iPad versus ASP.NET. La solución es poner lo siguiente en Page_Init en cada sitio web. No muy elegante, pero funciona en conjunto con lo anterior:

protected void Page_PreInit(object sender, EventArgs e) 
{ 
    if (Request.UserAgent != null && Request.UserAgent.IndexOf("AppleWebKit", StringComparison.CurrentCultureIgnoreCase) > -1) 
    { 
     this.ClientTarget = "uplevel"; 
    } 
} 
+0

Gracias @Avada Kedavra! Tenía exactamente el mismo problema, '' lo arregló. ¡Muy apreciado! Todavía no he puesto en la sección 'Page_PreInit', ¿podría esto simplemente colocarse en la página maestra, digamos que funciona en todas las páginas? –

+0

@mcpDESIGNS: No lo he intentado, pero estoy interesado en cualquier forma que pueda hacer que la solución sea más ordenada con menos código. ¿Has tenido éxito con el enfoque que sugieres? –

+0

Tendré que hacer más pruebas y ¡te lo haré saber! Y solo quería decir que 'Page_PreInit' en la página maestra lo haría para que no tenga que copiarlo/pegarlo en cada página secundaria. –

Cuestiones relacionadas