Implementación alternativa de Push/Comet Server para el navegador Android sin enviar mensajes 4KB?

Question

Estoy desarrollando una aplicación web que utiliza la técnica Comet Hidden iFrame para enviar datos desde el servidor al navegador móvil.

Todo funciona bien en Mobile Safari pero Android es mucho más doloroso. Parece que se requieren 4 KB de mensajes enviados desde el servidor para que el mensaje se tome en cuenta. Esto es para cada mensaje, no solo para el primero.

Algunas personas trataron de implementar el cometa utilizando XMLHttpRequest en streaming, pero tienen los mismos problemas de 4 KB (http://code.google.com/p/android/issues/detail?id=13044)

Alguien ha conseguido poner en práctica ¿Técnicas cometas en el navegador Android sin necesidad de rellenar los mensajes a 4 KB?

probado en Android evento enviado 2.1,2.2

Server no parece estar apoyada incluso en la versión Android 4,0 http://caniuse.com/eventsource

Lo mismo para WebSocket http://caniuse.com/websockets

gracias

-seb

Answer 1

No estoy seguro de si califica es una respuesta a su problema inmediato, pero la recomendación general es utilizar una técnica a prueba de futuro que vuelva a ser razonablemente buena polyfill.

Para su problema específico, creo que WebSockets es la mejor tecnología, en combinación con un servidor WebSocket (node.js, Kaazing), con buenas opciones de respaldo. Estoy más familiarizado con Kaazing: ofrece prácticamente el mismo rendimiento en navegadores no compatibles con WebSocket que el rendimiento nativo de WebSocket. Para obtener más información sobre la emulación WebSocket, puede encontrar this post useful on WebSocket emulation.

Answer 2

Este problema de búfer de 4 KB ha existido durante mucho tiempo y sigue siendo el caso en los navegadores de escritorio, así como Android Internet.app (que no sabía).

La solución es enviar un fragmento de 4 KB con la conexión inicial. Y este es un escenario donde HTTP Streaming es una solución mejor que HTTP Long-Polling. Con la transmisión, mantienes la conexión abierta cuando hay nuevos datos disponibles, a diferencia de Long-Polling donde cierras y luego vuelves a abrir una conexión. Esta técnica significa que hay un desafortunado primer pedazo de 4KB de datos inútiles pero todos los datos más allá de eso son datos reales (utilizables). Pasé horas de mi vida jugando con este tamaño de búfer y, a veces, es incoherente entre los navegadores web.

Pero, hay empresas como Caplin Systems que utilizan HTTP Streaming en sus aplicaciones de nivel empresarial, utilizadas por numerosas instituciones financieras, por lo que es posible hacer que esto funcione bien.

¿Alguien ha logrado implementar las técnicas de Comet en el navegador de Android sin tener que rellenar los mensajes a 4 KB?

Es muy poco probable que esto ocurra. Y WebSockets (como señaló @Peter Moskovits) es la forma en que se logrará esta comunicación bidireccional (con énfasis en impulsar en este momento) entre navegadores en el futuro.Para Android, esto significa que el usuario también necesitaría instalar Flash en su dispositivo para que la aplicación de Internet admita la técnica de recuperación de Flash, que será necesaria ya que Android, por el momento, no admite WebSockets de forma nativa.

Answer 3

En Android, con navegadores y rgd. WebSockets:

• Firefox Mobile tiene soporte (Incl. RFC6455 final)

• navegador integrado no tiene soporte para WS absoluto (. Hasta e incluyendo Android 4)

• Chrome para móviles (RFC6455 completo) .. solo está disponible para Android 4