Zamieszczony fragment kodu w Android Studio wdraża metodę nasłuchującą dla obsługi zdarzenia: przycisk = (Button) findViewById(R.id.yes_button);
przycisk.setOnClickListener(new View.OnClickListener() { ... });
Kod wykorzystuje metodę setOnClickListener, która jest podstawowym sposobem przypisywania reakcji na kliknięcie przycisku (Button) w Androidzie. To taki klasyczny wzorzec nasłuchiwania zdarzeń, w tym przypadku – kliknięcia użytkownika. Moim zdaniem, ta konstrukcja pojawia się praktycznie w każdym większym projekcie Androidowym, bo trudno sobie wyobrazić interfejs bez przycisków, które coś faktycznie robią. Co ciekawe, korzystając z setOnClickListener, przekazujemy obiekt anonimowej klasy implementującej interfejs View.OnClickListener, a w jej metodzie onClick() umieszczamy kod, który ma się wykonać po naciśnięciu przycisku. To bardzo elastyczne rozwiązanie, bo możemy tu zarówno wyświetlić Toast, przejść do innego activity, wysłać dane do internetu czy nawet ukryć inny widok. Warto pamiętać, że praktycznie wszystkie kontrolki dziedziczące po View mogą mieć własnych listenerów, ale Button to najbardziej naturalny przypadek użycia. To taka podstawa obsługi UI w Android Studio i moim zdaniem każdy, kto chce pisać apki na Androida, powinien mieć to opanowane na pamięć. Dodatkowo, od wersji Android API 26 można używać także lambda expressions, co jeszcze bardziej skraca kod, ale sama idea zostaje ta sama – reagujemy na kliknięcie przycisku.
W tym fragmencie kodu pojawia się metoda setOnClickListener, która, jeśli się tak chwilę zastanowić, nie jest wykorzystywana do reagowania na zmianę tekstu, wybieranie daty czy też zmianę stanu kontrolki Switch. To właśnie kliknięcia – czyli naciśnięcia przycisku – są tutaj obsługiwane. Spotkałem się już z tym, że osoby zaczynające przygodę z Androidem mylą czasem różne typy listenerów, bo faktycznie jest ich sporo i mają dość podobne nazwy, przez co łatwo się pogubić. Żeby wykryć zmianę w polu tekstowym (np. EditText), trzeba zastosować TextWatcher, gdzie obsługujemy metody jak afterTextChanged czy beforeTextChanged. Z kolei wybieranie daty zwykle wiąże się z użyciem DatePickerDialog, a tam stosujemy DatePickerDialog.OnDateSetListener, który zupełnie inaczej wygląda w kodzie. Jeśli chodzi o kontrolki Switch, to reagowanie na ich stan odbywa się za pomocą setOnCheckedChangeListener, gdzie w metodzie onCheckedChanged dowiadujemy się, czy Switch został włączony czy wyłączony. Typowym błędem jest patrzenie tylko na nazwę metody i przypisywanie jej do obsługi różnych kontrolek bez głębszego zastanowienia. Moim zdaniem warto poświęcić chwilę na przestudiowanie dokumentacji Androida, bo tam dość jasno opisano, które listener’y są przeznaczone do jakich zdarzeń. Ostatecznie, setOnClickListener zawsze oznacza, że obsługujemy kliknięcie – to taki standard branżowy w Androidzie i praktycznie nie stosuje się go do niczego innego niż reakcja na naciśnięcie widoku przez użytkownika.