מדינה ו-Jetpack פיתוח נייטיב

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

כל האפליקציות ל-Android מציגות את המצב למשתמש. דוגמאות למצבים באפליקציות ל-Android:

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

בעזרת Jetpack Compose תוכלו לציין בבירור איפה ואיך אתם שומרים את המצב באפליקציית Android ומשתמשים בו. המדריך הזה מתמקד בקשר בין המצב לבין רכיבי ה-Composable, ובממשקי ה-API ש-Jetpack Compose מציע כדי לעבוד עם המצב בקלות רבה יותר.

מצב ויצירה

Compose הוא פונקציונלי, ולכן הדרך היחידה לעדכן אותו היא להפעיל את אותו composable עם ארגומנטים חדשים. הארגומנטים האלה מייצגים את מצב ממשק המשתמש. בכל פעם שמצב מתעדכן, מתבצעת הרכבה מחדש. כתוצאה מכך, ערכים כמו TextField לא מתעדכנים באופן אוטומטי כמו שהם מתעדכנים בתצוגות מבוססות-XML אופרטיביות. כדי שהמצב החדש יתעדכן בהתאם, צריך לציין אותו במפורש ב-composable.

@Composable
private fun HelloContent() {
    Column(modifier = Modifier.padding(16.dp)) {
        Text(
            text = "Hello!",
            modifier = Modifier.padding(bottom = 8.dp),
            style = MaterialTheme.typography.bodyMedium
        )
        OutlinedTextField(
            value = "",
            onValueChange = { },
            label = { Text("Name") }
        )
    }
}

אם מריצים את הקוד הזה ומנסים להזין טקסט, לא קורה כלום. הסיבה לכך היא שה-TextField לא מתעדכן בעצמו – הוא מתעדכן כשהפרמטר value שלו משתנה. הסיבה לכך היא האופן שבו פועלים הרכבת קובצי Compose ושינוי שלהם.

למידע נוסף על הרכבה ראשונית ועל הרכבה מחדש, קראו את המאמר חשיבה ב-Compose.

מצב ברכיבים קומפוזביליים

פונקציות מורכבות יכולות להשתמש ב-API‏ remember כדי לשמור אובייקט בזיכרון. ערך שמחושב על ידי remember מאוחסן ב-Composition במהלך היצירה הראשונית, והערך המאוחסן מוחזר במהלך היצירה מחדש. אפשר להשתמש ב-remember כדי לאחסן אובייקטים שניתן לשנות ואובייקטים שלא ניתן לשנות.

mutableStateOf יוצרת משתנה MutableState<T> שניתן למדידה, שהוא סוג שניתן למדידה שמשולב בסביבת זמן הריצה של compose.

interface MutableState<T> : State<T> {
    override var value: T
}

שינויים ב-value מפעילים יצירת קומפוזיציה מחדש של כל הפונקציות הניתנות ליצירה שמקריאות את value.

יש שלוש דרכים להצהיר על אובייקט MutableState ב-composable:

  • val mutableState = remember { mutableStateOf(default) }
  • var value by remember { mutableStateOf(default) }
  • val (value, setValue) = remember { mutableStateOf(default) }

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

כדי להשתמש בתחביר של הנציג by, נדרשים הייבוא הבאים:

import androidx.compose.runtime.getValue
import androidx.compose.runtime.setValue

אפשר להשתמש בערך שנשמר כפרמטר לרכיבים מורכבים אחרים, או אפילו כלוגיקת הצהרות כדי לשנות את הרכיבים המורכבים שיוצגו. לדוגמה, אם אתם לא רוצים להציג את הודאת הפתיחה אם השם ריק, תוכלו להשתמש במצב בהצהרה if:

@Composable
fun HelloContent() {
    Column(modifier = Modifier.padding(16.dp)) {
        var name by remember { mutableStateOf("") }
        if (name.isNotEmpty()) {
            Text(
                text = "Hello, $name!",
                modifier = Modifier.padding(bottom = 8.dp),
                style = MaterialTheme.typography.bodyMedium
            )
        }
        OutlinedTextField(
            value = name,
            onValueChange = { name = it },
            label = { Text("Name") }
        )
    }
}

אמנם remember עוזר לשמור את המצב במהלך קומפוזיציות מחדש, אבל המצב לא נשמר במהלך שינויים בהגדרות. לשם כך, צריך להשתמש בפקודה rememberSaveable. rememberSaveable שומר באופן אוטומטי כל ערך שאפשר לשמור ב-Bundle. לערכים אחרים, אפשר להעביר אובייקט שומר מותאם אישית.

סוגים אחרים של מצבים נתמכים

ב-Compose אין צורך להשתמש ב-MutableState<T> כדי לשמור מצב, הוא תומך בסוגי observable אחרים. לפני שקוראים סוג אחר של משתנה שניתן לצפות בו ב-Compose, צריך להמיר אותו ל-State<T> כדי שרכיבי Compose יוכלו לבצע קומפוזיציה מחדש באופן אוטומטי כשהמצב משתנה.

Compose מגיע עם פונקציות ליצירת State<T> מטיפים נפוצים של נתונים שאפשר לצפות בהם, שמשמשים באפליקציות ל-Android. לפני שמשתמשים בשילובים האלה, צריך להוסיף את הפריטים המתאימים, כפי שמתואר בהמשך:

  • Flow: collectAsStateWithLifecycle()

    collectAsStateWithLifecycle() אוסף ערכים מ-Flow באופן שמתחשב במחזור החיים, וכך מאפשר לאפליקציה לחסוך במשאבי האפליקציה. הוא מייצג את הערך האחרון שהופלט מ-Compose‏ State. מומלץ להשתמש ב-API הזה כדי לאסוף תהליכים באפליקציות ל-Android.

    התלות הבאה נדרשת בקובץ build.gradle (היא צריכה להיות בגרסה 2.6.0-beta01 ואילך):

Kotlin

dependencies {
      ...
      implementation("androidx.lifecycle:lifecycle-runtime-compose:2.8.7")
}

Groovy

dependencies {
      ...
      implementation "androidx.lifecycle:lifecycle-runtime-compose:2.8.7"
}
  • Flow: collectAsState()

    collectAsState דומה ל-collectAsStateWithLifecycle, כי גם היא אוספת ערכים מ-Flow ומעבירה אותם ל-Compose‏ State.

    משתמשים ב-collectAsState לקוד שלא תלוי בפלטפורמה במקום ב-collectAsStateWithLifecycle, שמוגבל ל-Android בלבד.

    אין צורך ביחסי תלות נוספים ל-collectAsState כי הוא זמין ב-compose-runtime.

  • LiveData: observeAsState()

    observeAsState() מתחילה לעקוב אחרי LiveData הזה ולהציג את הערכים שלו באמצעות State.

    התלות הבאה נדרשת בקובץ build.gradle:

Kotlin

dependencies {
      ...
      implementation("androidx.compose.runtime:runtime-livedata:1.7.5")
}

Groovy

dependencies {
      ...
      implementation "androidx.compose.runtime:runtime-livedata:1.7.5"
}

Kotlin

dependencies {
      ...
      implementation("androidx.compose.runtime:runtime-rxjava2:1.7.5")
}

Groovy

dependencies {
      ...
      implementation "androidx.compose.runtime:runtime-rxjava2:1.7.5"
}

Kotlin

dependencies {
      ...
      implementation("androidx.compose.runtime:runtime-rxjava3:1.7.5")
}

Groovy

dependencies {
      ...
      implementation "androidx.compose.runtime:runtime-rxjava3:1.7.5"
}

עם שמירת מצב לעומת ללא שמירת מצב

רכיב מורכב שמשתמש ב-remember כדי לאחסן אובייקט יוצר מצב פנימי, וכך הרכיב המורכב הופך לרכיב עם מצב. HelloContent הוא דוגמה לרכיב מורכב עם מצב (stateful) כי הוא שומר ומשנה את המצב שלו (name) באופן פנימי. האפשרות הזו יכולה להיות שימושית במצבים שבהם מבצע הקריאה לא צריך לשלוט במצב, ויכול להשתמש בו בלי לנהל את המצב בעצמו. עם זאת, רכיבים מורכבים עם מצב פנימי נוטים להיות פחות ניתנים לשימוש חוזר וקשה יותר לבדוק אותם.

רכיב ללא מצב הוא רכיב ללא מצב. דרך קלה להשיג מצב ללא שמירת מצב היא באמצעות העלאת המצב.

כשאתם מפתחים רכיבים מורכבים לשימוש חוזר, לעיתים קרובות אתם רוצים לחשוף גם גרסה עם שמירת מצב וגם גרסה ללא שמירת מצב של אותו רכיב מורכב. הגרסה עם מצב (stateful) נוחה למבצעי קריאה שלא אכפת להם מהמצב, והגרסה ללא מצב (stateless) נחוצה למבצעי קריאה שצריכים לשלוט במצב או להעביר אותו.

העלאת הרמה של מצב (state hoisting)

העלאת המצב ב-Compose היא דפוס של העברת המצב למבצע הקריאה של ה-composable כדי להפוך את ה-composable ללא מצב. התבנית הכללית להעברת המצב לחלק העליון של הקוד ב-Jetpack Compose היא להחליף את משתנה המצב בשני פרמטרים:

  • value: T: הערך הנוכחי שרוצים להציג
  • onValueChange: (T) -> Unit: אירוע שמבקש לשנות את הערך, כאשר T הוא הערך החדש המוצע

עם זאת, אין הגבלה על onValueChange. אם אירועים ספציפיים יותר מתאימים לתוכן הקומפוזיציה, צריך להגדיר אותם באמצעות פונקציות lambda.

למצבים שמאוחזרים בצורה הזו יש כמה מאפיינים חשובים:

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

בדוגמה, מחלצים את name ואת onValueChange מ-HelloContent ומעבירים אותם למעלה בעץ, ל-HelloScreen composable שמפעיל את HelloContent.

@Composable
fun HelloScreen() {
    var name by rememberSaveable { mutableStateOf("") }

    HelloContent(name = name, onNameChange = { name = it })
}

@Composable
fun HelloContent(name: String, onNameChange: (String) -> Unit) {
    Column(modifier = Modifier.padding(16.dp)) {
        Text(
            text = "Hello, $name",
            modifier = Modifier.padding(bottom = 8.dp),
            style = MaterialTheme.typography.bodyMedium
        )
        OutlinedTextField(value = name, onValueChange = onNameChange, label = { Text("Name") })
    }
}

כשמרימים את המצב מ-HelloContent, קל יותר להבין את הרכיב הניתן לקיבוץ, לעשות בו שימוש חוזר במצבים שונים ולבדוק אותו. HelloContent מנותקת מהאופן שבו המצב שלה מאוחסן. משמעות הניתוק היא שאם משנים או מחליפים את HelloScreen, לא צריך לשנות את אופן ההטמעה של HelloContent.

התבנית שבה המצב יורד והאירועים עולים נקראת זרימת נתונים חד-כיוונית. במקרה כזה, המצב יורד מ-HelloScreen ל-HelloContent והאירועים עולים מ-HelloContent ל-HelloScreen. כשפועלים לפי זרימת נתונים חד-כיוונית, אפשר לנתק בין רכיבי ה-Composable שמוצגים במצב בממשק המשתמש לבין החלקים באפליקציה שמאחסנים את המצב ומשנים אותו.

מידע נוסף זמין בדף איפה להעביר את המצב.

שחזור המצב ב-Compose

ממשק ה-API של rememberSaveable מתנהג באופן דומה ל-remember כי הוא שומר את המצב במהלך יצירת קומפוזיציות מחדש, וגם במהלך יצירת מחדש של פעילות או תהליך באמצעות מנגנון שמירת המצב של המכונה. לדוגמה, זה קורה כשמסובבים את המסך.

דרכים לאחסון מצב

כל סוגי הנתונים שנוספים ל-Bundle נשמרים באופן אוטומטי. אם אתם רוצים לשמור משהו שלא ניתן להוסיף ל-Bundle, יש כמה אפשרויות.

חלוקה למקטעים

הפתרון הפשוט ביותר הוא להוסיף את ההערה @Parcelize לאובייקט. האובייקט הופך לניתן לחלוקה, וניתן לקבץ אותו בחבילה. לדוגמה, הקוד הזה יוצר סוג נתונים City שניתן לחלוקה ומאחסן אותו במצב.

@Parcelize
data class City(val name: String, val country: String) : Parcelable

@Composable
fun CityScreen() {
    var selectedCity = rememberSaveable {
        mutableStateOf(City("Madrid", "Spain"))
    }
}

MapSaver

אם מסיבה כלשהי השדה @Parcelize לא מתאים, אפשר להשתמש בשדה mapSaver כדי להגדיר כלל משלכם להמרת אובייקט לקבוצת ערכים שהמערכת יכולה לשמור בשדה Bundle.

data class City(val name: String, val country: String)

val CitySaver = run {
    val nameKey = "Name"
    val countryKey = "Country"
    mapSaver(
        save = { mapOf(nameKey to it.name, countryKey to it.country) },
        restore = { City(it[nameKey] as String, it[countryKey] as String) }
    )
}

@Composable
fun CityScreen() {
    var selectedCity = rememberSaveable(stateSaver = CitySaver) {
        mutableStateOf(City("Madrid", "Spain"))
    }
}

ListSaver

כדי שלא תצטרכו להגדיר את המפתחות למפה, תוכלו גם להשתמש ב-listSaver ולהשתמש באינדיקטורים שלו כמפתחות:

data class City(val name: String, val country: String)

val CitySaver = listSaver<City, Any>(
    save = { listOf(it.name, it.country) },
    restore = { City(it[0] as String, it[1] as String) }
)

@Composable
fun CityScreen() {
    var selectedCity = rememberSaveable(stateSaver = CitySaver) {
        mutableStateOf(City("Madrid", "Spain"))
    }
}

מאגרי המצבים ב-Compose

אפשר לנהל העברת מצב פשוטה בפונקציות הניתנות ליצירה עצמה. עם זאת, אם כמות המצבים שצריך לעקוב אחריהם גדלה, או אם צריך לבצע לוגיקה בפונקציות שניתנות ליצירה, מומלץ להעביר את האחריות על הלוגיקה והמצב לכיתות אחרות: מחזקי מצב.

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

הפעלה מחדש של חישובי הזיכרון כשהמקשים משתנים

משתמשים לעיתים קרובות ב-API של remember יחד עם MutableState:

var name by remember { mutableStateOf("") }

כאן, השימוש בפונקציה remember מאפשר לערך MutableState לשרוד תוך כדי יצירת קומפוזיציות מחדש.

באופן כללי, remember מקבל פרמטר lambda‏ calculation. כשהפונקציה remember מופעלת בפעם הראשונה, היא מפעילה את הפונקציה calculation מסוג lambda ושומרת את התוצאה שלה. במהלך הרכבת מחדש, הפונקציה remember מחזירה את הערך שנשמר בפעם האחרונה.

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

val brush = remember {
    ShaderBrush(
        BitmapShader(
            ImageBitmap.imageResource(res, avatarRes).asAndroidBitmap(),
            Shader.TileMode.REPEAT,
            Shader.TileMode.REPEAT
        )
    )
}

remember מאחסן את הערך עד שהוא יוצא מה-Composition. עם זאת, יש דרך לבטל את התוקף של הערך ששמור במטמון. ממשק ה-API remember מקבל גם פרמטר key או keys. אם אחד מהמפתחות האלה ישתנה, בפעם הבאה שהפונקציה תעבור ריבונדינג, remember תבטל את התוקף של המטמון ותריץ שוב את בלוק הלוגריתם לחישוב. המנגנון הזה מאפשר לכם לשלוט במחזור החיים של אובייקט ב-Composition. החישוב יישאר תקף עד שהנתונים המזינים ישתנו, במקום עד שהערך שנשמר יוצא מה-Composition.

בדוגמאות הבאות מוסבר איך המנגנון הזה עובד.

בקטע הקוד הזה נוצר רכיב ShaderBrush שמשמש כצבע הרקע של רכיב Box שמורכב. המכונה remember שומרת את המכונה ShaderBrush כי יקר ליצור אותה מחדש, כפי שהוסבר למעלה. הפונקציה remember מקבלת את הערך avatarRes כפרמטר key1, שהוא תמונת הרקע שנבחרה. אם avatarRes משתנה, המברשת מורכבת מחדש עם התמונה החדשה ומוחלת מחדש על Box. המצב הזה יכול לקרות כשהמשתמש בוחר תמונה אחרת לרקע מבורר.

@Composable
private fun BackgroundBanner(
    @DrawableRes avatarRes: Int,
    modifier: Modifier = Modifier,
    res: Resources = LocalContext.current.resources
) {
    val brush = remember(key1 = avatarRes) {
        ShaderBrush(
            BitmapShader(
                ImageBitmap.imageResource(res, avatarRes).asAndroidBitmap(),
                Shader.TileMode.REPEAT,
                Shader.TileMode.REPEAT
            )
        )
    }

    Box(
        modifier = modifier.background(brush)
    ) {
        /* ... */
    }
}

בקטע הקוד הבא, המצב מועבר לכיתה פשוטה של מחזיק מצב MyAppState. הוא חושף את הפונקציה rememberMyAppState כדי לאתחל מכונה של הכיתה באמצעות remember. חשיפת פונקציות כאלה כדי ליצור מכונה ששרדה קומפוזיציות מחדש היא דפוס נפוץ ב-Compose. הפונקציה rememberMyAppState מקבלת את הערך windowSizeClass, שמשמשת כפרמטר key של remember. אם הפרמטר הזה ישתנה, האפליקציה תצטרך ליצור מחדש את הכיתה של מחזיק המצב הפשוט עם הערך העדכני. מצב כזה יכול לקרות, למשל, אם המשתמש מסובב את המכשיר.

@Composable
private fun rememberMyAppState(
    windowSizeClass: WindowSizeClass
): MyAppState {
    return remember(windowSizeClass) {
        MyAppState(windowSizeClass)
    }
}

@Stable
class MyAppState(
    private val windowSizeClass: WindowSizeClass
) { /* ... */ }

Compose משתמש בהטמעה של equals בכיתה כדי להחליט אם מפתח השתנה ולבטל את התוקף של הערך המאוחסן.

אחסון מצב באמצעות מפתחות מעבר ליצירה מחדש

ה-API של rememberSaveable הוא מעטפת של remember שיכולה לאחסן נתונים ב-Bundle. ה-API הזה מאפשר לשמור את המצב לא רק אחרי יצירת מחדש, אלא גם אחרי יצירת מחדש של פעילות וסיום תהליך ביוזמת המערכת. rememberSaveable מקבל פרמטרים של input לאותו מטרה שבה remember מקבל את keys. המטמון לא תקף כשאחד מהקלטים משתנה. בפעם הבאה שהפונקציה תעבור עיבוד מחדש, rememberSaveable מריץ מחדש את בלוק הלוגריתם של החישוב.

בדוגמה הבאה, המשתנה rememberSaveable שומר את הערך של userTypedQuery עד ש-typedQuery משתנה:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}

מידע נוסף

למידע נוסף על סטטוס ו-Jetpack Compose, תוכלו לעיין במקורות המידע הנוספים הבאים.

דוגמיות

Codelabs

סרטונים

בלוגים