Scott Tiger Tech Blog

Blog technologiczny firmy Scott Tiger S.A.

HTML5: File, File Writer i FileSystem API

Autor: Piotr Karpiuk o 27. sierpnia 2011

Przedmiotem dzisiejszego posta jest wchodzące w skład HTML5 API dzięki któremu JavaScript może w przeglądarce operować na plikach lokalnych, co można wykorzystać do tworzenia cache’y i danych offline na użytek aplikacji (np. baza emaili w webowym kliencie poczty, dostępna nawet po utracie połączenia z Internetem). Póki co API zaimplementowane jest w Google Chrome 9+, a jego podstawy (File API) w Firefox 3.6.3+.

Czytelnik obeznany z obsługą AJAXa (zwłaszcza w najnowszej, drugiej wersji) odnajdzie się tu bez trudu, ponieważ sposób wykonywania operacji I/O jest bliźniaczo podobny jak w XMLHttpRequest2. Tu również mamy do dyspozycji zdarzenia które pozwalają nam monitorować przebieg operacji (obsługując je możemy np. uaktualniać pasek postępu), podobnie jak mamy do wyboru tryb asynchroniczny i synchroniczny (ten drugi z przeznaczeniem dla osobnych wątków – WebWorkers). Zawartość pliku możemy traktować jako łańcuch, Data URL, blob, lub ArrayBuffer. Data URL to (w uproszczeniu) łańcuch reprezentujący tablicę bajtów w Base64 – można go użyć w HTMLowym img.src (czyli jako źródło danych wyświetlanego obrazka). Dwa ostatnie typy danych zostały wprowadzone ponieważ sam JavaScript nie udostępnia typu całkowitoliczbowego ani wydajnej implementacji tablicy bajtów, przy czym ArrayBuffer reprezentuje bufor danych na potrzeby WebGL.

File

File API pozwala reprezentować w przeglądarce plik, jak również uzyskać dostęp do metadanych plików lokalnych wybranych w formularzu przez użytkownika, oraz dostęp do danych zawartych w plikach (odczyt). Istotna nowinka znacząco poprawiająca doznania Internautów: teraz w kontrolce wyboru pliku dzięki atrybutowi multiple użytkownik może wybrać wiele plików naraz, a dzięki webkitdirectory nawet cały katalog. Może też przeciągać pliki z pulpitu do formularza na stronie WWW i odwrotnie. Po wyborze plików, a przed wysłaniem ich do serwera, z poziomu JavaScriptu możemy ustalić dla każdego z nich nazwę, rozmiar, typ MIME, datę ostatniej modyfikacji itp., a także wczytać zawartość pliku do przeglądarki. Dzięki temu możemy np. już w przeglądarce stwierdzić że plik jest zbyt duży aby przesyłać go na serwer, wyświetlić podgląd obrazka (ang. thumbnail), ewentualnie zapisać zawartość pliku w systemie plików zarezerwowanym dla aplikacji webowej (patrz FileSystem API dalej) tak aby była dostępna offline gdy nie ma dostępu do Internetu itd.

Czytaj więcej »

Tags: ,
Napisany w Google Chrome, WWW | Brak komentarzy »

Server-Sent Events

Autor: Piotr Karpiuk o 19. listopada 2010

SSE to kolejna technologia komunikacji serwera z przeglądarką w ramach nowego standardu HTML5. Pozwala ona zestawić wydajny, jednokierunkowy kanał komunikacyjny w którym serwer pcha komunikaty do przeglądarki (aktualizacja statusu, zmiany kursów akcji, itp.). W odróżnieniu od WebSockets nie wymaga implementowania nowego protokołu i wykorzystuje HTTP. W kodzie JavaScript strony piszemy:

  var source = new EventSource('http://localhost/blog/events.php');
  source.addEventListener('message', function (event) {
    alert(event.data);
  });

Gdy połączenie HTTP zostanie zerwane, przeglądarka automatycznie zestawi nowe.

Oprócz zdarzenia message przeglądarka może również nasłuchiwać zdarzeń open (gdy kanał zostanie otwarty) i error (gdy wystąpi błąd), oraz zamknąć kanał wykonując close() na obiekcie EventSource.

Od strony serwera istotne jest aby nagłówek HTTP zawierał pozycje:

  Content-Type: text/event-stream
  Cache-Control: no-cache

Każdy komunikat ma postać:

  data: first linen
  data: second linenn

Tzn. może być wielowierszowy przy czym każdy wiersz zaczyna się prefiksem data:, a kończy się podwójnym znakiem końca wiersza.

Tags: ,
Napisany w WWW | Brak komentarzy »

WebSocket

Autor: Piotr Karpiuk o 10. listopada 2010

Aby dowiedzieć się więcej o innych zagadnieniach związanych z nowym standardem HTML5, zajrzyj do osobnego artykułu.

HTTP jest protokołem zapytanie-odpowiedź z własnymi narzutami na niepotrzebne nagłówki, przez co słabo się nadaje na realizację kanału full-duplex czasu rzeczywistego. Podejmowano różne rozpaczliwe próby rozwiązania problemu – wszystkie słabo skalowalne, nadmiernie obciążające sieć i procesor, wolne, nierzadko podatne na błędy i skomplikowane:

  • Ajax polling,
  • Ajax long-polling: polling wstrzymujący odpowiedź serwera gdy nie ma danych do przesłania,
  • streaming: serwer odsyła odpowiedź ale nie sygnalizuje jej końca, przez co przeglądarka odbiera kolejne „uzupełnienia” będące kolejnymi komunikatami od serwera; problemem są tu serwery proxy po drodze, które nie widząc końca komunikatu mogą zdecydować o jego buforowaniu; rozwiązanie to użycie TLS (SSL) lub powrót do Ajax long-polling przy wykryciu buforujących proxy po drodze; Comet (zwany też Ajax Push, Reverse Ajax, Two-way web, HTTP streaming, HTTP server push) – to zbiorczy termin dla zestawu różnych technik sprowadzających się do tego że długo realizowana odpowiedź na żądanie HTTP z przeglądarki pozwala serwerowi WWW wpychać kolejne dane do klienta.

HTML5 WebSocket definiuje kanał komunikacyjny full-duplex przeznaczony dla sterowanych zdarzeniami aplikacji WWW „czasu rzeczywistego”. W chwili obecnej implementowany w Chrome 4.0+, Firefox 4.0+ i Safari 5.0+ (nie ma w MSIE i Operze).

Jeśli serwer WWW implementuje standard, wówczas w dowolnym momencie istniejące połączenie HTTP można łatwo przekształcić w połączenie WebSocket. Wystarczy, że przeglądarka wyśle do serwera komunikat HTTP:

    GET /demo HTTP/1.1
    Host: example.com
    Connection: Upgrade
    Sec-WebSocket-Key2: 12998 5 Y3 1 .P00
    Sec-WebSocket-Protocol: sample
    Upgrade: WebSocket
    Sec-WebSocket-Key1: 4@1 46546xW%0l 1 5
    Origin: http://example.com

    [8-byte security key]

Serwer odpowiada:
Czytaj więcej »

Tags: ,
Napisany w WWW | Brak komentarzy »

HTML5

Autor: Piotr Karpiuk o 5. listopada 2010

Celem zespołu pracującego nad HTML5 jest utworzenie standardu który pozwalałby uruchamiać aplikacje RIA w przeglądarce WWW. Choć jeszcze niekompletny, to już stanowczo wspierany przez producentów wiodących przeglądarek standard będzie używany przez następne lata (zauważ, że powstały w 1997r. HTML4 obowiązuje juz 13 lat!).

Główne cechy projektu nowego standardu:

  • rozwiązuje praktyczne problemy (takie o których mówi się od lat),
  • wspiera istniejące elementy języka (większość z HTML 4.01 przeżywa w HTML5); zapewnia możliwość łatwego zastępowania nowości starymi odpowiednikami (łagodna degradacja),
  • nie wymyśla koła od nowa, korzysta z wydeptanych ścieżek (ang. pave the cowpaths),
  • jeśli jakiś wzorzec implementowany w JavaScripcie jest wystarczająco popularny, HTML5 realizuje go deklaratywnie za pomocą znaczników i arkuszy stylów,
  • w razie konfliktu interesów ustawia priorytety w kolejności: użytkownik, twórca aplikacji WWW, twórca przeglądarki, twórca specyfikacji, czystość teorii,
  • promuje rozdzielanie treści (znaczniki) od prezentacji (CSS); odradza używania niestosujących się do tej zasady znaczników w HTML 4.0 i dodaje nowe znaczniki semantyczne,
  • przejęcie funkcjonalności dotychczas oferowanej tylko przez pluginy (audio/video/edycja grafiki rastrowej).

Osobny artykuł – od dłuższego czasu przygotowywany na okoliczność prezentacji jaka w firmie ma się odbyć w listopadzie – przedstawia treściwe podsumowanie poszczególnych składowych HTML5 wraz z przykładami i linkami.

Tags:
Napisany w WWW | Brak komentarzy »