שיקולים נוספים

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

העברת העיצוב של האפליקציה

‫Material Design היא מערכת העיצוב המומלצת לעיצוב של אפליקציות ל-Android.

באפליקציות מבוססות-תצוגה, יש שלוש גרסאות של Material:

  • ‫Material Design 1 באמצעות הספרייה AppCompat (כלומר, Theme.AppCompat.*)
  • ‫Material Design 2 באמצעות ספריית MDC-Android (כלומר Theme.MaterialComponents.*)
  • ‫Material Design 3 באמצעות ספריית MDC-Android (כלומר Theme.Material3.*)

באפליקציות Compose, יש שתי גרסאות של Material:

  • ‫Material Design 2 באמצעות ספריית Compose Material (כלומר androidx.compose.material.MaterialTheme)
  • ‫Material Design 3 באמצעות הספרייה Compose Material 3 (כלומר androidx.compose.material3.MaterialTheme)

מומלץ להשתמש בגרסה העדכנית ביותר (Material 3) אם מערכת העיצוב של האפליקציה שלכם מאפשרת זאת. יש מדריכי העברה שזמינים גם ל-Views וגם ל-Compose:

כשיוצרים מסכים חדשים ב-Compose, בלי קשר לגרסה של Material Design שבה משתמשים, חשוב להקפיד להחיל MaterialTheme לפני כל קומפוזיציה שיוצרת ממשק משתמש מהספריות של Compose Material. רכיבי Material‏ (Button, ‏Text וכו') תלויים ב-MaterialTheme, וההתנהגות שלהם לא מוגדרת בלעדיו.

כל הדוגמאות של Jetpack Compose מבוססות על עיצוב מותאם אישית של Compose שנבנה על MaterialTheme.

מידע נוסף זמין במאמרים מערכות עיצוב ב-Compose והעברת עיצובים בפורמט XML ל-Compose.

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

בדיקת ממשק המשתמש המשולב של כתיבה ותצוגות

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

כשמשתמשים ב-Compose בפעילות או בקטע, צריך להשתמש ב-createAndroidComposeRule במקום ב-ActivityScenarioRule. ‫createAndroidComposeRule משולב עם ActivityScenarioRule ComposeTestRule שמאפשר לבדוק את הקוד של כתיבת ההודעה ואת הקוד של הצגת ההודעה בו-זמנית.

class MyActivityTest {
    @Rule
    @JvmField
    val composeTestRule = createAndroidComposeRule<MyActivity>()

    @Test
    fun testGreeting() {
        val greeting = InstrumentationRegistry.getInstrumentation()
            .targetContext.resources.getString(R.string.greeting)

        composeTestRule.onNodeWithText(greeting).assertIsDisplayed()
    }
}
AddingComposeToYourAppSnippets.kt

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

שילוב של Compose בארכיטקטורת האפליקציה הקיימת

דפוסי ארכיטקטורה של זרימת נתונים חד-כיוונית (UDF) פועלים בצורה חלקה עם Compose. אם האפליקציה משתמשת בסוגים אחרים של תבניות ארכיטקטורה, כמו Model View Presenter ‏ (MVP), מומלץ להעביר את החלק הזה בממשק המשתמש ל-UDF לפני או במהלך ההטמעה של Compose.

שימוש ב-ViewModel בכתיבת אימייל

אם משתמשים בספרייה Architecture Components ViewModel, אפשר לגשת אל ViewModel מכל קומפוננטה שניתנת להרכבה על ידי קריאה לפונקציה viewModel(), כמו שמוסבר במאמר Compose וספריות אחרות.

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

לדוגמה, אם רכיבי ה-Composable מתארחים בפעילות, הפונקציה viewModel() תמיד מחזירה את אותו מופע, שמתנקה רק כשהפעילות מסתיימת. בדוגמה הבאה, אותו משתמש (user1) מקבל הודעת ברוכים הבאים פעמיים כי נעשה שימוש חוזר באותו מופע של GreetingViewModel בכל הרכיבים הניתנים להרכבה שמתחת לפעילות המארחת. המופע הראשון של ViewModel שנוצר נמצא בשימוש חוזר ברכיבים קומפוזביליים אחרים.

class GreetingActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            MaterialTheme {
                Column {
                    GreetingScreen("user1")
                    GreetingScreen("user2")
                }
            }
        }
    }
}

@Composable
fun GreetingScreen(
    userId: String,
    viewModel: GreetingViewModel = viewModel(  
        factory = GreetingViewModelFactory(userId)  
    )
) {
    val messageUser by viewModel.message.observeAsState("")
    Text(messageUser)
}

class GreetingViewModel(private val userId: String) : ViewModel() {
    private val _message = MutableLiveData("Hi $userId")
    val message: LiveData<String> = _message
}

class GreetingViewModelFactory(private val userId: String) : ViewModelProvider.Factory {
    @Suppress("UNCHECKED_CAST")
    override fun <T : ViewModel> create(modelClass: Class<T>): T {
        return GreetingViewModel(userId) as T
    }
}
ComposeExistingArchSnippets.kt

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

@Composable
fun MyApp() {
    NavHost(rememberNavController(), startDestination = "profile/{userId}") {
        /* ... */
        composable("profile/{userId}") { backStackEntry ->
            GreetingScreen(backStackEntry.arguments?.getString("userId") ?: "")
        }
    }
}
ComposeExistingArchSnippets.kt

מקור מידע אמין לגבי מצב

כשמשתמשים ב-Compose בחלק אחד של ממשק המשתמש, יכול להיות ש-Compose וקוד המערכת של View יצטרכו לשתף נתונים. במקרים שבהם הדבר אפשרי, מומלץ להשתמש במצב המשותף הזה בתוך מחלקה אחרת שפועלת לפי השיטות המומלצות של UDF שמשמשות את שתי הפלטפורמות. לדוגמה, במחלקה ViewModel שחושפת זרם של הנתונים המשותפים כדי לשלוח עדכוני נתונים.

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

‫Compose כמקור מידע אמין

משתמשים ב-composable‏ SideEffect כדי לפרסם מצב של Compose בקוד שאינו Compose. במקרה כזה, מקור האמת נשמר בקומפוזיציה ששולחת עדכוני סטטוס.

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

@Composable
fun rememberFirebaseAnalytics(user: User): FirebaseAnalytics {
    val analytics: FirebaseAnalytics = remember {
        FirebaseAnalytics()
    }

    // On every successful composition, update FirebaseAnalytics with
    // the userType from the current User, ensuring that future analytics
    // events have this metadata attached
    SideEffect {
        analytics.setUserProperty("userType", user.userType)
    }
    return analytics
}
MigrationOtherConsiderationsSnippets.kt

מידע נוסף זמין במאמר בנושא תופעות לוואי ב-Compose.

הצגת המערכת כמקור מידע מהימן

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

בדוגמה הבאה, הרכיב CustomViewGroup מכיל את הרכיבים TextView ו-ComposeView עם הרכיב TextField שניתן להרכבה בתוכם. ה-TextView צריך להציג את התוכן שהמשתמש מקליד ב-TextField.

class CustomViewGroup @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyle: Int = 0
) : LinearLayout(context, attrs, defStyle) {

    // Source of truth in the View system as mutableStateOf
    // to make it thread-safe for Compose
    private var text by mutableStateOf("")

    private val textView: TextView

    init {
        orientation = VERTICAL

        textView = TextView(context)
        val composeView = ComposeView(context).apply {
            setContent {
                MaterialTheme {
                    TextField(value = text, onValueChange = { updateState(it) })
                }
            }
        }

        addView(textView)
        addView(composeView)
    }

    // Update both the source of truth and the TextView
    private fun updateState(newValue: String) {
        text = newValue
        textView.text = newValue
    }
}
ComposeExistingArchSnippets.kt

העברה של ממשק משתמש משותף

אם אתם עוברים בהדרגה ל-Compose, יכול להיות שתצטרכו להשתמש ברכיבי ממשק משותפים גם ב-Compose וגם במערכת View. לדוגמה, אם לאפליקציה יש רכיב מותאם אישית CallToActionButton, יכול להיות שתצטרכו להשתמש בו גם במסכים מבוססי-Compose וגם במסכים מבוססי-View.

ב-Compose, רכיבי ממשק משתמש משותפים הופכים לפונקציות שאפשר להשתמש בהן שוב באפליקציה, בלי קשר לשאלה אם הרכיב עוצב באמצעות XML או שהוא תצוגה מותאמת אישית. לדוגמה, אפשר ליצור CallToActionButtonרכיב שאפשר להרכיב ממנו רכיבים אחרים עבור רכיב מותאם אישית של קריאה לפעולהButton.

כדי להשתמש ב-composable במסכים מבוססי-תצוגה, צריך ליצור wrapper של תצוגה בהתאמה אישית שמתרחב מ-AbstractComposeView. בפונקציה הקומפוזבילית Content שהוגדרה כברירת מחדל, צריך להציב את הפונקציה הקומפוזבילית שיצרתם, עטופה בעיצוב של Compose, כמו בדוגמה הבאה:

@Composable
fun CallToActionButton(
    text: String,
    onClick: () -> Unit,
    modifier: Modifier = Modifier,
) {
    Button(
        colors = ButtonDefaults.buttonColors(
            containerColor = MaterialTheme.colorScheme.secondary
        ),
        onClick = onClick,
        modifier = modifier,
    ) {
        Text(text)
    }
}

class CallToActionViewButton @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyle: Int = 0
) : AbstractComposeView(context, attrs, defStyle) {

    var text by mutableStateOf("")
    var onClick by mutableStateOf({})

    @Composable
    override fun Content() {
        YourAppTheme {
            CallToActionButton(text, onClick)
        }
    }
}
ComposeExistingUISnippets.kt

שימו לב שהפרמטרים שאפשר להרכיב הופכים למשתנים שניתנים לשינוי בתוך התצוגה המותאמת אישית. כך אפשר להגדיר את התצוגה המותאמת אישית CallToActionViewButton כמתנפחת ושימושית, כמו תצוגה רגילה. דוגמה לשימוש ב-View Binding:

class ViewBindingActivity : ComponentActivity() {

    private lateinit var binding: ActivityExampleBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityExampleBinding.inflate(layoutInflater)
        setContentView(binding.root)

        binding.callToAction.apply {
            text = getString(R.string.greeting)
            onClick = { /* Do something */ }
        }
    }
}
ComposeExistingUISnippets.kt

אם הרכיב המותאם אישית מכיל מצב שניתן לשינוי, כדאי לעיין במאמר בנושא מקור האמת של המצב.

קביעת סדר עדיפויות להפרדה בין מצב לבין הצגה

באופן מסורתי, View הוא stateful. View מנהל שדות שמתארים מה להציג, בנוסף לאיך להציג את זה. כשממירים View ל-Compose, כדאי להפריד את הנתונים שמוצגים כדי להשיג זרימת נתונים חד-כיוונית, כפי שמוסבר בהמשך במאמר בנושא state hoisting.

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

לעומת זאת, קל להציג ב-Compose רכיבים שונים לחלוטין באמצעות לוגיקה מותנית ב-Kotlin:

@Composable
fun MyComposable(showCautionIcon: Boolean) {
    if (showCautionIcon) {
        CautionIcon(/* ... */)
    }
}
MigrationOtherConsiderationsSnippets.kt

מבחינת העיצוב, CautionIcon לא צריך לדעת או להתעניין למה הוא מוצג, ואין מושג של visibility: הוא נמצא בקומפוזיציה או שהוא לא נמצא בה.

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

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

לרכיבי View יש בדרך כלל מושג לגבי המיקום שלהם: בתוך Activity, ‏Dialog, ‏Fragment או בתוך היררכיה אחרת של View. מכיוון שהם לרוב מנופחים מקובצי פריסה סטטיים, המבנה הכללי של View נוטה להיות נוקשה מאוד. התוצאה היא צימוד הדוק יותר, וקשה יותר לשנות או לעשות שימוש חוזר בView.

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

הבעיה הזו פחות משמעותית ב-Compose עם קומפוזיציות שאפשר לעשות בהן שימוש חוזר. ההורים יכולים לציין בקלות מצב וקריאות חוזרות (callbacks), כך שאפשר לכתוב קומפוזיציות לשימוש חוזר בלי לדעת בדיוק איפה הן ישמשו.

@Composable
fun AScreen() {
    var isEnabled by rememberSaveable { mutableStateOf(false) }

    Column {
        ImageWithEnabledOverlay(isEnabled)
        ControlPanelWithToggle(
            isEnabled = isEnabled,
            onEnabledChanged = { isEnabled = it }
        )
    }
}
MigrationOtherConsiderationsSnippets.kt

בדוגמה שלמעלה, כל שלושת החלקים יותר מבודדים ופחות מצומדים:

  • ‫ImageWithEnabledOverlay צריך לדעת רק מה המצב הנוכחי של isEnabled, הוא לא צריך לדעת ש-ControlPanelWithToggle קיים, או אפילו איך אפשר לשלוט בו.

  • ControlPanelWithToggle לא יודע שImageWithEnabledOverlay קיים. יכול להיות שיהיו אפס, דרך אחת או יותר להצגת isEnabled, וControlPanelWithToggle לא ישתנה.

  • להורה לא משנה כמה רכיבי ImageWithEnabledOverlay או ControlPanelWithToggle מוטמעים. הילדים האלה יכולים להנפיש שינויים, להחליף תוכן או להעביר תוכן לילדים אחרים.

הדפוס הזה נקרא היפוך שליטה, ואפשר לקרוא עליו עוד במסמכי CompositionLocal.

טיפול בשינויים בגודל המסך

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

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

גלילה מקוננת עם Views

מידע נוסף על הפעלת יכולת פעולה הדדית של גלילה מקוננת בין רכיבי View שאפשר לגלול בהם ורכיבי Composables שאפשר לגלול בהם, שמקוננים בשני הכיוונים, זמין במאמר יכולת פעולה הדדית של גלילה מקוננת.

כתיבת אימייל ב-RecyclerView

הקומפוזבלים ב-RecyclerView הם בעלי ביצועים טובים מגרסה 1.3.0-alpha02 של RecyclerView. כדי לראות את ההטבות האלה, צריך לוודא שאתם משתמשים לפחות בגרסה 1.3.0-alpha02 של RecyclerView.

WindowInsets תאימות עם Views

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

לדוגמה, אם הפריסה החיצונית ביותר היא פריסת View ב-Android, צריך להשתמש ב-insets במערכת View ולהתעלם מהם ב-Compose. לחלופין, אם הפריסה החיצונית ביותר היא קומפוזיציה, צריך להשתמש ב-insets ב-Compose, ולשנות את הריווח של הקומפוזיציות בהתאם.AndroidView

כברירת מחדל, כל ComposeView צורך את כל ההנחות ברמת הצריכה WindowInsetsCompat. כדי לשנות את התנהגות ברירת המחדל הזו, מגדירים את ComposeView.consumeWindowInsets לערך false.

מידע נוסף זמין במאמר בנושא WindowInsets בכתיבת הודעות.