Lekcja 9. Obsługa zdarzeń — anatomia handlera i okna DisplayAlert

Czym jest złączenie zdarzenia?

W XAML: <Button Text="Kliknij mnie" Clicked="PrzyciskKlik_Click"/>. W C#: metoda o dokładnie tej samej nazwie, wykonywana po kliknięciu. Złączenie = wskazanie, że dana kontrolka ma uruchomić konkretną metodę, gdy wydarzy się określone zdarzenie (np. Clicked).

Anatomia metody obsługującej zdarzenie

Weźmy przykład: private async void Zaloguj_Click(object sender, EventArgs e). Rozbijmy to na części:

Element	Znaczenie
private	Metoda widoczna tylko w tej klasie — wystarcza w naszych projektach.
async	Pozwala użyć await — np. czekać na wyświetlenie okna dialogowego. Dzięki temu aplikacja się NIE zawiesza.
void	Metoda nic nie zwraca — handlery zdarzeń prawie zawsze są void.
Zaloguj_Click	Nazwa metody — konwencja: nazwa kontrolki + rodzaj zdarzenia (np. Przycisk_Click, Suwak_ValueChanged).
object sender	Obiekt, który wywołał zdarzenie — np. konkretny przycisk, który kliknięto.
EventArgs e	Dodatkowe dane o zdarzeniu — dla różnych kontrolek różne typy (np. ValueChangedEventArgs dla suwaka, DateChangedEventArgs dla DatePickera).

DisplayAlert — komunikat dla użytkownika

await DisplayAlert("Tytuł", "Treść", "OK") pokazuje proste okno z komunikatem i jednym przyciskiem. Wersja z DWOMA przyciskami (DisplayAlert("Tytuł", "Treść", "Tak", "Nie")) zwraca bool — true, gdy kliknięto pierwszy przycisk ("Tak"), false, gdy drugi ("Nie"). To najczęstszy sposób pytania użytkownika o potwierdzenie ważnej akcji (np. usunięcia danych).

DisplayPromptAsync — szybkie okno wprowadzania danych

string wynik = await DisplayPromptAsync("Tytuł", "Treść pytania") to odpowiednik klasycznego "InputBox" — otwiera okno z polem tekstowym i zwraca wpisany string (albo null, gdy użytkownik anuluje).

Dlaczego async/await w interfejsie użytkownika?

Operacje takie jak DisplayAlert czy DisplayPromptAsync są asynchroniczne — nie blokują wątku odpowiedzialnego za rysowanie interfejsu. Dzięki async/await aplikacja pozostaje płynna, a użytkownik widzi okno dialogowe natychmiast, zamiast czekać na "zamrożoną" aplikację.

Dobra praktyka: opakowuj kod w handlerze w try/catch, żeby ewentualny błąd pokazał krótki komunikat zamiast wywalić całą aplikację:

private async void Handler(object sender, EventArgs e)
{
    try
    {
        await DisplayAlert("Tytuł", "Treść", "OK");
    }
    catch (Exception ex)
    {
        await DisplayAlert("Błąd", ex.Message, "OK");
    }
}

Kiedy sender, a kiedy x:Name?

Masz jedną kontrolkę i używasz jej często → nadaj jej x:Name i odwołuj się po nazwie (prościej, czytelniej). Jeden wspólny handler dla WIELU kontrolek → czytaj sender i rzutuj do właściwego typu: if (sender is Button b) b.Text = "OK";