Manuskrypt HTML

Problem Zamrożonego UI i Piekło Callbacków - Wątek Główny

Zanim zagłębimy się w to, czym są korutyny, musimy zrozumieć, z jakim fundamentalnym problemem musimy mierzyć się od samych początków Androida. Ten problem ma swoje źródło w jednej, kluczowej koncepcji: Wątku Głównym.

Każda aplikacja na Androida, którą uruchamiasz, żyje i umiera w jednym, głównym procesie. Wewnątrz tego procesu istnieje jeden, niezwykle ważny wątek, znany jako Wątek Główny (Main Thread) lub Wątek UI (UI Thread).

Ten wątek jest odpowiedzialny za wszystko, co użytkownik widzi i z czym wchodzi w interakcję:

• Rysowanie interfejsu: Aktualizowanie widoków, wywoływanie funkcji @Composable.
• Obsługa zdarzeń: Reagowanie na kliknięcia, przewijanie, wpisywanie tekstu.
• Animacje: Płynne przesuwanie elementów po ekranie.

Wątek UI to w zasadzie nieskończona pętla zdarzeń, która musi działać z prędkością co najmniej 60 klatek na sekundę (nowsze modele posiadają odświeżanie na poziomie 144 Hz). Jeśli kiedykolwiek przestanie pracować – choćby na ułamek sekundy – użytkownik natychmiast to zauważy. Aplikacja zacina się, laguje. Dla ekranów 60 Hz mamy do dyspozycji około 16 ms na wykonanie wszystkich operacji (włącznie z renderowaniem UI)(Rys. 2.1).

Przeanalizujmy przykład:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        enableEdgeToEdge()
        setContent {
            AnrappTheme {
                BlockingUiDemoScreen()
            }
        }
    }
}

@Composable
fun BlockingUiDemoScreen() {
    var statusText by remember { mutableStateOf("Naciśnij przycisk, aby rozpocząć operację.") }

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp).background(Color.Cyan),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text(
            text = "Demonstracja Blokowania Wątku UI",
        )
        Spacer(modifier = Modifier.height(50.dp))

        Text(
            text = statusText,
            fontSize = 18.sp,
            textAlign = TextAlign.Center,
            modifier = Modifier.height(80.dp)
        )
        Spacer(modifier = Modifier.height(20.dp))

        Button(
            onClick = {
                statusText = "Operacja rozpoczęta..."

                try {
                    Thread.sleep(10000)
                } catch (e: InterruptedException) {
                }

                statusText = "Operacja zakończona!"
            },
            modifier = Modifier.fillMaxWidth()
        ) {
            Text("Uruchom 10-sekundową operację blokującą")
        }
        Spacer(modifier = Modifier.height(40.dp))

        var sliderPosition by remember { mutableStateOf(0f) }
        Slider(
            value = sliderPosition,
            onValueChange = { sliderPosition = it }
        )
    }
}

Zwróćmy uwagę, że mamy w ui przycisk i suwak. Wewnątrz funkcji onClick przycisku mamy kod:

Button(
    onClick = {
        statusText = "Operacja rozpoczęta..."

        try {
            Thread.sleep(10000)
        } catch (e: InterruptedException) {
        }

        statusText = "Operacja zakończona!"
    },
    modifier = Modifier.fillMaxWidth()
) {
    Text("Uruchom 10-sekundową operację blokującą")
}

Wywołujemy Thread.sleep(10000), czyli blokujemy wątek UI na 10 sekund. W tym czasie:

• Przycisk nie pokaże animacji kliknięcia.
• Inne animacje na ekranie będą zamrożone.
• Użytkownik, wykonując jakąkolwiek interakcję z ekranem, nie otrzyma żadnej odpowiedzi.

System operacyjny Android szybko zauważa, że nasza aplikacja nie odpowiada na zdarzenia. Po kilku sekundach wyświetla komunikat: Aplikacja nie odpowiada (ANR - Application Not Responding)(Rys. 2.2).

Wszystkie długotrwałe operacje: pobieranie danych z sieci, odczyt z bazy danych, skomplikowane obliczenia – muszą odbywać się w tle.

Przez lata, zanim pojawiły się korutyny, praca w tle oznaczała ręczne zarządzanie wątkami. Jeśli programista chciał pobrać dane z sieci po kliknięciu przycisku, jego plan działania musiał wyglądać tak:

1. W onClick (Wątek UI): Utwórz nowy, ręczny obiekt Thread.
2. W metodzie run() nowego wątku (Wątek Tła): Wykonaj czasochłonną operację sieciową.
3. Po zakończeniu operacji: Zdobądź wynik (np. dane użytkownika).
4. Problem: Nie możesz zaktualizować UI (np. TextView) z tego Wątku Tła. Spowoduje to awarię aplikacji.
5. Rozwiązanie: Utwórz obiekt Handler powiązany z Wątkiem UI.
6. Użyj handler.post {... }, aby wysłać wynik z powrotem do Wątku UI, który jako jedyny może bezpiecznie zaktualizować interfejs.

Ten proces był skomplikowany, ale jeszcze gorsze stawało się, gdy operacje były od siebie zależne. Wyobraźmy sobie pobranie danych użytkownika, następnie na ich podstawie pobranie jego zdjęcia, a na końcu zapisanie go w bazie:

button.setOnClickListener(v -> {
    // 1. Przechodzimy do tła, by pobrać użytkownika
    new Thread(() -> {
        User user = api.fetchUser("123");
        
        // 2. Musimy znowu przejść do tła, by pobrać zdjęcie
        new Thread(() -> {
            ProfilePicture pic = api.fetchPicture(user.getPictureUrl());
            
            // 3. I jeszcze raz do tła, by zapisać w bazie
            new Thread(() -> {
                database.save(pic);
                
                // 4. Wracamy do Wątku UI, by pokazać sukces
                mainThreadHandler.post(() -> {
                    imageView.setImage(pic);
                    textView.setText("Gotowe!");
                });
            }).start();
        }).start();
    }).start();
});

To, co widzimy powyżej, to Piekło Callbacków (Callback Hell). Kod staje się piramidą zagnieżdżonych wywołań. Jest praktycznie nieczytelny, niemożliwy do testowania, a obsługa błędów w każdym z tych kroków staje się koszmarem.

To jest właśnie problem, który doprowadził do rewolucji. Potrzebowaliśmy sposobu na pisanie kodu asynchronicznego, który wyglądałby jak prosty kod synchroniczny; bez callbacków i bez ręcznego zarządzania wątkami.

Korutyny

Wstęp

Po zidentyfikowaniu fundamentalnego problemu blokowania Wątku Głównego, naturalne pytanie brzmi: Jaka jest alternatywa?. Przez lata próbowaliśmy wielu rozwiązań, ale dopiero Kotlin wprowadził model, który zrewolucjonizował programowanie na Androida. Mowa o korutynach.

Aby zrozumieć ich siłę, musimy precyzyjnie zdefiniować, czym są i czym nie są.

Najczęściej spotkasz się z definicją korutyny jako lekkiego wątku (lightweight thread). Jest to użyteczne uproszczenie, pomaga zrozumieć, że korutyny, podobnie jak wątki, wykonują jakąś pracę w tle. Jednak to porównanie jest też mylące, ponieważ pomija ich najważniejszą cechę. UWAGA!!! - Korutyna nie jest wątkiem.

Lepszą, bardziej precyzyjną definicją jest: zawieszalne (suspendable) obliczenie.

Pomyśl o korutynie nie jak o pracowniku, ale jak o zadaniu lub jednostce pracy, którą można w dowolnym momencie wstrzymać (zawiesić) i wznowić w przyszłości, nie blokując przy tym pracownika (wątku), który ją wykonuje.

Kluczowa Różnica: Korutyna kontra Wątek

• Wątek (Thread) jest zarządzany przez System Operacyjny (OS). Jest ciężki, jego utworzenie i utrzymanie zużywa znaczące zasoby systemowe. Przełączanie się między wątkami jest operacją kosztowną dla procesora, ponieważ system musi zapisać stan jednego wątku i wczytać stan drugiego.
• Korutyna (Coroutine) jest zarządzana przez środowisko uruchomieniowe Kotlina. Jest lekka, to w zasadzie tylko obiekt w pamięci, który śledzi stan wykonywanego zadania. Tysiące, a nawet miliony korutyn mogą być uruchomione i zarządzane przez jeden wątek. Przełączanie się między korutynami jest niemal darmowe.

Korutyna nie jest wątkiem. Korutyna wykonuje się na wątku.

Wyobraźmy sobie kuchnię (naszą aplikację) i kucharza (Wątek).

Scenariusz 1: Kucharz jako Tradycyjny Wątek (Model Blokujący) Kucharz (Wątek UI) bierze przepis (zadanie). Pierwszy punkt przepisu brzmi: Gotuj wodę przez 5 minut. Kucharz włącza kuchenkę, a następnie stoi bezczynnie przez 5 minut, wpatrując się w garnek. W tym czasie w kuchni panuje chaos. Dzwoni telefon (interakcja użytkownika), przychodzą nowi goście (animacje) - ale kucharz jest zablokowany. Nie może zrobić nic innego, dopóki woda się nie zagotuje. To jest właśnie to, co robi Thread.sleep().

Scenariusz 2: Kucharz z Korutynami (Model Nieblokujący) Ten sam kucharz (ten sam Wątek UI) bierze ten sam przepis (teraz jako korutynę). Czyta: Gotuj wodę przez 5 minut. Kucharz nastawia wodę do gotowania (inicjuje operację wejścia/wyjścia), a następnie zawiesza (suspend) ten przepis i odkłada go na bok. Ponieważ jego ręce są wolne, natychmiast przechodzi do innego zadania - na przykład zaczyna kroić warzywa (obsługuje kliknięcie) lub przyprawiać sałatkę (rysuje animację). Kiedy po 5 minutach słyszy gwizdek czajnika (operacja w tle się zakończyła), kucharz wznawia (resume) pierwszy przepis i kontynuuje od miejsca, w którym skończył.

W tym modelu jeden kucharz (jeden wątek) żongluje wieloma przepisami (korutynami) jednocześnie, nigdy nie marnując czasu na bezczynne czekanie. Dodajmy tutaj że to, co nazywamy zawieszeniem (suspend), to nie jest pauza dla całej pracy. To jest pauza dla tej konkretnej korutyny na tym konkretnym wątku. To, kto rzeczywiście wykonuje pracę przy gotowaniu wody, rozwiążemy za chwilę.

Wątek roboczy

Musimy wyjaśnić, czym jest przepis w naszej analogii; jest to byt, który nazywamy funkcją z możliwością zawieszenia wykonania (suspend fun)

suspend fun ma się tak do korutyny, jak klasa ma się do instancji tej klasy; możemy mieć wiele instancji tej samej klasy:

• suspend fun to definicja lub plan (blueprint). To tylko definicja kroków, które mają zostać wykonane. Sama w sobie nie robi nic. Nie jest aktywna. Nie ma stanu działam lub jestem zawieszona
• korutyna to instancja lub aktywne wykonanie tego planu. Powstaje, gdy bierzesz suspend fun (lub dowolny blok kodu suspend) i faktycznie go uruchamiasz. Korutyna ma stan (aktywna, zawieszona, anulowana). To jest ten pracownik, który wykonuje kroki z planu.

Kiedy piszesz w kodzie scope.launch {... } (zaraz wyjaśnimy czym jest scope), ten blok kodu launch (nazywany konstruktorem korutyny) tworzy i uruchamia nową korutynę (nową instancję pracy). Ta nowa, żywa korutyna zaczyna wykonywać kod wewnątrz bloku {...}. Może działać następująco:

1. Korutyna (instancja) wywołuje suspend fun (plan).
2. Ta suspend fun (np. delay) mówi do korutyny: muszę teraz poczekać 1 sekundę. Możesz mnie zawiesić.
3. Korutyna (instancja) przechodzi w stan zawieszona. Zwalnia kucharza (wątek), który może iść robić coś innego (np. obsługiwać UI).
4. Po 1 sekundzie delay się kończy.
5. Korutyna (instancja) jest wznawiana na dowolnym wolnym wątku i kontynuuje pracę od następnej linii.

Słowo kluczowe suspend nie oznacza, że funkcja automatycznie wykonuje się na wątku w tle! Oznacza jedynie, że funkcja może zostać zawieszona. Jeśli wewnątrz funkcji suspend wykonasz kosztowną operację (np. ciężkie obliczenia matematyczne) bez jawnego przełączenia dyspozytora (o dyspozytorach nieco później), nadal zablokujesz wątek wywołujący (w tym przypadku Wątek UI).

Wracając do pytania: kto gotuje wodę gdy kucharz pójdzie np. kroić warzywa?

W tej analogii kucharz będzie naszym wątkiem UI (wątkiem głównym), którego nie chcemy blokować długimi operacjami. Ale nie jest on jedynym pracownikiem kuchni, są również pomocnicy kuchenni (wątki robocze/poboczne). Nasza analogia wygląda teraz następująco:

1. Szef Kuchni (Wątek UI) bierze przepis (korutynę). Czyta pierwszy punkt: Gotuj wodę przez 5 minut (np. pobierz dane z sieci, co robi suspend fun).
2. Szef Kuchni nie gotuje wody osobiście. To strata jego cennego czasu (musi obsługiwać UI).
3. Zamiast tego, woła Pomocnika Kuchennego. Daje mu garnek z wodą i mówi: Nastaw to na gazie (wykonaj operację sieciową). Jak się zagotuje, daj mi znać.
4. Ten Pomocnik idzie i faktycznie wykonuje pracę. Patrzy na garnek (czeka na odpowiedź sieci).
5. Szef Kuchni (Wątek UI), natychmiast po wydaniu polecenia, zawiesza (suspend) ten przepis - odkłada go na bok z notatką czekam na wodę od pomocnika.
6. Ponieważ jego ręce są wolne, Szef Kuchni (Wątek UI) natychmiast przechodzi do krojenia warzyw (obsługuje kliknięcie) i przyprawiania sałatki (rysuje animację).
7. Po 5 minutach Pomocnik (wątek IO) kończy pracę. Przybiega do Szefa Kuchni i mówi: Woda dla przepisu nr 5 jest gotowa! (sygnał zwrotny trafia z powrotem do Wątku Głównego).
8. Szef Kuchni (Wątek UI), gdy tylko skończy kroić sałatkę, bierze zawieszony przepis nr 5 i wznawia (resume) go od następnego kroku.

CoroutineScope

Kucharz nie może pracować w próżni, potrzebuje kuchni; przestrzeni przystosowanej do obsługiwania zadań kucharza, oraz posiadającej przygotowanych pomocników. Kuchnia to środowisko, w którym przepisy są realizowane, podobnie, nie możesz po prostu uruchomić korutyny w powietrzu; musisz ją uruchomić wewnątrz jakiegoś CoroutineScope. Nową korutynę tworzymy i włączamy za pomocą metody launch i możemy to zrobić tylko na CoroutineScope; przykładowo scope.launch{}. Wtedy mówimy: Chcę, aby ten przepis (korutyna) został wykonany w tej kuchni (scope).

Każda Kuchnia (CoroutineScope) ma swój regulamin i swoje zasoby. Ten regulamin to obiekt o typie CoroutineContext (Kontekst Korutyny). Posiada on zestaw atrybutów dla tej konkretnej kuchni. Dwa najważniejsze elementy w tym kontekście to:

• Job (Szef Zmiany): To jest komponent odpowiedzialny za cykl życia.
• Dispatcher (Szef Kucharzy): To jest komponent odpowiedzialny za przydzielanie pracy.

Dispatcher (Szef Kucharzy), który jest częścią CoroutineContext danej Kuchni, posiada własnych pomocników (własną pulę wątków). Dispatcher to w zasadzie strateg planowania. Mówi on, na którym wątku (lub puli wątków) dany przepis (korutyna) ma być w danym momencie wykonywany. Mamy kilku głównych Szefów Kucharzy (Dispatcherów), których możemy wybrać:

• Dispatchers.Main: Ten Szef ma pod sobą tylko jednego, specjalistycznego kucharza - Wątek UI. Każde zadanie, które mu dasz, zostanie wykonane tylko przez ten jeden wątek. Idealny do aktualizowania interfejsu.
• Dispatchers.IO: Ten Szef zarządza dużą, współdzieloną pulą wątków (pulą kucharzy) zoptymalizowaną do zadań wejścia-wyjścia (operacje sieciowe, dyskowe). Kiedy dajesz mu 100 przepisów (korutyn), on efektywnie rozdziela je między dostępnych kucharzy w swojej puli.
• Dispatchers.Default: Ten Szef również zarządza pulą wątków, ale jest ona zoptymalizowana pod zadania obciążające procesor (np. sortowanie ogromnej listy).

Kiedy korutyna (przepis) uruchomiona na Dispatchers.IO musi poczekać na odpowiedź z sieci (zawiesza się, suspend), zwraca pomocnika (wątek) z powrotem do puli, aby ten mógł zająć się innym zadaniem. Kiedy odpowiedź z sieci wraca, korutyna jest wznawiana i dostaje dowolnego wolnego pomocnika (wątek) z puli Dispatchers.IO, aby kontynuować pracę. Korutyna nie ma puli wątków. Korutyna używa puli wątków udostępnianej przez jej Dispatcher.

Drugim kluczowym elementem CoroutineScope jest Job (w naszej analogii będzie to odpowiednik Szefa Zmiany). Śledzi wszystkie korutyny aktualnie gotowane w danym zakresie (kuchni). Działa jak rodzic dla wszystkich korutyn uruchomionych w tym scope. Kiedy uruchamiasz korutynę za pomocą launch, funkcja ta zwraca właśnie obiekt Job.

val job = scope.launch {... }

Job to jedyny sposób, aby dowiedzieć się, co dzieje się z korutyną. Działa jak interaktywny bilet zamówienia w restauracji. Przechowuje on aktualny stan wykonania przepisu:

• New: Zamówienie przyjęte, ale jeszcze nie zaczęte.
• Active: Kucharz właśnie nad tym pracuje (lub czeka na wodę).
• Completed: Danie gotowe.
• Cancelled: Klient wyszedł, wyrzucamy składniki do kosza.
• Dzięki Job możesz programowo zapytać: job.isActive (czy jeszcze pracujemy?) lub job.isCancelled.

W świecie korutyn każdy Job może mieć rodzica i dzieci. Kiedy tworzysz CoroutineScope, ma on w sobie Główny Job (Szefa Zmiany). Kiedy w tym Scope uruchamiasz launch, powstaje nowy Job, który automatycznie staje się dzieckiem Głównego Joba. Tworzy to nierozerwalne drzewo zależności. Działają tu dwie żelazne zasady Ustrukturyzowanej Współbieżności:

• Zasada Anulowania (W dół): Jeśli anulujesz Rodzica (np. zamkniesz ekran i anulujesz coroutineScope), wszystkie dzieci są automatycznie anulowane (Canceled). Szef Zmiany mówi: Zamykamy kuchnię!, więc wszyscy kucharze natychmiast przestają gotować swoje dania. Nikt nie zostaje w pracy po godzinach.
• Zasada Oczekiwania (W górę): Rodzic nie może zakończyć pracy (Completed), dopóki wszystkie jego dzieci nie skończą. Szef Zmiany nie może wyjść do domu, dopóki ostatni pomocnik nie skończy zmywać naczyń.

Podsumowanie w naszej analogii: Jeśli CoroutineScope to Kuchnia, to:

• Job (w Scope): To Kierownik Zmiany. Pilnuje, żeby nikt nie pracował, gdy restauracja jest zamknięta.
• Job (zwracany przez launch): To Bilet Konkretnego Zamówienia. Jest przypięty do tablicy korkowej Kierownika. Jeśli Kierownik zdejmie bilet z tablicy i podrze go (anulowanie), kucharz natychmiast przestaje nad nim pracować.

Rozwiązanie problemu ANR

Wróćmy do przykładu z początku rozdziału. W poprzedniej wersji, gdy klikaliśmy przycisk, który wywoływał Thread.sleep(10000), cała aplikacja zawieszała się. Suwak (Slider) przestawał działać, przyciski nie reagowały, a po chwili system wyświetlał błąd ANR. Zaimplementujmy kod rozwiązujący ten problem, rozpoczniemy od dodania przepisu, czyli funkcji suspend

// Zmiana 1: Słowo kluczowe 'suspend'
suspend fun fetchDataFromServer(): String {
    println("Korutyna:...")
    // Zmiana 2: 'delay' zamiast 'Thread.sleep'
    delay(10000) // delay jest również funkcja suspend
    println("Korutyna:...")
    return "Dane pobrane pomyślnie!"
}

To, co nazywamy zawieszeniem (suspend), to nie jest pauza dla całej pracy. To jest pauza dla tej konkretnej korutyny na tym konkretnym wątku.

• Thread.sleep mówi do Wątku UI: Stój i nic nie rób przez 10 sekund.
• delay mówi do Wątku UI: Odkładam to zadanie na półkę na 10 sekund. Ty idź zajmij się czymś innym (np. rysowaniem suwaka). Wrócimy do tego później.

Wewnątrz Composable (CoroutineSolutionScreen) pojawia się nowa linijka:

val scope = rememberCoroutineScope()

Jest to niezbędne, ponieważ funkcja onClick przycisku jest zwykłą funkcją (nie jest suspend). Nie możemy z niej bezpośrednio wywołać fetchDataFromServer ani delay. Potrzebujemy bramy lub pomostu, który pozwoli nam wejść w świat asynchroniczny. Tym pomostem jest CoroutineScope powiązany z cyklem życia tego ekranu.

Warto zauważyć, że CoroutineScope uzyskany przez rememberCoroutineScope() w Jetpack Compose domyślnie wykorzystuje Dispatchers.Main (a konkretnie Main.immediate). Oznacza to, że kod wewnątrz launch wykonuje się na wątku głównym.

Zakres rememberCoroutineScope() jest ściśle powiązany z punktem w kompozycji, w którym został wywołany. Jeśli użytkownik opuści ten ekran (komponent zostanie usunięty z drzewa UI), scope zostanie automatycznie anulowany. Dzięki temu wszelkie trwające w nim operacje (np. nasze 10-sekundowe pobieranie danych) zostaną natychmiast przerwane, zapobiegając wyciekom pamięci i marnowaniu zasobów.

Wewnątrz onClick widzimy:

Button(onClick = {
statusText = "Operacja rozpoczęta..." // 1. Natychmiastowa aktualizacja UI

scope.launch { // 2. Start korutyny (Fire-and-forget)
        val result = fetchDataFromServer() // 3. Punkt zawieszenia (suspend)
        statusText = result // 4. Wznowienie i aktualizacja UI
    }
})

Co tu się dzieje krok po kroku?

• Użytkownik klika.
• Tekst zmienia się na "Operacja rozpoczęta...".
• scope.launch tworzy nową korutynę.
• Korutyna wchodzi do fetchDataFromServer, dochodzi do delay(10000) i zawiesza się.
• Wątek UI jest wolny! Przez te 10 sekund Wątek Główny obsługuje przesuwanie suwaka (Slider), animacje i inne kliknięcia.
• Po 10 sekundach korutyna budzi się, przypisuje wynik do result i aktualizuje statusText.

Ustrukturyzowana Współbieżność

Poprzednio nauczyliśmy się, jak uruchamiać zadania w tle (nastawiać wodę) i nie blokować przy tym kuchni. Co w sytuacji, gdy przygotowanie dania wymaga wykonania kilku czynności na raz, a my musimy mieć pewność, że wszystkie zostały ukończone, zanim wydamy posiłek?

Tu z pomocą przychodzi funkcja join(), która jest fundamentem synchronizacji w świecie korutyn.

Wyobraź sobie, że jesteś Szefem Kuchni (Korutyna-Rodzic). Masz przygotować główne danie: Stek z warzywami. Nie będziesz robić wszystkiego sam.

• Wołasz Pomocnika nr 1: Usmaż mięso! (zajmie to 2 sekundy).
• Wołasz Pomocnika nr 2: Ugotuj warzywa! (zajmie to 3 sekundy).

Obaj pomocnicy ruszają do pracy w tym samym momencie (współbieżność). Główna korutyn jest wolna i może zająć się innymi sprawami. Ale nie może wydać dania dopóki nie będzie gotowe. To czekanie wykonujemy za pomocą join().

Zobaczmy kod, któy symuluje taką sytuację:

// 1. Szef Kuchni (Rodzic) rozpoczyna pracę
scope.launch {
    logs.add("Szef kuchni (rodzic): Zaczynamy!")

    // 2. Zlecenie zadania Pomocnikowi 1 (Dziecko 1)
    val jobMieso = launch {
        delay(2000) // Symulacja smażenia
        logs.add("Kucharz 1: Mięso usmażone (2s).")
    }

    // 3. Zlecenie zadania Pomocnikowi 2 (Dziecko 2)
    val jobWarzywa = launch {
        delay(3000) // Symulacja gotowania
        logs.add("Kucharz 2: Warzywa gotowe (3s).")
    }

    logs.add("Szef kuchni: Zadania zlecone, scope czeka na zakończenie...")

    // 4. synchronizacja: Szef czeka na wyniki
    jobWarzywa.join()
    jobMieso.join()

    // 5. Finał
    logs.add("Szef kuchni: Wszyscy skończyli! Można podawać danie.")
}

W przykładzie widzimy koordynację zadań podrzędnych. Cały proces rozpoczyna się w momencie, gdy korutyna nadrzędna - nasz metaforyczny Szef Kuchni - uruchamia podzadania za pomocą funkcji launch. Jest to swego rodzaju bilet zamówienia, który daje nam unikalny uchwyt do konkretnej, trwającej korutyny. W naszym przypadku tworzymy dwa takie uchwyty: jobMieso oraz jobWarzywa, które stają się dziećmi głównej korutyny uruchomionej w scope.

Oba zadania startują niemal w tym samym momencie, co oznacza, że nie czekamy z gotowaniem warzyw do momentu, aż mięso będzie gotowe. Dzięki temu całkowity czas operacji nie jest sumą czasów poszczególnych zadań (5 sekund), lecz odpowiada czasowi najdłuższego z nich (3 sekundy). Jednak ta niezależność podzadań rodzi problem synchronizacji: co, jeśli Szef Kuchni zakończy swoją pracę szybciej niż jego pomocnicy? Bez odpowiedniej kontroli, log Można podawać danie pojawiłby się natychmiast po zleceniu zadań, co w naszej metaforze oznaczałoby wydanie klientowi pustego talerza, zanim składniki zdążą się ugotować.

Rozwiązaniem problemu wyścigu (race condition) jest funkcja join(). Z technicznego punktu widzenia jest to funkcja zawieszająca (suspend function), która służy do synchronizacji cyklu życia korutyn. Kiedy korutyna nadrzędna (rodzic) napotyka instrukcję jobWarzywa.join(), jej wykonanie zostaje zawieszone. Należy wyraźnie podkreślić różnicę między zawieszeniem a zablokowaniem: wątek obsługujący tę korutynę nie jest blokowany i może w tym czasie wykonywać inne operacje systemowe. Mechanizm join wprowadza korutynę wywołującą w stan oczekiwania, który trwa dopóki obserwowany obiekt Job nie osiągnie stanu końcowego (Completed lub Cancelled). Dopiero gdy podzadanie faktycznie zakończy swoje działanie, maszyna stanów wznawia korutynę rodzica od kolejnej linii kodu. Dzięki jawnemu wywołaniu join() na obu obiektach Job, realizujemy kontrakt Ustrukturyzowanej Współbieżności, w którym rodzic świadomie koordynuje pracę swoich dzieci i gwarantuje, że żadna operacja nie zostanie zakończona przedwcześnie, zapewniając spójność danych i przewidywalność przepływu aplikacji.

Warto zatrzymać się przy aspekcie, który czyni ustrukturyzowaną współbieżność bezpieczną - jest to automatyczna propagacja anulowania - wpominaliśmy już o tym wcześniej. Ale omówmy to jeszcze raz.

Wyobraźmy sobie, że nasz Szef Kuchni (rodzic) otrzymuje informację, że klient anulował zamówienie i wychodzi z restauracji. W świecie ustrukturyzowanej współbieżności Szef nie musi biegać po kuchni i osobiście prosić każdego pomocnika o przerwanie pracy. Wywołanie job.cancel() na korutynie-rodzicu automatycznie przesyła sygnał anulowania do wszystkich dzieci (jobMieso, jobWarzywa). Jeśli pomocnicy wykonują funkcje zawieszające (takie jak delay), natychmiast przerwą pracę.

W programowaniu aplikacji na Androida ten mechanizm jest niezwykle istotny. Kiedy użytkownik zamyka ekran (Activity), powiązany z nim zakres (viewModelScope lub lifecycleScope) zostaje anulowany. Dzięki hierarchii rodzic-dziecko, wszystkie trwające zapytania sieciowe czy obliczenia w tle zostają posprzątane automatycznie. Zapobiega to wyciekom pamięci i marnowaniu baterii na procesy, których wyniku nikt już nie zobaczy.

Odbieranie Wyników: Mechanizm async i await

Mimo że funkcja launch jest niezwykle przydatna, posiada jedno istotne ograniczenie: działa na zasadzie odpal i zapomnij (fire-and-forget). Zwraca ona obiekt Job, który pozwala nam sprawdzić czy praca trwa, lub ją przerwać, ale nie pozwala nam wyjąć ze środka żadnej wartości. W świecie rzeczywistym nie zawsze chcemy tylko zlecić zadanie; często potrzebujemy, aby pracownik coś nam przyniósł (np. konkretny składnik z magazynu). Do takich zadań służy funkcja async.

Analogia: Kurier i Pusta Skrzynka

Zanim przeanalizujemy kod, posłużmy się analogią zamówienia przesyłki:

• async: To moment kliknięcia Kup teraz. Sklep nie daje nam towaru natychmiast, ale daje nam numer śledzenia przesyłki (to jest nasz obiekt Deferred).
• Deferred: To metaforyczne puste pudełko. Pudełko istnieje fizycznie (mamy do niego referencję w kodzie), ale w tej chwili nie możemy z niego skorzystać, bo zawartość jest jeszcze w drodze.
• await(): To moment, w którym czekamy na dzwonek kuriera. Jeśli kurier już był - odbieramy zawartość natychmiast. Jeśli jeszcze jedzie - zawieszamy nasze inne czynności i czekamy, aż pudełko zostanie odpakowane.

Przykład Praktyczny: Generator Tajemniczego Hasła

Rozważmy implementację ekranu, który symuluje złożony proces generowania bezpiecznego hasła. Proces ten trwa 3 sekundy i musi zwrócić wynik bezpośrednio do zmiennej stanu interfejsu.

@Composable fun PasswordGeneratorScreen() { 
    var password by remember { mutableStateOf("...") } 
    val scope = rememberCoroutineScope()

    // Funkcja symulująca ciężkie obliczenia w tle
    suspend fun generatePassword(): String {
        delay(3000) // Symulacja pracy
        return "Kotlin-Is-Super-Secure-123"
    }

    Column(
        modifier = Modifier.fillMaxSize().padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text("Generator Tajemniczego Hasła", style = MaterialTheme.typography.headlineSmall)
        Spacer(Modifier.height(20.dp))

        Button(onClick = {
            password = "Generowanie..."
            
            // Uruchamiamy korutynę nadrzędną (szkielet operacji)
            scope.launch {
                // 1. Zlecenie zadania (async) - natychmiast dostajemy 'pudełko' Deferred
                val deferredPassword: Deferred<String> = async { generatePassword() }
                
                // 2. Oczekiwanie (await) - korutyna zawiesza się tutaj na 3 sekundy
                val result = deferredPassword.await()
                
                // 3. Po 3 sekundach korutyna wznawia pracę z gotowym wynikiem
                password = result
            }
        }) {
            Text("Wygeneruj hasło")
        }

        Spacer(Modifier.height(20.dp))
        Text(password, fontSize = 20.sp, fontFamily = FontFamily.Monospace)
    }
}

W powyższym kodzie kluczowy jest moment kliknięcia przycisku. Wywołujemy scope.launch, aby wejść do świata współbieżności. Wewnątrz niego dzieją się dwie rzeczy: Po pierwsze, linia async { generatePassword() } nie blokuje wykonania kodu. Funkcja async natychmiast zwraca obiekt typu Deferred<String>. Gdybyśmy w tym momencie sprawdzili wartość deferredPassword, dowiedzielibyśmy się jedynie, że zadanie jest w toku. Po drugie, wywołanie deferredPassword.await() jest instrukcją dla mechanizmu korutyn: Zatrzymaj tę konkretną korutynę w tym miejscu i czekaj, aż deferredPassword dostarczy wartość. Co niezwykle ważne - wątek UI pozostaje wolny. Użytkownik widzi napis Generowanie..., ale aplikacja nie jest zamrożona; system może w tym czasie obsłużyć inne zdarzenia.

Gdy funkcja generatePassword() skończy pracę i zwróci String, await() odpakuje go i przypisuje do zmiennej result. Dopiero wtedy wykonuje się ostatnia linia: password = result, co powoduje rekompozycję interfejsu i wyświetlenie hasła.

Most między światami: runBlocking

Wszystkie funkcje, które poznaliśmy do tej pory - launch oraz async - wymagają do działania istniejącego zakresu (CoroutineScope). Istnieją jednak sytuacje, w których musimy poczekać, aż świat korutyn zakończy swoją pracę, zanim pozwolimy światu zewnętrznemu (blokującemu) ruszyć z miejsca. Do tego celu służy runBlocking. Jak sama nazwa wskazuje, jest to funkcja, która blokuje bieżący wątek, na którym została wywołana, dopóki wszystkie korutyny wewnątrz jej bloku nie zostaną zakończone.

Wyobraź sobie strumień kodu asynchronicznego jako płynącą rzekę - korutyny płyną swobodnie, nie przeszkadzając sobie nawzajem. runBlocking jest jak tama, którą stawiamy w poprzek rzeki.

• Woda (wątek) przestaje płynąć dalej za tamę.
• Cały nurt zostaje zatrzymany tak długo, aż praca wewnątrz tamy nie zostanie ukończona.
• Dopiero gdy ostatnia korutyna w bloku runBlocking skończy działanie, tama zostaje otwarta i wątek może kontynuować wykonywanie kolejnych linii kodu pod blokiem.

Zastosowanie

Ponieważ runBlocking blokuje wątek, wywołanie go na wątku UI spowoduje natychmiastowe zamrożenie interfejsu użytkownika na cały czas trwania operacji wewnątrz bloku. Jest to powrót do problemu, który korutyny miały rozwiązać.

Kiedy zatem jest to przydatne?

1. Testy jednostkowe: W testach chcemy, aby proces testowy poczekał na wynik operacji asynchronicznej, zanim sprawdzi poprawność wyniku (asercję).
2. Funkcja main(): W prostych programach konsolowych Kotlin, gdzie musimy zatrzymać program przed zamknięciem, dopóki korutyny nie skończą pracy.
3. Integracja z kodem blokującym: Gdy musimy wywołać kod asynchroniczny wewnątrz biblioteki, która nie wspiera korutyn i wymaga natychmiastowego zwrotu wartości.

Porównanie mechanizmów

Poniższy przykład pokazuje, jak runBlocking wpływa na przepływ programu w porównaniu do launch.

fun runBlockingExample() { 
    println("1. Start programu")

    // Ten blok zatrzyma wątek na 2 sekundy!
    runBlocking {
        println("2. Wewnątrz runBlocking - start")
        delay(2000)
        println("3. Wewnątrz runBlocking - koniec")
    }

    println("4. Koniec programu - ta linia czekała na tamę")
}

W powyższym kodzie napis 4. Koniec programu pojawi się dopiero po 2 sekundach. Gdybyśmy zamiast runBlocking użyli launch (w odpowiednim scope), napis 4 pojawiłby się natychmiast po napisie 2, ponieważ rzeka płynęłaby dalej, podczas gdy korutyna pracowałaby obok.

Problem Monolitycznego Kodu

Na początku przygody z Jetpack Compose naturalnym odruchem jest pisanie całego kodu wewnątrz funkcji @Composable. Skoro UI to tylko funkcja, dlaczego nie umieścić w niej również pobierania danych z sieci czy logiki biznesowej?

Spójrzmy na kod, który działa, ale łamie zasady inżynierii oprogramowania. Nazywamy to antywzorcem "God Composable" - funkcją, która wie i robi wszystko.

// KROK 1: Kod "naiwny"
@Composable
fun UserProfileScreen() {
    // Stan UI + Logika w jednym miejscu
    var userData by remember { mutableStateOf("Ładowanie...") }
    val scope = rememberCoroutineScope() // Scope powiązany z cyklem życia UI

    Column {
        Button(onClick = {
            // Operacja sieciowa bezpośrednio w UI
            scope.launch {
                try {
                    val user = api.getUser() // Symulacja pobierania (2 sekundy)
                    userData = user.name.uppercase() // Logika biznesowa
                } catch (e: Exception) {
                    userData = "Błąd!"
                }
            }
        }) {
            Text("Pobierz dane")
        }
        Text(userData)
    }
}

Uruchamiamy aplikację, klikamy przycisk, dane się pobierają. Wszystko wygląda świetnie. Do momentu, gdy obrócimy telefon. Android przy zmianie konfiguracji (np. obrót ekranu) niszczy i tworzy aktywność od nowa. Funkcja remember traci pamięć. Użytkownik, który czekał na dane, nagle znów widzi ekran początkowy Ładowanie....

Rozwiązanie tego problemu już znamy z poprzedniego semestru. Spróbujmy więc naprawić nasz kod:

// rememberSaveable
var userData by rememberSaveable { mutableStateOf("Ładowanie...") }

Czy to rozwiązuje problem? Tylko pozornie i tylko w trywialnych przypadkach. Gdy spróbujemy zastosować to w większej aplikacji, napotkamy trzy krytyczne problemy, których rememberSaveable nie rozwiąże:

• Śmierć Korutyny: rememberCoroutineScope jest ściśle powiązany z widokiem. Gdy obracasz ekran w trakcie pobierania danych (np. wolne WiFi), stary widok ginie, a wraz z nim anulowana jest korutyna. Pobieranie zostaje przerwane w połowie. Nowy ekran powstaje, ale nic nie wie o tym, że poprzedni coś pobierał. Użytkownik klika, czeka i nic nie dostaje.
• Ograniczenia Pamięci (Bundle): rememberSaveable zapisuje dane w systemowym Bundle. Jest on przeznaczony dla małych danych (tekst, liczby). Jeśli spróbojemy tam zapisać listę 500 obiektów JSON pobranych z API, aplikacja wyrzuci błąd TransactionTooLargeException i się zamknie.
• Testowalność: Jak przetestować, czy nazwisko jest poprawnie zamieniane na wielkie litery? W obecnym kodzie jest to niemożliwe bez uruchamiania emulatora, bo logika jest zabetonowana wewnątrz przycisku.

Dochodzimy do wniosku, że funkcja Composable nie jest odpowiednim miejscem na trzymanie danych ani wykonywanie operacji. Potrzebujemy miejsca, które:

1. Przeżyje rotację ekranu (nie jak rememberSaveable).
2. Pozwoli korutynom dokończyć pracę, nawet gdy widok jest niszczony.
3. Nie ma limitu wielkości danych (nie jak Bundle).

Aby zrozumieć potrzebę architektury, posłużmy się analogią budowlaną:

• Budowanie budy dla psa (Brak architektury): Możesz to zrobić sam. Jeśli wbijesz gwóźdź w złym miejscu, łatwo to poprawić. To są małe, proste aplikacje.
• Budowanie wieżowca (Z architekturą): Tutaj potrzebujesz planu. Elektryk (Data Layer) nie maluje ścian, a malarz (UI Layer) nie kładzie instalacji gazowej. W dużym projekcie, jeśli Composable zajmuje się logiką API, to tak jakby malarz próbował naprawiać windę.

Potrzebujemy więc Kierownika Budowy, który ma plany w biurze (bezpiecznym od remontów) i zarządza pracami. Tym kierownikiem będzie komponent, który za chwilę poznamy.

Ewolucja Wzorców Architektonicznych

Skoro wiemy już, że wrzucanie wszystkiego do jednego worka ("God Composable") jest nie najlepszym rozwiązaniem, musimy zastanowić się, jak podzielić aplikację. W inżynierii oprogramowania ten problem nie jest nowy. Przez dekady wykształciło się wiele różnych podejść do tego problemu. Jednym z nich jest rodzina wzorców MVx, które różnią się sposobem, w jaki warstwa danych komunikuje się z warstwą wizualną.

Aby zrozumieć różnice między nimi, posłużymy się prostymi analogiami.

MVC (Model-View-Controller)

Jest to najstarsze podejście, które można porównać do wizyty w tradycyjnym sklepie, gdzie towar podaje sprzedawca.

• Ty (View): Stoisz przed ladą. Widzisz towar, ale jesteś pasywny - nie możesz go sam wziąć.
• Sprzedawca (Controller): To on rządzi procesem. Mówisz mu: Poproszę chleb (Interakcja).
• Magazyn (Model): Sprzedawca idzie na zaplecze, sprawdza stan magazynowy i bierze towar.

Wniosek: W tym układzie Sprzedawca (Controller) decyduje o wszystkim. To on musi wiedzieć, jak wygląda magazyn i to on decyduje, co pokazać klientowi. Musi też być w stanie wskazać konkretnego klienta, któremu musi wydać towar.

MVP (Model-View-Presenter)

Druga odmiana wzorca z rodziny MVx.

• Klient przy stoliku (View): Siedzisz i czekasz. Nie wiesz i nie interesuje Cię, co się dzieje w kuchni.
• Kelner (Presenter): Przyjmuje zamówienie i idzie do kuchni (Model).
• Kluczowa cecha: Kelner wraca z kuchni i własnoręcznie stawia talerz na Twoim stole.

W kodzie wygląda to tak, że Presenter (Kelner) posiada referencję do Widoku (Klienta). Wywołuje na nim konkretną metodę, np. view.showDinner(). Problem: Jest to sztywne połączenie 1:1. Kelner musi znać konkretny stolik. Jeśli Klient wyjdzie do toalety (Rotacja Ekranu/Zniszczenie Widoku), a Kelner wróci z talerzem i spróbuje go postawić na pustym miejscu, dojdzie do błędu (NullPointerException) - klient musi być dostępny.

MVVM (Model-View-ViewModel)

To podejście jest często wykorzystywane we współczesnym Androidzie.

• Użytkownik (View): Podchodzi do maszyny i naciska przycisk (Wysyła Event).
• Automat (ViewModel): Odbiera sygnał, mieli kawę, pobiera wodę (komunikuje się z Repozytorium/Modelem).
• Wynik (State): Automat wystawia kubek z kawą do szuflady odbiorczej (Emisja stanu).

Kluczowa różnica - Reaktywność: Automatu nie obchodzi, kto ten kubek weźmie.

• Automat tylko wystawia stan.
• Jeśli nikt nie stoi przed maszyną - kubek (dane) po prostu czeka w szufladzie.
• Jeśli użytkownik odejdzie (obróci ekran) i przyjdzie nowy (Activity zostanie stworzone na nowo) - kubek z kawą nadal tam jest. Nowy widok po prostu zagląda do szuflady i widzi gotowy napój.

W Compose tą szufladą są strumienie danych, takie jak StateFlow. ViewModel aktualizuje StateFlow, a Widok (Composable) jedynie nasłuchuje zmian. To rozwiązuje nasz problem z rotacją ekranu - ViewModel trzyma napój, niezależnie od tego, co dzieje się z klientem.

MVI (Model-View-Intent)

Jest to ewolucja wzorca MVVM, która kładzie rygorystyczny nacisk na jednokierunkowy przepływ danych (Unidirectional Data Flow).

• View (Ekran kiosku): Wyświetla aktualny stan zamówienia. Jest to tylko odczyt.
• Intent (Zamiar/Akcja): Gdy klikasz Dodaj frytki, nie zmieniasz bezpośrednio zamówienia. Wysyłasz do systemu zamiar (Intent) o treści: "Użytkownik chce dodać frytki".
• Model (System): System bierze Twój aktualny paragon, bierze Twój zamiar, przetwarza je i wypluwa zupełnie nowy, zaktualizowany paragon (State).

Kluczowa cecha - Cykliczność i Niezmienność: W przeciwieństwie do MVVM, gdzie ViewModel może mieć wiele różnych strumieni danych (osobno imię, osobno lista, osobno błędy), w MVI dążymy do posiadania jednego obiektu stanu (np. OrderUiState). W naszej metaforze: Nie możesz wziąć długopisu i dopisać frytek do wydrukowanego paragonu. Musisz wysłać żądanie, a system wydrukuje Ci nowy, zaktualizowany paragon. To zapewnia przewidywalność aplikacji - zawsze wiemy, co doprowadziło do obecnego stanu ekranu.

Naturalnie dążymy do MVI, używając pojedynczego StateFlow<UiState> w ViewModelu.

Implementacja MVVM: Analiza Techniczna

W tej sekcji przeanalizujemy implementację wzorca MVVM na prostym przykładzie. Skupimy się na separacji warstw oraz mechanizmie zachowania stanu przy zmianach konfiguracji.

Klasa ViewModel pełni rolę zarządcy stanu. Zwróćmy uwagę na wzorzec Backing Property, który zapewnia pełną enkapsulację danych.

class WordViewModel : ViewModel() {
    // 1. Stan wewnętrzny (Mutable) - prywatny
    // Używamy mutableStateListOf, który jest implementacją SnapshotStateList.
    // Dzięki temu Compose śledzi zmiany i wymusza rekompozycję.
    private val _words = mutableStateListOf("Witaj", "Świecie", "Jetpack")
    
    // 2. Stan publiczny (Immutable) - tylko do odczytu
    // Widok widzi tylko List<String>. Nie może jej modyfikować bezpośrednio.
    // To wymusza Unidirectional Data Flow.
    val words: List<String> get() = _words

    // 3. Interfejs publiczny (Actions/Events)
    // Jedyny sposób na zmianę stanu to wywołanie metody w ViewModelu.
    fun addWord(newWord: String) {
        _words.add(newWord)
    }

    fun clearList() {
        _words.clear()
    }
}

Zastosowanie mutableStateListOf zamiast standardowego List jest krytyczne dla reaktywności. W Jetpack Compose system nie obserwuje standardowych kolekcji Javy/Kotlina. Typy ze świata Compose (jak State<T>) implementują wzorzec Obserwatora, automatycznie powiadamiając subskrybentów (funkcje Composable) o zmianach.

Widok (Composable) staje się tzw. Passive View. Nie posiada własnego stanu logicznego, a jedynie renderuje to, co dostarczy ViewModel.

@Composable
fun WordScreen(
    // Wstrzykiwanie zależności (Dependency Injection)
    // Funkcja viewModel() wykorzystuje ViewModelProvider do pobrania instancji.
    viewModel: WordViewModel = viewModel()
) {
    Column {
        // Odczyt stanu (State Observation)
        LazyColumn {
            items(viewModel.words) { word ->
                Text(text = word, style = MaterialTheme.typography.headlineSmall)
            }
        }

        // Delegacja zdarzeń (Event Propagation)
        Button(onClick = { 
            viewModel.addWord("Nowe Słowo") 
        }) {
            Text("Dodaj element")
        }
    }
}

Aby skorzystać z funkcji viewmodel() musimy dodać odpowiednią zależność do bloku dependencies w pliku konfiguracyjnym projektu.

implementation("androidx.lifecycle:lifecycle-viewmodel-compose:2.9.2")

Kluczową zaletą ViewModelu jest przetrwanie rotacji ekranu. Nie dzieje się to jednak w sposób magiczny, lecz wynika z architektonicznego cyklu życia komponentów Androida.

Możemy myśleć o ViewModelu jak o Singletonie zakresowym (Scoped Singleton).

1. ViewModelStore: Każda Aktywność posiada obiekt ViewModelStore. Jest to mapa (HashMap), która przechowuje instancje ViewModeli.
2. Zmiana Konfiguracji (np. Rotacja):

Gdy użytkownik obraca ekran, system operacyjny niszczy obiekt Activity i tworzy nowy. Jednakże, obiekt ViewModelStore powiązany z tą aktywnością nie jest niszczony. Jest on cache'owany przez system w pamięci (w obiekcie NonConfigurationInstances).

3. Rekonstrukcja (Re-attach):

Nowa instancja Activity startuje. Funkcja viewModel() prosi klasę ViewModelProvider o instancję WordViewModel.

• Provider zagląda do zachowanego ViewModelStore.
• Znajduje tam istniejącą instancję WordViewModel (tę samą, która istniała przed obrotem).
• Zwraca tę instancję do nowej Aktywności.

Dzięki temu mechanizmowi, dane wewnątrz ViewModelu (nasza lista słów) pozostają w pamięci RAM nienaruszone, mimo że warstwa UI została całkowicie przebudowana. ViewModel ginie dopiero wtedy, gdy Aktywność zostanie trwale zakończona (np. przez przycisk Back lub finish()), co powoduje wywołanie metody onCleared() i wyczyszczenie ViewModelStore.

Warstwa Danych: Wzorzec Repozytorium

Do tej pory nasz ViewModel trzymał dane w pamięci. W większej aplikacji dane pochodzą z zewnętrznych źródeł: API (Retrofit), bazy danych SQL (Room), plików. Tutaj pojawia się pytanie: Czy ViewModel powinien wiedzieć, skąd pochodzą dane? Zgodnie z zasadą Separation of Concerns - absolutnie nie.

Wróćmy do metafory restauracji:

• ViewModel (Kelner): Chce po prostu otrzymać gotowe danie. Nie interesuje go, czy składniki są z targu, czy z lodówki.
• Repozytorium (Kuchnia/Magazyn): To tutaj zapadają decyzje skąd wziąć dane.

Aby uniezależnić ViewModel od konkretnego źródła danych, używamy interfejsu.

// Kontrakt: Mówi CO można zamówić, ale nie JAK to zdobyć
interface WordRepository {
    suspend fun getWords(): List<String>
}

W prostym przykładzie Repozytorium może wydawać się zbędną warstwą ("przekazywaczem"). Jednak w większych aplikacjach, które będziemy budować na kolejnych wykładach, Repozytorium pełni kluczowe funkcje:

• 1. Obsługa Trybu Offline (Caching):

To najważniejsze zastosowanie, zwane Single Source of Truth. Repozytorium może sprawdzać: Czy mamy internet?.

• Jest internet: Pobierz dane z API, zapisz je w lokalnej bazie danych (Room), a następnie zwróć dane z bazy.
• Brak internetu: Zwróć dane zapisane w bazie z poprzedniej sesji.

Dla ViewModelu ten proces jest niewidoczny - on po prostu prosi o dane i je dostaje, niezależnie od stanu sieci.

• 2. Agregacja Danych:

Często jeden ekran potrzebuje danych z wielu źródeł. Np. ekran Profilu może wymagać danych użytkownika (z endpointa /user) oraz listy ostatnich zamówień (z endpointa /orders). Repozytorium pobiera oba te zasoby równolegle (korzystając z async), łączy je w jeden obiekt UserProfile i dopiero taki gotowy produkt przekazuje ViewModelowi.

• 3. Mapowanie i Czystość Danych:

API często zwraca dane w formacie technicznym (brudnym), np. user_id_xq2, daty w formacie timestamp itp. Repozytorium służy jako obierak - przetwarza surowe obiekty JSON (DTO - Data Transfer Object) na czyste, czytelne obiekty domenowe, z których łatwo korzysta się w UI.

Problem Konstruktora z Parametrem: ViewModelFactory

Dotarliśmy do ostatniego wyzwania technicznego. Stworzyliśmy WordRepository i chcemy przekazać je do naszego WordViewModel.

Zmieniamy więc konstruktor:

class WordViewModel(private val repository: WordRepository) : ViewModel() { ... }

I tu pojawia się problem. Gdy w kodzie Composable wywołamy standardową funkcję: val viewModel: WordViewModel = viewModel(), aplikacja wyrzuci błąd RuntimeException.

Funkcja biblioteczna viewModel() domyślnie potrafi tworzyć tylko obiekty posiadające pusty konstruktor (bez parametrów). Działa ona na zasadzie refleksji.

Aby to zrozumieć, wyobraźmy sobie salon samochodowy:

• ViewModel bez parametrów (Samochód z placu): Wchodzisz, mówisz Poproszę Passata, sprzedawca daje Ci kluczyki do standardowego modelu stojącego na parkingu. Proste i szybkie.
• ViewModel z Repozytorium (Zamówienie Specjalne): Mówisz Poproszę Passata, ale z silnikiem V6 (Repozytorium). Sprzedawca rozkłada ręce - nie ma takiego na placu. Musi wysłać zamówienie do Fabryki, podając dokładną specyfikację, jak ten samochód złożyć.

W programowaniu tą specyfikacją jest wzorzec Factory.

Musimy dostarczyć instrukcję obsługi, która powie systemowi: Jeśli ktoś poprosi Cię o WordViewModel, to najpierw stwórz Repozytorium, a potem włóż je do środka.

Współcześnie najczęściej implementujemy to za pomocą companion object wewnątrz klasy ViewModelu:

class WordViewModel(private val repository: WordRepository) : ViewModel() {
    
    // ... kod ViewModelu ...

    // Definicja Fabryki (Instrukcja tworzenia)
    companion object {
        val Factory: ViewModelProvider.Factory = object : ViewModelProvider.Factory {
            @Suppress("UNCHECKED_CAST")
            override fun <T : ViewModel> create(modelClass: Class<T>): T {
                return WordViewModel(
                    // Ręczne Wstrzykiwanie Zależności (Manual DI)
                    repository = NetworkWordRepository()
                ) as T
            }
        }
    }
}

Metoda create to miejsce, w którym przejmujemy kontrolę nad tworzeniem obiektu. To my, a nie system, decydujemy, jaka implementacja repozytorium trafi do środka.

Teraz, gdy mamy już naszą fabrykę, musimy jej użyć w widoku. Zmieniamy wywołanie w funkcji WordScreen:

@Composable
fun WordScreen(
    // Przekazujemy fabrykę jako parametr 'factory'
    viewModel: WordViewModel = viewModel(factory = WordViewModel.Factory)
) {
    // ... reszta kodu bez zmian ...
}

Dzięki temu drobnemu dodatkowi, Android wie, jak skonstruować nasz złożony obiekt, zachowując jednocześnie wszystkie zalety cyklu życia ViewModelu (przeżycie rotacji ekranu).

„Czy musimy pisać taki boilerplate (nadmiarowy kod) dla każdego ekranu?”. Na tym etapie - tak. Jest to tzw. Manual Dependency Injection. Musimy rozumieć, jak obiekty są ze sobą łączone pod maską.

W Wykładzie 11 wprowadzimy bibliotekę Hilt. Zrobi ona dokładnie to samo, co my teraz ręcznie, ale automatycznie - za pomocą jednej adnotacji @HiltViewModel. Hilt wygeneruje ten kod fabryki za nas w czasie kompilacji.

Pełny kod przykładu: WordApp

Poniżej znajduje się kompletna implementacja omawianego w tym rozdziale przykładu. Kod łączy w sobie wszystkie poznane elementy: wzorzec Repozytorium (interfejs i implementacja), ViewModel z obsługą stanu i korutyn, Fabrykę (ViewModelProvider.Factory) oraz warstwę widoku w Jetpack Compose.

Możesz skopiować ten kod do jednego pliku (np. WordApp.kt) w swoim projekcie, aby przetestować działanie architektury MVVM.

// ---------------------------------------------------------
// 1. WARSTWA DANYCH (MODEL & REPOSITORY)
// ---------------------------------------------------------

// Kontrakt (Interfejs) - ViewModel wie tylko o tym
interface WordRepository {
    suspend fun getWords(): List<String>
}

// Konkretna implementacja (Symulacja sieci)
class NetworkWordRepository : WordRepository {
    override suspend fun getWords(): List<String> {
        // Symulacja opóźnienia sieciowego (2 sekundy)
        delay(2000)
        return listOf("Architektura", "MVVM", "w", "Praktyce", "Jest", "Super")
    }
}

// ---------------------------------------------------------
// 2. WARSTWA LOGIKI (VIEWMODEL)
// ---------------------------------------------------------

class WordViewModel(private val repository: WordRepository) : ViewModel() {

    // Stan prywatny (mutable)
    private val _words = mutableStateListOf<String>("Kliknij przycisk...")
    
    // Stan publiczny (read-only)
    val words: List<String> get() = _words

    // Funkcja wywoływana przez Widok (Event)
    fun loadData() {
        viewModelScope.launch {
            _words.clear()
            _words.add("Ładowanie...")
            
            // Pobranie danych z repozytorium (zawieszenie korutyny)
            val newWords = repository.getWords()
            
            _words.clear()
            _words.addAll(newWords)
        }
    }

    // Fabryka (ViewModel Factory) - Instrukcja tworzenia ViewModelu z parametrem
    companion object {
        val Factory: ViewModelProvider.Factory = object : ViewModelProvider.Factory {
            @Suppress("UNCHECKED_CAST")
            override fun <T : ViewModel> create(modelClass: Class<T>): T {
                return WordViewModel(
                    repository = NetworkWordRepository() // Wstrzykiwanie zależności
                ) as T
            }
        }
    }
}

// ---------------------------------------------------------
// 3. WARSTWA PREZENTACJI (VIEW / COMPOSE)
// ---------------------------------------------------------

@Composable
fun WordScreen(
    // Wstrzyknięcie ViewModelu za pomocą Fabryki
    viewModel: WordViewModel = viewModel(factory = WordViewModel.Factory)
) {
    Column(modifier = Modifier.padding(16.dp)) {
        
        // Przycisk wyzwalający akcję
        Button(onClick = { viewModel.loadData() }) {
            Text(text = "Pobierz słowa z serwera")
        }

        // Lista wyświetlająca stan
        LazyColumn(modifier = Modifier.padding(top = 16.dp)) {
            items(viewModel.words) { word ->
                Text(text = "• $word")
            }
        }
    }
}

Strumienie

W poprzednich rozdziałach (szczególnie przy omawianiu Coroutines i MVVM) nauczyliśmy się pobierać dane z wykorzystaniem funkcji zawieszających (suspend). Typowa funkcja w naszym repozytorium wyglądała tak:

// Stare podejście: Zwróć i zapomnij
suspend fun getUserNames(): List<String> {
    // 1. Wyślij zapytanie
    // 2. Czekaj na odpowiedź
    return listOf("Anna", "Jan", "Piotr") // 3. Zwróć wynik i zakończ funkcję
}

To podejście ma jedną, zasadniczą wadę: jest jednorazowe. Funkcja zwraca wynik i kończy swoje działanie. Jeśli później na serwerze zarejestruje się nowy użytkownik ("Zofia"), nasza aplikacja o tym nie wie. Widok wyświetla nieaktualne dane, dopóki użytkownik ręcznie nie odświeży ekranu.

Współczesne aplikacje rzadko działają na danych statycznych. Większość funkcji, z których korzystamy na co dzień, to procesy rozciągnięte w czasie:

• Czat: Wiadomości przychodzą jedna po drugiej.
• GPS: Lokalizacja zmienia się z każdym krokiem użytkownika.
• Pobieranie pliku: Chcemy widzieć postęp (1%, 2%, ... 100%), a nie czekać ślepo na koniec.
• Giełda/Krypto: Ceny zmieniają się kilkadziesiąt razy na minutę.

Potrzebujemy mechanizmu, który nie zwraca jednej paczki danych, ale otwiera kanał, którym dane mogą płynąć tak długo, jak to konieczne.

Odpowiedzią na to zapotrzebowanie jest Flow (Strumień). Jest to asynchroniczny strumień danych, który emituje wartości sekwencyjnie.

Różnice między klasyczną listą a strumieniem są fundamentalne:

• List<T>: Dane są dostępne natychmiast, cała grupa na raz. Aby uzyskać nowe dane, musisz ponownie wywołać funkcję.
• Flow<T>: Dane są obliczane lub pobierane asynchronicznie i emitowane pojedynczo (lub grupami) w czasie. Aplikacja nasłuchuje zmian, zamiast o nie pytać.

Możemy zapytać: "Przecież używaliśmy mutableStateOf i UI też odświeżało się automatycznie. Po co nam Flow?". Choć oba mechanizmy są reaktywne, służą do czegoś innego:

1. mutableStateOf (Stan UI): To kontener na aktualną wartość dla widoku. Mówi Compose: Przerysuj się, gdy to się zmieni. Jest ściśle związane z warstwą UI. Nie powinniśmy używać go w warstwie danych (Repozytorium), ponieważ uzależnilibyśmy logikę biznesową od biblioteki interfejsu.
2. Flow (Transport Danych): To mechanizm przesyłania danych z warstw niższych (Baza Danych, Sieć) do ViewModelu. Jest to czysty Kotlin, niezależny od Androida. Posiada operatory (jak map, filter, combine), które pozwalają obrabiać dane w locie.

Wzorzec architektury wygląda więc tak:

Repozytorium dostarcza strumień zmian (Flow), a ViewModel zamienia go na stabilny stan dla widoku (State).

Flow - Zimny Strumień

Podstawowy typ Flow w Kotlinie jest tzw. strumieniem zimnym (Cold Stream). Oznacza to, że kod produkujący dane (wewnątrz bloku flow { ... }) jest pasywny. Nie wykonuje się, dopóki ktoś nie zażąda danych.

Aby to zrozumieć, wyobraźmy sobie film w serwisie streamingowym (np. YouTube lub Netflix).

• Definicja Flow (Plik na serwerze): Film istnieje na serwerach YouTube. Ma swój scenariusz (klatki wideo następują po sobie). Jednak samo istnienie pliku nie powoduje, że film się odtwarza. Serwer nie zużywa zasobów na przesyłanie danych w pustkę.
• Operator collect (Przycisk Play): Transmisja danych rozpoczyna się dopiero w momencie, gdy użytkownik kliknie Odtwarzaj. W świecie Flow odpowiednikiem tego przycisku jest funkcja collect().
• Niezależność Widzów: To najważniejsza cecha. Jeśli trzech użytkowników włączy ten sam film:
• Użytkownik A kliknął "Play" minutę temu -> widzi 60. sekundę filmu.
• Użytkownik B klika "Play" teraz -> widzi 1. sekundę filmu (początek).

Każdy subskrybent otrzymuje swoją własną, niezależną kopię strumienia. Strumień startuje dla niego od zera.

Spójrzmy na przykład:

// 1. DEFINICJA (Przepis / Film na serwerze)
// Ten kod NIE wykonuje się w momencie przypisania do zmiennej!
val numberStream: Flow<Int> = flow {
    println("Strumień wystartował!") 
    for (i in 1..3) {
        delay(1000) // Symulacja pracy/pobierania
        emit(i)     // Emisja danych (klatka filmu)
    }
}

// 2. UŻYCIE (Subskrybent 1)
scope.launch {
    println("Widz 1 naciska PLAY")
    numberStream.collect { value -> 
        println("Widz 1 otrzymał: $value") 
    }
}

// 3. UŻYCIE (Subskrybent 2 - po chwili)
scope.launch {
    delay(1500)
    println("Widz 2 naciska PLAY")
    numberStream.collect { value -> 
        println("Widz 2 otrzymał: $value") 
    }
}

Wynik w logach:

Widz 1 naciska PLAY
Strumień wystartował!
Widz 1 otrzymał: 1
Widz 2 naciska PLAY
Strumień wystartował!  <-- Zauważ, że startuje drugi raz!
Widz 1 otrzymał: 2
Widz 2 otrzymał: 1     <-- Widz 2 otrzymuje pierwszą wartość,
                           mimo że Widz 1 jest już dalej

Spójrzmy na wynik działania naszego programu. Logi ujawniają trzy mechanizmy działania Flow:

1. Wielokrotny start (Re-ewaluacja):

Zauważmy, że komunikat "Strumień wystartował!" pojawia się w logach dwukrotnie.
Wniosek: Blok kodu przekazany do funkcji builder'a flow { ... } nie jest jednorazową inicjalizacją (jak konstruktor obiektu). Jest to instrukcja, która jest uruchamiana od nowa dla każdego subskrybenta.
Gdybyśmy wewnątrz tego bloku umieścili zapytanie HTTP, to przy 10 subskrybentach wykonalibyśmy 10 identycznych zapytań do serwera.

2. Niezależność Czasowa:

Gdy Widz 1 jest już w trakcie oglądania (otrzymuje liczbę 2), Widz 2 dopiero zaczyna i otrzymuje 1.
Wniosek: Subskrybenci nie dzielą między sobą postępu. Każde wywołanie collect() tworzy całkowicie niezależną instancję przepływu danych. To tak, jakby każdy z nich otworzył ten sam plik wideo w osobnym oknie odtwarzacza.

3. Brak Pamięci (State):

Gdy Widz 2 dołącza do strumienia, nie ma dostępu do danych, które zostały wyemitowane wcześniej. Strumień zimny nie przechowuje historii - on ją produkuje na bieżąco.

To zachowanie (restartowanie przy każdej subskrypcji) jest bardzo niebezpieczne w warstwie UI (Widoku). Wyobraź sobie, że użytkownik obraca telefon. System Android niszczy i tworzy na nowo Aktywność.

• Stara Aktywność przestaje nasłuchiwać (cancel).
• Nowa Aktywność zaczyna nasłuchiwać (collect).

W przypadku zwykłego Flow, spowoduje to restart całego procesu pobierania danych (np. ponowne zapytanie do API). Aby tego uniknąć i trzymać dane między obrotami ekranu, potrzebujemy strumienia gorącego - StateFlow.

1. Leniwość (Laziness): Jeśli stworzysz obiekt Flow, ale nigdy nie wywołasz collect, kod wewnątrz flow { ... } nigdy się nie wykona. Nie zostanie wysłane żadne zapytanie do sieci ani do bazy danych.

Pełny kod przykładu

Poniżej znajduje się kompletny kod demonstrujący koncepcję zimnego strumienia. Aplikacja pozwala symulować dołączanie nowych "widzów" (subskrybentów) do tego samego źródła danych.

Kod wizualizuje na ekranie logi, dzięki czemu widać moment startu strumienia dla każdego subskrybenta osobno.

// 1. Definicja Zimnego Strumienia ("Film na serwerze")
// Zauważ: Ta funkcja tylko zwraca przepis na strumień. Nie uruchamia go.
fun numberStream(log: (String) -> Unit): Flow<Int> = flow {
    val time = SimpleDateFormat("HH:mm:ss", Locale.getDefault()).format(Date())
    log("[$time] Strumień (re)startuje!")
    
    for (i in 1..5) {
        delay(1000) // Symulacja pobierania klatki filmu
        emit(i)     // Emisja danych
    }
}

@Composable
fun ColdStreamScreen() {
    // Lista do wyświetlania logów na ekranie
    val logs = remember { mutableStateListOf<String>() }
    // Helper do dodawania wpisów
    fun addLog(msg: String) = logs.add(msg)

    val scope = rememberCoroutineScope()

    Column(modifier = Modifier.padding(16.dp)) {
        Text("Demonstracja Zimnego Flow")
        
        Spacer(Modifier.height(16.dp))

        // Przycisk symulujący Widza 1
        Button(onClick = {
            scope.launch {
                addLog("Widz 1 klika START")
                // collect() uruchamia strumień OD ZERA
                numberStream { msg -> addLog(msg) }.collect { value ->
                    addLog("  Widz 1 ogląda: $value")
                }
            }
        }) {
            Text("Dołącz jako Widz 1")
        }

        // Przycisk symulujący Widza 2
        Button(onClick = {
            scope.launch {
                addLog("Widz 2 klika START")
                // collect() uruchamia OSOBNĄ instancję strumienia
                numberStream { msg -> addLog(msg) }.collect { value ->
                    addLog("  Widz 2 ogląda: $value")
                }
            }
        }) {
            Text("Dołącz jako Widz 2")
        }

        Spacer(Modifier.height(16.dp))

        // Wyświetlanie logów
        LazyColumn {
            items(logs) { log ->
                Text(text = log)
            }
        }
    }
}

StateFlow - Gorący Strumień

Wiemy już, że zwykły Flow jest strumieniem zimnym. Oznacza to, że każda subskrypcja uruchamia go od nowa. W kontekście warstwy danych (np. pobieranie pliku) jest to pożądane, ale w warstwie UI staje się poważnym problemem. W poprzednim rozdziale pojawił się przykład z wykorzystaniem Flow w warstwie UI i przypadku obrócenia urządzenia. Ponieważ Flow jest zimny, cały proces uruchamia się od początku. Potrzebujemy strumienia, który pamięta ostatnią wartość i działa niezależnie od tego, czy ktoś patrzy na ekran, czy nie. Takim strumieniem jest StateFlow. Różni się od zimnego dwoma kluczowymi cechami:

• Istnieje niezależnie od subskrybentów: Produkuje dane nawet wtedy, gdy nikt ich nie odbiera.
• Przechowuje stan (Replay = 1): Zawsze pamięta jedną, ostatnią wyemitowaną wartość. Nowy subskrybent otrzymuje ją natychmiast po podłączeniu.

Dobrą analogią dla StateFlow jest transmisja na żywo (Twitch):

• Streamer (ViewModel): Nadaje transmisję na żywo. Gra w grę, a licznik punktów i zdrowia zmienia się w czasie rzeczywistym. Transmisja trwa (dane płyną) niezależnie od tego, czy na kanale jest 1000 widzów, czy 0.
• Widz (Widok/UI):
• Gdy nowy widz wchodzi na kanał, nie ogląda transmisji od początku (jak filmu na YouTube).
• Widzi to, co dzieje się dokładnie w tej chwili (aktualny stan gry).
• Jeśli widz zminimalizuje aplikację Twitcha (aplikacja w tle) i wróci po minucie, zobaczy bieżącą akcję. To, co działo się przez tę minutę, przepadło (interesuje nas stan Live).
• Wspólny Obraz: Wszyscy widzowie oglądający ten sam kanał widzą dokładnie ten sam stan (np. ten sam obraz transmisji) w tym samym momencie.

Przejdźmy do przykładu:

class StreamerViewModel : ViewModel() {

    // 1. Wersja prywatna, modyfikowalna (MutableStateFlow)
    // WYMAGA wartości początkowej! Tablica wyników na starcie musi coś pokazywać (np. 0).
    private val _viewerCount = MutableStateFlow(0)

    // 2. Wersja publiczna, tylko do odczytu (StateFlow)
    val viewerCount: StateFlow<Int> = _viewerCount.asStateFlow()

    fun addViewer() {
        // Aktualizacja stanu jest natychmiastowa
        _viewerCount.value += 1
    }
}

Warto zauważyć, że MutableStateFlow wymaga podania wartości początkowej w konstruktorze. Jest to logiczne - skoro StateFlow gwarantuje, że zawsze ma wartość (jak tablica wyników), to musi mieć ją od momentu stworzenia.

Pełny kod przykładu

Poniższy kod demonstruje działanie StateFlow. Mamy "Streamera" (ViewModel), który zarządza licznikiem widzów. Zwróć uwagę na zachowanie aplikacji:

1. Klikaj Dodaj widza w Panelu Streamera.
2. Następnie kliknij Dołącz do transmisji jako Widz 1. Zobaczysz aktualną liczbę (np. 5), a nie 0.
3. Dołącz jako Widz 2. Otrzyma on tę samą wartość co Widz 1.

// --- 1. ViewModel (Streamer) ---
class StreamerViewModel : ViewModel() {
    // Stan wewnętrzny (Gorący strumień, zawsze ma wartość)
    private val _viewerCount = MutableStateFlow(0)
    
    // Stan publiczny (Tylko do odczytu)
    val viewerCount: StateFlow<Int> = _viewerCount.asStateFlow()

    fun addViewer() {
        _viewerCount.value += 1
    }
}

// --- 2. Widok (UI) ---
@Composable
fun StateFlowDemoScreen(
    viewModel: StreamerViewModel = viewModel()
) {
    Column(
        modifier = Modifier.fillMaxSize().padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text("Panel Streamera (StateFlow)")
        
        Spacer(Modifier.height(16.dp))
        
        // Panel Sterowania Streamera
        Card() {
            Column(
              modifier = Modifier.padding(16.dp), 
              horizontalAlignment = Alignment.CenterHorizontally) {
                Text("Jesteś Streamerem")
                Button(onClick = { viewModel.addViewer() }) {
                    Text("Dodaj widza (+1)")
                }
            }
        }

        Spacer(Modifier.height(32.dp))

        // Symulacja Widzów
        // Każdy komponent ViewerScreen niezależnie subskrybuje 
        // TEN SAM StateFlow
        ViewerScreen(viewModel, "Widz 1")
        Spacer(Modifier.height(8.dp))
        ViewerScreen(viewModel, "Widz 2")
    }
}

@Composable
fun ViewerScreen(viewModel: StreamerViewModel, viewerName: String) {
    // collectAsState() zamienia StateFlow w State z Compose
    val count by viewModel.viewerCount.collectAsState()
    
    Card(modifier = Modifier.fillMaxWidth()) {
        Row(
            modifier = Modifier.padding(16.dp),
            verticalAlignment = Alignment.CenterVertically,
            horizontalArrangement = Arrangement.SpaceBetween
        ) {
            Text(viewerName, style = MaterialTheme.typography.bodyLarge)
            Text(
                text = "Widzi licznik: $count", 
                style = MaterialTheme.typography.titleLarge
            )
        }
    }
}

SharedFlow: Obsługa Zdarzeń

Mamy już StateFlow, w któym przechowujemy stan (np. liczbą widzów). Jednak w aplikacjach mobilnych często mamy do czynienia z sytuacjami, które nie są stanem, ale zdarzeniem.

Przykłady zdarzeń jednorazowych:

• Wyświetlenie komunikatu Błąd połączenia z siecią (Toast/Snackbar).
• Nawigacja do innego ekranu po pomyślnym logowaniu.
• Wibracja telefonu.

Dlaczego StateFlow się tu nie nadaje? Wyobraźmy sobie, że używamy StateFlow do obsługi błędów.

1. Występuje błąd. Wpisujemy go do StateFlow: state.value = "Error".
2. Widok wyświetla Toast z błędem.
3. Użytkownik obraca telefon.
4. Widok tworzy się na nowo i subskrybuje StateFlow.
5. Ponieważ StateFlow pamięta ostatnią wartość, nowy widok natychmiast otrzymuje Error i wyświetla Toast ponownie.

Zdarzenia powinny być skonsumowane raz i zniknąć. Przykładowo: nie chcemy, aby dzwonek do drzwi dzwonił w nieskończoność przy każdym otwarciu drzwi. Do obsługi takich scenariuszy służy SharedFlow. Jest to również gorący strumień, ale skonfigurowany domyślnie tak, aby nie pamiętać historii.

Wróćmy do naszej transmisji. O ile obraz wideo (StateFlow) musi być ciągły i dostępny dla każdego, o tyle powiadomienia działają inaczej.

• Alert o donacji (Zdarzenie): Na ekranie pojawia się komunikat Widz1 wpłacił 5 zł.
• Widz obecny (Subskrybent): Widzi komunikat w momencie jego pojawienia się.
• Widz nieobecny (Aplikacja w tle): Jeśli widza nie ma w pokoju w momencie donacji, to po powrocie nie widzi starego alertu.

Działa to jak dzwonek do drzwi: słyszysz go tylko wtedy, gdy naciska go kurier. Jeśli wrócisz do domu godzinę później, dzwonek nie zaczyna nagle dzwonić, informując, że ktoś był.

Zobaczmy przykład. Różnice względem StateFlow są kluczowe:

class StreamerViewModel : ViewModel() {

    // 1. Brak wartości początkowej!
    // SharedFlow nie musi mieć wartości, on je tylko "przepycha".
    // replay = 0 (Domyślnie) -> Nowi subskrybenci NIE dostają starych zdarzeń.
    private val _donations = MutableSharedFlow<String>(replay = 0)
    
    val donations = _donations.asSharedFlow()

    fun sendDonationAlert(message: String) {
        viewModelScope.launch {
            // 2. Używamy emit(), a nie .value
            // To operacja zawieszająca (suspend), bo bufor może być pełny
            _donations.emit(message)
        }
    }
}

1. Parametr replay = 0:

To istotna konfiguracja dla zdarzeń jednorazowych. Parametr ten określa, ile ostatnich wartości ma być przechowywanych w pamięci dla nowych subskrybentów.

• W StateFlow wartość ta jest sztywno ustawiona na 1 (dlatego stan odtwarza się po np. obrocie ekranu).
• W SharedFlow ustawienie 0 gwarantuje, że zdarzenie wyemitowane w momencie $T_0$ nie zostanie dostarczone subskrybentowi, który rozpocznie nasłuchiwanie w momencie $T_1$. Zapobiega to błędowi ponownego wyświetlania komunikatów.
2. Brak pola .value:

Zauważmy, że SharedFlow nie posiada właściwości value. Można jedynie oczekiwać na nadchodzące emisje. Wymusza to na programiście podejście czysto reaktywne.

3. Funkcja emit() jest suspend:

W przeciwieństwie do ustawiania state.value = ..., metoda emit() w SharedFlow jest funkcją zawieszającą. SharedFlow obsługuje mechanizm Backpressure. Jeśli subskrybenci nie nadążają z przetwarzaniem zdarzeń, a bufor wewnętrzny się zapełni, funkcja emit zawiesi korutynę producenta do momentu zwolnienia miejsca w buforze. Zapewnia to bezpieczeństwo wątkowe i chroni przed zalaniem aplikacji nadmiarowymi danymi.

Pełny kod przykładu

Poniższy kod łączy oba światy. Mamy StateFlow dla licznika widzów (trwały) i SharedFlow dla alertów o donacjach (ulotny).

Zwróć uwagę na użycie LaunchedEffect w widoku - to specjalny blok w Compose służący do obsługi jednorazowych zdarzeń z korutyn.

// --- ViewModel ---
class EventsViewModel : ViewModel() {
    // Zdarzenia
    private val _donationEvents = MutableSharedFlow<String>()
    val donationEvents = _donationEvents.asSharedFlow()

    fun triggerDonation() {
        viewModelScope.launch {
            _donationEvents.emit("Ktoś wpłacił 10 PLN!")
        }
    }
}

// --- Widok ---
@Composable
fun EventsDemoScreen(
    viewModel: EventsViewModel = viewModel(),
    snackbarHostState: SnackbarHostState // Komponent do wyświetlania Toastów/Snackbarów
) {
    // Odbieranie zdarzeń w Compose
    // LaunchedEffect(Unit) uruchamia się RAZ przy wejściu na ekran.
    // Jeśli obrócisz ekran, uruchomi się ponownie, 
    // ale SharedFlow jest pusty (nie pamięta historii),
    // więc stary komunikat się nie pojawi.
    LaunchedEffect(Unit) {
        viewModel.donationEvents.collect { message ->
            // Reakcja na zdarzenie: Pokaż Snackbar
            snackbarHostState.showSnackbar(message)
        }
    }

    Column(
        modifier = Modifier.fillMaxSize().padding(16.dp),
        horizontalAlignment = Alignment.CenterHorizontally
    ) {
        Text("Obsługa Zdarzeń (SharedFlow)")
        Spacer(Modifier.height(32.dp))
        
        Button(onClick = { viewModel.triggerDonation() }) {
            Text("Wyślij Donację (Zdarzenie)")
        }
        
        Spacer(Modifier.height(16.dp))
        Text("Kliknij i obserwuj Snackbar. Po obrocie ekranu komunikat nie wróci.", 
             textAlign = TextAlign.Center)
    }
}

Podsumowanie

Wybór odpowiedniego rodzaju strumienia jest istotny dla poprswnego funkcjonowania aplikacji. Częstym błędem jest używanie StateFlow do wszystkiego (również do zdarzeń), co prowadzi do błędów z powtarzającymi się komunikatami, lub używanie zwykłego Flow w UI, co powoduje niepotrzebne restartowanie zapytań sieciowych. Poniższa tabela zestawia najważniejsze różnice, wykorzystując nasze analogie multimedialne.

Kiedy piszesz kod i zastanawiasz się, czego użyć, zadaj sobie te pytania:

• Czy to jest stan, który widok musi widzieć zawsze (nawet po obrocie)? -> Użyj StateFlow.
• Czy to jest jednorazowy sygnał (np. "Zalogowano", "Błąd")? -> Użyj SharedFlow.
• Czy pobierasz dane z bazy/sieci i przetwarzasz je sekwencyjnie? -> Użyj zwykłego Flow.

Bezpieczne pobieranie danych w UI

Na zakończenie musimy poruszyć temat wydajności. W świecie Androida aplikacja może znajdować się w tle (np. użytkownik przeszedł do innej aplikacji), ale wciąż być żywa w pamięci.

Jeśli w funkcji Composable użyjemy zwykłego collect lub collectAsState(), subskrypcja strumienia może pozostać aktywna nawet wtedy, gdy aplikacja jest w tle. Oznacza to, że jeśli ViewModel wciąż emituje dane (np. lokalizację GPS), aplikacja będzie przetwarzać te dane i zużywać baterię, mimo że użytkownik ich nie widzi. Zalecanym standardem jest używanie funkcji collectAsStateWithLifecycle() rozszerzającej dostarczanej przez bibliotekę androidx.lifecycle:lifecycle-runtime-compose.

Funkcja ta jest świadoma cyklu życia (Lifecycle-Aware):

1. Gdy aplikacja przechodzi w stan STOPPED (tło) -> Anuluje subskrypcję strumienia (zatrzymuje pobieranie danych).
2. Gdy aplikacja wraca do stanu STARTED (widoczna) -> Ponawia subskrypcję i pobiera najnowszy stan.

// Wymagana zależność w build.gradle w bloku dependencies:
// implementation("androidx.lifecycle:lifecycle-runtime-compose:...")

@Composable
fun UserProfileScreen(viewModel: UserViewModel) {
    // mniej wydajnie:
    // val state = viewModel.uiState.collectAsState()

    // Standard:
    val state by viewModel.uiState.collectAsStateWithLifecycle()

    Text(text = "Witaj, ${state.userName}!")
}

Dzięki temu prostemu zabiegowi nasza aplikacja jest nie tylko reaktywna, ale też oszczędna dla baterii użytkownika.

Powrót do podstaw

W poprzednich rozdziałach nauczyliśmy się tworzyć korutyny, używać launch, async oraz synchronizować zadania za pomocą join. Zanim jednak przejdziemy do zaawansowanych wzorców architektonicznych, musimy wyjaśnić jedno z najczęstszych nieporozumień dotyczących współbieżności w Kotlinie.

Wróćmy do przykładów, które omawialiśmy w Rozdziale 3. Przeanalizujmy dokładnie, na jakim wątku wykonywana jest każda linijka kodu.

Spójrzmy na generator haseł. Użyliśmy tu async, co mocno sugeruje asynchroniczność. Ale gdzie tak naprawdę dzieje się praca?

@Composable fun PasswordGeneratorScreen() { 
    var password by remember { mutableStateOf("...") } 
    // Domyślny scope w Compose używa Dispatchers.Main.immediate
    val scope = rememberCoroutineScope()

    // Funkcja symulująca ciężkie obliczenia
    suspend fun generatePassword(): String {
        // Tu nadal jesteśmy na WĄTKU GŁÓWNYM!
        // delay tylko zawiesza korutynę, nie zmienia wątku.
        delay(3000) 
        return "Kotlin-Is-Super-Secure-123"
    }

    Column(...) {
        Button(onClick = {
            password = "Generowanie..."
            
            // 1. START: Jesteśmy na Main Thread (obsługa kliknięcia)
            // launch bez argumentów dziedziczy kontekst (tu: Main)
            scope.launch { 
                // 2. WNĘTRZE KORUTYNY: Nadal Main Thread.
                
                // 3. ASYNC: Uruchamia nową korutynę, ale
                // dziedziczy dispatcher od rodzica (czyli Main Thread).
                val deferredPassword: Deferred<String> = async { 
                    generatePassword() // Wykonanie funkcji na Main Thread
                }
                
                // 4. AWAIT: Zawiesza korutynę rodzica (na Main Thread).
                // UI nie jest zablokowane tylko dlatego, że użyliśmy 'delay',
                // który jest funkcją nieblokującą.
                // Gdyby generatePassword() liczyło hashe przez 3 sekundy (CPU), 
                // aplikacja by "zamarzła" (ANR).
                val result = deferredPassword.await()
                
                // 5. WZNOWIENIE: Nadal Main Thread. Aktualizacja UI.
                password = result
            }
        }) { Text("Wygeneruj hasło") }
    }
}

Wniosek: Cała operacja, od kliknięcia, przez async, aż po wynik, odbyła się na jednym i tym samym wątku (Main). Zadziałało to płynnie tylko dlatego, że delay jest funkcją zawieszającą. Gdybyśmy tam wstawili prawdziwą pracę procesora, UI uległoby zamrożeniu.

Drugi przykład z kucharzami pokazywał współbieżność (robienie dwóch rzeczy naraz). Czy oznacza to jednak równoległość (użycie wielu rdzeni)?

// 1. Szef Kuchni (Rodzic)
// scope.launch domyślnie używa Dispatchers.Main
scope.launch {
    // WĄTEK: Main Thread
    logs.add("Szef kuchni (rodzic): Zaczynamy")

    // 2. Zlecenie zadania Pomocnikowi 1
    // launch dziedziczy kontekst -> Dispatchers.Main
    val jobMieso = launch {
        // WĄTEK: Main Thread
        // Korutyna zawiesza się na wątku głównym, ustępując miejsca innym
        delay(2000) 
        logs.add("Kucharz 1: Mięso usmażone (2s).")
    }

    // 3. Zlecenie zadania Pomocnikowi 2
    // launch dziedziczy kontekst -> Dispatchers.Main
    val jobWarzywa = launch {
        // WĄTEK: Main Thread
        delay(3000) 
        logs.add("Kucharz 2: Warzywa gotowe (3s).")
    }

    // WĄTEK: Main Thread
    logs.add("Szef kuchni: Zadania zlecone...")

    // 4. Synchronizacja
    // join() to punkt zawieszenia na Main Thread.
    // Korutyna rodzica "czeka" (nie blokując wątku), aż dzieci skończą.
    jobWarzywa.join()
    jobMieso.join()

    // 5. Finał
    // WĄTEK: Main Thread
    logs.add("Szef kuchni: Wszyscy skończyli!")
}

Wniosek: Mimo że mamy trzy korutyny (Rodzic, Kucharz 1, Kucharz 2), wszystkie skaczą po tym samym wątku głównym.

Oczywiście, zarówno launch, jak i async przyjmują opcjonalny argument typu CoroutineContext, który pozwala jawnie wskazać dyspozytora.

// Możemy wymusić inny wątek w momencie startu
scope.launch(Dispatchers.IO) {
    // Teraz jesteśmy na wątku tła.
    // Dobre dla zapisu do pliku.
    saveToFile()
    
    // PROBLEM: Nie możemy stąd bezpiecznie dotknąć UI
    // textLabel.text = "Zapisano" // BŁĄD!
}

Choć jest to możliwe, w architekturze MVVM rzadko używamy tego podejścia bezpośrednio w warstwie UI. Powoduje to problemy z aktualizacją interfejsu (musimy ręcznie wracać na Main Thread) i utrudnia testowanie. Dlatego stosujemy podejście, w którym korutyna startuje na UI (żeby mieć do niego dostęp), a skacze na inne wątki tylko wtedy, gdy to konieczne.

Wyróżniamy dwa główne wzorce przełączania wątków, którymi zajmiemy się w tym rozdziale:

1. Podejście Imperatywne (withContext): Stosowane wewnątrz funkcji. Mówimy: Wykonaj ten fragment kodu na innym wątku i wróć do mnie z wynikiem.
2. Podejście Reaktywne (flowOn): Stosowane w strumieniach. Mówimy: Wszystkie dane powyżej tego punktu mają być produkowane na innym wątku.

Podejście Imperatywne: Bezpieczeństwo funkcji z withContext

Wróćmy do problemu blokowania UI. Wiemy już, że wywołanie trudnej obliczeniowo funkcji wewnątrz viewModelScope.launch zablokuje ekran.

Rozwiązaniem tego problemu w podejściu imperatywnym jest funkcja withContext:

1. Przyjmuje jako argument Dispatcher (np. Dispatchers.Default lub IO).
2. Zawiesza bieżącą korutynę (nie blokując wątku, z którego została wywołana).
3. Wykonuje blok kodu na wskazanym dyspozytorze.
4. Po zakończeniu pracy wznawia korutynę na pierwotnym dyspozytorze.
5. Zwraca wynik ostatniej linii bloku kodu (działa jak wyrażenie).

To sprawia, że kod wygląda na sekwencyjny, mimo że pod spodem następuje skomplikowane przełączanie wątków.

// Definicja funkcji Main-Safe (Bezpiecznej dla UI)
suspend fun performHeavyCalculation(): Int {
    // 1. Zmiana kontekstu na wątek obliczeniowy
    return withContext(Dispatchers.Default) {
        // 2. Symulacja ciężkiej pracy (np. przetwarzanie obrazu)
        // To nie zablokuje UI, mimo że funkcja 'sleep' normalnie blokuje wątek.
        // Blokujemy tu wątek roboczy, a nie główny.
        Thread.sleep(2000) 
        
        // 3. Obliczenie wyniku
        val result = 42 * 100 
        
        // 4. Zwrócenie wyniku (ostatnia linia)
        result 
    }
    // 5. Automatyczny powrót na wątek, z którego wywołano funkcję
}

// Użycie w ViewModelu
fun onCalculateClicked() {
    viewModelScope.launch { // Start na Main Thread
        _uiState.value = UiState.Loading // Aktualizacja UI
        
        // Wywołanie - tu korutyna się "zawiesza" na Main Thread
        // UI pozostaje responsywne (np. kręci się loader)
        val result = performHeavyCalculation()
        
        // Powrót na Main Thread z gotowym wynikiem
        _uiState.value = UiState.Success(result)
    }
}

Podejście Reaktywne: Bezpieczeństwo strumieni z flowOn

O ile withContext świetnie sprawdza się w funkcjach, które wchodzą i wychodzą, o tyle w przypadku strumieni (Flow) sytuacja jest bardziej złożona. Strumień to rurociąg, przez który dane płyną w czasie.

We Flow obowiązuje zasada: kod wewnątrz bloku flow { ... } wykonuje się w tym samym kontekście, w którym wywołano collect().

Ponieważ w Androidzie zazwyczaj zbieramy dane (collect) w warstwie widoku (Activity/Composable), która działa na wątku głównym, oznacza to, że domyślnie producent danych też działałby na wątku głównym.

// BŁĘDNE PODEJŚCIE
// Repository
val usersFlow = flow {
    // To wykona się na Main Thread, jeśli collect będzie na Main!
    // Spowoduje to zamrożenie UI przy każdym odczycie z bazy.
    val data = database.readUsers() // Operacja blokująca IO
    emit(data)
}

// ViewModel / UI
viewModelScope.launch { 
    // Zbieramy na Main Thread (domyślnie w viewModelScope)
    usersFlow.collect { show(it) } 
}

Aby zmienić wątek, na którym produkowane są dane, używamy operatora flowOn. Jego działanie jest specyficzne: zmienia on kontekst wykonania tylko dla operatorów znajdujących się powyżej niego (tzw. upstream).

// PRAWIDŁOWE PODEJŚCIE
val usersFlow = flow {
    // 1. To wykona się na Dispatchers.IO
    val data = database.readUsers()
    emit(data)
}.map { users -> 
    // 2. To też wykona się na Dispatchers.IO (bo jest powyżej flowOn)
    users.filter { it.isActive }
}.flowOn(Dispatchers.IO) // <--- GRANICA ZMIANY KONTEKSTU
.map { users ->
    // 3. To wykona się w kontekście odbiorcy (zazwyczaj Main)
    // Bo jest PONIŻEJ flowOn
    users.map { it.name }
}

Dzięki flowOn możemy bezpiecznie wykonywać operacje bazodanowe lub sieciowe w repozytorium, a wynik dostarczać gotowy do wyświetlenia na wątku UI.

Porównanie withContext i flowOn

Podsumujmy różnice między tymi dwoma mechanizmami:

Transformacja Strumieni

Zanim poznamy operator stateIn, musimy zrozumieć problem architektoniczny, który on rozwiązuje. Wymaga to przypomnienia fundamentalnej różnicy między strumieniami zimnymi a gorącymi oraz przeanalizowania cyklu życia aplikacji w Androidzie.

W Rozdziale 5 zdefiniowaliśmy dwa rodzaje strumieni. Spójrzmy na nie teraz z perspektywy wydajności:

• Zimny Strumień (Flow): To jest przepis na dane.
• Nie przechowuje danych.
• Kod wewnątrz bloku flow { ... } nie wykonuje się, dopóki ktoś nie zacznie nasłuchiwać (collect).
• Każdy nowy subskrybent powoduje ponowne wykonanie kodu producenta od początku.
• Gorący Strumień (StateFlow/SharedFlow): To jest gotowe danie na stole.
• Przechowuje dane (stan) w pamięci.
• Produkuje dane niezależnie od tego, czy ktoś ich słucha.
• Nowy subskrybent otrzymuje natychmiast aktualny stan (talerz z jedzeniem), bez konieczności gotowania wszystkiego od nowa.

W Androidzie zmiana konfiguracji (np. obrót ekranu, zmiana trybu jasny/ciemny) powoduje całkowite zniszczenie i odtworzenie Aktywności. Jeśli w warstwie UI nasłuchujemy na zimny strumień (zwykły Flow) pochodzący bezpośrednio z repozytorium, dochodzi do marnotrawstwa zasobów.

Prześledźmy ten scenariusz krok po kroku:

1. Użytkownik uruchamia ekran. Activity woła collect().
2. Zimny Flow startuje: Repozytorium łączy się z bazą danych, wykonuje zapytanie SQL, przetwarza wyniki. Dane trafiają na ekran.
3. Użytkownik obraca ekran.
4. Stare Activity jest niszczone -> collect() zostaje anulowany.
5. Nowe Activity jest tworzone -> woła nowe collect().
6. Zimny Flow startuje OD NOWA: Repozytorium znowu łączy się z bazą, znowu wykonuje to samo zapytanie SQL.

// --- REPOZYTORIUM ---
// Zimny strumień - kod w środku wykona się przy KAŻDEJ subskrypcji
fun getTasks(): Flow<List<Task>> = flow {
    println("Pobieram dane z bazy...") // To loguje się przy każdym obrocie!
    val tasks = database.queryAll()
    emit(tasks)
}

// --- VIEWMODEL (BŁĘDNE PODEJŚCIE) ---
// ViewModel tylko przekazuje zimny strumień dalej
val tasksFlow = repository.getTasks() // To nadal jest zimny Flow

Architektura MVVM daje nam idealne miejsce na rozwiązanie tego problemu. ViewModel przeżywa zmianę konfiguracji urządzenia.

Musimy więc:

1. Pobrać dane raz (uruchomić zimny strumień).
2. Przechować wynik w pamięci ViewModelu (zamienić w gorący stan).
3. Nowe Activity po obrocie powinno otrzymać dane z pamięci ViewModelu, zamiast uderzać do repozytorium.

Do tej transformacji służy operator stateIn, który omówimy w kolejnej sekcji.

Operatory stateIn i shareIn

Skoro wiemy już, że musimy zamienić zimny strumień (przepis) w gorący (danie), Kotlin dostarcza nam do tego dwa dedykowane operatory: stateIn oraz shareIn.

Operator stateIn zamienia dowolny Flow<T> w StateFlow<T>. Przypomnijmy, że StateFlow jest obserwowalnym pojemnikiem na dane, który zawsze posiada wartość. Dlatego operator ten wymaga podania wartości początkowej.

// ViewModel
val uiState: StateFlow<UiState> = repository.getDataStream()
    .map { data -> UiState.Success(data) } // Transformacja danych
    .stateIn(
        scope = viewModelScope, // 1. Gdzie strumień ma żyć?
        started = SharingStarted.WhileSubscribed(5000), // 2. Kiedy ma działać?
        initialValue = UiState.Loading // 3. Co pokazać na początku?
    )

Parametr started jest kluczowy dla oszczędzania zasobów. Najczęściej używaną strategią w Androidzie jest SharingStarted.WhileSubscribed(5000).

• Działanie: Utrzymuj połączenie ze źródłem (upstream) tak długo, jak ktoś nasłuchuje w UI.
• Timeout (5000 ms): Jeśli liczba subskrybentów spadnie do zera (np. użytkownik obrócił ekran i stare Activity zniknęło), nie zrywaj połączenia od razu. Poczekaj 5 sekund.

Zmiana konfiguracji często jest niemal natychmiastowa. Stare Activity znika (subskrybenci = 0), a chwilę później nowe Activity się pojawia (subskrybenci = 1).

• Dzięki opóźnieniu 5s, strumień nie zauważa tej krótkiej przerwy. Połączenie z bazą danych nie jest zrywane, a nowe Activity natychmiast dostaje dane z pamięci.
• Jeśli jednak użytkownik naciśnie przycisk Home i wyjdzie z aplikacji na dłużej niż 5 sekund - strumień zostanie zatrzymany, zwalniając zasoby (np. zamykając połączenie sieciowe).

Operator shareIn zamienia Flow<T> w SharedFlow<T>. Używamy go dla danych, które mają charakter zdarzeniowy (Events), a nie stanowy (State). Przykłady to: powiadomienia, toasty, sygnały nawigacyjne.

Różnice względem stateIn:

1. Nie wymaga wartości początkowej (zdarzenia nie muszą istnieć na starcie).
2. Pozwala konfigurować parametr replay (ile starych zdarzeń pamiętać dla nowych subskrybentów).

Wyobraźmy sobie strumień alertów z serwera. Chcemy, aby te alerty trafiały do wszystkich ekranów w aplikacji, ale nie chcemy, aby nowy ekran po otwarciu wyświetlał stare, nieaktualne komunikaty.

val notificationEvents: SharedFlow<String> = repository.getAlerts()
    .shareIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        replay = 0
    )

Gdybyśmy ustawili replay = 1, to każdy nowy ekran po otwarciu od razu dostałby ostatni komunikat.

Podsumujmy:

Łączenie danych: Operator combine

W aplikacjach stan ekranu (UI State) rzadko pochodzi z jednego źródła. Często musimy połączyć dane z dwóch lub więcej niezależnych strumieni.

Typowe scenariusze:

• E-commerce: Cena produktów (z Bazy) + Kod rabatowy (z Pola tekstowego).
• Profil: Dane użytkownika (z Sieci) + Ustawienia prywatności (z DataStore).
• Listy: Lista zadań (z Bazy) + Wybrany filtr kategorii (z ViewModela).

Do realizacji tego celu służy operator combine, który nasłuchuje na kilka strumieni jednocześnie. Jego działanie można porównać do formuły w arkuszu kalkulacyjnym (np. =A1+B1).

1. Czeka, aż wszystkie strumienie wyemitują pierwszą wartość (synchronizacja startowa).
2. Gdy którykolwiek ze strumieni wyemituje nową wartość, operator bierze tę nową wartość oraz ostatnie znane wartości z pozostałych strumieni.
3. Uruchamia blok lambda, w którym łączymy te dane w jeden obiekt wynikowy.

Załóżmy, że mamy repozytorium dostarczające aktualną sumę koszyka oraz pole tekstowe w ViewModelu, gdzie użytkownik wpisuje kod rabatowy.

class CartViewModel(repository: CartRepository) : ViewModel() {

    // 1. Strumień z repozytorium (np. z bazy danych)
    // Zmienia się rzadko (tylko gdy dodamy produkt)
    val cartTotalFlow: Flow<Double> = repository.getCartTotal()

    // 2. Strumień z pola tekstowego
    // Zmienia się często (przy każdym naciśnięciu klawisza)
    val promoCodeFlow = MutableStateFlow("")

    // 3. Łączenie w jeden stan UI
    val uiState: StateFlow<CartUiState> = combine(
        cartTotalFlow,
        promoCodeFlow
    ) { total, code ->
        // Ta lambda wykonuje się, gdy zmieni się cena LUB kod
        
        val discount = if (code == "PROMO20") 0.20 else 0.0
        val finalPrice = total * (1.0 - discount)

        // Zwracamy obiekt stanu
        CartUiState(
            totalPrice = total,
            discountApplied = discount > 0,
            finalPriceToPay = finalPrice
        )
    }.stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        initialValue = CartUiState() // Stan początkowy (pusty)
    )
    
    fun onCodeChanged(code: String) {
        promoCodeFlow.value = code
    }
}

Dzięki combine, nasz UI jest w pełni reaktywny. Jeśli użytkownik wpisze poprawny kod, cena przeliczy się natychmiast. Jeśli w międzyczasie w tle przyjdzie aktualizacja ceny z bazy danych - cena również przeliczy się automatycznie, uwzględniając wpisany kod.

Pełne Przykłady Implementacji

Poniżej znajdują się kompletne kody źródłowe omawianych zagadnień, gotowe do przekopiowania do projektu.

Przykład 1: Bezpieczne obliczenia z withContext

Ten przykład pokazuje podejście imperatywne. Wykonujemy ciężką operację (symulacja renderowania wideo) na kliknięcie przycisku, nie blokując paska postępu na ekranie.

// 1. Definicja stanów UI (Sealed Interface)
sealed interface UiState {
    data object Idle : UiState                    
    data object Loading : UiState                 
    data class Success(val result: Int) : UiState 
}

// 2. ViewModel (Logika biznesowa)
class CalculationViewModel : ViewModel() {

    private val _uiState = MutableStateFlow<UiState>(UiState.Idle)
    val uiState: StateFlow<UiState> = _uiState.asStateFlow()

    fun onCalculateClicked() {
        viewModelScope.launch {
            _uiState.value = UiState.Loading

            val result = performHeavyCalculation()

            _uiState.value = UiState.Success(result)
        }
    }

    private suspend fun performHeavyCalculation(): Int {
        return withContext(Dispatchers.Default) {
            Thread.sleep(2000) 
            42 * 100
        }
    }
}

// 3. Widok (Composable)
@Composable
fun CalculationScreen(viewModel: CalculationViewModel = viewmodel()) {
    val state by viewModel.uiState.collectAsStateWithLifecycle()

    Box(
        modifier = Modifier.fillMaxSize(),
        contentAlignment = Alignment.Center
    ) {
        Column(
            horizontalAlignment = Alignment.CenterHorizontally,
            verticalArrangement = Arrangement.spacedBy(16.dp)
        ) {
            // Reakcja na konkretny stan
            when (val currentState = state) {
                is UiState.Idle -> {
                    Text(text = "Gotowy do obliczeń")
                }
                is UiState.Loading -> {
                    CircularProgressIndicator()
                    Text(text = "Przetwarzanie...")
                }
                is UiState.Success -> {
                    Text(
                        text = "Wynik: ${currentState.result}"
                    )
                }
            }
            Button(
                onClick = { viewModel.onCalculateClicked() },
                enabled = state !is UiState.Loading
            ) {
                Text("Rozpocznij ciężką pracę")
            }
        }
    }
}

Przykład 2: Optymalizacja strumienia z flowOn

Ten przykład pokazuje podejście reaktywne. Przenosimy przetwarzanie danych strumieniowych (filtrowanie i sortowanie) na wątek tła, podczas gdy repozytorium i widok pozostają czyste.

// 1. Model danych
data class User(val name: String, val isActive: Boolean)

// 2. Repository (Symulacja warstwy danych)
class UserRepository {
    // Funkcja zwraca "zimny" strumień (Cold Flow)
    fun fetchUsersFromDb(): Flow<List<User>> = flow {
        // SYMULACJA BLOKUJĄCEGO IO
        // Normalnie zablokowałoby to UI, gdyby nie flowOn
        Thread.sleep(2000) 
        
        val users = listOf(
            User("Anna Kowalska", true),
            User("Jan Nowak", false),
            User("Marek Zegarek", true),
            User("Zofia Samosia", true)
        )
        emit(users)
    }
}

class UserViewModel : ViewModel() {
    private val repository = UserRepository()

    val uiState: StateFlow<UiState> = repository.fetchUsersFromDb()
        .map { users -> users.filter { it.isActive }}
        .flowOn(Dispatchers.IO) // <--- GRANICA ZMIANY KONTEKSTU (Upstream na IO)
        .map { users ->
            // Ten map jest ZA flowOn, więc wykona się na kontekście kolektora (Main)
            UiState.Success(users.map { it.name.uppercase() }) as UiState
        }
        .onStart {
            // Emitujemy stan ładowania na początku subskrypcji
            emit(UiState.Loading)
        }
        .stateIn(
            scope = viewModelScope,
            started = SharingStarted.WhileSubscribed(5000),
            initialValue = UiState.Loading
        )
}

// Definicja stanów widoku
sealed interface UiState {
    data object Loading : UiState
    data class Success(val userNames: List<String>) : UiState
}

// 4. Widok (Composable)
@Composable
fun UserListScreen(viewModel: UserViewModel = viewModel()) {
    val state by viewModel.uiState.collectAsState()

    Box(modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
        when (val currentState = state) {
            is UiState.Loading -> {
                Column(horizontalAlignment = Alignment.CenterHorizontally) {
                    CircularProgressIndicator()
                    Spacer(modifier = Modifier.height(8.dp))
                    Text("Pobieranie bazy danych...")
                    Text("(Sprawdź Logcat)")
                }
            }
            is UiState.Success -> {
                LazyColumn(
                    modifier = Modifier.fillMaxSize(),
                    contentPadding = PaddingValues(16.dp)
                ) {
                    item {
                        Text(
                            "Aktywni Użytkownicy:",
                            modifier = Modifier.padding(bottom = 16.dp)
                        )
                    }
                    items(currentState.userNames) { name ->
                        Card(
                            modifier = Modifier
                                .fillMaxWidth()
                                .padding(vertical = 4.dp),
                            elevation = CardDefaults.cardElevation(defaultElevation = 2.dp)
                        ) {
                            Text(
                                text = name,
                                modifier = Modifier.padding(16.dp)                            )
                        }
                    }
                }
            }
        }
    }
}

Przykład 3: Łączenie strumieni danych z combine

// 1. Model Stanu UI
data class CartUiState(
    val baseTotal: Double = 0.0,
    val finalPrice: Double = 0.0,
    val discountApplied: Boolean = false,
    val currentCode: String = ""
)

// 2. Repository (Symulacja danych zewnętrznych)
class CartRepository {
    // Symuluje koszyk, który zmienia się w czasie
    fun getCartTotal(): Flow<Double> = flow {
        // Startowa cena koszyka
        emit(100.0) 
        
        // Po 5 sekundach symulujemy, że np. dodano produkt na innym urządzeniu
        delay(5000) 
        emit(200.0) // Cena rośnie. Combine automatycznie przeliczy wynik.
    }
}

// 3. ViewModel (Logika łączenia strumieni)
class CartViewModel : ViewModel() {
    private val repository = CartRepository()

    // Strumień 1: Cena z bazy danych (Read-only Flow)
    private val cartTotalFlow = repository.getCartTotal()

    // Strumień 2: Kod wpisywany przez usera (MutableStateFlow)
    private val promoCodeFlow = MutableStateFlow("")

    // Operator combine
    val uiState: StateFlow<CartUiState> = combine(
        cartTotalFlow,
        promoCodeFlow
    ) { total, code ->
        // Ta lambda uruchamia się, gdy zmieni się ALBO cena, ALBO kod
        
        // Logika biznesowa rabatu
        val isPromoValid = code.trim() == "PROMO20"
        val discount = if (isPromoValid) 0.20 else 0.0
        val finalPrice = total * (1.0 - discount)

        // Zwracamy nowy, połączony stan
        CartUiState(
            baseTotal = total,
            finalPrice = finalPrice,
            discountApplied = isPromoValid,
            currentCode = code
        )
    }.stateIn(
        scope = viewModelScope,
        started = SharingStarted.WhileSubscribed(5000),
        initialValue = CartUiState()
    )

    // Funkcja wywoływana z UI przy wpisywaniu tekstu
    fun onCodeChanged(newCode: String) {
        promoCodeFlow.value = newCode
    }
}

// 4. Widok (Composable)
@Composable
fun ShoppingCartScreen(viewModel: CartViewModel = viewModel()) {
    // UI reaguje na każdą zmianę w uiState (pochodzącą z dowolnego strumienia)
    val state by viewModel.uiState.collectAsStateWithLifecycle()

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(24.dp),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text("Twój Koszyk")
        
        Spacer(modifier = Modifier.height(32.dp))

        // Karta z podsumowaniem
        Card(
            elevation = CardDefaults.cardElevation(defaultElevation = 4.dp),
            modifier = Modifier.fillMaxWidth()
        ) {
            Column(modifier = Modifier.padding(16.dp)) {
                Row(
                    modifier = Modifier.fillMaxWidth(),
                    horizontalArrangement = Arrangement.SpaceBetween
                ) {
                    Text("Cena produktów:")
                    Text(
                      "${state.baseTotal} PLN", 
                      fontWeight = FontWeight.Bold
                    )
                }

                // Wiersz: Rabat
                if (state.discountApplied) {
                    Row(
                        modifier = Modifier.fillMaxWidth(),
                        horizontalArrangement = Arrangement.SpaceBetween
                    ) {
                        Text("Rabat (PROMO20):")
                        Text(
                          "-20%", 
                          fontWeight = FontWeight.Bold
                        )
                    }
                }

                Divider(modifier = Modifier.padding(vertical = 8.dp))

                // Wiersz: Suma końcowa
                Row(
                    modifier = Modifier.fillMaxWidth(),
                    horizontalArrangement = Arrangement.SpaceBetween
                ) {
                    Text("Do zapłaty:")
                    Text(
                        "${state.finalPrice} PLN", 
                    )
                }
            }
        }

        Spacer(modifier = Modifier.height(24.dp))

        // Pole tekstowe do wprowadzania kodu
        OutlinedTextField(
            value = state.currentCode,
            onValueChange = { viewModel.onCodeChanged(it) },
            label = { Text("Kod rabatowy") },
            placeholder = { Text("Wpisz: PROMO20") },
            singleLine = true,
            modifier = Modifier.fillMaxWidth(),
            isError = state.currentCode.isNotEmpty() && !state.discountApplied,
            supportingText = {
                if (state.currentCode.isNotEmpty() && !state.discountApplied) {
                    Text("Nieprawidłowy kod")
                } else if (state.discountApplied) {
                    Text("Kod przyjęty!", color = Color(0xFF2E7D32))
                }
            }
        )
    }
}

W poprzednich rozdziałach do przesyłania danych używaliśmy strumieni (Flow). Strumień działał jak radio: stacja nadawcza emitowała sygnał, a każdy, kto nastroił odbiornik (collect), otrzymywał te same dane.

Co jednak w sytuacji, gdy potrzebujemy precyzyjnej komunikacji jeden-do-jednego? Wyobraźmy sobie fabrykę: jedna maszyna produkuje śruby, a druga je pakuje. Każda śruba wyprodukowana przez maszynę A musi trafić do maszyny B. Nie chcemy, aby śruba zaginęła, ani żeby trafiła do dwóch paczek naraz. Do takich zadań Kotlin udostępnia osobny prymityw synchronizacyjny: Kanały (Channels).

Kanał (Channel) to koncepcyjnie taśmociąg łączący dwie korutyny.

• Nadawca (Producer): Wrzuca dane z jednej strony rury.
• Odbiorca (Consumer): Wyciąga dane z drugiej strony.