Om du ger dig in i reaktiv programmering med Kotlin har du förmodligen märkt att inte alla flöden beter sig på samma sätt. För de som är mindre bekanta betyder detta i grunden om flödet är "statiskt", det väntar på att någon ska anropa det, eller "dynamiskt", det pumpar konstant data även när ingen tittar på det. Att hantera detta effektivt är skillnaden mellan en blixtsnabb app och en som äter upp enhetens minne.
I den här artikeln ska vi gå in på hur man går från standard kalla dataströmmar till heta dataströmmar med hjälp av `stateIn` och `sharedIn` . Vi kommer inte bara att hålla oss till teorin; vi ska se hur man implementerar den i `ViewModel` och, viktigast av allt, hur man förhindrar att enhetstester blir en mardröm när data inte skickas som förväntat.
Förstå skillnaden mellan kalla och varma flöden
För att komma igång på rätt sätt är det viktigt att förstå att ett Cold Flow är som en låt på Spotify som börjar från början varje gång du trycker på play; det vill säga att varje samlare får sin egen oberoende datasekvens. De är idealiska för resurskrävande uppgifter som bara behöver utföras när någon lyssnar, till exempel en databasfråga.
Å andra sidan är Hot Flows mer som en radiostation: musiken spelas oavsett om du har radion på eller inte. Här delar flera prenumeranter samma dataström. Dessa är viktiga när du behöver hantera UI-tillståndet eller utlösa händelser som behöver nå flera delar av applikationen samtidigt.
StateFlow: Statens väktare
StateFlow är en typ av hotflow specialiserad på att underhålla tillstånd. Dess huvudsakliga funktion är att den alltid behåller det senaste värdet , vilket gör den till det perfekta verktyget för att ersätta de äldre LiveData-värdena i Android. För att den ska fungera krävs ett initialvärde i konstruktorn, vilket säkerställer att användargränssnittet alltid har något att visa.
När vi arbetar med en ViewModel använder vi vanligtvis ett privat MutableStateFlow för att ändra värdet internt och exponera ett publikt StateFlow så att vyn bara kan läsa det. Det är viktigt att komma ihåg att StateFlow kombinerar emissioner ; om värdena ändras för snabbt kan garbage collector hoppa över vissa mellanliggande tillstånd och bara ta emot det senaste, vilket är effektivt för användargränssnittet.
SharedFlow: Global evenemangssändare
Till skillnad från den tidigare metoden bibehåller inte SharedFlow ett standardnuvarande tillstånd. Istället används det för att sända händelser till flera prenumeranter . Tänk dig att du behöver meddela hela appen att en användare har loggat ut; ett SharedFlow är den ideala lösningen eftersom det låter dig konfigurera uppspelningen , vilket definierar hur många gamla värden som skickas till nya prenumeranter.
Dessutom erbjuder den omfattande kontroll över mottryck genom parametern onBufferOverflow . Du kan bestämma om sändaren ska pausas när bufferten är full, eller om du föredrar att kassera det äldsta eller nyaste objektet för att undvika att blockera programkörningen.
Transformera kalla flöden med stateIn och sharedIn
Ibland har vi ett kallt flöde som är väldigt dyrt att underhålla (som en permanent nätverksanslutning) och vi vill inte att varje prenumerant ska öppna en ny anslutning. Det är här stateIn- operatorn kommer in i bilden , som omvandlar ett kallt flöde till ett delat hett tillståndsflöde. Denna operator kräver en CoroutineScope och en startstrategi.
Konfigurationen av Delning påbörjad är nyckeln: Lazily Insamlingen börjar med den första prenumeranten och slutar inte, medan WhileSubscribed Det är det smartaste alternativet för Android, eftersom stoppar dataproduktionen när ingen lyssnar (till exempel när appen körs i bakgrunden), vilket sparar batteri och minne.
Om du behöver ett SharedFlow istället för ett StateFlow är operatorn att använda shareIn . Detta fungerar på liknande sätt men är mer flexibelt, vilket gör att du kan definiera exakt hur många element som ska skickas om till nya medlemmar i flödet med hjälp av replay- parametern.
Teststrategier för heta flöden
Att testa dessa flöden är knepigt. När testpersonen är flödets observatör är det bäst att skapa falska implementeringar från repositorier som genererar kontrollerade värden. Om modulen exponerar flödet kan vi använda funktioner som first() för att validera det första problemet eller toList() för ändliga flöden.
Ett vanligt problem med stateIn Det vill säga, om vi använder WhileSubscribedTestet kan misslyckas eftersom flödet inte aktiveras om det inte finns någon uppsamlare. För att åtgärda detta måste vi starta en tom samlare i backgroundScope av testet, vilket säkerställer att operatorn är aktiverad och uppdaterar värdena. För att förenkla processen rekommenderas användning av biblioteket. Turbine, vilket gör det möjligt att validera utsläpp sekventiellt och på ett mycket mer naturligt sätt.
- För StateFlows är rekommendationen att validera egenskapen direkt värde istället för att samla in flödet, vilket undviker problem med att kombinera snabba värden.
- Det är viktigt att använda Obegränsad testavsändare för att säkerställa att insamlingskorutinen är klar innan data utfärdas i testet.
Att bemästra övergången mellan kalla och varma dataflöden genom korrekt tillämpning av stateIn och sharedIn gör att du kan bygga mycket mer robusta Android-arkitekturer, optimera resursförbrukningen och säkerställa sömlös och lätttestad datasynkronisering mellan affärslogik och användargränssnittet. Dela denna information så att fler kan lära sig om den.