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

ההעברה מ-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 מוגדר בהתאם למחזור החיים של היעד, והוא מתבטל כשהיעד מוסר מ-backstack. בדוגמה הבאה, כשמשתמש עובר למסך 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 כמקור מידע אמין

אפשר להשתמש ברכיב הקומפוזבילי 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 composable עבור רכיב הקריאה לפעולה המותאם אישית 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 הוא בעל מצב. 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: הוא נמצא ב-Composition או שהוא לא נמצא בה.

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

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

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

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

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

@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 מציעה לבניית ממשקי משתמש מותאמים.

גלילה מקוננת עם רכיבי View

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

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

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

WindowInsets תאימות עם Views

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

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

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

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