Aplikacja: Lista mailingowa w HTML5 (IndexedDB i AppCache)


24 stycznia 2014 / Michał Załęcki


Gdy HTML5 przestawał być odległą przyszłością głośno mówiło się o tym, że pozwoli on na pisanie aplikacji, cokolwiek to by miało oznaczać. Pozostawmy jednak nomenklaturę i zajmijmy się tym co ma dla nas faktyczne znaczenie. Czas zweryfikował możliwości HTML5, a specyfikacja dojrzała. My zaczęliśmy korzystać z dobrodziejstw nowego narzędzia.

Dzisiaj spośród wielu nowych funkcji HTML5 szczególnie interesować będą nas dwie. Jedna z nich to AppCache, który pozwoli użytkownikom na korzystanie ze strony WWW w trybie offline. Na łamach WEBroad pojawił się już artykuł dający solidne podstawy do korzystania z AppCache, a wpis z typowo praktycznym podejściem będziecie mogli przeczytać już niedługo. Druga nowość to IndexedDB. Specyfikacja jest w fazie Candidate Recommendation. Wsparcie IndexedDB pozwala już na jej funkcjonalne wykorzystanie bez zapewniania rozwiązania zastępczego na każdym kroku, chodź to zależy oczywiście od samego charakteru witryny. Dla większości użytkowników urządzeń mobilnych IndexedDB jest jednak nadal niedostępna.

Funkcje aplikacji

Przed napisaniem aplikacji musimy jasno określić jakie funkcje ma spełniać. Nasza będzie pozwalała na:

  • Stworzenie listy mailingowej (dodawanie, edytowanie i usuwanie)
  • Wysłanie maila, poprzez kliknięcie linku mailto, dla konkretnego kontaktu
  • Wysłanie maila, poprzez kliknięcie linku mailto, do wszystkich kontaktów
  • Dane będą przechowywane za pomocą bazy danych IndexedDB
  • Z aplikacji będzie można korzystać bez połączenia z Internetem
  • Dodawane adresy muszą mieć poprawny format, a w przypadku błędu musimy poinformować o tym użytkownika

Skoro już określiliśmy podstawową funkcjonalność pora zabrać się za pisanie aplikacji. By zaoszczędzić na czasie skorzystamy z Zurb Foundation, ale nic nie stoi na przeszkodzie żebyście napisali własny CSS.

HTML

Poza oczywistymi kwestiami warto zwrócić uwagę na to, że w tagu <head> umieściliśmy atrybut manifest. Wartością atrybutu manifest jest ścieżka do pliku manifest.

.htaccess

Plik manifest musi zostać wysłany z mime-type text/cache-manifest. Może to wymagać dodania powyższego typu.

JavaScript

To właśnie tu dzieje się cała „magia”. W kontekście IndexedDB znajomość SQL jest zbędna. IndexedDB nie przechowuje danych w tabelach z sztywno określonymi wartościami jakie mają znaleźć się w odpowiednich kolumnach. IndexedDB przechowuje dane na zasadzie całych obiektów. Brzmi nieźle prawda?

 

1. appCacheStatus()

Funkcja appCacheStatus zwraca aktualny status cachu przeglądarki.

2. validEmail(email)

Funkcja validEmail pozwala na sprawdzenie czy podany w parametrze adres mailowy jest poprawny.

3. updateSendToAllLink(addresses)

Funkcja updateSendToAllLink uaktualnia link służący do wysłania maila wszystkim kontaktom z listy mailingowej.

4. showAddresses(addresses)

Funkcja showAddresses generuje listę kontaktów.

5. addAddress(e)

Funckcja addAddress odpowiada za dodanie adresu do listy. Zachodzi w niej sprawdzenie czy adres mailowy jest poprawny. Jeżeli tak, to wykorzystuje przekazany w zadaszeniu obiekt do stworzenia transakcji za pomocą której zostanie zapisany nowy kontakt.

6. getAddresses(db, callbacks)

Funkcja getAddresses pobiera za pomocą kursora wszystkie kontakty i uruchamia przekazane w drugim parametrze funkcje zwrotne przekazując do nich listę pobranych adresów.

7. deleteAddress(e)

Funckja deleteAddress analogicznie do addAddress odpowiada za usunięcie kontaktu z bazy danych.

8. editAddress(e)

Funkcja editAddress pełni dwa zadania. Pierwsze to pobranie edytowanego kontaktu i wypełnienie formularza. Drugie to uaktualnienie danych i wyczyszczenie formularza. Musimy pamiętać, że nie następuje tu przeładowanie witryny. Co więcej, to nawet nie jest formularz.

9. Informacja o nowej wersji

Przeglądarka załaduje witrynę i wykryje, że plik manifest uległ zmianie (sygnał do uaktualnienia pamięci cache). Nowa strona zostanie załadowana dopiero po ponownym odwiedzeniu strony. Dlatego w dobrym tonie jest poinformowanie użytkowania o tym fakcie i danie mu możliwości wyboru.

10. Big Bang!

Jeżeli tylko wspierana jest IndexedDB to otwieramy bazę danych i dodajemy zdarzenia do przycisków. Pamiętać trzeba, że niektóre z przycisków są później dołączane do DOM i przypisanie im zdarzeń musi odbyć się za pomocą zdarzenia funkcji delegate.

Przydatne linki


Tagi:


5 odpowiedzi na “Aplikacja: Lista mailingowa w HTML5 (IndexedDB i AppCache)”

  1. Piotr Nalepa pisze:

    Pomysł na appkę ciekawy. Kilka rzeczy, które mi się rzuciły w oczy.
    1). Raz język angielski, raz język polski …
    2). selektory w jQuery, lepiej stosować zapis $(’tbody’, '#table’) lub $(’#table’).find(’tbody’);
    3). formatowanie kodu jest straszne …

    • Dzięki.

      1 i 3 > Z tym formatowaniem to coś źle wyświetla(ło), spójrz jak jest na GitHub, jest tam też poprawiony język. Zauważyłem to dopiero po publikacji (wstawieniu screena).

      2 > Preferuję find, o jakieś 40%. Umknęło w ferworze „walki” z problemami na FF :)

  2. Comandeer pisze:

    >IndexedDB przechowuje dane na zasadzie całych obiektów. Brzmi nieźle prawda?
    WebSQL przy niektórych aplikacjach brzmi o wiele lepiej i przystępniej ;)

    co do samego IndexedDB – byłem pewien, że nie da się napisać bardziej brzydkiego API niźli DOM < 4. Myliłem się. W3C potrafi… No cóż ;)
    IndexedDB ma tak naprawdę jedną, jedyną przewagę nad localStorage – jest asynchroniczne. Gdyby localStorage było asynchroniczne, nikt o zdrowych zmysłach nie używałby tego potwora. No ale stało się, "kompatybilności Sieci łamać nie wolno", za co teraz pokutujemy…
    IndexedDB bez jakiejkolwiek warstwy abstrakcji jest dla mnie po prostu nieużywalne. I po prostu przekombinowane. A za argument o SQLi, który uwalił speckę WebSQL, należy się komuś kulka w łeb.

    Co do samej apki: pomyślałbym o ładnym przełożeniu tego na obiekty (lub choćby jeden namespace) i systemie szablonów. Funkcje wbrew pozorom później trudno utrzymywać ;)

    • Jeżeli chodzi o localStorage to nie zapominajmy, że jest ono alternatywą dla cookies, a nie żadnego z ww. systemów bazodanowych. Nad śmiercią WebSQL ubolewam szczególnie, że w SQL czuje się jak ryba w wodzie. Zastąpiono je tym nieszczęsnym IndexedDB z okropnym API. SQL injection jest/było problemem marginalnym, ale przecież można było napisać coś na zasadzie Active Record dla osób, którym zleżałoby na bezpieczeństwie i tym samym zażegnać problem.

      Jeżeli chodzi o samą aplikacje to nie będę jej chyba rozwijał, ale jeżeli jednak by się tak stało to przestrzeń nazw faktycznie by się przydała.

      • Comandeer pisze:

        Nie zgodzę się, że localStorage zastępuje jedynie cookies. Dzięki globalnemu interfejsowi JSON możemy „zestringowić” de facto każdy obiekt (oprócz DOM-owego) i włożyć do magazynu. A wystarczy obudować to jakimś ładnym API i można nawet wyszukiwanie wbudować. I to samo, uniwersalne API mogłoby korzystać z kilku mechanizmów przechowywania pod spodem (coś na zasadzie wzorca Adapter), więc upieklibyśmy dwie pieczenie na jednym ogniu

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.