2011-11-22 9 views
5

Zajmuję się tworzeniem aplikacji sieci web, która wykorzystuje technikę ukrytych iFrame Comet do przesyłania danych z serwera do przeglądarki mobilnej.Alternatywne wdrożenie serwera Push/Comet dla przeglądarki Android bez wysyłania wiadomości 4KB?

Wszystko działa poprawnie na Mobile Safari, ale Android jest o wiele bardziej bolesny. Wydaje się, że wymagane są komunikaty o wielkości 4 KB wysyłane z serwera, aby wiadomość mogła zostać pobrana na konto. To jest dla każdego komunikatu nie tylko pierwszego.

Niektórzy ludzie próbowali realizacji Comet używając XMLHttpRequest strumieniowe ale mają te same problemy 4KB (http://code.google.com/p/android/issues/detail?id=13044)

Czy ktoś udało się wdrożyć Techniki komet w przeglądarce Androida bez konieczności przesyłania wiadomości do 4KB?

Testowane na Androida 2.1,2.2

Serwer wysłał zdarzenie nie wydaje się być obsługiwane nawet w wersji Android 4,0 http://caniuse.com/eventsource

samo dla websocket http://caniuse.com/websockets

dzięki

-seb

Odpowiedz

2

Nie jestem pewien, czy kwalifikuje się Jest to odpowiedź na twój natychmiastowy problem, ale ogólną rekomendacją jest zastosowanie techniki przyszłościowej, która powróci do rozsądnie dobrego polyfill.

Dla konkretnego problemu uważam, że WebSockets to najlepsza technologia w połączeniu z serwerem WebSocket (node.js, Kaazing), z dobrymi opcjami rezerwowymi. Jestem bardziej zaznajomiony z Kaazing: zapewnia praktycznie taką samą wydajność w przeglądarkach niezgodnych z WebSocket, co natywna wydajność WebSocket. Aby uzyskać więcej informacji na temat emulacji WebSocket, możesz znaleźć this post useful on WebSocket emulation.

+0

Websockets ** nie ** działają na większości połączeń 3G. Miej to na uwadze, skacząc na modę. –

+0

Właśnie dlatego emulacja jest tak ważna ... –

1

Ten problem z buforem 4KB istnieje od dłuższego czasu i nadal występuje w przeglądarkach komputerowych, a także w Androidzie Internet.app (o czym nie wiedziałem).

Rozwiązaniem jest wysłanie porcji 4KB z początkowym połączeniem. I jest to jeden scenariusz, w którym HTTP Streaming jest lepszym rozwiązaniem niż HTTP Long-Polling. W przypadku przesyłania strumieniowego połączenie pozostanie otwarte, gdy dostępne będą nowe dane, w przeciwieństwie do opcji Long-Polling po zamknięciu, a następnie ponownym otwarciu połączenia. Ta technika oznacza, że ​​istnieje początkowo niefortunna porcja 4KB bezużytecznych danych, ale wszystkie dane poza nią są rzeczywistymi danymi (użyteczne). Spędziłem wiele godzin z tym rozmiarem bufora i czasami jest niespójne między przeglądarkami.

Ale są firmy takie jak Caplin Systems, które używają Streaming HTTP w swoich aplikacjach na poziomie korporacyjnym, używanych przez wiele instytucji finansowych, dzięki czemu można pracować tak dobrze.

Czy ktoś zdołał wdrożyć techniki komet w przeglądarce Androida bez konieczności wysyłania wiadomości do 4KB?

Jest wysoce nieprawdopodobne, aby tak się stało. A WebSockets (jak wskazano przez @Peter Moskovits) są sposobem, w jaki ta dwukierunkowa komunikacja (z naciskiem na pchnięcie w tym momencie) zostanie osiągnięta w przyszłości w przeglądarce.W przypadku Androida oznacza to, że użytkownik musiałby również zainstalować Flash na swoim urządzeniu, aby aplikacja internetowa obsługiwała awaryjną technikę Flash, która będzie wymagana od chwili obecnej, ponieważ Android nie obsługuje natywnie WebSockets.

1

Na Androidzie oraz w przeglądarkach i rgd. WebSockets:

  • Firefox Mobile ma wsparcia (. Zaw końcowy RFC6455)

  • wbudowana przeglądarka nie obsługuje WS ogóle (. Aż do i włącznie z Androidem 4)

  • Chrome for Mobile (pełny RFC6455) .. tylko na Androida 4

+0

Websockets są wsparte z Androidem 4.4 –

Powiązane problemy