5

I am developing a web application that uses Comet Hidden iFrame technique to push data from server to mobile browser.

Everything works fine on Mobile Safari but Android is a lot more painful. It seems to require 4 KB messages to be sent from the server in order the message to be taken in account. This is for each messages not only the first one.

Some people tried implementing Comet using XMLHttpRequest streaming but have the same 4KB issues (http://code.google.com/p/android/issues/detail?id=13044)

Has anyone managed to implement Comet techniques on Android browser without requiring to pad the messages to 4KB ?

Tested on Android 2.1,2.2

Server sent event seems not to be supported even on version Android 4.0 http://caniuse.com/eventsource

Same for websocket http://caniuse.com/websockets

thanks

-seb

seb
  • 425
  • 5
  • 16

3 Answers3

2

Not sure if it qualifies as an answer to your immediate problem, but the general recommendation is to use a future-proof technique that falls back to a reasonably good polyfill.

For your specific issue, I believe WebSockets is the best technology, in combination with a WebSocket server (node.js, Kaazing), with good fallback options. I'm more familiar with Kaazing: it provides virtually the same performance on non-WebSocket-compliant browsers as the native WebSocket performance. For more on WebSocket emulation, you may find this post useful on WebSocket emulation.

Peter Moskovits
  • 4,236
  • 1
  • 20
  • 15
1

This 4KB buffer problem has been around for a long time and is still the case on desktop browsers as well as Android Internet.app (which I didn't know about).

The solution is to send a 4KB chunk with the initial connection. And this is one scenario where HTTP Streaming is a better solution than HTTP Long-Polling. With streaming you keep the connection open when new data is available, unlike Long-Polling where you close and then re-open a connection. This technique means that there is an initial unfortunate 4KB chunk of useless data but all data beyond that is actual data (usable). I've spent hours of my life messing with this buffer size and it's sometimes inconsistent between web browsers.

But, there are companies such as Caplin Systems who use HTTP Streaming in their enterprise level applications, used by numerous financial institutions, so it is possible to get this working consistently well.

Has anyone managed to implement Comet techniques on Android browser without requiring to pad the messages to 4KB ?

It's highly unlikely that this will ever happen. And WebSockets (as pointed out by @Peter Moskovits) are the way that this bi-directional communication (with an emphasis on push at the moment) will be achieved cross-browser in the future. For Android this does mean that the user would also need Flash installed on their device for the Internet application to support the Flash fallback technique which will be required since Android, for the moment, does not natively support WebSockets.

leggetter
  • 15,248
  • 1
  • 55
  • 61
1

On Android, and with browsers, and rgd. WebSockets:

  • Firefox Mobile has support (incl. final RFC6455)

  • builtin browser has no support for WS whatsoever (up to and incl. Android 4)

  • Chrome for Mobile (full RFC6455) .. only avail for Android 4

oberstet
  • 21,353
  • 10
  • 64
  • 97