Ionic to framework do tworzenia hybrydowych aplikacji mobilnych, wykorzystujący silnik Cordova i oparty na frameworku Angular JS. Tutaj nie będziemy jednak szczegółowo omawiać aspektów związanych z jego wykorzystaniem, a jedynie przedstawię zbiór kilku luźnych obserwacji i problemów, z którymi można się spotkać, tworząc aplikacje z wykorzystaniem Ionic 2 na platformy iOS i Android. Będzie więc o kilku różnicach w działaniu aplikacji Ionic na tych dwóch platformach.

# View lifecycle

To dość ważna sprawa, bo związana z cyklem życia aplikacji. Ionic definiuje kilka stanów w cyklu życia pojedynczego widoku, a właściwie event’ów z nim związanych:

• ionViewCanEnter – wywoływany przed wejściem do widoku (zanim jeszcze to wejście jest możliwe)
• ionViewWillEnter – wywoływany tuż przed wejściem do widoku, na późniejszym etapie, tuż przed tym gdy widok stanie się aktywny
• ionViewDidEnter – po wejściu do widoku
• ionViewDidLoad – po całkowitym załadowaniu widoku (uwaga – nie zostanie wywołany, gdy powtórnie otworzymy zcache’owany widok)
• ionViewCanLeave – wywoływany przed wyjściem z widoku, analogicznie jak CanEnter
• ionViewWillLeave – przed wyjściem z widoku, tuż przed tym gdy widok przestanie być aktywny
• ionViewDidLeave – po wyjściu z widoku, gdy widok już przestał być aktywny
• ionViewWillUnload – tuż przed całkowitym usunięciem widoku

O ile na Androidzie wszystkie event’y cyklu życia są wywoływane tak jakbyśmy się tego spodziewali, o tyle na iOS okazuje się, że nie wszystkie i nie zawsze. W moim przypadku istotny fragment kodu miał być wykonywany w momencie opuszczania widoku. Problemem okazał się fakt, że podczas gdy Android w momencie wyjścia z widoku faktycznie go usuwa, iOS pozostawia go w pamięci, a tym samym eventy:

• ionViewCanLeave
• ionViewWillLeave
• ionViewDidLeave

nigdy nie zostają wywołane. W rzeczywistości jest to nie tyle błąd Ionic’a, co raczej pewne niedopatrzenie koncepcyjne (okazuje się, że dyskusja związana m.in. z tym problemem pojawiła się również na GitHub Ionic). Warto jednak mieć świadomość, że cykl życia aplikacji może być znacząco różny zależnie od platformy i lepiej zawsze upewnić się, że aplikacja zadziała w przewidywalny sposób pod każdym z systemów.

#iFrame a dostęp do hardware’u

Wydawałoby się, że to raczej dość nietypowy problem, jednak w praktyce okazuje się on zaskakująco powszechny. Załóżmy, że z jakiegoś powodu potrzebujemy umieścić jakiś element naszej aplikacji wewnątrz ramki iFrame (to najprostszy sposób, żeby wyświetlić np. zewnętrzny zasób). Tak uruchomiony kod nie będzie miał dostępu do funkcji hardware’owych systemu, np. do żyroskopu (dotyczy to iOS w wersji od 9.2 w górę) i nie ma tu znaczenia czy będzie to zasób zdalny czy lokalny. Przykład z życia wzięty? Wyświetlenie wirtualnego spaceru wewnątrz aplikacji. Taki spacer najczęściej sam w sobie jest osobną, małą aplikacją webową. Włączenie jego kodu bezpośrednio do kodu naszej aplikacji hybrydowej może okazać się kłopotliwe, dlatego często spotykanym rozwiązaniem jest umieszczenie go zdalnie (na serwerze) lub lokalnie (w zasobach aplikacji) i wywołanie niejako niezależnie, właśnie wewnątrz ramki. Jeśli wspomniany spacer posiada funkcje związane z wykorzystaniem żyroskopu (co w tym przypadku jest raczej częste), to niestety te funkcje nie będą działać pod iOS (pod Androidem nie ma tego problemu). Rozwiązanie? In App Browser, ale to już raczej temat na osobny wpis.

#Urządzenie a emulator

Chociaż emulatory iOS na macOS to jedne z lepszych emulatorów z jakimi możemy się spotkać, to jednak wciąż są tylko emulatorami i ich działanie nie zawsze w pełni pokrywa się z działaniem aplikacji na fizycznym urządzeniu. Przykładem może być polityka bezpieczeństwa, a konkretnie zezwolenie aplikacji na dostęp do określonych adresów URL. Okazuje się, że w niektórych przypadkach emulator jest bardziej restrykcyjny niż fizyczny iPhone i w przypadku dostępu do zewnętrznych adresów wymaga dodatkowych definicji w konfiguracji. Jeśli więc na emulatorze lub urządzeniu nie możemy uzyskać dostępu do zewnętrznych adresów URL, sprawdźmy czy w pliku konfiguracyjnym mamy zdefiniowane:

<access origin="*"/>
<allow-intent href="*"/>
<allow-navigation href="*"/>

Przy czym wildcard *  są dobre na potrzeby developmentu. Dla wersji produkcyjnej zamiast *  lepiej zdefiniować adresy dokładniej, choćby tak: http://example.com/* lub nawet bardziej ogólnie: *://*.example.com/*.

Czy mam problem z pamięcią?

Jak sprawdzić czy aplikacja gubi pamięć? Jest kilka szybkich sposobów, które pozwolą nam wstępnie postawić diagnozę. Szczególnie łatwo zorientujemy się jeśli wycieki pamięci są znaczne.
Naturalnie pierwszą rzeczą, która powinna zwrócić naszą uwagę jest samo zachowanie aplikacji. Jeśli aplikacja spowalnia w miarę działania, wydłużają się czasy reakcji systemu lub w jakiś inny sposób zachowuje się coraz mniej stabilnie im dłużej jest uruchomiona, wówczas powinna zapalić nam się czerwona lampka.
Doskonałych narzędzi do diagnozy problemów z wyciekami pamięci dostarcza np. Chrome Dev Tools.
Szybką odpowiedź na pytanie o sam fakt istnienia problemu często może dać obserwacja wykresu alokowanej pamięci. W Chrome Dev Tools, w zakładce Memory znajdziemy opcję „Record Allocation Timeline”. Zaznaczamy ją, klikamy „start”, wykonujemy operacje na aplikacji, które wzbudzają nasze największe podejrzenia (np. te, które wiążą się z alokowaniem i zwalnianiem największej ilości pamięci), przywracamy aplikację do punktu wyjściowego i na koniec klikamy „stop”, żeby Chrome skończył rejestrowanie wykresu. Jeśli z każdym kolejnym powtórzeniem operacji wykres rośnie (charakterystyczny jest wykres schodkowy lub „ząbkowy”), może to być pierwszym potencjalnie złym objawem. Najważniejsze jednak będzie to, czy w określonych, tych samych stanach aplikacji poziomy użycia pamięci (a więc poziomy wykresu) również są zbliżone. Świadomie używam tu słowa „zbliżone”, ponieważ pewne różnice mogą być naturalne. A więc, jeśli rozpoczęliśmy rejestrowanie wykresu, gdy aplikacja znajdowała się w określonym stanie i na koniec powróciliśmy do tego samego stanu, ale poziom użycia pamięci na koniec jest wyższy niż był na początku (wykres jest powyżej początkowego poziomu) to najprawdopodobniej oznacza to jakieś wycieki.

Z wykresu alokacji nie dowiemy się jednak gdzie jest i na czym dokładnie polega problem. Znacznie dokładniejsze odpowiedzi da nam obserwacja stosu i to właśnie ten sposób sprawdza się dla mnie najlepiej.

Jak odzyskać pamięć?

A zatem jak odnaleźć i wyeliminować wycieki pamięci w aplikacji JavaScript? Oto przepis, który sam stosuję:

1. Otwórz aplikację i przejdź do stanu początkowego (za chwilę to sobie wyjaśnimy). Nazwijmy go stanem A.
2. Otwórz narzędzia Dev Tools i przejdź do zakładki „Memory„. Wybierz opcję „Take Heap Snapshot„.
3. Wykonaj Snapshot (nr. 1).
4. Teraz wykonaj na aplikacji operację, którą chcesz przetestować pod kątem wycieków pamięci (np. załadowanie jakiegoś widoku). Przyjmijmy, że po tej operacji aplikacja znajduje się w stanie B.
5. Wykonaj kolejny Snapshot (nr. 2).
6. Przywróć aplikację do stanu A z punktu 1 (np. przechodząc z powrotem do poprzedniego widoku).
7. Wykonaj Snapshot nr. 3.
8. Teraz wybierz Snapshot nr. 3 i z rozwijanej listy zamiast domyślnie zaznaczonego „All objects” wybierz opcję „Objects allocated between Snapshot 1 and Snapshot 2”

Mówiąc o stanie początkowym, mam na myśli stan, z którego możesz bezpośrednio wykonać operację, którą zamierzasz przetestować pod kątem wycieków. A więc jeśli operacją testowaną na wycieki pamięci jest wyświetlenie widoku B, przejdź do dowolnego innego widoku (A), z którego masz możliwość bezpośredniego przejścia do B.
Oczywiście wszystko zależy od tego jak działa Twoja aplikacja, niemniej zasada pozostaje podobna. Operacją z punktów 4 i 6 może być przechodzenie pomiędzy określonymi stronami aplikacji lub np. wyłączenie i włączenie całej aplikacji, gdy daje ona taką możliwość.

Ale co właściwie zrobiliśmy powyżej?

Warto wiedzieć, że wykonując Snapshot stosu przeglądarka najpierw uruchamia Garbage Collector. A zatem użyta wcześniej pamięć, która nie jest już wykorzystywana powinna być na tym etapie zwolniona.

Warto też wiedzieć, że często rozmiar pierwszego snapshot’a może być odrobinę większy od pozostałych i nie koniecznie jest to dla nas powód do zmartwień. Natomiast kolejne snapshoty wykonywane w tych samych stanach aplikacji powinny już mieć te same rozmiary. Dla eksperymentu możesz więc wykonać dowolną liczbę powtórzeń punktów 4-7 i porównywać ze sobą rozmiary co drugich snapshotów. Ale wróćmy do naszego wyniku.

Wyświetlając obiekty zaalokowane pomiędzy snapshotem 1 i 2, wyświetlamy te obiekty, których alokacja była niezbędna do wyświetlenia widoku B. Ale przecież… Jesteśmy w widoku A. A zatem obiekty zaalokowane między snapshotami 1 i 2, które są nadal obecne w snapshocie 3 to nasi podejrzani.

Na liście znajdują się obiekty pogrupowane według typów. Rozwijając grupę zobaczymy listę konkretnych obiektów danego typu. Ich zidentyfikowanie nie zawsze będzie jednak łatwe. Czasem łatwo zidentyfikujemy obiekt po samym jego typie, o ile jest on specyficzny. Gorzej jeżeli jest to po prostu typ „Object” czy „Array”. Wówczas w identyfikacji mogą pomóc nam dwa elementy.
Po najechaniu kursorem na dany obiekt wyświetli nam się jego podgląd (czasem może być on niedostępny). Pola i metody mogą naprowadzić nas na trop. Z kolei po kliknięciu w wybrany obiekt w oknie poniżej wyświetli nam się jego graf. Może nam się więc udać zlokalizować obiekt na podstawie charakterystycznych obiektów w grafie.

Chrome oznacza niektóre elementy kolorami, co również bywa bardzo pomocne. Elementy oznaczone na czerwono to elementy odłączone z drzewa DOM, czyli takie, do których istnieją referencje, ale nie należą do DOM. Najczęściej takie elementy same w sobie nie są przyczyną wycieków, a raczej tylko ich symptomem. Mogą więc być wskazówką do poszukiwań, ale przyczyny powinniśmy szukać gdzie indziej. Inne elementy są oznaczone na żółto – to elementy, do których istnieją bezpośrednie referencje z poziomu JavaScript. I to te elementy najczęściej doprowadzą nas do przyczyny wycieków, więc warto poświęcić im szczególną uwagę.

Powodzenia i dbajcie o pamięć!

Amnezja?

W pewnym sensie… Wycieki pamięci, to obszary pamięci, które zostały zaalokowane, ale w wyniku błędu programistycznego, nie mogą zostać zwolnione, mimo, że nie są już potrzebne. W JavaScript nie alokujemy pamięci bezpośrednio. Nie musimy też jawnie jej zwalniać, bo robi to za nas Garbage Collector. Skoro wszystko dzieje się automatycznie, to skąd biorą się błędy?

Przyczyny?

Najłatwiej chyba pokazać to poprzez przykłady. Poniżej kilka spośród tych najbardziej popularnych.

Przykład #1. Przypadkowa zmienna globalna

Spójrzmy na poniższy fragment kodu:

function memLeak() {
  a = new Array(9999);
}

W praktyce jest to odwołanie do niezadeklarowanej zmiennej. W JavaScript takie odwołanie skutkuje utworzeniem zmiennej globalnej, czyli niejawnie:

function memLeak() {
  window.a = new Array(9999);
}

W tym przypadku zapomnieliśmy o słowie kluczowym var:

function memLeak() {
  var a = new Array(9999);
}

Taka zmienna pozostanie w pamięci w całym zakresie globalnym aplikacji, zamiast zajmować ją tylko na czas wykonania funkcji.

Przykład #2. Zapomniany callback lub timer

var a = {
  text: "Hello world!"
};

setInterval(function(){
  var element = document.getElementById('element');
  element.innerHTML = a.text;
}, 5000);

W powyższym przykładzie kodu,nawet kiedy usuniemy element, nie zostanie on zebrany przez Garbage Collector, ponieważ nie pozwala na to wciąż działający interval. Dopóki działa interval, ze względu na odniesienie w nim zawarte, z pamięci nie zostanie również usunięty obiekt a. Kiedy usuwamy element, powinniśmy zawsze zatrzymać wszystkie timery i usunąć eventListener’y, które się do niego odnoszą.

Przykład #3. Zapomniane odwołanie do elementu DOM

Spójrzmy na poniższy przykład kodu:

var element1 = document.getElementById('el1');
var element2 = document.getElementById('el2');

element1.addEventListener("click", function(){
  element2.parentNode.removeChild(element2);
});

Element element2 nie zostanie usunięty z pamięci, bo odwołanie do niego wciąż jest zawarte w eventListener elementu element1.

var element = document.getElementById('element');

function memLeak() {
  document.body.removeChild(document.getElementById('element');
}

I znów podobna sytuacja. W tym przypadku mimo, że usunęliśmy element z drzewa DOM, referencja do niego wciąż istnieje, więc element pozostanie w pamięci.

Co dalej?

To tylko kilka najbardziej typowych i tym samym najbardziej oczywistych przykładów kodu, który może prowadzić do wycieków pamięci. Sposobów na gubienie pamięci może być jednak znacznie więcej i szczególnie przy bardziej rozbudowanych aplikacjach trudno się ich w 100% wystrzec. Na szczęście jednak istnieje wiele narzędzi, które mogą ułatwić diagnozowanie tego typu błędów i ich korygowanie.

W kolejnej części postaram się opisać w jaki sposób, za pomocą przeglądarkowych narzędzi developerskich sprawdzić czy w aplikacji istnieją wycieki pamięci i zlokalizować je w kodzie aplikacji.

Część 2: http://blog.insprit.pl/javascript-memory-leaks-czyli-utracona-pamiec-cz-2/

Nieprecyzyjnie sformułowane zamówienie może być kłopotliwe zarówno dla zamawiającego, jak i wykonawcy, a to dlatego, że stanowi ono swego rodzaju barierę w komunikacji między obiema stronami. Oczywiście w dużej mierze to rolą wykonawcy, jako specjalisty w swojej branży, jest naprowadzenie Cię na odpowiedni tor i podpowiedzenie zarówno tego nad czym należy się zastanowić, jak i tego dlaczego poszczególne kwestie są ważne. Jeśli zupełnie nie wiesz od czego zacząć, nie martw się – dobry wykonawca z pewnością przeprowadzi Cię przez ten proces. Zgodzisz się pewnie jednak, że dobrą dla obu stron sytuacją jest, gdy przynajmniej „z grubsza” wiesz jakie kryteria są dla Ciebie istotne.

Z jednej strony jako zamawiający możesz mieć problem z wyspecyfikowaniem swoich potrzeb i oczekiwań. To przecież nie Twoja specjalizacja, czasem więc barierą bywa ograniczona znajomość technikaliów z tym związanych: „nie znam się, więc nie wiem co powinienem wziąć pod uwagę”. Z drugiej strony dla wykonawcy kłopotliwe bywa wyłuskanie technicznych informacji z humanistycznego i czasami nieco chaotycznego opisu zamawiającego. W niektórych przypadkach te problemy komunikacyjne mogą prowadzić do nieporozumień lub niezadowolenia z efektów współpracy, a w skrajnych przypadkach nawet do zupełnego niepowodzenia projektu.

Żeby więc przynajmniej odrobinę ułatwić Wam sprawne przejście przez ten najwcześniejszy (i chyba najważniejszy) etap projektu, postaram się wskazać kilka aspektów, które warto wziąć pod uwagę specyfikując swoje potrzeby. Bez wątpienia nie jest to kompletna lista zagadnień. Wiele może zależeć od specyfiki konkretnego projektu, dlatego starałem się wybrać tylko te najbardziej uniwersalne aspekty, które zazwyczaj jednak będzie trzeba rozważyć. Mogą one stanowić jakiś punkt wyjścia do dalszych szczegółowych rozmów. Odpowiedzenie sobie na poniższe pytania powinno ułatwić Wam też sprecyzowanie i lepsze poznanie swojej własnej wizji efektu końcowego.

#1 Po pierwsze: czego właściwie potrzebujesz?

Postaraj się nie ograniczać do „strony internetowej” albo „aplikacji”, ale też przedstawić nieco szerszy kontekst. Niech to będzie „strona-wizytówka niewielkiej firmy budowlanej z informacjami o firmie i portfolio projektów”, albo „blog modowy w modelu freemium”. A w przypadku aplikacji np. „aplikacja do zarządzania danymi osobowymi pracowników i niezautomatyzowanymi grafikami pracy w kilkudziesięcioosobowej firmie logistycznej”. Warto też określić jaką rolę biznesową ma pełnić dana strona/aplikacja. Taki opis już da potencjalnemu wykonawcy jakieś wyobrażenie o tym z jaką branżą będzie miał do czynienia, jakiego typu będzie to strona lub aplikacja i jaka mniej więcej może być skala projektu.

#2 Kim jesteś i do kogo kierujesz swoją stronę/aplikację?

Wbrew pozorom to ważne. Czy jesteś osobą prywatną, reprezentujesz przedsiębiorstwo lub jakiegoś rodzaju organizację? Czy to będzie aplikacja wyłącznie do wewnętrznego użytku w firmie? A może aplikacja o globalnym zasięgu? Czy strona/aplikacja kierowana jest do jakiejś określonej grupy odbiorców? W jaki sposób użytkownicy będą jej używać? Może np. wiesz, że większość użytkowników korzysta ze strony/aplikacji w trakcie przemieszczania się? A może znaczna część użytkowników to osoby w określonym wieku? Zastanów się, czy jesteś w stanie jakoś określić swoich odbiorców. Mając tą wiedzę, wykonawca może zwrócić uwagę na coś o czym nie pomyślałeś lub o czym nie wiedziałeś, np. na to, że w niektórych przypadkach jesteś zobowiązany spełnić określone normy dostępności WCAG.

#3 Co już wiesz?

Może rozważasz lub nawet jesteś już zdecydowany na jakieś konkretne rozwiązania techniczne/wizualne. Np. aplikacja ma być wykonana w konkretnej technologii, którą warunkują inne systemy, z którymi ma docelowo współpracować lub takie są ograniczenia techniczne serwera. A może strona internetowa ma być oparta o konkretny system CMS, do którego zdążyłeś/zdążyłaś się przyzwyczaić? Wspomnij o tym, to ważne! A może strona ma być wyłącznie w biało-szarej kolorystyce i basta? Wspomnij i o tym, dlaczego nie! Skoro coś wiesz z góry, podziel się tym od razu, nie zatrzymuj tego na później. Nawet jeśli wydaje Ci się, że to błahostka, nie obawiaj się o tym powiedzieć. Jeśli nawet okaże się to rzeczywiście mało istotne na tym etapie rozmów, na pewno nikt nie obrazi się, że o tym mówisz!

#4 Co może nie być oczywiste?

Zastanów się o czym wykonawca może nie pomyśleć sam z siebie, jakie sprawy mogą nie być oczywiste? Może np. Twoja strona generuje wyjątkowo duży ruch lub użytkownicy przesyłają na serwer znaczne ilości danych? Może aplikacja ma działać na wyjątkowo dużej bazie danych lub wymaga zapewnienia ponadprzeciętnie wysokich standardów bezpieczeństwa? To niezwykle ważne informacje.

#5 Czy masz jakiś punkt odniesienia?

Może istnieją aplikacje czy strony WWW, które są dla Ciebie punktem odniesienia? Może funkcjonują już podobne aplikacje? Może znalazłeś przykłady, które odpowiadają Ci od strony wizualnej? Przekaż wykonawcy namiary na nie. Zaznacz przy tym co podoba Ci się w podanych przykładach a co nie, co chciałbyś rozwiązać podobnie, a czego Ci w nich brakuje. Wykonawcy będzie wówczas łatwiej ocenić Twoje potrzeby i trafić w Twój gust.

#6 Kilka technikaliów

Czy potrzebujesz responsywności (RWD)?

Jeśli mówimy o stronie internetowej, to krótko: tak, potrzebujesz. Każda współczesna strona powinna być dostosowana do wyświetlania na ekranach dowolnej wielkości. Jeśli mowa o aplikacji web, tu już sprawa może nie być aż tak oczywista. Np. w przypadku narzędzi tworzonych na potrzeby wewnętrzne, czasem może się to okazać zbędne.

Czy w przypadku strony WWW potrzebujesz systemu CMS?

Jeśli Twoja strona internetowa ma być raczej prosta i nie zamierzasz zbyt często wprowadzać na niej jakichkolwiek zmian, to możesz rozważyć zrezygnowanie z integracji z systemem CMS. Pozwoli to nieco obniżyć koszt realizacji.

I najważniejsze – co ma być w środku?

Jakie funkcjonalności ma posiadać aplikacja? Jaka będzie zawartość strony? W przypadku aplikacji trudno o jakieś uogólnienie, bo każda będzie miała inne, specyficzne dla siebie elementy – po prostu postaraj się wykazać jak największą precyzją. Z kolei w przypadku strony internetowej istotnymi elementami może być np.: wielojęzyczność, możliwość rejestracji użytkowników, zintegrowanie z innymi aplikacjami, niestandardowa wyszukiwarka, integracja płatności online, itd. Najlepiej gdy spróbujesz opisać jaka powinna być zawartość/funkcjonalność każdego rodzaju podstrony występującej w Twoim serwisie.

#7 Czy potrzebujesz dodatkowych usług?

Np. hostingu. Jeśli masz już zapewniony hosting lub planujesz go wykupić gdzie indziej to poinformuj o tym gdzie lub jakie są warunki techniczne. Jeśli nie masz jeszcze hostingu, zaznacz, że oczekujesz uwzględnienia tego w ofercie.
A może ważna będzie dla Ciebie asysta i wsparcie techniczne? Postaraj się określić, czy oczekujesz go tylko w początkowym okresie korzystania z systemu czy chciałbyś aby asysta była zapewniona długoterminowo.

A co Ty powinieneś wiedzieć o wykonawcy?

Ważne jest nie tylko to, żebyś przekazał potencjalnemu wykonawcy własne oczekiwania, ale również, abyś poznał jego możliwości, sposób działania i filozofię pracy. Czy wykonawca realizuje swoje projekty w zgodzie z aktualnie obowiązującymi standardami? Czy zapewnia wysoką dostępność tworzonych serwisów i ich zgodność z rekomendacjami WCAG 2.0? Czy ma wiedzę w obszarze usability i user experience oraz rozeznanie w aktualnych trendach, aby móc doradzić Ci najkorzystniejsze rozwiązania?

Czym jest WCAG i dlaczego to jest ważne?

WCAG 2.0 to powstały z inicjatywy W3C zbiór rekomendacji służących zwiększeniu dostępności serwisów internetowych. Mówiąc prościej: chodzi o to, aby serwisy internetowe były łatwiej dostępne dla osób z różnego rodzaju niepełnosprawnościami, m.in. niewidomych i niedowidzących, niedosłyszących, z ograniczeniami poznawczymi czy ruchowymi. Ale nie tylko! Podążanie za wytycznymi WCAG powinno sprawić, że Twoja strona będzie bardziej przyjazna wszystkim, nie tylko niepełnosprawnym użytkownikom.

Jak sprawić, aby witryna była bardziej dostępna?

Nic prostszego – na przykład skorzystać z wytycznych WCAG:) Ale na początek odpowiedzmy sobie na kilka pytań:

Czy aby witryna była dostępna, musi być w 100% zgodna z WCAG? Nie. To, że witryna nie spełnia wszystkich co do jednego kryteriów WCAG nie znaczy jeszcze, że jest niedostosowana do potrzeb niepełnosprawnych. Przynajmniej podstawowe założenia w nim opisane powinna jednak spełniać. Im więcej z nich spełnia – tym mniejsza szansa, że któryś z Twoich gości nie będzie w stanie z niej skorzystać. Nie ma ograniczeń w tym jak wysoko postawisz sobie poprzeczkę – warto dążyć do ideału.

Czy strona zgodna z WCAG na pewno będzie dostępna w 100% dla wszystkich? Niekoniecznie. WCAG nie wyczerpuje tematu dostępności stron. Jest to niewątpliwie obszerne kompendium i większość ważnych aspektów jest w nim poruszona, ale z pewnością wciąż można zrobić jeszcze więcej. Nie zapominajmy też o tym, że Internet i cała związana z nim technologia rozwija się z każdym dniem, a rekomendacja WCAG 2.0 została opublikowana w 2008 roku. Duża część wytycznych została jednak sformułowana w na tyle ogólny i uniwersalny sposób, że nie tracą nic ze swojej aktualności.

Które wytyczne WCAG powinienem w takim razie spełnić? WCAG wyróżnia trzy poziomy dostępności stron: A, AA oraz AAA. Każdy kolejny stawia coraz wyższe wymagania. Moim osobistym zdaniem, poziom A powinien być traktowany jako niezbędne minimum, a do realizacji większości wytycznych poziomu AA powinna dążyć każda strona internetowa. Poziom AAA nie zawsze jest potrzebny, a w praktyce dla wielu stron może być nieosiągalny. Niekoniecznie należy się jednak sztywno trzymać podziału zaproponowanego przez WCAG. O ile raczej wszystkie wytyczne poziomu A wypadałoby spełniać, o tyle spośród wytycznych poziomu AA i AAA można próbować wybrać te, które w konkretnym przypadku będą kluczowe lub których koszt wprowadzenia (niekoniecznie w znaczeniu finansowym) będzie dla nas akceptowalny. Należy być też świadomym, że zastosowanie niektórych rekomendacji WCAG może wiązać się z koniecznością wprowadzenia pewnych kompromisów, np. w zakresie warstwy wizualnej serwisu.

Jak stworzyć dostępną stronę?

Nie takie to jednak straszne jak mogłoby się na pierwszy rzut oka wydawać. Aby strona spełniała podstawowe standardy dostępności wystarczy stosować się do pewnych prostych, ogólnych zasad.

#1 Używaj tagów HTML zgodnie z ich przeznaczeniem

Każdy tag ma swoje konkretne zadanie. Nagłówki h# powinny być nagłówkami, a ich priorytety h1, h2, itd powinny odwzorowywać ich funkcję w treści. Tabele służą do przedstawiania danych tabelarycznych, nie do budowania układu elementów. Itd…

#2 Dbaj o kolejność elementów w kodzie HTML

Elementy w kodzie powinny być ułożone w kolejności ich czytania.

Prosta zasada, odnosząca się do dwóch powyższych punktów: na swojej stronie WWW spróbuj wyłączyć obsługę JavaScript oraz CSS tak, aby strona wyświetlała się tylko i wyłącznie w czystym HTML. Czy to co widzisz ma sens? Byłbyś skłonny bez żadnych zmian wydrukować to i dać komuś do przeczytania?

#3 Pamiętaj o atrybutach

Niektórzy nie będą mogli obejrzeć obrazka, który zamieściłeś na stronie, obejrzeć pliku video lub odsłuchać nagrania. Niech odpowiednie atrybuty opisują zawartość tych elementów. Ale nie pisz „Ładny obrazek nr 1”. Uzupełniając te atrybuty wyobraź sobie, że musisz w jednym zdaniu opowiedzieć o zawartości pliku komuś, kto nigdy go nie zobaczy i nie usłyszy. To samo odnosi się m.in. do linków.

#4 Obsługa klawiaturą

Byłbyś w stanie poruszać się po swojej stronie nie używając myszki? Spróbuj! Niektórzy będą musieli, więc zrób co możesz, aby im tego nie utrudniać. Np. w każdej chwili powinno być jasne, który element strony ma aktualnie focus.

#5 JavaScript

Nie nadużywaj skryptów i pamiętaj, aby każdy element strony pozostawał dostępny po wyłączeniu obsługi JS.

#6 Captcha i inne bariery

Na pewno nie lubisz spamu. I obawiasz się robotów, automatów, UFO i wszelkich innych nie-ludzkich istnień atakujących Twoją witrynę. Wcale się nie dziwię, ale pamiętaj, że chcesz obronić się tylko przed napastnikiem, a nie strzelać do wszystkiego co się rusza. Jest wiele stron, które skutecznie obroniły się przed wszystkimi, którzy mieli ochotę je odwiedzić. Jest też całe mnóstwo takich, które dopuściły tylko ograniczone grono wybrańców lub na które wiele osób przestało zaglądać, bo znudziło im się mozolne udowadnianie przy każdych odwiedzinach: tak, naprawdę jestem człowiekiem. Jestem pewien, że nie taki jest Twój cel. Zapewnij metodę weryfikacji łatwo dostępną dla wszystkich „ludzi”, a jeśli nie jesteś w stanie zrobić tego nie pomijając jakiejś ich części to zrezygnuj z tego rozwiązania. I przy okazji jeszcze jedno – nie przerzucaj na swoich gości obowiązku walki z Twoim spamem. To nie ich sprawa.

Na podsumowanie

Właściwie na tym można by zamknąć listę najważniejszych z najważniejszych elementów dostępności. Niewiele, prawda? Tę garść zasad można uznać za konieczne minimum, które powinien spełniać każdy serwis WWW. Warto jednak sięgnąć nieco głębiej, szczególnie wtedy, gdy serwis kierowany jest do szerokiego grona odbiorców lub gdy wśród tych odbiorców możemy spodziewać się osób z ograniczeniami. Przykre jest to, że zdecydowana większość stron niestety nie spełnia nawet tak podstawowych standardów.

Dlatego jeśli tworzysz serwisy WWW nie zapominaj o tej (niemałej) grupie użytkowników. A jeśli powierzasz swój serwis specjaliście, warto wybrać takiego, który nie ignoruje aspektu dostępności i ma na ten temat odpowiednią wiedzę. Nie obawiaj się dodać do specyfikacji wymagań zamówienia, punktu: wymagana zgodność z WCAG 2.0, level A.

Uzupełnienie

Warto wiedzieć, że w Rozporządzeniu Rady Ministrów z dnia 12 kwietnia 2012 r., w sprawie m.in. minimalnych wymagań dla systemów teleinformatycznych jest mowa o tym, że:

W systemie teleinformatycznym podmiotu realizującego zadania publiczne służące prezentacji zasobów informacji należy zapewnić spełnienie przez ten system wymagań Web Content Accessibility Guidelines (WCAG 2.0), z uwzględnieniem poziomu AA

Tworząc aplikacje webowe wcześniej czy później spotykamy się z tym problemem: mamy lokalną instancję aplikacji, w rozbudowanym środowisku deweloperskim i nadchodzi moment, kiedy potrzebujemy uruchomić ją na fizycznym urządzeniu mobilnym.

Oczywiście zwykle nie mamy możliwości przenieść całego środowiska deweloperskiego na telefon czy tablet. Jeśli mamy możliwość łatwej i szybkiej publikacji aplikacji na publicznym serwerze, może to być jakiś półśrodek, choć takie rozwiązanie raczej będzie dalekie od ideału, a w wielu przypadkach wręcz zupełnie pozbawione sensu.

Co nam pozostaje? Emulatory, które jak pewnie większość z nas miała okazję się przekonać, niestety przeważnie są dalekie od ideału (co nie znaczy, że bezużyteczne!). Na szczęście jednak są jeszcze inne, znacznie bardziej efektywne metody i jedną z nich postaram się dzisiaj opisać. W stosunkowo łatwy sposób możemy uruchomić aplikację (działającą ciągle w naszym lokalnym środowisku) „zdalnie„, na urządzeniu mobilnym.
Można to oczywiście zrobić na wiele różnych sposobów. Oto jeden z nich, w kilku prostych krokach.

Moje lokalne środowisko deweloperskie było skonfigurowane pod Windows 7, a urządzenia mobilne były wyposażone w różne wersje systemu Android.

1. Na komputerze instalujemy proxy – w moim przypadku był to Charles (program jest płatny, ale gdyby komuś to wystarczyło to przez 30 dni można skorzystać z bezpłatnej wersji próbnej). Można oczywiście użyć innego programu, choć należy mieć na uwadze, że nie każdy z nich obsłuży każdą aplikację. U mnie nie sprawdził się np. Squid, który, choć jest dobrym opensource’owym oprogramowaniem, ma niestety problem z obsługą websocketów – poszedł więc w odstawkę na rzecz wspomnianego Charles’a.
2. Na komputerze uruchamiamy przeglądarkę Chrome i otwieramy: chrome://inspect
   • klikamy „Port forwarding…„,

     

   • na liście portów dopisujemy dowolny (niezajęty) port, np. 9000 i podajemy dla niego IP: localhost:xxxx, gdzie xxxx to port na którym działa nasz proxy (w Charles’ie numer portu możemy sprawdzić w ustawieniach),
   • zaznaczamy „Enable port forwarding” i zatwierdzamy.

     

3. Na urządzeniu mobilnym uruchamiamy tryb debugowania. Wcześniej musimy mieć odblokowane menu programisty („Developer Options Menu”) – w przypadku Androida w wersji od 4.2 w górę, robimy to wchodząc w Ustawienia > Informacje o urządzeniu [ > informacje o oprogramowaniu] i 7-krotnie stukamy w numer kompilacji (Build number).
4. Na urządzeniu mobilnym otwieramy ustawienia sieci (Ustawienia > Wi-Fi). Odnajdujemy naszą bieżącą sieć, przytrzymujemy aby wyświetlić menu i wybieramy: Modyfikuj sieć > Ustawienia zaawansowane, a następnie ustawiamy:
   • Proxy: manual
   • Proxy host: localhost
   • Proxy port: ten sam, który podaliśmy w „Port forwarding” w Chrome (np. 9000)
   • Zapisz
5. Podłączamy urządzenie do komputera za pomocą kabla. Jeśli na komputerze nie mamy sterowników USB dla naszego urządzenia, oczywiście należy je zainstalować. Tutaj znajdziecie wszystkie potrzebne informacje o sterownikach USB: https://developer.android.com/studio/run/oem-usb.html.
6. Jeśli odpowiednie sterowniki są zainstalowane, to po podłączeniu kablem, na urządzeniu powinno wyświetlić się pytanie o pozwolenie na debugowanie, które akceptujemy.
7. Na komputerze uruchamiamy nasze środowisko deweloperskie tak jak zwykle i dodatkowo uruchamiamy proxy (np. Charles).
8. Na urządzeniu mobilnym (w przeglądarce Chrome) wpisujemy adres naszej lokalnej aplikacji, dokładnie ten sam co na komputerze, i… Wreszcie dzieją się czary! Powinniśmy zobaczyć nic innego jak właśnie naszą aplikację.
9. W Chrome na komputerze, pod adresem chrome://inspect, powinno być widoczne nasze podłączone urządzenie mobilne i lista stron, które są na nim otwarte w przeglądarce Chrome.

   

10. Na komputerze, w chrome://inspect klikamy „inspect” pod adresem naszej aplikacji – pojawia się dodatkowe okno, zawierające narzędzia deweloperskie, dzięki którym możemy debugować aplikację na urządzeniu mobilnym dokładnie tak samo jak lokalnie na komputerze. Możemy też obsługiwać stronę (na urządzeniu) zarówno z poziomu urządzenia jak i komputera.

Gotowe! Pamiętajcie, że jeśli po zakończeniu pracy będziecie chcieli zwyczajnie korzystać na urządzeniu mobilnym z tej samej sieci wi-fi, musicie najpierw usunąć wprowadzone w punkcie 4. ustawienia, a przywrócić je, gdy następnym razem będziecie chcieli uruchomić aplikację.

Mam nadzieję, że ten sposób mobilnego debugowania aplikacji webowych sprawdzi się u Was równie dobrze, jak sprawdził się u mnie.