Implementazione push/Comet server alternativo per browser Android senza inviare messaggi 4KB?

Question

Sto sviluppando un'applicazione Web che utilizza la tecnica iFrame di Comet Hidden per inviare dati dal server al browser mobile.

Tutto funziona bene su Mobile Safari ma Android è molto più doloroso. Sembra che siano necessari 4 KB per essere inviati dal server in modo che il messaggio venga preso in considerazione. Questo è per ogni messaggio non solo il primo.

Alcune persone hanno cercato attuazione Comet utilizzando lo streaming XMLHttpRequest, ma hanno gli stessi problemi di 4KB (http://code.google.com/p/android/issues/detail?id=13044)

Qualcuno è riuscito a implementare Tecniche di cometa sul browser Android senza dover caricare i messaggi su 4KB?

provata su Android evento inviato 2.1,2.2

Server non sembra essere supportata anche su Android versione 4,0 http://caniuse.com/eventsource

Lo stesso vale per websocket http://caniuse.com/websockets

grazie

-seb

Answer 1

Non so se si qualifi es come risposta al tuo problema immediato, ma la raccomandazione generale è di usare una tecnica a prova di futuro che ricada su un valore ragionevole polyfill.

Per il tuo problema specifico, credo che WebSockets sia la migliore tecnologia, in combinazione con un server WebSocket (node.js, Kaazing), con buone opzioni di fallback. Sono più familiare con Kaazing: offre praticamente le stesse prestazioni su browser non compatibili con WebSocket come le prestazioni native di WebSocket. Per ulteriori informazioni sull'emulazione WebSocket, è possibile trovare this post useful on WebSocket emulation.

Answer 2

Questo problema con il buffer da 4 KB è in circolazione da molto tempo ed è ancora valido per i browser desktop e per Android Internet.app (di cui non ero a conoscenza).

La soluzione è inviare un blocco da 4KB con la connessione iniziale. E questo è uno scenario in cui HTTP Streaming è una soluzione migliore di HTTP Long-Polling. Con lo streaming si mantiene aperta la connessione quando sono disponibili nuovi dati, diversamente dal polling prolungato in cui si chiude e si riapre una connessione. Questa tecnica significa che c'è una prima sfortunata quantità di 4KB di dati inutili, ma tutti i dati al di là di questo sono dati effettivi (utilizzabili). Ho passato ore della mia vita a scherzare con questa dimensione del buffer ed a volte è incoerente tra i browser web.

Ma ci sono aziende come Caplin Systems che usano HTTP Streaming nelle loro applicazioni di livello enterprise, utilizzate da numerose istituzioni finanziarie, quindi è possibile farlo funzionare in modo coerente.

Qualcuno è riuscito a implementare le tecniche di Comet sul browser Android senza dover caricare i messaggi su 4KB?

È altamente improbabile che ciò accada mai. E WebSockets (come sottolineato da @Peter Moskovits) sono il modo in cui questa comunicazione bidirezionale (con un'enfasi sulla spinta al momento) sarà realizzata cross-browser in futuro.Per Android ciò significa che l'utente avrebbe anche bisogno di Flash installato sul proprio dispositivo affinché l'applicazione Internet supporti la tecnica di fallback Flash che sarà richiesta poiché Android, per il momento, non supporta nativamente WebSockets.

Answer 3

Su Android, con browser e rgd. WebSockets:

• Firefox Mobile ha il supporto (. Incl RFC6455 finale)

• del browser integrato non ha il supporto per WS di sorta (. Fino al incl Android 4)

• Chrome per dispositivi mobili (full RFC6455) .. disponibile solo per Android 4