העברת תצוגות XML ל-Jetpack Compose

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

שלבים בהעברה

  1. יצירת תוכנית: יוצרים תוכנית מפורטת ומקיפה לביצוע ההעברה. מומלץ ליצור רשימת מטלות להעברה לפי סדר עדיפויות.
  2. זיהוי קובץ ה-XML שמועמד להעברה : מתחילים עם הרכיבים הכי קטנים שהם צמתי עלים בהיררכיה, ומרחיבים את תוכנית ההעברה מלמטה למעלה לרכיבים גבוהים יותר בהיררכיה. מועמדים טובים להעברה ראשונית הם קטנים, חסרי מצב (stateless) ויש להם פחות תלות.
  3. ניתוח ההיררכיה: אחרי שמזהים את תצוגת ה-XML שרוצים להעביר, צריך לנתח את מבנה הפריסה וההטמעה של ה-XML.
  4. צילום המצב ההתחלתי: מריצים בדיקת צילום מסך כדי לצלם את המצב ההתחלתי של תצוגת ה-XML שנבחרה.
  5. דרישה מוקדמת: הגדרת יחסי תלות ב-Compose צריך לבדוק אם בפרויקט הוגדרו יחסי תלות ב-Compose והקומפיילר. אם לא, פועלים לפי ההוראות להגדרת יחסי תלות של Compose ו-Compiler.
  6. דרישה מוקדמת: הגדרת ערכות נושא ב-Compose צריך לבדוק אם כבר הוגדרה ערכת נושא ב-Compose בפרויקט. אם לא, צריך לפעול לפי ההוראות בנושא יצירת ערכות עיצוב. שומרים על העיצוב המקורי בפורמט XML בזמן שהאפליקציה נמצאת במצב פעולה הדדית. כאן מוסבר איך להעביר עיצוב בפורמט XML ל-Compose כדי להבין דפוסים של מצב ועד שהפרויקט עובר באופן מלא ל-Compose.
  7. העברת תצוגת ה-XML ל-Compose: מתחילים בהמרה של קוד ה-XML ל-Compose, מחילים את העיצוב המתאים ומוסיפים תצוגות מקדימות של Compose לרכיבים שניתן להגדיר שהועברו. לתרחישי העברה נפוצים, אפשר לעיין במקורות מידע נוספים. לדוגמה, כדי לעבור ל-Lazy APIs ב-Compose, פועלים לפי השלבים במאמר העברה של RecyclerView ל-Compose.
  8. החלפת השימושים: מחליפים את השימושים הקודמים בתצוגת ה-XML כדי להשתמש ברכיב החדש של Compose. כדי להוסיף פיתוח נייטיב ב-Views, פועלים לפי השלבים במאמר פיתוח נייטיב ב-Views. כדי להוסיף Views ב-Compose, פועלים לפי השלבים שמפורטים במאמר בנושא Views ב-Compose.
  9. אימות ההעברה: מוודאים שהמצב הראשוני שצולם בבדיקת צילום המסך זהה לתצוגה המקדימה של רכיב ה-Composable שהועבר. אם יש הבדלים, צריך לבצע איטרציה בממשק המשתמש החדש שניתן להרכבה ולשפר אותו כך שיתאים למצב הראשוני. יוצרים בדיקות חדשות של ממשק המשתמש של Compose עבור הרכיב החדש שניתן להרכבה.
  10. הסרת XML: אחרי שהקומפוזיציה החדשה שהועברה תואמת לממשק המשתמש הראשוני ב-XML, מסירים את קוד התצוגה ב-XML שיצא משימוש ואת הבדיקות שלו.

תרחישי העברה נפוצים

מוודאים שנעשה שימוש בתוספים dp ו-sp (16.dp, 20.sp) בקומפוזיציות. אם tools:text מופיע בתצוגת ה-XML, צריך להשתמש בו ברכיב @Preview נפרד שניתן להגדיר.

שיוך המרה למשנה

רוב מאפייני ה-XML הופכים לחלק משרשרת modifier או פרמטרים של הפונקציה הניתנת להרכבה.

מאפיין XML Compose Equivalent
android:layout_width="match_parent" Modifier.fillMaxWidth()
android:layout_height="match_parent" Modifier.fillMaxHeight()
android:layout_width="wrap_content" (התנהגות ברירת מחדל, בדרך כלל לא נדרש שינוי)
android:padding="Xdp" Modifier.padding(X.dp)
android:layout_margin="Xdp" Modifier.padding(X.dp) (ריווח חיצוני)
android:gravity="center" ‫contentAlignment = Alignment.Center (Box) או horizontalAlignment / verticalArrangement (Column/Row)
android:background="@color/white" Modifier.background(colorResource(R.color.white))
android:visibility="gone" עטיפה בבלוק if (visible) { ... }

העברת סגנונות (styles.xml)

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

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

  • תבנית: אם רכיב XML משתמש בסגנון מותאם אישית (לדוגמה, style="@style/MyPrimaryButton"), אל תנסו לשכפל את הסגנון בשורה. במקום זאת, מציעים ליצור קומפוננטה ספציפית.
  • דוגמה:
    • ‫XML: <Button style="@style/MyPrimaryButton" ... />
    • כתיבת הודעה: MyPrimaryButton(onClick = { ... })
  • קבוצות נפוצות של מאפיינים: אם סגנון מגדיר משנים נפוצים (כמו padding + height), כדאי לחלץ אותם למאפיין תוסף קריא או למשתנה Modifier משותף.