Lekcja 15. Wyświetlanie list danych — CollectionView, binding i ItemTemplate

Wyobraź sobie, że tworzysz aplikację, w której chcesz wyświetlić listę książek, produktów albo zadań do zrobienia. Nie chcesz ręcznie tworzyć osobnej kontrolki Label dla każdej pozycji — chcesz, żeby program SAM wypełnił listę na podstawie danych. Do tego służy mechanizm złożony z czterech współpracujących elementów: model danych (klasa opisująca jedną pozycję, np. Ksiazka), kolekcja (zbiór obiektów modelu, najlepiej ObservableCollection<T>), DataTemplate (opisuje wygląd JEDNEGO elementu listy) i binding (automatyczne powiązanie danych z interfejsem).

Zwykła List<T> a ObservableCollection<T>. Zwykła List<string> świetnie nadaje się do przechowywania danych w kodzie, ale NIE odświeża automatycznie interfejsu, gdy coś się w niej zmieni (dodanie, usunięcie elementu). ObservableCollection<T> (z System.Collections.ObjectModel) działa tak samo jak lista, ale DODATKOWO informuje podpięty do niej CollectionView o każdej zmianie — dzięki temu wystarczy wywołać Ksiazki.Add(nowaKsiazka), a lista na ekranie natychmiast pokaże nową pozycję, bez żadnego ręcznego odświeżania.

Odświeżanie POJEDYNCZEJ właściwości — interfejs INotifyPropertyChanged. ObservableCollection powiadamia o dodaniu/usunięciu całego elementu, ale co, gdy zmienia się tylko JEDNO pole istniejącego obiektu (np. status "Wypożyczona" zmienia się na "Dostępna")? Do tego model musi implementować interfejs INotifyPropertyChanged — każdy set właściwości wywołuje wtedy zdarzenie PropertyChanged, informując interfejs, KTÓRA konkretnie właściwość się zmieniła, żeby odświeżyć tylko ten fragment ekranu:

public class Ksiazka : INotifyPropertyChanged
{
    private bool _wypozyczona;

    public bool Wypozyczona
    {
        get => _wypozyczona;
        set { _wypozyczona = value; OnPropertyChanged(); OnPropertyChanged(nameof(StatusOpis)); }
    }

    public string StatusOpis => Wypozyczona ? "Wypożyczona" : "Dostępna";

    public event PropertyChangedEventHandler? PropertyChanged;
    void OnPropertyChanged([CallerMemberName] string? nazwa = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nazwa));
}

Atrybut [CallerMemberName] sprawia, że parametr nazwa automatycznie przyjmuje nazwę właściwości, z której metoda została wywołana — nie trzeba jej ręcznie wpisywać jako string (co łatwo popsuć literówką). Zwróć uwagę na StatusOpis — to właściwość WYLICZANA (bez set, tylko =>), która zależy od Wypozyczona; dlatego w setterze Wypozyczona ręcznie wywołujemy DRUGIE OnPropertyChanged(nameof(StatusOpis)), żeby interfejs wiedział, że ta zależna właściwość też się zmieniła.

CollectionView i DataTemplate. Właściwość ItemsSource wskazuje kolekcję do wyświetlenia, a CollectionView.ItemTemplate (jako DataTemplate) opisuje wygląd JEDNEGO wiersza — MAUI automatycznie "sztancuje" ten szablon dla każdego elementu kolekcji. Atrybut x:DataType="models:Ksiazka" na DataTemplate mówi kompilatorowi, jakiego typu obiektu dotyczy binding wewnątrz — dzięki temu błędy w nazwach właściwości (np. literówka w {Binding Tytuł}) są wykrywane already przy kompilacji, a nie dopiero w czasie działania aplikacji.

Odczytanie, KTÓREGO elementu dotyczy kliknięcie w wierszu. Gdy przycisk wewnątrz szablonu wiersza zostanie kliknięty, trzeba dowiedzieć się, do którego obiektu z kolekcji ten konkretny wiersz się odnosi. W MAUI robi się to przez BindingContext obiektu, który wywołał zdarzenie: var ksiazka = (sender as BindableObject)?.BindingContext as Ksiazka; — każdy wiersz listy ma swój WŁASNY BindingContext ustawiony automatycznie na odpowiadający mu element kolekcji.

Filtrowanie listy (np. przez SearchBar). Prosta i skuteczna technika: trzymaj gdzieś ORYGINALNĄ, pełną listę (np. w polu klasy), a przy każdej zmianie tekstu wyszukiwania twórz NOWĄ, przefiltrowaną kolekcję przez LINQ (.Where(...)) i podstawiaj ją do ItemsSource. Gdy pole wyszukiwania jest puste, przywracasz oryginalną listę.