System obsługi gestów

Nieoficjalne Tłumaczenie Beta

Ta strona została przetłumaczona przez PageTurner AI (beta). Nie jest oficjalnie zatwierdzona przez projekt. Znalazłeś błąd? Zgłoś problem →

System obsługi gestów zarządza cyklem życia gestów w twojej aplikacji. Dotyk może przechodzić przez kilka faz, podczas gdy aplikacja określa intencje użytkownika. Na przykład aplikacja musi rozpoznać, czy dotyk to przewijanie, przesuwanie widżetu czy stuknięcie. Intencja może się nawet zmieniać podczas trwania dotyku. Może też występować wiele dotyków jednocześnie.

System odpowiedzi na dotyk jest potrzebny, aby komponenty mogły negocjować te interakcje bez dodatkowej wiedzy o komponentach nadrzędnych lub podrzędnych.

Najlepsze praktyki

Aby twoja aplikacja działała płynnie, każde działanie powinno mieć następujące cechy:

• Informacja zwrotna/podświetlenie - pokaż użytkownikowi, co obsługuje jego dotyk i co się stanie po zwolnieniu gestu

• Możliwość anulowania - podczas wykonywania działania użytkownik powinien móc przerwać je w trakcie dotyku, odsuwając palec

Te funkcje sprawiają, że użytkownicy czują się swobodniej podczas korzystania z aplikacji, ponieważ pozwalają eksperymentować i wchodzić w interakcje bez obawy o popełnienie błędu.

TouchableHighlight i Touchable*

System odpowiedzi może być skomplikowany w użyciu. Dlatego dostarczyliśmy abstrakcyjną implementację Touchable dla elementów, które powinny być "klikalne". Wykorzystuje ona system odpowiedzi i pozwala konfigurować interakcje dotykowe deklaratywnie. Używaj TouchableHighlight wszędzie tam, gdzie na stronie internetowej użyłbyś przycisku lub linku.

Cykl życia systemu odpowiedzi

Widok może stać się responderem dotykowym poprzez implementację odpowiednich metod negocjacji. Dwie metody pytają widok, czy chce zostać responderem:

• View.props.onStartShouldSetResponder: evt => true, - Czy ten widok chce zostać responderem na początku dotyku?

• View.props.onMoveShouldSetResponder: evt => true, - Wywoływane przy każdym ruchu dotykowym na widoku, gdy nie jest responderem: czy ten widok chce "przejąć" odpowiedzialność za dotyk?

Jeśli widok zwróci true i spróbuje zostać responderem, nastąpi jedna z następujących sytuacji:

• View.props.onResponderGrant: evt => {} - Widok odpowiada teraz za zdarzenia dotykowe. To czas na podświetlenie i pokazanie użytkownikowi, co się dzieje

• View.props.onResponderReject: evt => {} - Ktoś inny jest obecnie responderem i nie zwolni tej roli

Jeśli widok odpowiada, mogą zostać wywołane następujące procedury obsługi:

• View.props.onResponderMove: evt => {} - Użytkownik przesuwa palec

• View.props.onResponderRelease: evt => {} - Wywoływane na końcu dotyku, tj. "touchUp"

• View.props.onResponderTerminationRequest: evt => true - Ktoś inny chce zostać responderem. Czy ten widok powinien zwolnić respondera? Zwrócenie true pozwala na zwolnienie

• View.props.onResponderTerminate: evt => {} - Responder został odebrany widokowi. Mógł zostać przejęty przez inne widoki po wywołaniu onResponderTerminationRequest lub przez system operacyjny bez pytania (dzieje się tak z Centrum sterowania/Centrum powiadomień w iOS)

evt to syntetyczne zdarzenie dotykowe o następującej strukturze:

• nativeEvent
  • changedTouches - Tablica wszystkich zdarzeń dotykowych, które zmieniły się od ostatniego zdarzenia
  • identifier - Identyfikator dotyku
  • locationX - Pozycja X dotyku względem elementu
  • locationY - Pozycja Y dotyku względem elementu
  • pageX - Pozycja X dotyku względem elementu głównego
  • pageY - Pozycja Y dotyku względem elementu głównego
  • target - Identyfikator węzła elementu otrzymującego zdarzenie dotykowe
  • timestamp - Identyfikator czasu dotyku, przydatny do obliczania prędkości
  • touches - Tablica wszystkich aktualnych dotyków na ekranie

Przechwytywanie handlerów ShouldSet

onStartShouldSetResponder i onMoveShouldSetResponder działają w modelu propagacji (bubbling), gdzie najgłębszy węzeł jest wywoływany jako pierwszy. Oznacza to, że najbardziej zagnieżdżony komponent stanie się responderem, gdy wiele widoków zwróci true dla handlerów *ShouldSetResponder. Jest to pożądane w większości przypadków, ponieważ zapewnia działanie wszystkich kontrolek i przycisków.

Jednak czasem komponent nadrzędny może chcieć zapewnić sobie status respondera. Można to osiągnąć używając fazy przechwytywania (capture phase). Zanim system responderów przejdzie w górę od najgłębszego komponentu, wykona fazę przechwytywania, wywołując on*ShouldSetResponderCapture. Jeśli komponent nadrzędny chce uniemożliwić dziecku zostanie responderem przy rozpoczęciu dotyku, powinien zdefiniować handler onStartShouldSetResponderCapture zwracający true.

• View.props.onStartShouldSetResponderCapture: evt => true,

• View.props.onMoveShouldSetResponderCapture: evt => true,

PanResponder

Do interpretacji gestów na wyższym poziomie abstrakcji, zapoznaj się z PanResponder.