StateFlow ו-SharedFlow

‫StateFlow ו-SharedFlow הם Flow APIs שמאפשרים ל-Flows לשלוח עדכוני סטטוס בצורה אופטימלית ולשלוח ערכים לכמה צרכנים.

StateFlow

‫StateFlow הוא זרם ניתן לצפייה שמחזיק מצב ופולט את העדכונים של המצב הנוכחי והמצב החדש למאספים שלו. אפשר לקרוא את ערך המצב הנוכחי גם דרך המאפיין value. כדי לעדכן את הסטטוס ולשלוח אותו לתהליך, מקצים ערך חדש למאפיין value של המחלקה MutableStateFlow.

ב-Android, ‏ StateFlow מתאים מאוד לסוגים שצריכים לשמור על מצב ניתן לשינוי שניתן לצפייה.

בהמשך לדוגמאות מתוך Kotlin flows, אפשר לחשוף StateFlow מתוך LatestNewsViewModel כדי ש-View יוכל להאזין לעדכונים של מצב ממשק המשתמש, וכך מצב המסך ישמר באופן מובנה גם אחרי שינויים בהגדרות.

class LatestNewsViewModel(
    private val newsRepository: NewsRepository
) : ViewModel() {

    // Backing property to avoid state updates from other classes
    private val _uiState = MutableStateFlow(LatestNewsUiState.Success(emptyList()))
    // The UI collects from this StateFlow to get its state updates
    val uiState: StateFlow<LatestNewsUiState> = _uiState

    init {
        viewModelScope.launch {
            newsRepository.favoriteLatestNews
                // Update UI with the latest favorite news
                // Writes to the value property of MutableStateFlow,
                // adding a new element to the flow and updating all
                // of its collectors
                .collect { favoriteNews ->
                    _uiState.value = LatestNewsUiState.Success(favoriteNews)
                }
        }
    }
}

// Represents different states for the LatestNews screen
sealed class LatestNewsUiState {
    data class Success(val news: List<ArticleHeadline>) : LatestNewsUiState()
    data class Error(val exception: Throwable) : LatestNewsUiState()
}

המחולל הוא המחלקה שאחראית לעדכון של MutableStateFlow, וכל המחלקות שאוספות נתונים מ-StateFlow הן הצרכנים. בניגוד לתהליך קר שנבנה באמצעות הכלי flow, תהליך StateFlow הוא פעיל: איסוף נתונים מהתהליך לא מפעיל קוד של יצרן. StateFlow תמיד פעיל ונמצא בזיכרון, והוא הופך למועמד לאיסוף זבל רק כשאין יותר הפניות אליו משורש של איסוף זבל.

כשצרכן חדש מתחיל לאסוף נתונים מהזרימה, הוא מקבל את המצב האחרון בזרם ואת כל המצבים הבאים. אפשר לראות את ההתנהגות הזו במחלקות אחרות שאפשר לצפות בהן, כמו LiveData.

ה-View מאזין ל-StateFlow כמו בכל זרימה אחרת:

class LatestNewsActivity : ComponentActivity() {
    private val latestNewsViewModel: LatestNewsViewModel = TODO() // getViewModel()

    override fun onCreate(savedInstanceState: Bundle?) {
        // ...
        // Start a coroutine in the lifecycle scope
        lifecycleScope.launch {
            // repeatOnLifecycle launches the block in a new coroutine every time the
            // lifecycle is in the STARTED state (or above) and cancels it when it's STOPPED.
            repeatOnLifecycle(Lifecycle.State.STARTED) {
                // Trigger the flow and start listening for values.
                // Note that this happens when lifecycle is STARTED and stops
                // collecting when the lifecycle is STOPPED
                latestNewsViewModel.uiState.collect { uiState ->
                    // New value received
                    when (uiState) {
                        is LatestNewsUiState.Success -> showFavoriteNews(uiState.news)
                        is LatestNewsUiState.Error -> showError(uiState.exception)
                    }
                }
            }
        }
    }
}

כדי להמיר כל רצף לפונקציה StateFlow, משתמשים באופרטור הביניים stateIn.

‫StateFlow,‏ Flow ו-LiveData

יש דמיון בין StateFlow לבין LiveData. שניהם הם מחלקות של בעלי נתונים שניתנים לצפייה, ושניהם פועלים לפי דפוס דומה כשמשתמשים בהם בארכיטקטורת האפליקציה.

עם זאת, חשוב לזכור שאופן הפעולה של StateFlow שונה מזה של LiveData:

  • ב-StateFlow צריך להעביר מצב ראשוני ל-constructor, אבל ב-LiveData לא.
  • ‫LiveData.observe() מבטל את הרישום של הצרכן באופן אוטומטי כשהתצוגה עוברת למצב STOPPED, אבל איסוף נתונים מ-StateFlow או מכל תהליך אחר לא מפסיק את האיסוף באופן אוטומטי. כדי להשיג את אותה התנהגות, צריך לאסוף את הרצף מLifecycle.repeatOnLifecycleבלוק.

הפיכת רצפי פעולות קרים לחמים באמצעות shareIn

‫StateFlow הוא זרם פעיל – הוא נשאר בזיכרון כל עוד הזרם נאסף או כל עוד קיימות הפניות אחרות אליו משורש איסוף האשפה. אפשר להפוך זרימות קרות לחמות באמצעות האופרטור shareIn.

לדוגמה, אם משתמשים ב-callbackFlow שנוצר ב-Kotlin flows, במקום שכל מאסף ייצור flow חדש, אפשר לשתף את הנתונים שאוחזרו מ-Firestore בין המאספים באמצעות shareIn. צריך להעביר את הפרטים הבאים:

  • CoroutineScope שמשמש לשיתוף התהליך. ההיקף הזה צריך להיות פעיל למשך זמן ארוך יותר מכל צרכן, כדי שרצף הפעולות המשותף יישאר פעיל כל עוד צריך.
  • מספר הפריטים להפעלה חוזרת לכל מאסף חדש.
  • המדיניות בנושא התנהגות בתחילת הסשן.

class NewsRemoteDataSource(
    private val externalScope: CoroutineScope
) {
    val latestNews: Flow<List<ArticleHeadline>> = flow {
        // ...
    }.shareIn(
        externalScope,
        replay = 1,
        started = SharingStarted.WhileSubscribed()
    )
}

בדוגמה הזו, הפריט האחרון שמועבר בזרם latestNews מועבר מחדש אל מאגר חדש, והזרם נשאר פעיל כל עוד externalScope פעיל ויש מאגרי נתונים פעילים. מדיניות ההתחלה SharingStarted.WhileSubscribed()שומרת על הפעילות של היצרן במעלה הזרם כל עוד יש מנויים פעילים. יש מדיניות הפעלה אחרת, כמו SharingStarted.Eagerly כדי להפעיל את המפיק באופן מיידי או SharingStarted.Lazily כדי להתחיל לשתף אחרי שהמנוי הראשון מופיע ולשמור על התהליך פעיל לנצח.

SharedFlow

הפונקציה shareIn מחזירה SharedFlow, זרם פעיל שפולט ערכים לכל הצרכנים שאוספים ממנו נתונים. ‫SharedFlow הוא הכללה של StateFlow שניתנת להגדרה במידה רבה.

אפשר ליצור SharedFlow בלי להשתמש ב-shareIn. לדוגמה, אפשר להשתמש ב-SharedFlow כדי לשלוח סימני זמן לשאר האפליקציה, כך שכל התוכן יתרענן באופן קבוע באותו הזמן. בנוסף לאחזור החדשות האחרונות, יכול להיות שתרצו לרענן את קטע פרטי המשתמש עם אוסף הנושאים המועדפים עליו. בקטע הקוד הבא, רכיב TickHandler חושף רכיב SharedFlow כדי שרכיבים אחרים ידעו מתי לרענן את התוכן שלו. בדומה ל-StateFlow, משתמשים במאפיין גיבוי מסוג MutableSharedFlow בכיתה כדי לשלוח פריטים לזרימה:

// Class that centralizes when the content of the app needs to be refreshed
class TickHandler(
    private val externalScope: CoroutineScope,
    private val tickIntervalMs: Long = 5000
) {
    // Backing property to avoid flow emissions from other classes
    private val _tickFlow = MutableSharedFlow<Unit>(replay = 0)
    val tickFlow: SharedFlow<Unit> = _tickFlow

    init {
        externalScope.launch {
            while (true) {
                _tickFlow.emit(Unit)
                delay(tickIntervalMs)
            }
        }
    }
}

class NewsRepository(
    // ...
    private val tickHandler: TickHandler,
    private val externalScope: CoroutineScope
) {
    init {
        externalScope.launch {
            // Listen for tick updates
            tickHandler.tickFlow.collect {
                refreshLatestNews()
            }
        }
    }

    suspend fun refreshLatestNews() { /* ... */ }
    // ...
}

אפשר להתאים אישית את ההתנהגות של SharedFlow בדרכים הבאות:

  • ‫replay מאפשרת לשלוח מחדש מספר ערכים שנשלחו בעבר למנויים חדשים.
  • ‫onBufferOverflow מאפשרת לכם לציין מדיניות לגבי המצב שבו המאגר מלא בפריטים שצריך לשלוח. ערך ברירת המחדל הוא BufferOverflow.SUSPEND, שגורם להשעיה של המתקשר. אפשר גם להשתמש באפשרויות DROP_LATEST או DROP_OLDEST.

‫MutableSharedFlow כולל גם מאפיין subscriptionCount שמכיל את מספר האוספים הפעילים, כדי שתוכלו לבצע אופטימיזציה של הלוגיקה העסקית בהתאם. ‫MutableSharedFlow מכיל גם פונקציה resetReplayCache אם לא רוצים להפעיל מחדש את המידע האחרון שנשלח לזרימה.

מקורות מידע נוספים על תהליכי עבודה