Okiem niewidomego. Poukładajmy to

W poprzednim artykule sporo uwagi poświęciłam użyteczności wszelkiego rodzaju instrukcji. Dzisiaj zaś chciałabym pokazać, że osoba niewidoma jest w stanie wykonać na swoim urządzeniu wiele operacji. O programowaniu i układaniu interfejsu Użytkownika też już co nieco opowiadałam, gdy tłumaczyłam, dlaczego moim pierwszym wyborem w pracy nad aplikacjami będzie SwiftUI.

Zdarzają mi się jednak sytuacje, w których, z racji wymagań projektu, powracam do UIKit. Wówczas pozostają dla mnie otwarte dwie drogi do przygotowania interfejsu: w InterfaceBuilder lub w kodzie.

Tworzenie interfejsów

Z oczywistych względów wolę pracować w czystym kodzie. Ale czasami, we współpracy z projektantem, potrzebna jest wizualizacja. Wówczas pozostaje już (niestety) tylko i wyłącznie InterfaceBuilder.

Czy można z czytnikiem ekranu pracować układając interfejs graficznie?

Nie należy to do rzeczy najłatwiejszych. No i proces jest naprawdę bardzo długi. Razem z Julią postanowiłyśmy pokazać ten proces na filmie. W rzeczywistości trwał też dużo dłużej niż na nagraniu.

Jak pewnie daje się zauważyć, umieszczenie wszystkich elementów na kanwie naprawdę sporo zajmuje. A potem jeszcze trzeba przypiąć je we właściwym miejscu, upiększyć i, co najważniejsze, połączyć z kodem.

Gdybym miała wypisać wszystkie spostrzeżenia, jakie mi się nasuwają podczas tego procesu, artykuł ten prawdopodobnie zmieniłby się w książkę (albo przynajmniej solidny rozdział). Wybrałam więc te kwestie, których poruszenie może być pomocne między innymi dla twórców tutoriali.

Ułożenie i przypięcie komponentów

Nie mam najmniejszego wpływu na to, w jakim punkcie kanwy zostanie upuszczony element, który chcę na niej umieścić. Oznacza to, że będę musiała ręcznie wpisać jego współrzędne, żeby potem móc zagnieździć jedne elementy w innych. Oczywiście tabela po lewej stronie kanwy (Document Outline) jest tutaj niezastąpiona, bo pozwala mi to szybciej odnaleźć określone elementy. Mogę też w razie potrzeby nazywać je wedle własnego uznania.

Ponieważ nie mam żadnej kontroli nad tym, gdzie dany element wyląduje, podpowiedzi XCode dotyczące rozmieszczenia ich tak, by spełniały wytyczne dotyczące tworzenia interfejsu mógłby równie dobrze nie istnieć. Nie są nigdy ogłaszane przez czytnik ekranu. Niewiele więc wyjaśnią mi w tutorialach zrzuty ekranu z widocznymi niebieskimi ramkami oraz bardzo lakonicznymi opisami dotyczącymi poszczególnych elementów interfejsu, ich grupowania itp.

Pomocne natomiast byłoby dla mnie, gdyby ekran został opisany w taki sposób, abym wiedziała, jaki komponent gdzie na ekranie się znajduje. Podejrzenie kanwy ukończonego projektu, aby ustalić te wszystkie detale, zajmuje bardzo wiele czasu. Gdybym zatem miała samodzielnie odtwarzać to, co z takim trudem przejrzałam i przeanalizowałam, wykonanie całej reszty instrukcji zawartych w artykule prawdopodobnie zdarzyłoby się kilka godzin lub nawet kilka dni później.

Układanie interfejsu użytkownika dla naszej aplikacji szkoleniowej zajęło mi prawie dwa tygodnie, z czego najdłuższe i najbardziej żmudne okazało się stworzenie krótkiego formularza z dosłownie kilkoma polami tekstowymi.

Połączenia

Kolejnym aspektem pracy z interfejsem użytkownika jest tworzenie połączeń z kodem. I tutaj też muszę podejść do procesu nieco inaczej. Klasyczna, najczęściej opisywana w tutorialach metoda przeciągnięcia i upuszczenia połączenia w odpowiednim miejscu w kodzie najczęściej dla mnie nie działa. A nawet jeśli udałoby mi się przeciągnąć połączenie do edytora, znajdzie się ono w zupełnie dowolnym miejscu. A ja nie tylko nie lubię chaosu w kodzie, lecz raczej muszę bardzo dbać tak o jego strukturę, jak i o naprawdę sensowne nazewnictwo, żeby potem szybko się w nim odnaleźć. Zwłaszcza że na typowym ekranie takich połączeń będzie naprawdę bardzo dużo (minimum jedno lub dwa dla elementów funkcjonalnych, a dla kontenerów czasami i więcej).

Oczywiście w przypadku akcji uruchamianych przy pomocy komponentów (IBAction) dochodzi jeszcze kwestia wyboru odpowiedniego typu eventu. Naciśnięcie, naciśnięcie i przytrzymanie, podwójne stuknięcie, przeciągnięcie lub upuszczenie mogą dla tego samego komponentu wyzwalać zupełnie inne zachowania aplikacji. Na samym początku nauki programowania było to dla mnie kompletnie niejasne. Więc, jak zawsze w podobnych przypadkach, dochodziłam do celu metodą prób i błędów.

Dlaczego zwracam uwagę głównie na ten aspekt? Ponieważ tworzenie połączeń z czytnikiem ekranu odbywa się czasami trochę „na odwrót”. Dotyczy to głównie przejść pomiędzy ekranami. Gdy jakiś przycisk na ekranie A ma wywołać przejście do ekranu B, muszę rozpocząć połączenie od ekranu B do przycisku na ekranie A. To zwiększa prawdopodobieństwo, że XCode zechce ze mną współpracować i rzeczone przejście zechce utworzyć.

W przypadku innych typów połączeń dużo łatwiej będzie, jeśli najpierw stworzę odpowiednie własności i metody w danej klasie kodu i potem spróbuję wskazać połączenia na kanwie. Nadal będzie to długi proces i nie zawsze skuteczny, ale zwiększa prawdopodobieństwo sukcesu.

Podsumowując

Układanie interfejsu z czytnikiem ekranu w InterfaceBuilder jest zadaniem jak najbardziej wykonalnym. Wymaga jednak czasu, dokładnych instrukcji oraz naprawdę sporo cierpliwości. Odbywa się też trochę „na opak”. I jak zawsze, warto tworząc wytyczne w tutorialach lub specyfikacjach, nie zapominać o WCAG. Opisując komponent, warto używać jego nazwy, nie tylko koloru (np. typ eventu lub przejścia, w tym wyjścia ze sceny).