Ważną nowością w standardzie HTML5 jest wprowadzenie API pozwalających na wymianę danych między dokumentem, przeglądarką a serwerem. Przyjrzyjmy się najbardziej obiecującym z nich.
API (Application Programming Interface — interfejs programowania aplikacji) związane z HTML-em 5 zacierają granice miedzy dokumentem, pamięcią przeglądarki a zasobami serwera. Znacząco ułatwią tworzenie webaplikacji, ale wykorzysta je również branża reklamowa i twórcy aplikacji na urządzenia mobilne.
Geolocation API
API geolokalizacyjne (http://dev.w3.org/geo/api/spec-source.html ) pozwala na pobranie lokalizacji, w której fizycznie znajduje się internauta i przekazanie jej do serwera. Druga funkcja Geolocation API to śledzenie zmiany lokalizacji, jeśli użytkownik przemieszcza się w trakcie odwiedzania strony. W skład Geolocation API wchodzi obiekt Position oraz trzy metody:
- getCurrentPosition – zwraca obiekt Position z informacjami o geograficznym położeniu urządzenia lub błąd
- watchPosition – śledzi użytkownika i wysyła nowy obiekt Position przy każdej zmianie położenia
- clearWatch – zatrzymuje wybrany proces śledzenia
API to było projektowane z myślą o urządzeniach mobilnych z wbudowanym GPS-em, takich jak smartfony i tablety. Jednak Firefox 3.5 wdrożył ten system jako pierwsza przeglądarka przeznaczona na komputery biurkowe. W połowie 2010 roku API obsługiwały wszystkie najważniejsze przeglądarki (w tym Internet Explorer), chociaż w niektórych przypadkach musiały wykorzystać do tego Google Gears.
Skąd przeglądarka wie gdzie jestem?
Urządzenia mobilne mogą pobierać dane z wbudowanego GPS-u lub ustalić pozycję za pomocą tzw. triangulacji. Metoda ta polega na pomiarze siły sygnału trzech najbliższych stacji bazowych, wyznaczeniu przybliżonych odległości od nich i znalezieniu współrzędnych geograficznych punktu, który odpowiada takiemu układowi. Dokładność wynosi od kilkudziesięciu metrów do 2-3 kilometrów, w zależności od zagęszczenia stacji bazowych (w mieście większe) i czasu trwania sesji.
Ustalenie pozycji jest trudniejsze w przypadku komputerów stacjonarnych i większości laptopów – zwykle nie mają ani modułu GPS, ani dostępu do sieci GSM. Przeglądarki korzystają więc z Google Location Services. Usługa ta gromadzi informacje o położeniu bezprzewodowych routerach WiFi oraz lokalizacjach sieci o danym IP. W najlepszych okolicznościach (duże zagęszczenie sieci WiFi w okolicy) dokładność może wynieść nawet kilka metrów!
Standard zakłada, że w obydwu przypadkach niezbędne będzie udzielenie wyraźnej zgody na dostęp danej witryny do Geolocation API, chociaż mimo wszystko budzi ono obawy co do zachowania prywatności. Odpowiedzi na pytania związane z prywatnością można znaleźć na stronie Mozilli (http://pl.www.mozilla.com/pl/firefox/geolocation/).
Naturalne zastosowanie Geolocation API to szybkie wyszukiwanie interesujących punktów i osób w okolicy przez telefon. Jednak API przyda się również w serwisach społecznościowych i informacyjnych (dostaniemy więcej spersonalizowanych informacji lokalnych). Nie można zapomnieć o wyświetlaniu reklam lokalnych usługodawców. Kiedy będziemy przeglądać temat na forum dotyczący naprawy butów, obok wyświetli się reklama najbliższego szewca.
Baza danych w przeglądarce
Web SQL Database (http://dev.w3.org/html5/webdatabase/) służy do tworzenia baz danych i wykonywania operacji na nich na komputerze użytkownika, z wykorzystaniem znanego języka zapytań do baz danych.
Baza przechowywana jest w pamięci przeglądarki, a dostęp do niej następuje tylko w ramach jednej domeny. Może zostać usunięta przez użytkownika. {link_wew 6858}Baza danych{/link_wew} zachowuje się więc podobnie jak cookies, ale jej niezaprzeczalną zaletą jest możliwość manipulowania danymi za pomocą prostych metod API i znanego dialektu SQL.
API wygląda na użyteczne i pozwoli np. na stworzenie cache’u bazy, pracę offline albo przeniesienie obciążenia z serwera na komputer użytkownika. Warto zwrócić uwagę na to, że jest to trend odwrotny do obecnego, zakładającego przeniesienie jak największej ilości obliczeń w chmury obliczeniowe.
Standard definiuje SQLite jako język zapytań, ale W3C nie gwarantuje, że zostanie on zachowany. W specyfikacji czytamy nawet, że stosowanie SQLite jako jedynego dialektu jest nie do zaakceptowania przez W3C. Web SQL Database wspierają jedynie Chrome, Safari i Opera. Z racji niepewnej przyszłości tego API, obecnie nie należy stosować go jako jedynego systemu dostępu do danych przez webaplikację.
Web Storage lepsze niż ciasteczka
Oczywiście nie zabrakło alternatywy do Web SQL Database. W najprostszych rozwiązaniach wystarczy Web Storage API (http://www.w3.org/TR/2009/WD-webstorage-20091222/), baza danych przyporządkowująca klucz do wartości, bardzo przypominająca mechanizm cookies. Web Storage przystosowano jednak do pracy w wielu otwartych jednocześnie kartach przeglądarki, w których użytkownik wypełnia ten sam formularz – np. podczas zakupów. Samo cookies może nie działać poprawnie w takiej sytuacji, a dane mogą zostać nadpisane.
Mechanizm ten pozwala również na przechowywanie dużej ilości danych po stronie klienta (np. wpisywany przez niego tekst na blogu). Ułatwia to odzyskanie danych w przypadku awarii. Ilość miejsca przeznaczonego na dane konkretnych witryn powinni określić producenci przeglądarek. Również odpowiedzialność za dostęp do danych z różnych domen (np. domen wyższego poziomu i subdomen) została przeniesiona na nich.
Baza na przyszłość
Web Storage z powodu swojej prostoty nie sprawdzi się jednak wszędzie. W styczniu 2010 roku W3C przedstawiło więc szkic kolejnego API, które posłuży do budowy baz danych po stronie klienta. Indexed Database API (http://www.w3.org/TR/2010/WD-IndexedDB-20100105/) ma stać się alternatywą dla Web SQL Database. W przeciwieństwie do niego, nie jest ograniczone jednym językiem zapytań. Również Microsoft entuzjastycznie wypowiada się o Indexed Database, co może świadczyć zarówno o obsłudze API przez Internet Explorera jak i współpracę z MS SQL-em.
Indexed Database ma współpracować z nierelacyjnymi bazami danych, obsługiwać transakcje i – tak jak większość nowych API – działać asynchronicznie. O ile prace nad tym API nie zostaną wstrzymane, a producenci przeglądarek je zaakceptują, to ma ono duże szanse na oficjalne wsparcie ze strony W3C.
JavaScript w końcu podziała w tle!
Jednym z ciekawszych API wprowadzonych z HTML-em 5 jest technologia Web Workers, która dodaje wielowątkowość do JavaScriptu. Utworzenie nowego obiektu Worker pozwoli na równoległą pracę różnych fragmentów kodu JS (w ramach jednego procesu). Sprawdza się to do jednej instrukcji:
var worker = new Worker ("worker.js");
Jako argument (lub argumenty) podajemy pliki mające być wykonane w oddzielnych wątkach. Wątki działające w tle nie mają dostępu do obiektów DOM. Z jednej strony eliminuje to problem synchronizacji dostępu do zasobów między wieloma wątkami. Nie trzeba korzystać z semaforów czy muteksów, co zdecydowanie ułatwia pracę. Z drugiej strony możliwości Web Workers są przez to ograniczone.
Do komunikacji między wątkami możemy wykorzystać komunikaty oraz… Web Storage albo Web SQL Database. Za poprawność danych odpowiada w tym przypadku przeglądarka, a dokładniej wbudowany w nią silnik bazodanowy, więc również pozbywamy się problemów z synchronizacją czy zakleszczeniami.
Wprowadzenie wielowątkowości pozwala na przeniesienie skomplikowanych obliczeń w tło. Dzięki temu nie trzeba już wywoływać skryptu co ustalony czas, a komunikacja między serwerem i przeglądarką może zachodzić przez cały czas w wyjątkowo łatwy sposób.
Web Workers API jest wykorzystywane przez Firefoksa (od wersji 3.5) oraz w uproszczonej wersji w Safari 4. Pozostałe przeglądarki wymagają skorzystania z nieaktualizowanego już Google Gears.
Komunikacja z serwerem w trybie ciągłym
Równie interesująca technologia, wprowadzona w 2009 roku w przeglądarce Chromium, to Web Sockets (http://dev.w3.org/html5/websockets/). API to służy do utrzymania stale otwartego, dwukierunkowego połączenia między serwerem a przeglądarką, które wykorzystuje protokół TCP. Wprowadzenie Web Sockets pozwoli zmniejszyć obciążenie sieci (nie trzeba przesyłać nagłówków przy każdym komunikacie). W połączeniu z Web Workers umożliwi ponadto wygodną pracę twórców aplikacji na urządzenia mobilne.
W chwili pisania artykułu trwały prace nad wdrożeniem technologii do Firefoksa i Safari. Oczywiście wymagane jest również skonfigurowanie serwera tak, aby potrafił komunikować się z przeglądarką. Można do tego wykorzystać np. moduł pywebsocket (http://code.google.com/p/pywebsocket/) do serwera Apache, wydany przez Google.
To jeszcze nie standard!
API wprowadzone w HTML5 pozwolą na łatwą i skuteczną komunikację miedzy serwerem a użytkownikiem i szersze wykorzystanie dostępnych zasobów takich jak informacje o położeniu czy dodatkowa pamięć. Niestety to, czy zostaną wdrożone zależy w dużej mierze od twórców przeglądarek.
Nie można również zapominać o tym, że HTML5 w dużej części pozostaje w stanie szkicu, a nie oficjalnego standardu, więc wiele może się jeszcze zmienić. Najdobitniej pokazało to Web SQL Database API, które nagle zostało zastąpione inną technologią. Gdyby ktoś postanowił wykorzystać omawiane API w produktach komercyjnych, powinien cały czas mieć na uwadze jego historię. W3C może jeszcze powiedzieć „nie, tego jednak nie chcemy”.
